Software Test Plan

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

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

1. על המסמך עצמו: הסבר לגבי מהו מסמך זה, למה הוא מיועד, מה הוא אמור להכיל. זה ברמה גבוהה (high level) ויכול להכלל בתבנית.
2. תיאור המערכת כפי שהיא קיימת היום.
3. מבט על הגרסה הספציפית: האם היא גרסה ראשית, מה ברמה גבוהה התכולה העיקרית שלה, מי הם הלקוחות שלה, הבעיות העיקריות שלה (שינויי פלאטפורמה, זמנים קצרים במיוחד), ואיך אנו מתכוונים לפתור אותם. האם אנו משנים שיטה בבדיקות וכו'. מעיין תקציר של דברים שממליא יופיע אח"כ.
4. רשימת הנושאים הפתוחים. מומלץ שזה יהיה לינק לאקסל. זה צריך לכלול את כל הנושאים הפתוחים, לפי העמודות האלה:
   מספר, קיצור, פירוט, שייכות (בדיקות עומס, מעבדה וכו'), אחראי, פריוריטי, תאריך סגירה מצופה, סטאטוס (בטיפול, טרם טיפול, טופל). אם שולחים את זה כדוח שבועי, אפשר להוסיף עמודה פנימי / חיצוני, כלומר אם זה פנימי לבדיקות ולא תריך לעניין גורמים חיצוניים, ואז להשתמש בזה כפילטר.
5. אסטרטגיית הבדיקות:
   מה מטרת הבדיקות (לכסות את כל הדרישות וכד').
   שלבי הבדיקות: בדיקות מערכת, בדיקות עומסים וכד'.
   איך נקבע סדר הבדיקות.
   ועוד.
6. כמות כ"א בהתאם לשלבי הבדיקה.
7. מה לא יכלל בבדיקות. לא פחות חשוב. אם יש דברים שלא יכללו אבל ייבדקו ע"י גורמים חיצוניים - יש לציין ולתאם.
8. סיכונים. קישור למסמך חיצוני. כתבתי על כך בעבר.
9. המדידות שאנו מתכוונים לקיים. כתבתי על כך בעבר.
10. לוחות זמנים. גם מסמך חיצוני, כלל ציוני דרך. לא חייב פירוט של גאנט, אפשר תחילה וסיום כל כל פיצ'ר, של רגרסיות וכד'. זה נועד לתת תמונת "על" בכדי להבין אם יש בעייה. סיום של פרוגרסיה יום לפני סיום הגרסה = בעייה.
11. קישור לגאנט.
12. רשימת הנפשות הפועלות בגרסה. תפקידים עיקריים.
13. רשימת אינטרפייסים (מחלקות אחרות וכד').
14. פירוט החניכות שיש לעשות לצוות הבדיקות לקראת הגרסה.
15. חומרה ותוכנה שנזדקק להם.
16. ניהול הגרסה מבחינת הבדיקות:
    אילו דוחות יונפקו, רשימת תפוצה ותדירותם.
    אילו ישיבות סטטוס יתקיימו, משתתפים ותדירותם.
17. מסמכי הבדיקות והאחריות שלהם (ברמת תכנון, צ'ק ליסטים, דוחות).
18. באגים:
    צפי של מספר באגים לגרסה מול פיצ'רים. יש להבין כמה צפויים, וכמה זמן לסגור אותם, ולהתחשב בזמן זה בתכנון הבדיקות.
    ניהול של הבאגים: מי מחליט מה יתוקן, תהליכים וכד'.
19. טבלת כיסוי (Traceability Matrix).
20. מטרות האיכות (למשל שהגרסה תצא עם 0 באגים של התקנה).
21. צלילה לסוגי הבדיקות (למשל בדיקות פונקציונליות, ATP, עומס ועוד):
    איך נבדוק (תצורה כמערכות הפעלה ועוד ולפי איזו אסטרטגיה - למשל לפי כמות רוב משתמשי המערכת, באילו builds וכד').
    רשימת הרגרסיות.
    לוחות זמנים של הסוג הספציפי.
    האנשים שישתתפו (כולם).
    כלי הבדיקה.
    קונפיגורציית מעבדה.
    דרישות חומרה, רשת.
    מסמכים (כל מסמך בדיקות + תאריכים).
    תנאי כניסה לחדר בדיקות ותנאי יציאה.

• Jul 1, 2015