מעבר ממפל למבחן זריז

כאשר חברה מחליטה לעבור מבדיקת מפל לבדיקה זריזה, באילו תחומים חשובים ביותר להתרכז לצורך בדיקת זריז יעילה?

איך ההשוואה בין בדיקות בזריז לזו של מודל המפל? איזה מערך פעילויות חשוב לבודקים להכיר ולעשות?



בדיקה לאורך הפיתוח

הדבר הראשון שיש להבין הוא שבפיתוח זריז, הבדיקה משולבת לאורך כל מחזור החיים; בדיקת התוכנה באופן רציף לאורך כל פיתוחה.


במודל המסורתי של מפל, הבדיקה היא מאמץ גדול והיא נותרת לקראת סוף הפיתוח, ואילו אצל Agile הבדיקה היא קטנה אך תכופה יותר וקורה לאורך כל ההתפתחות.

בדיקה לאורך כל הפיתוח פירושה גם שהתוכנה במצב שניתן לשחרור במהלך הפיתוח, כך שניתן לשלוח אותה מתי שזה מתאים.


במודל מפל מלמדים אותנו לחשוב בשלבים, כגון שלב התכנון, שלב הפיתוח ושלב הבדיקה. לפיתוח זריז אין שלב בדיקה נפרד ככזה. מפתחים עוסקים הרבה יותר בבדיקות וכותבים בדיקות יחידה אוטומטיות לחוזר על מנת לאמת את הקוד שלהם.



השתתפות מפתח בבדיקות

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

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

היבט חשוב נוסף הוא בדיקת אוטומציה כדי להיות מסוגל לבצע בדיקות באופן רציף עם פיתוח המוצר. לא מדובר רק בבדיקות אוטומטיות ליחידות, אלא גם בבדיקות אוטומטיות של API ו- UI.




צוותים משולבים וחוצי פונקציות

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

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

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

אין צוות מבחן בזריזות.




חשיבה איכותית, גישה שלמה לכל הצוות

כוון למניעת פגמים ולא לגילוי פגמים.

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

זה מבטיח כי כל מה שנבנה נבדק ומובן על ידי כל בעלי העניין. כמו כן, מכיוון שיותר אנשים מעורבים בהגדרת קריטריוני הקבלה ו'הגדרת בוצע ', ניתן לתקן טעויות מוקדם יותר ובסופו של דבר המוצר הנכון נבנה נכון.

כולם מעורבים ואחראים על איכות המוצר.




פחות תיעוד, יותר שיתוף פעולה

בפיתוח Agile, יש יותר דגש על שיחה ושיתוף פעולה כדי להבהיר דרישות יותר מאשר הגישה המסורתית של מפרטים ותיעוד.

למרות שניתן לברר דרישות במידה מסוימת בהתפתחות זריזה, עדיין ייתכן שהדרישות יהיו מעורפלות וחסרות, ולחברי הצוות יהיה הבנה שונה של הדרישות.

אז מה זה אומר עבור בודק זריז? דאגה נפוצה למבחני המעבר להתפתחות Agile היא שהם לא יודעים בדיוק בשביל מה הם בודקים. אין להם מפרט מפורט לבדיקה, אז איך הם יכולים לבדוק את זה?

אינך צריך שיהיה לך תיעוד מפורט כדי להתחיל בבדיקה. פעמים רבות, בודקים הגונים יכולים להשתמש בשיקול הדעת ובשכל הישר שלהם כדי לאמת מוצר. ידע בתחום מתחיל להיות חשוב ביותר.


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