בדיקות מונחות-הקשר - 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.