מה עושה בודק האג'ייל בתחילת הספרינט?

- מכינים את הבדיקות ברמה הגבוהה יותר ומתקדם עם התקדמות הפיתוח.
- לומדים על הטכנולוגיה הקשורה לפיתוח.
- לומדים על אוטומציה, מפתחים אוטומציה לקוד קיים.
- לומדים על כלי performance.
- מוודאים שהקוד שנכתב הוא טסטבילי (כמו למשל הוצאת פרמטרים מחוץ לקבצים הבינריים בכדי שנוכל ל"שחק" איתם.
- לתכנן כלים שיעזרו בבדיקות.
- כמובן ללמוד יותר על בדיקות (ספרים, קורסים).
- לשפר תהליכים.

אג'ייל: האם יש לדווח על באגים במערכת ניטור?

בעד:

1. כבר רגילים, אין צורך ללמוד משהו חדש.

2. יש בבאג הרבה מידע (סביבות, לוגים, על מי הבאג, באיזה הקשר התגלה וכד').

3. נח להוסיף לו דברים כמו צילומי מסך.

4. שמירת מידע על באגים שתוקנו, נדע למשל מתי תוקנו ואיך במידה שהם חוזרים. או למשל אם באג התגלה כבר כ-invalid חוסך זמן לבודק לתעד שוב.

5. מדידות.

6. במקרה שיש כמה קבוצות ויכולה להיות השפעה הדדית. יחד עם זה תמיד עדיף לתקשר את הבאגים בשיחה.

7. אם מודדים באגים.

נגד:

1. צורך זמן.

2. הרבה באגים בכלל לא מתכוונים לתקן.

3. מספיק פתק פשוט עם הבאג והכנסת הסנריו לרגרסיות.

4. גם היום מפתחים בד"כ לא מכניסים בגים שהתגלו בקידוד.

5. ניתן לשמור מידע גם בדף FAQ.

6. מעודד פחות תקשורת ורבלית בין צוותים.

7. דורש טיפול רב: כתיבה, טריאג'ים, הסברים, שחזורים, הערות.

המטרות של הבדיקות - רבעוני בדיקות האג'ייל - מתי כיסינו את כל רבדי הבדיקות

עדיין מהספר Agile testing

אם נבין את המטרות של הבדיקות, נבין אילו סוגי בדיקות אנו צריכים ונבין מתי מיצינו את סוגי הבדיקות.

הסופרות של הספר הנ"ל מחלקות את הבדיקות לארבעה רבעים

שני הסוגים השמאליים הם בדיקות התומכות בפיתוח. בלשון הסופרות הכוונה בבדיקות שנעשות ביחד עם הפיתוח ועוזרות לו. בדיקות אלה הן ההבדל המהותי בבדיקות מסורתיות מול בדיקות אג'ייל סטייל.

הרבע הראשון הוא כולו אוטומטי ונקרא לפעמים TDD, test driven development. אלו בדיקות של קוד שנכתבות לעיתים טרם נכתב הקוד.

הבדיקות כוללות unit tests, בדיקת החלקים הבסיסיים ביותר במערכת, ובדיקות של כמה יחידות כאלה שנקראות component tests.

בדיקות הרבע השני גם תומכות בפיתוח, אך ברמה גבוהה יותר. בדיקות אלה נקראות גם business/customer-facing tests ובודקות את האיכות והפיצ'רים שהלקוח ביקש. כאן נבדק קוד שהלקוח איפיין. הבדיקות מדגימות את התנגדות התוכנה ברמה גבוהה.

מלבד בדיקות ה-UI, בדיקות אלו צריכות להיות אוטומאטיות.

למעשה התגובה האוטומטית המהירה של שני הרבעים הראשונים לאחר כל שינוי קוד היא מיסודות של קבוצת אג'ייל.

בדיקות שמבקרות את המוצר

ישנם אספקטים אחרים למוצר, חלקם אינם באים ישירות מדרישות הלקוח, כמו בדיקות security, יוזביליטי וכד'. עלינו להשתמש בבדיקות מסוג אחד בכדי לאתר את הבעיות.

הרבע השלישי בא להראות שזהו המוצר שהלקוח צריך (למרות שכביכול יש לנו כבר תוצאות של שני הרבעים הראשונים). הוא בודק אם המוצר עונה לדרישות ועומד בתחרות. כאן אנו מדמים משתמשים אמיתיים.

אלו בדיקות ידניות בלבד.

אלו בדיקות UAT, אקספלורטורי ויוזביליטי.

הרבע הרביעי הוא טכנולוגי שגם מבקר את המוצר, למשל:

בדיקת ביצועים

עמידות (robustness)

Security

בחלק מהמקרים בדיקות אלה צריכות להיעשות לפני כל שאר הבדיקות.

וזה הצ'קליסט כפי שמופיע בספר:

• Are we using unit and component tests to help us find the right design for our application?
• Do we have an automated build process that runs our automated unit tests for quick feedback?
• Do our business-facing tests help us deliver a product that matches customers’ expectations?
• Are we capturing the right examples of desired system behavior? Do we need more? Are we basing our tests on these examples?
• Do we show prototypes of UIs and reports to the users before we start coding them? Can the users relate them to how the finished software will work?
• Do we budget enough time for exploratory testing? How do we tackle usability testing? Are we involving our customers enough?
• Do we consider technological requirements such as performance and security early enough in the development cycle? Do we have the right tools to do “ility” testing?

המעבר הראשוני לאג'ייל - הקשיים וכיצד ניתן להתכונן מראש

הכתוב מטה הוא מעיין סיכום של הפרק השלישי ("שינויים אירגוניים) בספר Agile Testing*

הרבה מהצלחת המעבר לאג'ייל תלוי בתרבות האירגונית. גורם מעכב הוא למשל באם חלק מהאנשים הם בעלי ניסיון מר בעבודה באג'ייל. אם מתעלמים מהתרבות האירגונית המעבר עלול להיכשל.

יש לשים לב להלך הרוח של אנשים שעלולים לחשוש למשל מאיבוד עבודה. והחשש הוא רגש עצמתי.  חשש אחר הוא החשש לאיבוד הכח למשל של הבודקים כחלק מקבוצת בדיקות:

-          חשש שהם יאבדו את הזהות שלהם כבודקים.

-          חשש שהדיווח למנהל שהוא מפתח (ואני שואל: למה חייב שיהיה מפתח?) יגרום להם להיות בעדיפות נמוכה מאשר לשאר המפתחים.

-          חשש שאין להם הכישורים הנדרשים מבודקי אג'ייל.

-          שבקבוצת האג'ייל הבנויה ממפתחים לא יהיה מי שייתן להם תמיכה.

-          חשש שהם ומנהליהם ילכו לאיבוד בשיטת העבודה החדשה.

בכל ארגון יש להתייחס לפחדים אלה ואם צריך יש להביא מדריך מנוסה שיעזור בתהליך המעבר. יש להסביר שהפחד מהשינוי הוא טבעי.

בנוסף, לפי מתודולוגיית האג'ייל, אין אחראי איכות אחד, אלא כולם אחראי איכות, והבודק הוא גם אחראי איכות וגם בודק, כמו שהמפתח אחראי איכות ומפתח. קשה לעבור מתפקיד האחראי הבלעדי של הבדיקות לאחד מהאחראים.

למעשה האחריות של הבודק גדלה: בד"כ אין לו מנהל שהוא בודק תוכנה, ולכן התפקיד שלו גודל. יש יתרונות אבל גם חסרונות. על הבודק להיות מסוגל לשאול שאלות, להסביר דברים הקשורים לבדיקות לכאלה שאינם בודקים ולפעמים להגן על עמדותיו ועוד.

אם הארגון אוהב להשתפר באופן כלי הכניסה לאג'ייל תהיה קלה יותר.

בכדי להקל על הבודק כדאי שייכנס לצוות האג'ייל מתחילת הפרויקט ואם יש צורך להדריכו ע"י מדריך בדיקות אג'ייל מנוסה.

אחד השינויים הוא שבעבודת בדיקות מסורתית מצופה מהעובד שיעבוד עד לשעות מאוחרות בעת הוצאת גרסה ולעתים בסופי שבוע. באג'ייל הבודק נותן את המיטב לאורך הפיתוח ומבטל את ההתאמצות לקראת הסוף. בנוסף יש לקחת משימות ריאליות ללוחות הזמנים.

באג'ייל הלקוחות מוזמנים להשתתף בפיתוח, אם אפשר שנציג ישהה בסביבת הפיתוח. יש כאן יותר מן השותפות מאשר יחסי לקוח / מזמין העבודה. הבודק עובד צמוד ללקוח בכדי שיוכל לאפיין את ה-acceptance tests וידע מה חשוב ללקוח מבחינת איכות המוצר.

אם מתחילים בקבוצת אג'ייל אחת בארגון מסורתי, יש אתגרים המיוחדים למצב הזה. על כל הקבוצות, האג'ייל והמסורתיות, ללמוד להתגמש בכדי שיוכלו לעבוד האחת עם רעותה כשסדר העבודה שונה בתוכן, ולשתף מידע באופן תמידי. ואם אין דרכים מקובלות בכדי לקבל את מה שצריך, צריך להיות יצירתי.

על המנהלים להבין שצוות האג'ייל עובד בצורה שונה, ולתת לו את החופש הדרוש בכדי שיעבדו בצורה יצירתית. על צוות האג'ייל להגיע להסכמה על דרכי הפעולה שלהם. אפשר לנסות כיוונים שונים ולהמשיך עם אלו שנמצאו יעילים יותר.

בחברה גדולה מנהל הבדיקות יכול להיות מדריך שיכול לתת תמיכה ומידע לבודקים ויעזור להם לתקשר עם קבוצתם החדשה.

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

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

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

מנהלים באג'ייל לא עסוקים בניהול מקרו אלא יותר בהסרת מכשולים מהקבוצה

המעבר עלול להיות ארוך ומתסכל. בשל הקשיים הנ"ל, מומלץ לחגוג פורמלית כל הישג.

בכדי להצליח יש להיות סבלני. לפעמים לקבל את דעת הרוב גם אם לא נכונה וכשזו נכשלת להציע שוב את נקודת המבט שלך. תבנה לך שם בהדרגה. פתח את עצמך ע"י הליכה לכנסים, קריאת ספרים וכד'. אל תסגל את נקודת המבט של "משטרת האיכות" אלא היה חלק מקבוצה שהאיכות חשובה לכולם. אם ניסית את כל זה ולא הלך, אולי כדאי שתחשוב על מקום אחר.

Agile Testing, Lisa Crispin, Janet Gregory,  Addison-Wesley 2009

"למה הבדיקות לא מצאו את הבאג הזה בזמן?"

מפליא שעד היום, כשפיתוח התכנה כבר אינו דבר חדש ומקורות המידע הם כמעט אינסופיים, הדבר הבא עדיין קורה:
שכשנמצא באג באיחור, בין אם כשהמוצר עדיין לא שוחרר או אחרי שחרורו, בעלי תפקידים שואלים כדבר מובן מאיליו את השאלה הבאה:

"למה הבדיקות לא מצאו את הבאג הזה בזמן?"

בדרך כלל בטון מאשים, כועס, מאוכזב וצדקני.

למעשה, שאלה זו לא אמורה להישאל, כיוון שהיא בפועל מביכה את מי ששואל בהראותה שהוא או היא אינם מבינים את תהליך פיתוח התוכנה. בנוסף, אם מדובר במנהל ששואל את זה (אלא אם זה מנהל בדיקות), זה מצביע על העובדה שהוא לא מבין בסדרי עדיפויות.

בפעם הבאה שמישהו שומע את השאלה הזו, כדאי שיקח את זכות הדיבור ויאמר את הדברים הבאים:

• האם המוצר ומשתמשיו אינם יותר חשובים ממציאת האשם? האם העבודה כצוות מגובש לא חשובה יותר מעבודה של אחד-כנגד-השני?
  
• הדבר החשוב כרגע הוא רק אחד: לעבוד ביחד בכדי לפתור את הבעייה בצורה היעילה ביותר.
  
• וגם: הפקת לקחים הינו מאכל שאוכלים אותו כשהוא מוגש בטמפרטורת החדר, לא כשהוא מחומם (כן, כמו נקמה, להבדיל).

וכשמגיעים לחלק של הפקת הלקחים, גם לא שואלים "למה הבדיקות לא מצאו את הבאג הזה בזמן?", אלא את השאלות הבאות:

• איך אפשר לוודא שהדבר ייצויין בפירוש בדרישות של המוצר?
  
  - רלוונטי למשל אם הבאג קרה בתחום "אפל" שלא היה מצויין בדרישות, כמו למשל תיאור של ההתנהגות אצל משתמשים חדשים היה אך פוספסה ההתנהגות שהיא שונה בעדכון המוצר.



• איך אפשר לוודא שהדבר ייצויין בפירוש בדיזיין של הפיתוח?
  
  - רלוונטי למשל אם לא היה פירוט מלא של תהליך מסויים ולכן זה לא נבדק.



• איך אפשר לוודא שההתנהגות תבדק בפיתוח לפני המסירה לבדיקות?



• האם כדאי וניתן בתהליך הפיתוח והבדיקות ליצור בדיקה משלימה שהיתה עשויה למצוא את הבעייה?



• ו-כן, איך אפשר לוודא שבאג קריטי יתגלה מוקדם על-ידי הבדיקות?

ברור שלא תמיד הבעיה היא רוחבית. למשל, ייתכן שסביבת הבדיקות לא הייתה נכונה כי הבודק טעה טעות שעלולה לקרות. ייתכן שהבעייה לא אמורה להיות בדרישות המוצר. אבל לניסיוני, רוב ה-escapes, הבאגים שספוספסו, הם רוחביים.

לא מזמן הייתי בתערוכת הטיטאניק. למדתי שהטעות לא הייתה של מישהו אחד. הטעות הייתה של מי שהחליט על מספר סירות ההצלה (שהיה מועט ביחס לכמות הנוסעים), על מי שלא חשב על תהליך מסודר במקרה אסון, על מי ששכח לספק משקפות לצופים, על רב החובל שהתעלם מאזהרות על קרחונים, על כך שטכנאי תקשורת ישנו בלילה ואיש לא מילא את מקומם, ואפילו על ברגי האניה שלא יוצרו כראוי. 

יש לציין שבגישת ה"עליהום" יש חסרונות רבים:

1. הוצאת אנרגיה באפיק מיותר במקום לחשוב על פתירת הבעייה.
2. התעלמות ממקורות הבעייה (שברוב המקרים אינה רק בבדיקות) ומכאן שהיא תקרה שוב.
3. פגיעה מורלית בבודקים שעלולה להביא לירידה במוטיבציה ובאיכות.
4. פירוק הגישה הצוותית והבאה ליחס של אנחנו נגדם, ריבים מיותרים.

ואילו בגישה הנכונה השיפור יביא לחיזוק הצוותיות, לגאוות יחידה (הנה אנו משתפרים) וכמובן יביא למניעת הישנות המקרה.