בכל פעם שאני מארח מומחי QA בפודקאסט שלי, אני שומע את אותו הסיפור: הפיתוח רץ ב-200 קמ"ש, הדד-ליין נושף בעורף, וצוות הבדיקות נשאר עם הררי משימות וזמן אפסי.
בואו נהיה כנים – המרדף אחרי "כיסוי מלא" (Comprehensive Testing) הוא קרב אבוד מראש. אי אפשר לבדוק הכל, ואם תנסו לעשות את זה, כנראה שתפספסו את הדברים שבאמת יכולים להפיל לכם את המערכת. השאלה היא לא "כמה בדקנו", אלא מה החלטנו לבדוק קודם.
כאן נכנסת לתמונה הגישה של Risk-Based Testing (RBT). זה לא עוד מושג תיאורטי; זה הכלי שהופך אתכם מצוות "מגיב" לצוות "אסטרטגי".
למה בכלל אכפת לנו מסיכונים?
העיקרון הוא פשוט: לא כל חלק בתוכנה נולד שווה. באג קטן בעיצוב של דף ה-"אודות" הוא מטרד אסתטי, אבל תקלה במנגנון התשלומים היא קטסטרופה עסקית. RBT עוזר לנו לשים את המשאבים המוגבלים שלנו איפה שהם הכי נחוצים.
ז'אן אן הריסון, מומחית בתחום המכשור הרפואי, אומרת את זה הכי טוב: "בכל גרסה אנחנו בונים טבלת סיכונים מחדש. אנחנו לא מחפשים רק באגים, אנחנו מחפשים השפעה (Impact) והסתברות (Likelihood)".
נוסחת הקסם (הפרקטית) של בוב קרוז
בוב קרוז פיתח נוסחה פשוטה שעוזרת להוריד את התחושות מהבטן למספרים בשטח. הוא מחשב את ההסתברות לתקלה כך:
$$Probability = \frac{(Complexity \times 3) + (Frequency \times 2) + Newness}{3}$$
- מורכבות (משקל 3): קוד מסובך = יותר באגים. מתמטיקה פשוטה.
- תדירות שימוש (משקל 2): ככל שהפיצ'ר בשימוש גבוה יותר, החשיפה שלו לתקלות גדולה יותר.
- חדשנות (משקל 1): קוד חדש תמיד נושא איתו סיכון מובנה.
אחרי שיש לנו הסתברות, אנחנו מכפילים אותה בהשפעה העסקית (בסולם של 1-10). התוצאה? ציון סיכון סופי שקובע מה נכנס ראשון למעבדה.
איך עושים את זה נכון (בלי להסתבך)?
- מיפוי ויזואלי: אל תשאירו את הנתונים באקסלים משעממים. צרו "מפת חום" (Heat Map). ירוק לסיכון נמוך, אדום לסיכון קריטי. זה הכלי הכי חזק שיש לכם כשאתם צריכים להסביר למנהלי מוצר למה לא בדקתם הכל.
- שיתוף פעולה: אל תשבו לבד בחדר. בוב ממליץ על ישיבות בזק של 5 שניות: מציגים פיצ'ר, כל אחד מרים שלט עם ציון סיכון, עושים ממוצע וממשיכים הלאה.
- דינמיות: סיכונים משתנים. מה שהיה קריטי בתחילת הספרינט עשוי להפוך למשני בגרסה הבאה. אל תפחדו לעדכן את סדר העדיפויות שלכם תוך כדי תנועה.
טעויות שראיתי בשטח
הטעות הכי גדולה היא אובר-אנג'ינירינג. אם תהליך הערכת הסיכונים לוקח לכם יותר מ-10 דקות לרכיב, אתם כנראה עושים משהו לא נכון. המטרה היא לקבל החלטות מהירות ומושכלות, לא לבנות דוקטורט על כל באג.
בנוסף, אל תתייחסו ל-RBT כאל דרך "להתחמק" מבדיקות. המטרה היא לא להימנע מסיכון, אלא לנהל אותו בצורה גלויה.
השורה התחתונה
בסוף היום, איכות היא לא רק היעדר באגים – היא היכולת למנוע את "הדברים הרעים באמת". כפי שז'אן אן הריסון מזכירה לנו: "שיחות על סיכונים הן לא עימותים, הן חלק בלתי נפרד מהבטחת איכות".
הסיכון לא חייב להיות מפחיד; הוא פשוט צריך להיות גלוי.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
TesQA 