בדיקות אוטומטיות בסביבות עבודה אג'יליות

​ליאור כץ, מנהל כלי בדיקות אוטומטיות וביצועים, טאקט בדיקות

אנחנו שם, עולם פיתוח התוכנה צועד בצעדי ענק לעבוד בסביבות אג'יליות, ואנחנו אנשי הטסטים האוטומטיים צריכים להתיישר ולהתאים את עצמנו לקידמה...
 
כמה נושאים מאוד מעניינים בהקשר זה יידונו בכתבה
 
מה עושים כשהחברה שלנו יום בהיר אחד מחליטה לעבור לעבוד במוד אג'ילי? איך מחלקים נכון את הצוות בתוך האירגון? לאן לוקחים את הצוות מטרות\ציפיות? איך זה משפיע על חברי צוות האוטומציה? איך מנהלים צוות אוטומציה בסביבות אג'יליות? האם משנים מתודולוגיות עבודה (פיתוח ניהול) שהיינו רגילים עליהם, או שאנחנו  ממשיכים כרגיל? תמיד לימדו אותנו שטסטים אוטומטיים זה בהקשר של בדיקות רגרסיה, עכשיו הדגש הוא לא על בדיקות רגרסיה מה עושים איך ממקדים את הצוות?
 
Testing Automation ROI – איפה בסביבה אג'ילית מרוויחים הכי הרבה מבדיקות אוטומטיות?
 
כל השאלות האלה עלו בראשי ביום שעברנו לעבוד מסביבות Water Fall הישן, הידוע (ואפשר לאמר גם הטוב J) למוד אג'ילי, זה לא סוד שפלטפורמת העבודה האג'ילית פתוחה לשינויים וגמישה לפי צרכי האירגון, ולכן עד היום לא מצאתי מקום מסודר בוא יש הוראות הפעלה מדויקות לניהול צוות אוטומציה בסביבות אג'יליות, יותר נכון כשכל החברה מסתדרת בקבוצות Scrum קטנות צוות הבדיקות הידניות מתחלק בין קבוצות ה Scrum ויכולת הבדיקה המהירה נהיה דרוש יותר מאי פעם, השאלה האם לפזר את חברי צוות האוטומציה בין קבוצות ה Scrum היא כבר לא שאלה אלה תשובה, אבל רגע, גם מהפך כזה בצוות האוטומציה (חלוקה לקבוצות Scrum) צריך להעשות בזהירות ובחשיבה קדימה.
 
אז ככה במעבר למוד אג'ילי צוות הבדיקות האוטומטיות נעשה חשוב מאין כמותו מכיוון שהפיתוח נעשה מהיר הרבה יותר ממה שהיינו רגילים, ז"א התוצרים יוצאים הרבה יותר מהר ממה שהיינו רגילים ובפרקי זמן קצרים בהרבה, וכמובן קבוצת הבדיקות הידניות לא יכולה לתת מענה לכל דרישות ההרצות לכל קבוצת Scrum הרצת   Sanity & Regression, כמו כן בדיקה של הפונקציונאליות החדשה צריכה להיעשות בתדירות גבוהה הרבה יותר וקשורה לתוצרים היומיים (Build יומי וכו...), הסכמנו שהחשיבות של צוות הבדיקות האוטומטיות עולה כמה מונים במעבר למוד אג'ילי, על זה אין עוררין, בואו נראה איך מיישמים את זה...
 
בכדי להבין איך מיישמים את מתודולוגיית הניהול של צוותי הבדיקות האוטומטיות בארגונים שונים ראיינתי גם שניים מחברי הטובים מהתחום מאיר עוזיאל (דירקטור QA חברת Live Person), ושלומי זלמה (מנהל צוות בדיקות Load Runner)
 
אז מה עושים כשהחברה שלנו יום בהיר אחד מחליטה לעבור לעבוד במוד אג'ילי? איך מחלקים נכון את הצוות בתוך האירגון?
בדומה לצוותי הבדיקות הידניות איש האוטומציה הופך להיות חלק בלתי נפרד מקבוצת ה Scrum, ז"א אם הארגון שלי עכשיו מתחלק ל 3 קבוצות Scrum, צוות האוטומציה מחולק בין שלושת הקבוצות, כולל כל האחראיות של איש צוות מן המניין, השתתפות בכל שלבי הפרוייקט (Sprint planning, Development, Testing & product demo), רצוי מאוד להשאיר שלד של הצוות (איש צוות בכיר או ראש הצוות) להרצות כלליות ופיתוחים כלליים, ועכשיו אעשה סדר:

לאן לוקחים את הצוות מטרות\ציפיות?
עברנו לעבוד במוד אג'ילי, הבקרה יותר קשה המטרות יותר מסובכות, עכשיו זה לא רק אני ראש הצוות שיקבע האם חבר הצוות עמד ביעדים, מטרות הצוות הם קודם כל לעמוד במטרות יחד עם צוות ה Scrum, עכשיו הניהול מטרציוני לחלוטין, הבקרה על חברי הצוות נעשית בתיאום עם ה Scrum Master עם מנהל הפיתוח וה PMO, השליטה בתוכניות העבודה הם בידיים האמונות של חברי הצוות ולא שלך ראש צוות האוטומציה, כמובן שראש צוות האוטומציה הוא חלק בלתי נפרד מהתהליך, תפקידו להיות שותף מלא ומבקר מבחוץ.
 
זה בהחלט שינוי מהותי ותפיסתי, שבוא גם חברי הצוות:

ננסה להגדיר ביחד את מטרות אנשי האוטומציה לאחר מעבר למוד אג'ילי:

שימו לב שמהיום שבוא עברנו למוד עבודה אג'ילי אפשר להגדיר את מטרות הצוות אך המטרות מפורטות יותר ברמה פרטנית של אנשי הצוות.
 
איך זה משפיע על חברי צוות האוטומציה?
מה יותר לא יושבים ביחד כל הצוות? לא חולקים את הבעיות הטכניות ביחד? מי מנהל אותנו? ראש צוות האוטומציה? ה Scrum Master? מי מגדיר לנו את המשימות? להמשיך לעבוד במתודולוגיות העבודה שלנו?
 
אני חייב להודות שגם לי אישית עלו כל השאלות האלה בזמן קצר מאוד אחרי ששנים הורגלנו לעבוד ב Water fall בשיטה ריכוזית שהכל תחת שליטה רוב הצוות יושב באותו מקום ואפשר כמעט ב Gant אחד לשלוט בכל פעילות הצוות,
 
כמובן שיש פיתרון לכל השאלות שהועלו בתחילת סעיף זה, אך חשוב מאוד להדגיש!!! חייבים אבל חייבים להכין את הצוות למעבר, דבר ראשון חייבים בקרה מלאה על פעילות אנשי הצוות וזה אומר:

כמו כן צוות האוטומציה צריך להמשיך להפגש באופן רציף וייחודי לצוות, בכדי להעביר אינפורמציה נדרשת, ולשמור על מתודולוגיות עבודה קבועות באירגון, כדאי להשאיר חלק מצוות האוטומציה כעמוד שידרה שנותן תמיכה רוחבית ברמת האירגון (Regression and sanity execution)
 
ניהול צוות אוטומציה בסביבות אג'יליות?
כאמור כל הסוגיות שהעלנו למעלה, משפיעות על פעילות ותפקוד מנהל קבוצת האוטומציה, באספקט הניהולי ישנם כמה טיפים שחשוב לדבר עליהם:
 
מנהל צוות אוטומציה הופך להיות עמוד שידרה לצוות, מכמה אספקטים:

דרכי הניהול כמובן גמישות לפי התנהלות האירגון, ומשמעויות האוטומציה באירגון, הדגשים שנתנו למעלה יכולים להיות רלוונטיים לכל אירגון ובכל מקום בו עוברים לפלטפורמת עבודה אג'ילית,
 
האם משנים מתודולוגיות עבודה (פיתוח ניהול) שהיינו רגילים עליהם, או שאנחנו  ממשיכים כרגיל?
אמנם תקופת הפיתוח מתקצרת במעבר למוד עבודה אג'ילי, אנשי צוות האוטומציה מצטרפים לקבוצות ה scrum (ברוב המקרים) אך מתודולוגיית הכתיבה, וניהול פרוייקטי האוטומציה נשאר בעינו, זאת אומרת, שאם עד היום כל קבוצת האוטומציה פיתחה ע"פ מתודולוגיית פיתוח מסודרת, הפרוייקט נוהל ע"פ מתודולוגיה המתאימה לניהול פרוייקטי אוטומציה, אין שום סיבה שלא נשמר את דפוסי העבודה הקיימים בצוות
 
תמיד לימדו אותנו שטסטים אוטומטיים זה בהקשר של בדיקות רגרסיה, עכשיו הדגש הוא לא על בדיקות רגרסיה מה עושים איך ממקדים את הצוות?
תלוי בגודל הצוות, ראיתי אירגונים שצוות האוטומציה מונה 25 אנשי צוות, צוות כזה יכול להתפזר בצוותי ה scrum , ומשאירים גרעין מרכזי בכדי לתחזק את ה regression sets ולהרחיב אותם, כמובן שחלק מתפקיד איש האוטומציה בצוות ה Scrum הוא להריץ את ה regression וכמובן רוב עיסוקו לפתח במקביל לפיתוחים החדשים בקבוצת ה scrum
 
ROI – איפה בסביבה אג'ילית מרוויחים הכי הרבה מבדיקות אוטומטיות?
שאלת השאלות, כרגיל כמה שיותר הרצות נקבל ROI  גבוהה יותר, הרצות על Build ליילי בכדי להבין את תקינות ה Build יחזירו ROI במיידי, פיתוחים אוטומטיים ל API (איפה שאפשר) יחזירו ROI מהיר ביותר, וכמובן שימוש חוזר בבדיקות ה Regression, שימוש בכלים אוטומטיים ל data inflation ולתהליכים חוזרים ונשנים, הרצה ע"י בודקים יידניים ומפתחים, כל אלה יחזירו ROI גבוהה בסביבות אג'יליות.
 
עכשיו כמו שהבטחתי אני אתן לקולגות שלי לדבר ולספר כיצד פרקטית מיישמים את מתודולוגיית האג'ייל באספקט של טסטים אוטומטיים בשני אירגונים גדולים, ניסינו להתמקד בשאלות רלוונטיות ליישום המתודולוגיה
 
מאיר עוזיאל – מנהל מחלקת QA בחברת Live Person
 
קבוצת ה QA מונה מעל 30 אנשי QA מתוכם 8 אנשי אוטומציה
 
אודות LivePerson
חברת לייבפרסון היא מובילת שוק בפיתוח טכנולוגיות אינטראקציה עם גולשים בזמן אמת. בהתבסס על יכולות ניתוח מתקדמות של הרגלי פעילות גולשים ואפשרות להגיב במדיות השונות, עוזרת החברה ללקוחותיה לחזק את הקשר עם הלקוחות ולמקסם את אפשרויות השיווק, המכירה והתמיכה הטכנית. יותר מ- 8,500 חברות ביניהן Home Depot, British Telecom, HP, Apple , Microsoft,City Bank ו- Verizon סומכות על LivePerson למקסם את השפעת ערוצי התקשורת מול הלקוחות באינטרנט. משרדי החברה הראשיים בניו-יורק עם משרדים בסן-פרנסיסקו, אטלנטה, לונדון ותל-אביב.
 
1.       יישום – טסטים אוטומטיים בסביבות אג'ייל בחברת LP


a.       הכול מתחיל מהאנשים שהארגון מגייס לשורותיו. בחירת אנשי אוטומצייה נכונים מזווית הניסיון ומגוון היכולות.
 
                         i.      כאשר ניגשים לגיוס אנשי אוטומצייה, נראה שהכי פשוט להביא אנשים מנוסים, מקצועים    ועם הרבה ניסיון בכלי זה או אחר.  החוכמה היא לגייס ובעיקר להכשיר אנשי פיתוח בדיקות אוטומטיות ליצר את הבדיקות הנדרשות ואז להעביר אותם לאוטומצייה
 
                 Ii      .      ידע מוקדם בשפות פיתוח שונות יתן יתרון רב בבחירת פיתרונות אוטמציה שונים
b.      הטמעת אנשי אוטומציה בקבוצות ה crum


                                                         i.            ייעול עבודת צוות ה scrum בזמן sprint ע"י פיתוח בדיקות אוטומטיות בזמן פיתוח המוצר

                                                       ii.            הקטנת כמות הבדיקות הידניות בזמן regression שממתינות להמרה לבדיקות אוטומטיות

2.       ייתרונות הבדיקות האוטומטיות בסביבות אג'ייל מנקודת מבטו של מנהל ה .QA
 
a.     כדי לעבוד ב Scrum אמיתי חייבים סביבת פיתוח שנבדקת כל לילה על ידיי הרצה מלאה של כל
הבדיקות האוטומטיות הקיימות (unit tests and Automation scripts )
 
b.     כל הפיתוחים יתווספו לבדיקות ה Regression


3.       מסקנות עד היום – איפה צריך לשפר, מה אנחנו עושים הכי נכון ואם כן מה היית ממליץ לקולגות להשתמש?
 
a.       מציאת הדרך המהירה להמרת כל הטסטים הידנים של גירסאות קודמות לאוטומצייה, אם על ידי מיקור חוץ או על ידיי הוספת כוח אדם
 
b.      השיפור חייב להגיע בשני אזורים עיקרים:
 
   i.      שימוש גדול יותר בכלים שונים והורדת התלות בכלי זה או אחר.
 
   ii.      פיתוח מתודולוגיות אוטומטיות לשינוי סדר היום של הבודקים הידנים. מבדיקות ידניות, לבדיקות ידניות משולבות באוטומצייה שאותה יפעילו הבודקים עצמם, בכלים פשוטים לתפעול שלא דורשים יידע בפיתוח (שימוש ב Sellenium, Jmeeter)
 
4.       מבט לעתיד – הייבטים אירגוניים שצריך לשנות או לא, צוות אוטומציה מול צוות בדיקות ידניות בסביבה אג'ילית, התאמת מרקם העבודה האג'ילי לבדיקות האוטומטיות באספקטים מסוימים
 
      הפיכת היחס בודקים ידניים מול בודקים אוטומטיים. נכון להיום על כל שלושה בודקים ידניים יש לנו איש אוטומציה אחד, המטרה היא שעל כל שלושה אנשי אוטומציה יהיה איש בדיקות ידניות אחד מאחר והמורכבות והסיבוכיות של המוצר שלנו עולה, ולא נוכל לתת מענה ידני במחיר ובזמן הנדרש. 
 
שלומי זלמה - מנהל צוות בדיקות LoadRunner בחברת HP,  צוות הבדיקות אחראי להוציא מוצר תקין, ובאיכות גבוהה, תוך כדי שמירה על דיוק, Scalability, ותאימות לאחור.
 
אודות LoadRunner מבית HP
תוכנת HP LoadRunner מאפשרת לקבל תמונה מדויקת של ביצועי המערכת מקצה לקצה; לוודא כי יישומים חדשים או משודרגים עומדים בדרישות הביצועים, וכן לזהות, ולמנוע צווארי בקבוק במהלך הפיתוח ומחזור החיים של איכות התוכנה. בדיקות באמצעות הדמיית אלפי משתמשים וירטואליים לדמות תסריטי בדיקה אפשריים בסביבת הייצור

יישום  – טסטים אוטומטיים בסביבות אג'יליות
במהלך הספרינט השימוש בכלים האוטומטיים מתבצע בכל לילה, בבדיקת הבילד היומי והרצת ה Sanity הקיים, ריצות אלה מתבצעות באופן אוטומטי ע"י batch process, ואת התוצאות אנחנו מקבלים בבוקר למייל.
 
כל בילד רישמי שמתקבל מהפיתוח נבדק ע"י Mini Regression set ומשמש כ gate keeper לקבלה לתחילת בדיקות.
 
כיום אנו עובדים ליישם בדיקות אוטומטיות בעזרת API ויצירת בדיקות לפיתוחים חדשים במהלך הפיתוח.
חשוב לציין בכדי לישם את הבדיקות בעזרת ה API נדרש צוות הפיתוח לחשוב אוטומציה, ולעזור ביצירת סטים של הרצות API, אחת המטרות היא הרצה בזמן הפיתוח.
 
ייתרונות הבדיקות האוטומטיות בסביבות אג'ייל מנקודת מבטו של מנהל ה .QA
בסביבה אג'ילית בה אנחנו מתבקשים לתגובה מהירה והחלטות כגון האם הבילד כשיר ולדווח לפיתוח בזמן אמת כאשר יש בעיות, האוטומציה ממלאת את תפקיד ה gate keeper ולכן בדיקת sanity אוטומטית רצה על כל בילד שמעומד ל QA, אני כמנהלQA  יכול לדעת בצורה מאד מהירה אם המוצר עבר sanity E2E במידה ולא מנהל הפיתוח יקבל דיווח מיידי ממש בתחילת הsprint, וכך יהיה מספיק זמן לתקן בעיות בזמן פיתוח, מעבר לזה הצלחנו ליישם sanity שרץ אוטומטית לאחר כל בילד לילי ובכך לדווח בכל בוקר לפיתוח באם הקוד שפותח ייצר בעיות עוד הרבה לפני סיום הsprint.
 
מסקנות עד היום – איפה צריך לשפר, מה אנחנו עושים הכי נכון ואם כן מה היית ממליץ לקולגות להשתמש?
תגובה בזמן אמת ובזמן קצר, יישום אוטומציה בזמן פיתוח הקוד ומייד לאחר סיום הכתיבה, הרצות, כמו כן תוצאות מיידיות הרצות ע"י הפיתוח, והרחבת תסריטי הבדיקה בזמן הQA.a.       מה אנחנו עושים הכי נכון – יישום אוטמציה שרצה על בילד ליילי, ללא מגע יד אדם החל מהקמת מכונה, התקנת המוצר וכלי הבדיקה ולאחר מכן הרצה ודיווח במייל.b.       שיפור – ויתור על חבילות אוטומציה שלא מחזירות את עצמן מבחינת השקעה, באזורים בהם סביבות העבודה לא ייציבות ודרוש תחזוקה גבוהה, אין מקום לאוטומציהc.       המלצות –                                                                i.      לבחור את האנשים הנכונים בקבוצה לעסוק באוטומציה, אנשים בעלי אוריינטציה לפיתוח, ראייה מרחבית, ויכולת טכנית גבוהה                                                              ii.      לתת הערכות זמנים ראליות, ככל האפשר ולבחון ROI.                                                            iii.      והכי חשוב להוסיף זמן למחקר ולא ישר לקפוץ לפתח, חשוב לבצע מחקר מבחינת הבנת האזור המיועד איך הוא עובד, על איזה פלטפורמות, יש \ אין API, לבחון שימוש בכלים \ חבילות קיימות או ליצור מחדש

מבט לעתיד – הייבטים אירגוניים שצריך לשנות או לא, צוות אוטומציה מול צוות בדיקות ידניות בסביבה אג'ילית, התאמת מרקם העבודה האג'ילי לבדיקות האוטומטיות באספקטים מסוימים
במבט לעתיד, המטרה לפתח אוטומציה לדרישות חדשות במערכת, להיות מסוגל לעבוד במוד של תגובה מהירה, להיות קרוב יותר לפיתוח, ולאפשר לאנשי צוות הבדיקות ידניות להריץ טסטים אוטומטיים לפי דרישה. לדוגמה, כל אחראי תחום מסויים יריץ בדיקות אוטומטיות בתחום שלו וינתח את התוצאות ע"פ דרישה, שיקולים מקצועיים וידע רב בתחום.
 
חברים עכשיו אחרי שהבנו איך מטמיעים אוטומציה בסביבות אג'יליות, ואיך אמר אחד ממנהלי הQA  הבכירים בארץ "לא ניתן יהיה לבדוק את הפיתוחים החדשים ללא טסטים אוטומטיים"
 
המעבר לאג'ייל רק יגביר את השימוש בטסטים האוטומטיים ויעצים את ה ROI שאנחנו מקבלים
 
תודה ונפגש בפרוייקט האוטומציה הבא J
 
ליאור