האנציקלופדיה לבדיקות – קובי יונסי
מדדי בדיקות תוכנה הם אינדיקטורים הניתנים לכימות וקשורים להתקדמות תהליך בדיקת התוכנה בהיבטים שונים של הפרויקט. מטרת מדדי בדיקות התוכנה היא להגביר את היעילות והאפקטיביות של תהליכי הבדיקות תוך סיוע בקבלת החלטות טובות יותר לבדיקות עתידיות על ידי מתן נתונים מדויקים על תהליך הבדיקה שהתבצע בעבר ומתבצע בהווה.
ניתן לסווג מדדי בדיקות לכמה קטגוריות:
- מדדי פרויקט – שמטרתם לוודא את התקדמות הפרויקט לקראת קריטריון היציאה כמו למשל אחוז מקרי בדיקה שהורצו, עברו בהצלחה או נכשלו.
- מדדי מוצר – שמזהים תרומה למוצר כמו למשל כמה כיסוי של מקרי בדיקה השגנו וכמה ממקרי הבדיקה שהורצו עברו בהצלחה.
- מדדי תהליכים - מזהים התקדמות בבדיקות או בפיתוח כמו למשל אחוז התקלות שהתגלו ביחס לבדיקות שבוצעו.
- מדדי אנשים – מאפשרים לזהות ביצוע של בעלי תפקיד בפרויקט, כמו למשל כמות הבדיקות שהורצו בפועל על ידי צוות הבדיקות ביחס ללוח הזמנים המצופה מהם.
חשוב לציין שישנם מדדים שיכולים לסייע לזהות התקדמות בכמה קטגוריות יחדיו, כמו למשל גרף שמזהה כמות דיווחי תקלות יומי מאפשר לנו לדעת מהי איכות המוצר בשלב נתון ומכאן להוות מדד למוצר אך במקביל מאפשר לקבל תמונה ביחס למצבו של תהליך הבדיקות באופן כללי, איפה אנחנו עומדים ומה נותר לנו לבדוק.
כבודקים מה שבדרך כלל יעניין אותנו הם המדדים ביחס לתהליך הבדיקות אותם נצטרך להציג מעת לעת בישיבות צוות פורמליות ולא פורמליות מול בעלי העניין בפרויקט (אנשי הפיתוח, הלקוחות, מנהלי המוצר ושחקנים נוספים שלוקחים חלק בתהליך)
שימוש במדדים מסייע לבודקים להציג תוצאות באופן עקבי ומסודר, לעקוב אחר קצב ההתקדמות, ולזהות מראש נקודות חולשה שיכולות להתפתח לצווארי בקבוק בפרויקט אם לא יקבלו מענה בזמן.
לפיכך מדדי בדיקות הם חלק בלתי נפרד בשלב תכנון הבדיקות (מסמכי STP) וגם בשלב תהליך הבדיקות עד לסגירתם ומטרתם לסייע לאנשי הבדיקות לתעד את סטטוס הבדיקות בכל שלב מאבני הדרך של הפרויקט.
כאשר מטרת התכנון ומהותו היא לתרגם מחשבות מהטווח הארוך לפעילויות מתקנות בטווח הקצר בכדי שנהיה ליוזמים ולא למגיבים.
מדדי בדיקות בתהליך בדיקות הם חשובים ביותר, מכיוון שהם מסייעים לצוותי הבדיקה לקבוע את איכות התוכנה ולוודא שהיא תואמת את התקנים וציפיות הלקוחות. הנה כמה סיבות לחשיבות מדדי בדיקות בתהליך הבדיקות
איכות התוכנה: מדדי בדיקות מאפשרים להעריך את איכות התוכנה. הם מסייעים לזהות בעיות, באגים ותקלות, ובכך להעריך האם פיתוח התוכנה עונה על ציפיות הלקוחות.
שימושיות: המדדים מאפשרים לצוותי הבדיקה לקבוע אם התוכנה ישימה וקלה לשימוש, ובכך לשפר את חוויית המשתמש.
אמינות: מדדי בדיקות מסייעים לוודא שהתוכנה פועלת באופן אמין ותקין ושהיא לא גורמת לכשלים או לתקלות בסביבה הפועלת.
חסכון בזמן ומשאבים: השימוש במדדים מאפשר לזהות במהירות תקלות ובאגים, ובכך לחסוך בזמן ובמשאבים. זה יכול להפחית את העלויות ולקצר את מחזור הפיתוח.
שיפור מתודולוגיות: מדדי בדיקות עוזרים לצוותי הבדיקה להבין אילו מתודולוגיות עובדות בצורה טובה ואילו דורשות שיפור.
התאמה לצרכי הלקוח: המדדים מסייעים להבטיח שהתוכנה תתאים לצרכי הלקוחות ותענה על הציפיות שלהם, מה שמעלה את הסיכוי לשחרור מוצר מוצלח החוצה.
בהיבט הבדיקות ישנם חמישה ממדים שדרכם נבצע מעקב לבדיקות:
1. סיכוני מוצר, מדדים של סיכוני מוצר יכולים לכלול:
1.1. אחוז הסיכון מהמוצר ביחס למקרי בדיקה שעברו בהצלחה.
1.2. אחוז הסיכון מהמוצר מול מקרי בדיקה שנכשלו.
1.3. אחוז הסיכון מהמוצר מול בדיקות שטרם נבדקו.
1.4. אחוז הסיכון ביחס לסיכון הכללי מהמוצר.
* הפורמולה הבסיסית לחישוב סיכון תהיה:
אחוז הסיכון = תדירות הסיכון X השפעת הסיכון
2. תקלות, מדדים של תקלות יכולים לכלול:
2.1. כמות תקלות שדווחו מול כמות תקלות שנפתרו.
2.2. כמות תקלות מול רכיבים שנבדקו.
2.3. כמות תקלות ביחס לגרסה, מהדורה של המוצר.
2.4. כמות תקלות וכמה מהן נדחו או שהן כפולות (Duplicated).
2.5. כמות תקלות וכמה מהן שנפתרו ויצרו תקלות חדשות. (נקרא גם: Daughter Bugs).
3. בדיקות, מדדים של בדיקות יכולים לכלול:
3.1. כמות הבדיקות שתוכננו מול בדיקות שנכתבו בפועל/ שהורצו בהצלחה/ שנכשלו/ שלא נבדקו.
3.2. סטטוס של בדיקות רגרסיה ובדיקות אימות.
3.3. כמות שעות יומית שתוכננו לבדיקות וכמות השעות היומית ששימשו אותנו בפועל.
4. כיסוי, מדדים של כיסוי יכולים לכלול:
4.1. מדד כיסוי הדרישות שהשגנו.
4.2. מדד כיסוי הסיכונים שאליו הגענו שמצביע על רמת הסיכון שנותרה מהמערכת.
4.3. כיסוי תצורה וסביבה של המערכת כמו למשל כמות ההתקנות שהוכנסו בפלטפורמות שונות ביחס לתכנון המקורי.
4.4. כיסוי קוד שבוצע.
5. בטחון, מדדים של ביטחון לא ניתן לכמת במספרים ולכן נהוג בחלק זה לבצע סקרים מול בודקי התוכנה ביחס לתחושה שלהם מהמוצר ומרמת האיכות בזמן שבדקו את המוצר.
כמו כן נהוג לבקש חוות דעת מפורטת בשלב בדיקות הקבלה ממשתמשי הקצה הפוטנציאלים של המוצר בין אם מדובר בבדיקות ביטא או בדיקות אלפא.
מעבר למדדים אלו, ישנם מספר מדדים שיכולים בנוסף להוסיף לתודעת הבדיקות בארגון וללמד אותנו ואת מנהלי הפרויקט על קצב התקדמות הבדיקות ובשלותו של המוצר.
המרכזיים שבהם כוללים למשל:
עמידה בלוח הזמנים המטרה העיקרית של עמידה בלו"ז היא לקבוע מהו ההפרש בין זמן הביצוע הצפוי לזה שבפועל כך שנוכל לבצע תיקונים בזמן ולהשקיע משאבים בכדי למנוע איחור צפוי בזמן עלייה לאוויר. פעולות מתקנות אלו הן חלק מבקרת הבדיקות (Test Control)
שיעור מציאת התקלות, יכול ללמד אותנו על יעילות צוות הבדיקות ועל טיב המערכת והקוד שפותח על ידי המפתחים.
ניתן לחשב מדד זה לפי גרסה, לפי אחוז יומי, שבועי, חודשי או מול מודול במערכת.
יעילות מקרי הבדיקה, מדד זה מאפשר לנו לקבוע אילו מקרי בדיקה הניבו תקלות בשיעורים גבוהים יותר ואז נוכל להשתמש במקרים אלו בגרסאות הבאות ולהעניק להם תיעדוף גבוה יותר כמקרי בדיקה עם אחוז גבוה יותר למציאת תקלות.
כדי לממש זאת ניתן להשתמש בפורמולה הבא:
Test Case Effectiveness =
Number of defects detected / Number of test cases run) x 100)
כיסוי קוד, Code Coverage מודד את החלקים בקוד שנבדקו כלומר היחס בין הקוד שנבדק לבין כלל הקוד שנכתב. המטרה היא לוודא שכמה שיותר מהקוד נבדק, כך שלא תהיה חסרות בבדיקה שעשויה להוביל לבעיות בפרקי התוכנה שלא נבדקו.
פשטות קוד, Code Complexity הפשטות של קוד הוא מדד שמשקף עד כמה הקוד מסובך. פשטות קוד זה קוד שנכתב בצורה מודולרית מחלקים קטנים ופשוטים ואין בו יותר מידי הסתעפויות ולכן קוד פשוט יותר נוטה להיות יותר קריא ופחות סביר שבו יהיו בעיות.
Defect Density מדד זה מציין את מספר התקלות שהתגלו בקוד ליחידה של מידות כמו שורות קוד, פונקציות, או יחידות אחרות. ערכים נמוכים במדד זה יכולים להצביע על איכות טובה של התוכנה.
זמן ממוצע בין כשלים, Mean Time Between Failures משמש לחשב את הזמן הממוצע בין כשלים בתוכנה. זמן זה משמש להערכת היציבות ואמינות התוכנה ומשקף את רמת הביטחון ממנה.
חומרה של באגים Bugs Severity מדד זה משמש לסווג באגים לפי חומרתם ומתייחס ליחס בין מספר הבאגים החמורים לכלל הבאגים שנמצאו ובכך ניתן לתעדף את הטיפול בהם. באגים עם חומרה גבוהה יעלו לראש התור בתהליך התיקון ויקבלו עדיפות על פני באגים אחרים. מעבר לכך מדד זה מצוי במקרים רבים בקריטריוני היציאה ומאפשר לנו להחליט אם המערכת תימסר או לא תימסר ללקוח. לדוגמא אם 40% מהבאגים הם חמורים, זה יחס שאינו סביר מבחינת איכות תוכנה שתימסר ללקוח ולכן ההחלטה הצפויה תהיה שלא למסור את המוצר.
שביעות רצון של הלקוח מדד זה משמש למדוד את שביעות רצון הלקוחות מהתוכנה. זהו מדד חשוב מאוד, שמראה כמה התוכנה עונה על ציפיות המשתמשים והאם אנחנו בכיוון של GO או NOT GO מבחינתו של משתמש הקצה הסופי.
למדדי הבדיקות יש מחזור חיים שכולל:
אנליזה – שלב הראשון בו נזהה מה הם המדדים שחשובים לנו ונרצה להשתמש בהם.
תקשורת – שלב שבו ניידע את כל מי שקשור לפרויקט לגבי הדרישה שלנו למדדים אלו. כמו כן נלמד את צוות הבדיקות לגבי הנתונים ומקורות הנתונים שאותם נאסוף לצורך עיבוד שוטף. לפעמים צריך לפתח קוד או לקסטם את מערכת ניהול הבדיקות בכדי שתפיק לנו את הערכים הנמדדים בצורה נוחה למעקב ולהצגה.
הערכה – ניתוח ועיבוד הנתונים לכדי חישוב שיאפשר לנו לקבל תמונת מצב מדויקת ועדכנית, ולפי כך נוכל לדעת האם אנחנו רצים וצמודים לתוכנית או שיש צורך בפעולות תיקון.
דיווח – הפצת דוח התקדמות הבדיקות על בסיס המדדים לבעלי העניין וקבלת משוב חוזר מהם לגבי המשך הפעילות בפגישות שנקיים לאורך תהליך הבדיקות.
לסיכום, מדדי בדיקות בתהליך בדיקות הם כלי ניהולי ממדרגה ראשונה והיות שכך, הם משמשים אותנו גם למעקב אחרי התקדמות הבדיקות במהלך הפרויקט ולכן ניתנת למדדים אלו חשיבות גבוהה באפשרות לסייע לצוותי הבדיקה להבטיח את איכות התוכנה, למנוע בעיות פוטנציאליות ולוודא שהתוכנה תואמת את התקנים וציפיות המשתמשים.
כדי לבצע את התהליך באופן נכון ויעיל יש לבחור את המדדים איתם נשתמש, לזהות את מקורות המידע, לאסוף באופן קבוע מדדים לאורך הפרויקט, להעריך ולחשב את המספרים ולתרגם זאת לפעולות אופרטיביות שיש לבצע בכדי שנוכל לתקן או לשמר פעולה רציפה בתהליך הבדיקות.
יש נושאים ומושגים נוספים שהייתם רוצים לקרוא עליהם? תשלחו מייל ואשמח לכתוב[email protected]
