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 ועודכן כעת.