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

מוטו: שיטה שתצליח צריכה להתאים לבני האדם, ולא להתאים את בני האדם לשיטה.

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

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

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

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

להלן הכישלונות של Agile מבחינת הבדיקה:

הבידוד של הבודקים

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

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

היעדר ביקורת

קשור לבידוד. מי בוחן את מה שהבודק בודק? אם למזלו/ה הוא בצוות שאכפת לו, הם יכולים לתרום רבות, אך הם לא בודקים מקצועיים.

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

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

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

מנהיגות

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

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

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

קריירה

אולי לא קשור למשימות היום-יום, אבל מתכנת בעולם Agile יכול לשנות את עמדתו להיות CTO למשל. מה התפקיד הבא של הבוחן?

בהשפעת המחויבות הקבוצתית

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

תצוגה ברמת המערכת

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

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

דברים אחרים שמנהלי QA עשו וחסרים ב- Agile

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

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

"Test automation is a craft (discipline) of its own, requiring specific skills. It takes time, effort, and dedication to become good at it and therefore isn’t something that can be done “on the side,” even if you're the best developer ever."

Arnon Axelrod - Complete Guide to Test Automation, p34

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


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

העבודה מול הפיתוח

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

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

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

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

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

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

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

· הם לא מכירים את המערכת עד הסוף.

· כל פעם אני מסביר לבודקים מחדש על הפיצ'ר הזה שוב ושוב.

· לא ברור בכלל מדיווחי הבאגים מה הבעיה, אין לוגים וכד'.

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

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

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

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

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

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