מחבר: וולף

שלב רביעי במחזור פיתוח תוכנה זה ביצוע בדיקות. שלב שבו בודקי תוכנה, בודקים ומדווחים על באגים. למעשה בשלב הזה יש מימוש מסמך 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.

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
בדיקות חוזרות

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

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

בדיקות שפיות – Sanity Testing

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

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

בדיקות עשן – Smoke Testing

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

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

בודקים באופן מהיר כל המערכת, לאחר הוצאת BUILD.

לסיכום:

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

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

לשם כך יש להבין את השוני בין אבטחת איכות (Quality Assurance) ובקרת איכות (Quality Control).

QA – Quality Assurance
מזה אבטחת איכות  ?

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

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

QC – Quality Control
מזה בקרת איכות ?

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

TESTING
תהליך בדיקות

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

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

QA VS QC
מה עדיף בקרת איכות או אבטחת איכות ?

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