מודל V

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

Requirements <-> Acceptance test

  • בשלב הדרישות נציג הלקוח כותב מקרי בדיקות או בונה checklist עבור Acceptance testing.
  • דרישות הלקוח מתורגמים למסמך דרישות עסקיות BRS


 Specification <-> System Testing

  • בשלב של Specification צוות הפיתוח עושה טרנספורמציה של דרישות שיש במסמך BRS למסמך SRS
  •   צוות QA כותב מקרי בדיקה עבור בדיקות מערכת (System Testing) לפי מסמך SRS.


Design <-> Integration testing

  •  בשלב אפיון (Design) צוות הפיתוח עושה טרנספורמציה של דרישות אשר מתארות במסמך SRS למסמך SDD כאשר יש:
    – Architecture Design: תכנון על-ידי מפתחים high-level design, איך מודולים במערכת יעבדו אחד עם השני.
    – Module Design: תכנון על-ידי מפתחים low-level design, איך מודול בעצמו יעבוד כלומר מה מאפיינים שלו.
  •   בודקי תוכנה כותבים מקרי בדיקות עבור בדיקות אינטגרציה (Integration Testing) לפי מסמך SRS ו-SDD.

High Level Design – HLD: תיאור מודולים שונים במערכת ויחסם אחת כלפי השני.

Low Level Design – LLD: תיאור מפורט של כל מודול/קומפוננט.


Code <-> Unit testing

 מתכנתים מפתחים את המוצר/תוכנה(Coding) וגם עושים בדיקות קופסה לבנה ( debugging, code coverage.. ) עבור היחידה שמתפתחת (Unit testing), תוך שימוש בטכניקות של קופסה לבנה.


לסיכום מודל V זה:

Verification Testing

בודקים אם תהליך הבניה של המערכת נעשה בצורה נכונה.

Validation testing

בדיקה שכל דרישות מתקיימות לשם שימוש.

למעשה מודל V:

  • הצד השמאלי של מודל V זה תהליך הפיתוח של המערכת
    – SDLC – Software Development Life Cycle
  • הצד הימני של מודל V זה תהליך של בדיקות
    – STLC – Software Test Life Cycle

Validation take place after Verification phase

VALIDATION TESTING מבצעים בזמן :  integration testing, system testing, load testing, compatibility testing, stress testing, functional testing.

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

מתי משתמשים במודל V ?

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

מודל V מחליף מודל ישן Waterfall Model.

משתמשים כאשר פרויקט הוא לא גדול ודרישות הן ברורות.

בדיקות אינטגרציה

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

יש כמה סוגי בדיקות אינטגרציה , למשל:

:Big Bang Approach

  • בדיקת מערכת כאשר פעילים כל מודולים.

:Incremental Approach

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

משתמשים במקום מודלים חסרים ב-STUBS ובמקום בקרה משתמשים ב-DRIVER.

פיתוח בסבבים

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

Spiral Model – פיתוח בסבבים

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

למעשה זה פיתוח מחזורי מצטבר עם אותו תהליך :

[ הגדרת חלק מהדרישות – בדיקת סיכונים – עיצוב ומימוש + בדיקות – בדיקות קבלה וחזרה לדרישות ] ⇐ תחזוקה.

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

הערה: כאשר מוסיפים עוד ועוד דרישות יש לבדוק אם לא נגרמו פגמים למערכת (בדיקות רגרסיה – Regression testing ).

:Planning Phase

  • הבנה ותרגום דרישות של הלקוח למסמך דרישות עסקיות BRS.

:Risk analysis phase

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

:Developed phase

  • בונים מסמך SRS על סמך מסמך BRS ועל סמך SRS את המסמך SDD ו-STD.
  • מממשים את הדרישות אשר במסמך SDD ועושים בדיקות לפי מסמך STD (מריצים מקרי בדיקה ומדווחים על הבאגים ..).

:Evaluation phase

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

יתרונות פיתוח בסבבים:

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

מתי משתמשים ב-Spiral Model ?

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

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

מודל מפל המים

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

דרישות – אפיון – עיצוב – מימוש – בדיקות– תחזוקה

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

מודל ישן ולכן אני לא ממליץ להשתמש ב-Waterfall כי זה לא חסכוני גם כלכלית וגם מבחינת הזמן.

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

מחזור פיתוח תוכנה – תחזוקה

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

SDLC:

Requirements & Analysis (SRS doc.) => Design (SDD doc.)=> Code (unit test)=> Test (Fixing bugs, Reporting bugs by QA team)=> Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD doc.) => Test (Fixing bugs, Reporting bugs by QA team) => Deployment & Maintenance

Deployment – פריסת המערכת

  1. בדיקות בחוג סגור של אנשים(בודקי תוכנה) בחברה המתפתחת את המערכת – גרסת אלפא.
  2. לאחר מכן בודקים שמערכת עובדת באתר מחוץ לחברה מתפתחת את המוצר -גרסת בטא.
  3. בודקי תוכנה וגם מנהל המוצר עושים בדיקות קבלה – RC BUILD.
  4. המוצר יוצא לשוק גדול ובודקי תוכנה בודקים שדרוגים במוצר כאשר המוצר כבר בשוק – Release.

 Maintenance –  תחזוקה

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

מחזור פיתוח תוכנה – בדיקות

שלב רביעי במחזור פיתוח תוכנה זה ביצוע בדיקות. שלב שבו בודקי תוכנה, בודקים ומדווחים על באגים. למעשה בשלב הזה יש מימוש מסמך STD על-ידי בודקי תוכנה – בדיקת של המערכת לפי מקרי בדיקה שבמסמך STD ודיווח על הבאגים במסמך-Software Problem Report.

אני ממליץ להשתמש בכלי לניהול באגים JIRA

SDLC:

Requirements & Analysis (SRS doc.) => Design (SDD doc.) => Coding=> Test (Fixing bugs, Reporting bugs by QA team) => Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD) => Unit Test by Developers=> Test(Fixing bugs, Reporting bugs by QA team) => Deployment & Maintenance

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

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

מחזור פיתוח תוכנה – מימוש

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

מפתחים בזמן מימוש מערכת עושים בדיקות יחידה
(debugging/White testing) עבור המודולים/קומפוננטים.

SDLC:

Requirements & Analysis (SRS doc.)=> Design => Coding => Test => Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD doc.) =>Unit Test by Developers=> Test => Deployment & Maintenance

מחזור פיתוח תוכנה – אפיון

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

מפתחים בונים מסמך שמאפיין טכני את כל מאפיינים של הדרישות אשר במסמך SRS כך שבשלב המימוש לפי מסמך SDD יכלו לפתח את כל הדרישות.

מסמך SDD מתחלק ל-HLD ו-LLD 

  • High Level Design – HLD :תיאור טכני של כל המערכת.
  • Low Level Design  – LLD: תיאור טכני של כל מודול/קומפוננט במערכת.

SDLC:

Requirements & Analysis (SRS doc) => Design (SDD) => Coding=> Test => Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc) => Design (STD) => Unit Test by Developers=> Test => Deployment & Maintenance

Software Test Description – STD
מסמך בדיקות אשר מכיל מקרי בדיקה

בשלב הזה, נוצר מסמך בדיקות STD כאשר בודקים (testers) בונים תרחישי בדיקה (Scenarios) לפי מטריצת דרישות RTM.

מחזור פיתוח תוכנה – דרישות ותכנון

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

לדוגמה:

לקוח אומר את הדרישות שהוא מצפה מהמערכת,
כגון אני רוצה לבנות אתר שיהיו בו אופציות הבאות:

  1. הרשמה לאתר.
  2. כניסה/יציאה.
  3. אזור אישי של המשתמש.
  4.  עלות ההחזקה של האתר בחודש לא תהיה יותר מ-1000$.

SDLC:

Requirements & Analysis(SRS doc.) => Design => Coding=> Test => Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD doc) => Unit Test by Developers=> Test (STR doc) => Deployment & Maintenance

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

BRS - Business Requirement Specification

למעשה BRS זה:

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

 דוגמה של תרגום דרישות הלקוח למסמך דרישות BRS:

דרישות פונקציונליות:

  1. הרשמה לאתר (דרישת הלקוח)
    תרגום דרישות הלקוח למסמך דרישות BRS:
    * ניתן יהיה להירשם לאתר מ-mobile וגם ממחשבים נייחים – BR1
    * עלות מנוי לאחר הרשמה ראשונה, תהיה למשך 30 ימים ראשונים חינם – BR2
    * ….
  2. אזור אישי של המשתמש הנרשם (דרישת הלקוח)
    תרגום דרישות הלקוח למסמך דרישות BRS:
    * עמוד ה-WELCOME למשתמש רשום BR3
    * אופציות לשינוי פרטים אישיים BR4
    * הוספת נתונים של ניהול פיננסי BR5
    * שליחת הודעות אישיות למשתמשים אחרים BR6
    * ….

דרישות לא פונקציונליות:
תרגום דרישות הלקוח למסמך דרישות BRS:
* אתר חייב להיות SSL מאובטח BR7
* זמן טעינה של האתר לא יעלה מעבר ל-1.25 מילי שניות BR8
* עלות השרת וכל הוצאות עבור פרסומות/קידום לא יעלו מעבר ל-1K$ בחודש וזמן הפיתוח חייב להיות עד שנה אחת BR9
*…

Hardware Specification
תרגום דרישות הלקוח למסמך דרישות BRS:

* אתר חייב להיות זמין באנדרואיד  מעל גרסה 4 HS1
* אתר אמור לעבוד תקין בכל רזולוציה HS2

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

מחזור פיתוח תוכנה – שלב של ניתוח

Analysis Requirements phase

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

SRS - Software Requirements Specification

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

למעשה מסמך SRS זה פירוט יותר עמוק של המסמך BRS.

במסמך SRS יש:

  • תיאור Software פונקציונלי ולא פונקציונלי
  • תיאור Hardware איזו מערכות יהיו בשימוש סביב ה-Software
  • תיאור User Interface תוך שימוש בדיאגרמות כגון:

 מסמך SRS מורכב משני תת מסמכים:

  • FRS – Functional Requirement Specification
    – תיאור פונקציונלי של המערכת שיש לממש.
  • SRS – System Requirement Specification
    – תיאור של Software ו-Hardware של המערכת שיהיו בשימוש.

Planning phase
תכנון בדיקות

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

למעשה בשלב הזה נוצר מסמך תכנון בדיקות STP.

לדוגמה:

בדיקות רגרסיה ובדיקות חוזרות

Regression testing
בדיקות רגרסיה

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

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

Re-Testing
בדיקות חוזרות

בדיקה שהבאג אכן תוקן – בדיקות מקיפות עבור פונקציונליות שתוקנה.

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

דילוג לתוכן