Page 11 - מגזין HP Software | גיליון 2 - אוגוסט 2013

11
אוגוסט 3102
///
גיליון 2
///
HP Software
מגזין
מעמידים מספר אתגרים משמעותיים בפני Continuous Delivery / Continuous Integration ומגמת ה-MaaSפרויקט ה-
המוכר לנו. אנו נדרשים לספק פלטפורמה ואפליקציות יציבות בד בבד עם הצורך לשחרר גרסאות QAעולם ה-
הוא מינימאלי ביותר. דרישות אלו מצריכות חשיבה מחודשת ביחס Stabilizationבתדירות גבוהה, כאשר זמן ה-
לתהליכי הפיתוח והבדיקות המשמשים אותנו כיום, ובניית תשתית ותהליכי אוטומציה יציבים לאורך זמן.
הגדרנו תהליכי פיתוח ובדיקות המחייבים שיתוף פעולה של כל הגורמים: כדי לנסות ולהתמודד עם אתגרים אלו
בין התהליכים העיקריים שהוגדרו: .CI/CD- ו DEV, QA
. כך שגם ScrumTeam ותחת האחריות של ה-User Stories תהליך של כתיבת הטסטים ומימושם הם חלק מפיתוח ה- •
אחראי למימוש חלק של הטסטים.DEV
.CI מבלי שיש לו טסט שכתוב, מומש ורץ ב- Done-או לעבור ל Check-inלא יכול לעבור User Story •
נשאר ירוק.build, כך שכל מפתח אחראי לדואג שה-You break you fix itהגדרנו תהליכי פיתוח במתכונת - •
לבדוק את הקוד QA הוא לכתוב קוד ותפקיד ה-DEVתהליכים אלו הביאו לשינוי בתפישה המיושנת שתפקיד ה-
ירוק.build כולו לכתוב קוד איכותי שעובד ותמיד לדאוג ל-ScrumTeamולדאוג לאיכותו. בתהליך שיצרנו - אחריות ה-
- כדי תחזוקת טסטים מינימאלית .1 שני עקרונות מרכזיים הנחו אותנו בדרך לבניית תשתית אוטומציה יציבה:
-יכולת ניתוח מהירה של טסטים שנפלושרוב הזמן יושקע בפיתוח טסטים חדשים ולא בשכתוב טסטים ישנים. 2.
כך שלא נצטרך להשקיע זמן יקר בחקירת הנפילות.
Behavior Driven , שנתן בידינו מספר יתרונות. ראשית, הוא מבוססJBehave את האוטומציה בחרנו לבנות באמצאות
פשוט וקל להבנה; המאפשר לכולם הבנה של תפקוד הטסט, syntaxדבר שמאפשר כתיבת טסטים ב- Development (BDD)D
ניתן להגיע JBehave . שנית, עם End User וה-Use Caseללא צורך בכניסה לקוד. בנוסף, הטסט נבנה מנקודת מבט של ה-
.Selenium אנו עושים שימוש ב-UI; וב-REST ישרות מעל ה- JBehave לפתרון אחיד לצד הפלטפורמה שבה אנו מריצים
בתהליך זה, הטסטים כתובים בצורה כמה שיותר גנרית, תוך הטסטים האוטומטיים נבנו בתהליך פיתוח מודולארי.
מורכבים וגדולים User Flows של טסטסים כדי לבנות טסטים גדולים יותר המכסים )Re use(שנעשה שימוש חוזר
הפך לתהליך פשוט, לאור העובדה שהוא מורכב מהקוביות של E2E יותר. בפועל, יצרנו מצב שממימוש טסט
עצמו. פתרון זה טומן בחובו יתרון חשוב נוסף - צמצום זמן תיקון User Storyטסטים שכבר נבנו במהלך פיתוח ה-
או שדרוג הטסטים; באופן זה שינוי של מקומות בודדים מוביל לתיקון הטסטים כולם, תוך ייתור של המשימה
המייגעת בה נדרש לשכתב כל טסט וטסט.
לבסוף, תהליכים אלו ונוספים (שלא הוזכרו כאן מפאת קוצר היריעה) נותנים בידינו את היכולת להוציא מוצר
noach.kurtz@hp.com ● ארוכים לפני שחרור גרסאQAאיכותי, באופן מהיר, תוך חיסכון של תהליכי
מעמידים מספר Continuous Delivery / Continuous Integration ומגמת ה-MaaSפרויקט ה-
נח קורץ מספר על חידושים  המוכר לנו QAאתגרים משמעותיים בפני עולם ה-
בתהליכי הפיתוח והבדיקות המסורתיים, ובניית תשתית ותהליכי אוטומציה יציבים