איך להתמודד עם משימה מעורפלת של בדיקה דחופה של מוצר חדש

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

• קודם כל אם באמת הכוונה להציג למישהו, אז צריך להחליט מראש מה היו בדיוק הסנריו שיוצגו, ולעשות את מרב הבדיקות עליהם ועל סביבתם הקרובה. אבל זו הייתה רק דוגמא.
• 30 דקות: כן חשוב לדבר עם מנהל המוצר ולהבין את מטרת המוצר, שימוש "רגיל" של משתמש קצה וכד', לרשום שימושים חשובים / נפוצים.
• 30 דקות: לדבר עם הפיתוח (שמן הסתם יודע יותר מאיתנו כי בלי להסביר לו הוא לא יוכל לפתח) שבוודאי יודע היכן המקומות הפגיעים ומה חשוב שיתבצע. לצרף לרשימה הקודמת.
• לנסות לקבל כמה שיותר expected results שאפשר מהגורמים לעיל.
• 15 דקות: לסגור את הרשימה של הדברים חשובים ביותר לבדיקה ולסדר לפי סיכונים.
• לוודא שכולם בסביבה וזמינים לעזרה מיידית.
• 45 דקות: מעבר ראשוני על התוכנה. פשוט לעבור עמוד עמוד, תפריט תפריט, ובזריזות. נכון שזה נשמע כמו בזבוז, אבל זה ייתן לך קצת פרספקטיבה על המוצר ויאתר בעיות בסיסיות ביותר. אפילו פונקציה חשובה פחות כמו מה חדש תתגלה כחשובה מאוד אם היא מקריסה את המערכת או מראה טקסט של מפתח משועמם שהיה צריך לכתוב כמה מילים כתופסי מקום והא כתב משהו על המקצוע של אחותו של העמית שלו.
• עברו שעתיים יקרות מאוד, כי בעיות צריך לתקן ואח"כ לבדוק, אז מתחילים לחפור. מתחילים בפעולות קלות ועוברים לקשות. רבע שעה ראשונה עדיף שר"צ הפיתוח או מנהל המוצר יישבו איתך ופשוט יעקבו אחריך. את התוצאות צריך לשמור, אפילו ב"קצרנות" על נייר. כל דבר שלא ברור תוך 5 דקות - בניגוד לבד"כ כשמומלץ לנסות ולהבין יותר לעומק - ללכת לפיתוח/מנהל המוצר ולשאול. כל באג - לכתוב ולתת עדיפויות. באג שחייבים לתקן, ללכת במיידי לפיתוח, להציג, לוודא הבנה ושהתיקון מיושם במקום, לחזור ולהמשיך בבדיקות.

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

אם זה קורה יותר מידי (האמת שפעם אחת זה כבר יותר מידי) נסו לערוך מעיין חוזה עם מי שצריך שלא יישנו מקרים כאלה.