מסמך הבדיקות STR הוא קיצור של – Software Test Report, כלומר 'מסמך תוצאות הבדיקות', והוא יישלח על ידי ראש צוות ה QA להנהלת הפרויקט.
במסמך זה נבצע סיכום של סבב הבדיקות, אנחנו נרצה לשקף למקבלי ההחלטות את מצב הפרויקט, כמה תסריטים הורצו, כמה עברו בהצלחה, כמה בודקים השתתפו במהלך הבדיקות, כמה תקלות נמצאו מתוך התקלות כמה מהן גבוהות וכמה נסגרו במהלך סבב הבדיקות ומה המשך זמן הרצה של סבב הבדיקות, סיכונים. במעמד המסמכים צוות הבדיקות צריך לגבש את ההמלצות שלו לשלבים הבאים לפרויקט, תנאים ומדדים לפתיחת סבב הבדיקות הבא או אישור העברה לייצור.
איך נחלק את מסמך ה STR
פתיח קצר
פרק תסריטים:
- כמה תסריטים הורצו
- כמה תסריטים עברו בהצלחה
- כמה תסריטים נכשלו
פרק תקלות:
- כמה תקלות נמצאו במהלך הסבב
- כמה תקלות נסגרו במהלך הסבב
- כמה תקלות נשארו פתוחות מהסבב הקודם.
- עדיפות וחומרת התקלות הפתוחות (גבוה, בינוני, נמוך)
משאבים ולוחות זמנים:
- תאריך תחילת הסבב הנוכחי ותאריך הסיום
- תאריך תחילת הסבב הבא ותאריך סיומו העתידי בתיאום מראש מול צוות הפיתוח כך שכלל התקלות הגבוהות טופלו, וכ 70% מהבינוניות נסגרו, כתנאי סף לפתיחת הסבב הקרוב.
- כמה בודקים / אחוזי משרה הוקצו עבור הסבב הזה
המלצות וסיכונים לסבב הבא / עלייה לייצור:
- מה ההמלצות של צוות הבדיקות
- איפה נכון להתמקד כדי להתגבר על צוואר הבקבוק באם קיים
- האם יש מוכנות לעליה לייצור/סבב הבא
- מה הקריטריונים הנדרשים כדי לעבור לשלב הבא
- מי המשאבים הנדרשים להיות בשלב הבא
- מה הצליח ועבד טוב בסבב הבדיקות ובאיזה תהליכים, תקשורות ואינטגרציה היה ניתן לעשות טוב יותר
- מה השורה התחתונה של צוות הבדיקות, עולים לשלב הבא או לא, ואם לא מה נדרש לדעת צוות ה QA כדי להגיע מוכנים היטב לשלב הבא.
רוצה ללמוד בדיקות תוכנה? כנס עכשיו לקורס שלנו וקבל כלים איכותיים
TesQA 