רמות בדיקה
בבדיקות תוכנה קיימים 4 סוגים של רמות בדיקה המתבצעים במהלך מחזור חיים של פיתוח תוכנה עם תחילת שלבי הבדיקות.
בדיקות יחידה > בדיקות אינטגרציה > בדיקות מערכת (מסירה) > בדיקות קבלה
בדיקות יחידה - בדיקות של יחידות עצמאיות ו/או רכיבים בדידים במערכת התוכנה
בדיקות אינטגרציה - בדיקות היחידות העצמאיות כקבוצה
בדיקות מערכת (מסירה) - בדיקת שלמות המערכת
בדיקות קבלה - בדיקת עמידת המערכת בדרישות העסקיות
בדיקות יחידה
בדיקות אינטגרציה
בדיקות מערכת
בדיקות קבלה
יחידות עצמאיות
קבוצת יחידות
שלמות המערכת
עמידה בדרישות המערכת
פיתוח
אינטגרציה
בדיקות
קבלה
פיתוח
מה נבדק
סביבת עבודה
רמת בדיקה
רמת בדיקות יחידה
בדיקה ברמת יחידות המערכת הקטנות המאמתות את תקינותן של היחידות באופן עצמאי (פרוצדורה או פונקציה).
בדיקת היחידה העצמאית אינה מבטיחה את תקינותה של כל המערכת, אך חשיבותה עצומה. בשלב בדיקות היחידה מאתרים את מירב התקלות המקומיות בקוד בטרם ישולב בתוצרת המודול / אפליקציה / המערכת.
בדיקות יחידה מתבצעות באחריות צוותי הפיתוח בסביבת הפיתוח:
1. בשלב המקדים לשחרור קוד חדש או קוד שעבר שינוי
2. סקירת מבנה פנימי של קוד (סוג בדיקה: קופסא לבנה)
3. השוואת קלט ופלט (סוג בדיקה: קופסא שחורה)
4. סביבת בדיקה: פיתוח
שיטות בדיקה
קופסא לבנה - WHITE BOX
קופסא שחורה - BLACK BOX
המפתח מכין סט של קלטים שירוצו על הקוד בצפיה לפלטים מתאימים
בדיקת המסך והתהליך העסקי ע"י הזנת קלטים
בדיקת מצב הקוד: קוד נקי או מלוכלך
בדיקה על רכיב או הפונקציה הבודדת כאשר סט הבדיקות יכיל מצבים חיוביים ושליליים
על המפתח לתכנן באופן נכון ומיטבי את תסריטי הריצה ואת כמות התסריטים הנדרשת.
חסרון: שינויים תדירים בקוד גורמים לתחזוקה רבה של תסריטי בדיקה.
יתרונות
א. מציאת תקלה בשלב רמת היחידה (UNIT TESTׂׂׂׂ) מגדילה את הבטחון להעברת קוד נקי ומערכת יציבה מסביבת הפיתוח לסביבת הבדיקות.
ב. עלות תקלה ותיקונה בסביבת אינטגרציה / בדיקות / קבלה / ייצור עלותם גבוה יותר מאשר עלות תיקונה בשלב המקדים והראשוני למציאת התקלה בסביבת הפיתוח.
ג. תחקור תקלה בסביבת הפיתוח מהיר יותר וקל יותר לשחזור מאשר בסביבת אינטגרציה / בדיקות / קבלה / ייצור. סיבה: תקלה המתגלה בשלב מאוחר יותר, לא תמיד פשוטה לשחזור או להבנה כיצד לטפל בה, לעיתים הפיתוח פוגש תקלה שמצאו בסביבת הבדיקות לאחר שבועות או חודשים והיכולת שחזור לגבי אופן טיפול מתארך ביחס לטיפול בתקלה עם הימצואתה בסביבת הפיתוח.
בדיקות
יחידה
בדיקות
אינטגרציה
בדיקות
מערכת
בדיקות
קבלה
עלות תיקון שגיאה
(רמת בדיקות אינטגרציה (שילוב
בדיקות אינטגרציה (שילוב) מוודאות כי הרכבים השונים של המערכת מקושרים זה עם זה, ומתקשרים בינהם כהלכה. בדיקות האינטגרציה הפרויקטאליות נערכות באחריות צוות אינטגרציה, צוותי פיתוח וצוותי בדיקות.
הבדיקה מתבצעת בסביבת הבדיקות או בסביבת האינטגרציה, לרוב הבדיקות מתבצעות לאחר בדיקות יחידה ומשך הבדיקות ארוך ביחס לבדיקות יחידה.
שיטות בדיקה
קופסא לבנה - WHITE BOX
קופסא שחורה - BLACK BOX
קופסא אפורה - GRAY BOX
מצב בו שתי יחידות / רכיבים או יותר נבדקים באופן משולב ולא כיחידה בודד (= unit test). הבדיקה תתבצע גם בין מודולים שונים, ממשקים בין מערכות ושילובים אפשריים אשר מטרתם להראות הצלחה בשילוב של המרכיבים השונים.
רמת בדיקות מערכת
בדיקות מערכת הינן בדיקת שילוב של מספר תת מערכות זו עם זו, המדמה ככל האפשר את המציאות ומאפשרת בדיקה כוללת של המערכת באספקטים שונים, כגון: תהליכי עבודה, טראנזקציות, שימוש בתפריטי מערכת, הודעות שגיאה, הרשאות עבודה וכיו"ב.
הבדיקות נכתבות בראיית משתמש הקצה ולפיכף מתוכננות בשיטת "קופסא שחורה", כלומר לא נבדק איכות הקוד של הרכיב הבודד. תכנון בדיקות מערכת (או בדיקות מסירה) מתבצעות אל מול דרישות ואפיוני המערכת ע"י צוות הבדיקות.
שיטות בדיקה
מרבית סוגי הבדיקות (למעט unit test) מתאימים לרמת בדיקה מערכת:
קופסא שחורה - BLACK BOX
בדיקות פונקציונאליות
בדיקות לא פונקציונאליות
בדיקות ממשקים
בדיקות הסבה
בדיקות אבט"מ
ועוד...
רמת בדיקות קבלה
מטרתן של בדיקות הקבלה הינה אישור לקוח לקבלת המערכת לאחר בדיקת עמידתה בדרישות אשר הציב לה הלקוח.
תסריטי הבדיקה נכתבים ע"י צוות בדיקות המסירה בהתאם לצורך הבדיקה של הלקוח או ע"י צוות הבדיקות של הלקוח. הבדיקות תהיינה מצומצמות יחסית להיקף של בדיקות ברמת מערכת. סיום בדיקות הקבלה בהצלחה, יוביל לאישור תקינות ראשונית למערכת ואישור להתקנתן באתר מבצעי (אצל הלקוח)
הבדיקות יבוצעו ע"י נציגי הלקוח על מנת לוודא יישום כל היכולות מהיבט המשתמש, כפי שנדרש על ידו.
שיטות בדיקה
קופסא שחורה - BLACK BOX
נציג הלקוח (משתמש המערכת או צוות הבדיקות של הלקוח) מכינים סט תסריטי בדיקה אשר מהווים את דרישות המערכת ע"פ אפיון המערכת. נציג הלקוחמכין מראש נתונים למצבים או תרחישים אפשריים כנגזרת מהנסיון העסקי של המשתמש עם עולם התוכן בו הוא עובד.
נציג הלקוח מבצע בדיקות פונקציונאליות כאשר הוא בודק פלט - קלט בלבד. הבדיקות מתבססות על תהליכים מרכזיים בעולם העסקי של משתמש המערכת (= לקוח), כאשר סוגי משתמשים שונים, בודקים היבטים עסקיים שונים.