מתודולוגיה ותהליכי בדיקות | נטליה רחמני

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

דגם מפל המים- Waterfall Model

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

יתרונות

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

חסרונות

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

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

V מודל -  V Model

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

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

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

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

יתרונות

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

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

• יעדי הבדיקה משתנים וספציפיים לכל רמת בדיקה

חסרונות

•  מודל ה- V הוא נוקשה מאוד והכי פחות גמיש, המשמעות היא שאם אחת הדרישות משתנה, עיצוב ומימוש הקוד עשוי להשתנות ועל הבוחן לעדכן את תיעוד הבדיקה בכללותו.
• המודל מצריך משאבים רבים – ולכן מתאים בעיקר לחברות גדולות.

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

מודל הספירלה - Spiral Model

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

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

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

יתרונות

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

חסרונות

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

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

עבור פרויקטים קטנים יותר, סביר כי מודל ה-Agile יתאים יותר.

Agile

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

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

ישנם מאפיינים מקובלים לפיתוח Agile :

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

יתרונות

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

חסרונות

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

לסיכום:

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