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

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

כאשר ה-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 כיוון שהאופנה מכתיבה אותה, והיא יותר זולה (אין פיתוח של מנהלים ומנהלים של האנשים).
אך האם האיכות השתפרה? אני בספק רב. לכן ההבטחה של האג'ייל, כפי שבאה לידי ביטוי למשל בספר שהזכרתי, לא מומשה.