משפט השדה של בודק התוכנה

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

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

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

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

הפלואו היה שכאשר ביצעת חיפוש, סרגל הכלים הוסיף את המקור לכתובת האתר ומשם משצר בבסיס הנתונים. לדוגמה, חיפשת את המילה "כלב" מטאב חדש. החיפוש יתבצע ותראה את התוצאות בדיוק כמו בחיפוש Google, ולכתובת האתר יתווסף פרמטר כמו source=NewTab (או source=AddressBar במקרה החיפוש היה דרך שורת הכתובת, וכו').

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

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

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

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

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

לאחר ניתוח הבעיה, מצאנו את הסיבה:

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

2. בעיית הנתונים שחסרו נבעה מכך שבטבלה החדשה חסרו כמה עמודות.

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

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

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

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

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

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

הדרך השנייה היתה להתחיל לענות למנכ"ל בפגישה ולהאשים את (מי שאני רואה) האחראי לכישלון.

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

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

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

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

מה אתם חושבים? האם החמצת הבאג היתה באשמתי? האם התנהגתי נכון?

STR מי מה ומתי

STR = Software/System Testing Results/Report

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

STR יוצא פר גרסה ויש לשמרו חמש שנים אם רוצים לעבוד בהתאמה עם חלק מה-ISO.

מדוע צריך STR?

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

אחריות:

מנהל הבדיקות / הבודק בקבוצת האג'ייל.

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

דוגמא ל-STR מתוך Testrail:

מחזור החיים של ה-STR?

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

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

הצורה האופטימלית:
ל-STR להכיל מבנה זהה של מסמכי הבדיקות כולם, כולל כל ההיררכיה - מרמת החלוקה לתת-מוצרים וה-tests groups עד לצעדים הבודדים.
בכדי שיהיה לנו ערך מהתבוננות ב-STR על כל צעד יש לרשום: עבר / נכשל / לא הורץ / blocked.
אם צעד נכשל יש לרשום: מס' באג, את חומרתו, ולציין את הסטטוס שלו. יש להדגיש באגים פתוחים. אם הבאג נסגר - יש לעדכן את המסמך.
אם לא הורץ - מדוע? בגלל באג / חוסר בזמן / עוד לא הגענו אליו. כדאי להוסיף מועד הרצה עתידי (גם כשזה בגלל באג כלומר blocked).
כדאי להשאיר מקום להערות.
עדיף כלי מדורג, כלומר כזה שיכיל את כל הבדיקות עד לרמת הצעד הבודד, אבל שניתן לצפות בו ברמות שונות. כלומר: סך ההרצות, רמת נושאי הבדיקה עד לצעד הבודד. אם test case עבר, אין צורך שכל הצעדים יהיו פרושים כ-default.
כמובן שאם יש אפשרות לשמירת גרסאות זה מצוין, כאשר הכוונה של סבבים. כלומר אם הריצו מסמך פעמיים שיישאר תיעוד של שתי ההרצות ולא רק של האחרונה.
בנוסף יש להכניס כל מידע רלוונטי: סביבת הבדיקות, קונפיגורציה, גרסאות ועוד.

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

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

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

מה גורלו של ה-STR?
בסוף גרסה עוברים עם מנהל הפרויקטים וכל מי שמעורב בגרסה ברמה הניהולית כולל איש SQM* אם יש על הנושאים הפתוחים ב-STR ומחליטים אל מול ה-STR ושאר נתוני ה-exit criteria אם הגרסה בשלה לצאת.

אם מישהו בכל זאת רוצה תבנית של טופס STR "כמו פעם" - https://strongqa.com/qa-portal/testing-docs-templates/test-report

*SQM - System Quality Manager - אחראי לאיכות תהליכי פיתוח רוחביים, לא לבדיקות.

פורסם במקור: Jul 1, 2015 ועודכן כעת.