כשניהלתי צוות, היו לנו מוצרים לא פשוטים לבדיקה. היה קשה להחליט כיצד לגשת ולכתוב טסטים - מה נחשב טסט טוב ומה לא. עם הניסיון והזמן גיבשתי לנו טיפים שבסופו של דבר קראתי לה רשימת הזהב ותלינו אותה על הקיר.
אני אפרט כאן את העיקריים מהרשימה.
כלל הזהב. בהעדר מקור אמין לתוצאות המצופות מהטסט, רוב הסיכויים שתגששו באפלה.
ראיתי לא מעט טסטים שהניחו הנחות תלושות מהמציאות, פתחו באגים חסרי תועלת וגרמו לבזבוז זמן.
אינכם יכולים להניח תוצאות "הגיוניות" לפי שיקול דעתכם. עליכם להחליט על מה להסתמך.
באופן אידאלי, זה אמור להיות ה-spec או מסמך ה- Design. אך בהכירי את "הנפשות הפועלות", אני יכול לחשוב על מספר מקומות שיגחכו לשמע צמד מילים אלה.
עדיין, נסו לחפש מנהל פרוייקטים, מנהל מוצר, ראש-צוות פיתוח או כל יישות אחרת שניתן לסמוך עליה לגבי התוצאה הרצויה בטסט. כל זוג עיניים נוסף מחוץ ל-QA עדיף על החלטות שרירותיות שיגרמו אח"כ לעוגמת נפש.
במקרים שדורשים יצירתיות מיוחדת, הייתי מייעץ לכם לחפש מוצר דומה של מתחרה ולראות איך הוא התמודד עם אותם מקרים שאתם בודקים. במינון הנכון, זה יכול לעזור.
ראיתי לא מעט טסטים שהיו כרוכים בזמן הכנה ארוך ומייגע, רק כדי בסוף לתפוס התנהגות של המוצר שלא עניינה אף אחד ולא גרמה לפתיחת שום באג. עדיין, כמו שכל בודק מנוסה יודע, once הטסט נכנס לרשימת הבדיקות, הוא לא יצא משם גם לא על אלונקה.
כדאי לחשב היטב יחס עלות-תועלת לטסט כאשר כותבים אותו.
תתפלאו לדעת כמה טסטים פשוטים וטריביאלים יכולים להפיל מערכות מורכבות.
בכל מקרה, גם אם אתם רוצים "להרשים" מישהו בטסטים שלכם ואתם החלטתם לכתוב טסטים מתחכמים במיוחד, אני ממליץ - תשאירו אותם לסוף, או שתשאירו אותם ל-cycles מתקדמים, כך שהם ירוצו רק אחרי שכל הבדיקות הטריביאליות והבסיסיות רצו.
לא כל טסט שעולה לכם בראש, הוא בהכרח ראוי לרוץ בכל cycle. חישבו על ה-steps הנדרשים ובמיוחד על התזמון שנדרש להם.
אל תחשבו רק על מי שכותב את הטסט אלא בעיקר על מי שמריץ אותו. גם בשעות מאוחרות ובסופו של יום מפרך.
רוב הבעיות בבדיקות ידניות, מקורן בבעיות של בודקים שעשו טעויות בהרצה או דיווחו על תוצאות לא נכונות.
טסט טוב הוא טסט שכל בודק יכול לקרוא, להבין, להריץ ולדווח על התוצאות, תוך זמן סביר.
אם תכתבו טסט שקשה להבין או להריץ, קיים סיכוי שיריצו אותו בצורה שגויה, או יתעלמו ממנו לחלוטין (כן, זה קיים).
טסט שמניב בכל פעם תוצאות שונות, הוא טסט בעייתי. כל ריצת טסט צריכה לגרום לתוצאה ברורה שבלעדיה, פותחים באג. ברגע, שהבודק צריך לגרד בראש כשהוא מקבל תוצאות שונות בכל פעם - הסיכויים לפתיחת באג מועיל נמוכים.
גם אם הבודק הצליח לאפיין את הבדיקה כדרוש, הסיכויים שהמפתח יצליח לשחזר את הבאג, קטן.
ישנה נטייה, בעיקר אצל בודקים לא מנוסים, לכתוב טסטים שבודקים פינות נידחות ואפלות של המוצר. אולי כי זה קל או כי זה מגניב ופחות משעמם מלכתוב טסט 'נורמלי'.
טסטים שבודקים פינות קצה, רק ישגעו את הפיתוח ויגרמו לו לתעסוקה מיותרת. עדיף להתמקד ב-use case מכוונות לקוח והתנהגות נורמלית ברוב המקרים. רק אם נשאר מקום וזמן אפשרי לבדוק מדגמית מקרי קצה או Extreme Negative use cases.
בכל מקרה, כך או כך כדאי לזכור, שמה שחשוב בבדיקות הוא האיכות ולא הכמות. כבר יצא לי לראות לא אחת ערמות של טסטים בתוך cycle שמילאו אותם רק כדי שיהיה מה להראות בדוחות.
הבדיקות צריכות לעבוד בשביל ה-QA ולא להיפך.
אני אפרט כאן את העיקריים מהרשימה.
Reference
כלל הזהב. בהעדר מקור אמין לתוצאות המצופות מהטסט, רוב הסיכויים שתגששו באפלה.
ראיתי לא מעט טסטים שהניחו הנחות תלושות מהמציאות, פתחו באגים חסרי תועלת וגרמו לבזבוז זמן.
אינכם יכולים להניח תוצאות "הגיוניות" לפי שיקול דעתכם. עליכם להחליט על מה להסתמך.
באופן אידאלי, זה אמור להיות ה-spec או מסמך ה- Design. אך בהכירי את "הנפשות הפועלות", אני יכול לחשוב על מספר מקומות שיגחכו לשמע צמד מילים אלה.
עדיין, נסו לחפש מנהל פרוייקטים, מנהל מוצר, ראש-צוות פיתוח או כל יישות אחרת שניתן לסמוך עליה לגבי התוצאה הרצויה בטסט. כל זוג עיניים נוסף מחוץ ל-QA עדיף על החלטות שרירותיות שיגרמו אח"כ לעוגמת נפש.
במקרים שדורשים יצירתיות מיוחדת, הייתי מייעץ לכם לחפש מוצר דומה של מתחרה ולראות איך הוא התמודד עם אותם מקרים שאתם בודקים. במינון הנכון, זה יכול לעזור.
Simplicity
ראיתי לא מעט טסטים שהיו כרוכים בזמן הכנה ארוך ומייגע, רק כדי בסוף לתפוס התנהגות של המוצר שלא עניינה אף אחד ולא גרמה לפתיחת שום באג. עדיין, כמו שכל בודק מנוסה יודע, once הטסט נכנס לרשימת הבדיקות, הוא לא יצא משם גם לא על אלונקה.
כדאי לחשב היטב יחס עלות-תועלת לטסט כאשר כותבים אותו.
תתפלאו לדעת כמה טסטים פשוטים וטריביאלים יכולים להפיל מערכות מורכבות.
בכל מקרה, גם אם אתם רוצים "להרשים" מישהו בטסטים שלכם ואתם החלטתם לכתוב טסטים מתחכמים במיוחד, אני ממליץ - תשאירו אותם לסוף, או שתשאירו אותם ל-cycles מתקדמים, כך שהם ירוצו רק אחרי שכל הבדיקות הטריביאליות והבסיסיות רצו.
Testable
לא כל טסט שעולה לכם בראש, הוא בהכרח ראוי לרוץ בכל cycle. חישבו על ה-steps הנדרשים ובמיוחד על התזמון שנדרש להם.
אל תחשבו רק על מי שכותב את הטסט אלא בעיקר על מי שמריץ אותו. גם בשעות מאוחרות ובסופו של יום מפרך.
רוב הבעיות בבדיקות ידניות, מקורן בבעיות של בודקים שעשו טעויות בהרצה או דיווחו על תוצאות לא נכונות.
טסט טוב הוא טסט שכל בודק יכול לקרוא, להבין, להריץ ולדווח על התוצאות, תוך זמן סביר.
אם תכתבו טסט שקשה להבין או להריץ, קיים סיכוי שיריצו אותו בצורה שגויה, או יתעלמו ממנו לחלוטין (כן, זה קיים).
Reproducible
טסט שמניב בכל פעם תוצאות שונות, הוא טסט בעייתי. כל ריצת טסט צריכה לגרום לתוצאה ברורה שבלעדיה, פותחים באג. ברגע, שהבודק צריך לגרד בראש כשהוא מקבל תוצאות שונות בכל פעם - הסיכויים לפתיחת באג מועיל נמוכים.
גם אם הבודק הצליח לאפיין את הבדיקה כדרוש, הסיכויים שהמפתח יצליח לשחזר את הבאג, קטן.
Validity
ישנה נטייה, בעיקר אצל בודקים לא מנוסים, לכתוב טסטים שבודקים פינות נידחות ואפלות של המוצר. אולי כי זה קל או כי זה מגניב ופחות משעמם מלכתוב טסט 'נורמלי'.
טסטים שבודקים פינות קצה, רק ישגעו את הפיתוח ויגרמו לו לתעסוקה מיותרת. עדיף להתמקד ב-use case מכוונות לקוח והתנהגות נורמלית ברוב המקרים. רק אם נשאר מקום וזמן אפשרי לבדוק מדגמית מקרי קצה או Extreme Negative use cases.
בכל מקרה, כך או כך כדאי לזכור, שמה שחשוב בבדיקות הוא האיכות ולא הכמות. כבר יצא לי לראות לא אחת ערמות של טסטים בתוך cycle שמילאו אותם רק כדי שיהיה מה להראות בדוחות.
הבדיקות צריכות לעבוד בשביל ה-QA ולא להיפך.
אין תגובות:
הוסף רשומת תגובה