אג'ייל במבט ביקורתי

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

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

צוות של גיבורים

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

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

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

  

פתרונות אפשריים

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

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

מה קורה כשהבודק לא בא

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

מה קורה כשהבודק לא אוטומטי

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

  

פתרונות אפשריים

האיכות היא של כולם וגם המפתחים יכולים לעזור.

צוות של מפתחי על

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

  

פתרונות אפשריים

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

כשהאג'ייל הופך לתירוץ

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

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

  

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

  

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

אפשר לראות בטוויטר יציאות כמ "אבל זה לא לפי חוקי האג'ייל". אבל מה קרה ל"לבדוק ולאמץ"?

  

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

  

פתרון אפשרי

שמישהו בחברה יקח אחריות על היישום, ישב עם הצוותים ויעזור להם להבין מה שחשוב.

פיתוחים ארוכים ומורכבים

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

במקום אחר הוא נותן סיבות:

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

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

  

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

  

פתרונות אפשריים

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

מלכודת היועצים

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

פתרונות אפשריים

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

הערכות זמנים וישיבות

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

  

  

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

  

במאמרה על Mapping Biases to Testing,  מאייקה ברינגהוף אומרת שצריך להיזהר מהערכות שמכניסות בכח פיתוחים לתוך ספרינט רק בשביל שיראה טוב.

פתרונות אפשריים

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

מדידות

לדעת אהרון גריי המדידות של האג'ייל, הוא מוסיף בהקשר של ה-burn down charts, לא נותנות כלום מלבד תשובה לשאלה האם צדקנו בהערכות שנתנו. הוא לא מודד את שביעות רצון הלקוח, האם סיפקנו לו את מה שהוא רצה, האם צמצמנו את "החוב הטכני" למינימום וכד'.

סיכום

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

  

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

תכונות שיעזרו לנו להיות בודקים טובים יותר

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

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

אני לא חושב שיש הרבה שיש להם כל התכונות, אם בכלל. אז לא להתייאש.  

כדאי לבחור לא יותר מ-2-3 תכונות לשיפור בכל פעם ולא להתפזר.

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

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

  

  

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

כמה טיפים לעבודה עם מכונות וירטואליות

מה זו מכונה וירטואלית?

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

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

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

בבדיקות דסקטופ השימוש במכונות וירטואליות, להלן VM או Virtual Machine, הוא נרחב ושימושי מאוד.

יש מספר חברות שמייצרות VMs, אני מכיר יותר את VMware אבל רוב הטיפים להלן נכונים לכולם.

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

הנה דוגמא לעץ של snapshots שנשמרו במכונה וירטואלית המדמה ווינדואוס 10. ניתן לבחור להפעיל כל אחד מה-snapshots בעץ ללא קשר למיקומו

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

ניתן להכין מערכות הפעלה מקבצי ISO.

  

טיפים לשימוש: 

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

2. אם מריצים מכונות במחשב האישי, הוא צריך להיות חזק, ומאוד מומלץ להשתמש בכונני SSD.

3. השתמשו כמה שיותר ב-snapshots בזמן הבדיקות. לפעמים יש באגים שרק בעזרת שמירה העל snapshot יהיה ניתן לשחזר!

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

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

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

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

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

6. שמות משמעותיים ל-snapshots. אף אחד לא יזכור מה 59snapshot אומר.

7. כן, נדיר אבל אפשרי שיהיה מצב שה-VM לא מתנהג בדיוק כמו PC ובאג שנמצא שם אינו אמיתי. נדיר, אבל תדעו שאפשרי.

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

9. אפשר להסריט מתוך ה-VM וגם לצלם את המסך.

10. שימו לב לאייקונים למעלה - הם יכולים להועיל. 

When you have a new Image, this is what you want to install to prepare for the tests to come:

1. If you don't have a user with admin rights or a user with user rights, create them (start, right click on computer, manage, local users).

2. If you want a set that the users will not require passwords.

3. Login to the user, open the browsers, log off and relogin to the admin.

4. Make sure the VM configurations are set to get OS updates. From time to time update the OS.

5. Install any tool you think you might need, for example: install fiddler, install 7zip.

6. Set on the desktop or in windows explorer shortcuts to any directory you know that are going to use in the tests.

7. Save a snapshot.

8. If you use different divisions (for example one with IE & Firefox, one with IE and Chrome save them now.

קישורים מעניינים:

How to Install and Use VMWare Virtual Machine in Software Testing

מכונות וירטואליות בוויקי

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

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

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

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

מסמך זה זו התחלה, אני לא מתיימר לתמצת את הנושא.

  

הנה לינק למיינד מפ.

עצות לבודק שעובר לאג'ייל (או שכבר שם) - ראיון עם בוריס יוזבינסקי

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

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

הנה כמה אפשרויות פחות טובות:

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

- הבודק האוטרקי: בודק זה בא לעבוד וחשוב לו לעשות עבודה טובה, אבל הרבה יותר חשוב לו להיות המומחה הבלתי מעורער בבדיקות. אין צורך להתייעץ, אין צורך לשתף אף אחד.

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

הבודק השקט: זה שאני יושב עם הפיתוח בחדר לא אומר שאני צריך לדבר איתם!

הבודק הסקריפטופוב: לא לא! רק לא אוטומציה!

  

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

  

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

--------------------------------------------------------------------------------------------------------------------

הראיון

בוריס, ספר לי קצת על עצמך:

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

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

נטו OJT.

  

ולבדיקות נטו איך הגעת?

בתפקידי השני ב"פוליקום" במשרת סטודנט. עסקנו בתקשורת בפתרונות Tailormade לחברות גדולות כמו IBM. ואח"כ הגעתי ל-AVG.

מה מעניין אותך במקצוע הבדיקות?

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

איך קיבלת את הבשורה על המעבר לאג'ייל, לפני שזה קרה?

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

ואיך זה היה בפועל?

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

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

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

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

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

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

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

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

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

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

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

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

האם ריבוי המשימות שלך לא מסיט אותך מהבדיקות עצמן?

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

מהי העצה שלך לבודק שעובד היום לאג'ייל?

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

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

אתה רוצה לעשות שינוי בקריירה לכיוון ניהול מוצר. למה לעזוב את הבדיקות?

גם קצת מיציתי אחרי 4 שנים. הבנתי שאני לא רוצה להיות מפתח. יותר מעננן אותי כרגע  הצד של הביזניז. יש כאן ראייה רחבה יותר מאשר הבדיקות ושם אני רואה את עצמי גם בעוד 10 שנים. יש לי גם Passion לזה.

--------------------------------------------------------------------------------------------------------------------

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

השאלה היא:

Are you up to it?

בדיקות יחידה, Unit Test

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

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

מסיבה זו אני אכנס מעט לתהלך שבד"כ אנו לא מעורבים בו, ה-unit test, להלן UT.

  

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

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

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

מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.

 

בדיקות יחידה, Unit Testבדיקות יחידה, Unit Test

  

מטרות: 

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

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

  

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

  

בדיקות טובות של UT הן:

• אוטומאטיות;
• קלות לניהול;
• קלות להרצה;
• שומרות לוגים;
• מייצרות סטטיסטיקות;
• כוללות בדיקות שליליות, טיפול בבעיות;
• ערכי קצה וערכי default;
• ארגומנטים לא ואלידיים (טקסט במקום מספר). 

כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.

  

נקודות נגד:

מאריך את זמן הפיתוח, לא תמיד קל ליישום.

  

הערה: נעזרתי בויקי באנגלית: https://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.

ביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'ילית

הספר הזה, Agile Testing: A Practical Guide for Testers and Agile Teams , יכול להיחשב כבסיס הידע של בדיקות התוכנה. נכון, קשור לאג'ייל, אבל גם מי שלא עובד באג'ייל ימצא הרבה דברים שיכולים לעזור לו, ברמה כזו ששווה גם לו (או לה) לקרוא את הספר.

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

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

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

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

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

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

ביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'יליתביקורת ספר: 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?

בדיקות מונחות-הקשר - Context-Driven Testing

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

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

  

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

בוויקי BP מוגדר כך:

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things.

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

  

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

  

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

  

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

doing the best we can with what we get

הרעיון של Context-Driven Testing, להלן  CDT,  קיים בבדיקות מאז ומתמיד ובעצם בכל נושא כשחושבים על זה 

(למשל תקראו סיפורים על מצביאים מפורסמים והשיטות הייחודיות שלהם לנצח). אבל מי שניסח אותו בתחום הבדיקות היו קם קאנר, ג'יימס באך ו-Bret Pettichord. ניתן למצוא את המניפסט באתר ייעודי של קאנר בנושא זה: http://context-driven-testing.com (הכותרת של חלק זה לקוחה משם). קשה להבין את המניפסט ללא הקדמה (לשון אחר, ללא הקשר, LOL), ולכן כנראה באך וקאנר הוסיפו את שאר החלקים. אני מקווה שכעת, לאחר שקראת את הנאמר כאן, המניפסט יהיה ברור יותר. אני ממליץ לקרוא את כל עמוד הבית, אבל אם זה אמ;לק בשבילכם, הנה שבעת הסעיפים של המניפסט:

1.    The value of any practice depends on its context.

2.    There are good practices in context, but there are no best practices.

3.    People, working together, are the most important part of any project’s context.

4.    Projects unfold over time in ways that are often not predictable.

5.    The product is a solution. If the problem isn’t solved, the product doesn’t work.

6.    Good software testing is a challenging intellectual process.

7.    Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

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

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.

 בהמשך הם משווים בין CDT לשיטות אחרות, הנה ההשוואה בקצרה (אני חושב שחשוב להבין את ההבדלים הלו בכדי להבין את ה-CDT טוב יותר):

שיטות אחרות	הסבר	CDT
context-aware	מסתכלים על משהו שנחשב כ-BT בתור נקודת התחלה ואז עורכים שינויים שיתאימו למצב הספציפי.	הבודק מסתכל על הדרישות של האנשים שדעתם חשובה במיזם והאילוצים המעשיים, כמו גם על ההזדמנויות שהמיזם מציב. מבחינתו, הסטנדרט הוא בגדר עצה ולא מרשם.
context-oblivious, context-specific או context-imperial	ב-Context-oblivious מדובר על בודקים בד"כ חדשים שמיישמים את מה שהם למדו ולא את מה שנחוץ. ב- Context-specificהכוונה לסביבה בה בודקים אמנם לפי הקשר, אבל יותר מסיבות היסטוריות ולא ממשיכים לשנות את השיטה בהינתן שהמצב משתנה במיזם. וב- Context-imperial הבודק מתעקש לשנות את הבדיקות לפי מה שנראה לו כ-BP.
Agile	יש דמיון בין השיטות, אבל באג'ייל עדיין יש סממנים של BP. למשל: בודק אג'ילי יכוון את בדיקתו למצב שיש Unit Tests. בנוסף באג'ייל מעדיפים מעט מסמכים ככל הניתן.	לעומת זאת, בודק CDT יעריך את איכות ה-Unit Tests באם קיימים או במידה שלא, ויבדוק בהתאם. יתר על כן, אין בהגדרה בודק אג'ילי ללא Unit Tests, בעוד שבודק CDT יכול להיות. בודק CDT גם ירגיש בנוח בסביבה מרובת מסמכים, אם זה מתחייב מהמצב.
standards-driven	בודקים מסוימים מעדיפים לעבוד לפי מודלים, למשל מודל ה-V.	בודק CDT פשוט עובד בהתאם למה שניצב מולו.

  

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

  

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

 When you say that something is a “best practice”, you may impress the uninitiated, or intimidate the inexperienced, but you just look foolish to people who believe in the possibility of excellence. Excellence in an intellectual craft simply cannot be attained by ignorantly copying what other people say that they do. Yet, the notion of a best practice is really just an invitation to be an ignorant pawn in someone else’s game of process manners– or it’s a trick to make people pawns in your own game.