מחזור החיים של הבאג

הצעה:

1. לאחר שמהנדס הבדיקות פתח באג (וראה כאן) אני ממליץ להעביר אותו (assign) לראש צוות הבדיקות. זה עלול להשמע סתם כהערכת התהליך, אך זה מאוד מומלץ.
   הסיבות לכך הן:
   א. ייתכן שר"צ כבר מכיר את הבעייה ומישהו אחר כבר פתח באג על זה.
   ב. משאיר את ר"צ מעודכן.
   ג. יתכן שזה אינו באג "אמיתי".
   ד. ר"צ יבחן אם הבאג אכן כתוב נכון, אם החומרה בדרגה הנכונה וכו'.
   במקרה כזה צריך להיות סטטוס open.
2. ראש הצוות מעביר את הבאג לאחראי בפיתוח (ר"צ) או במקרים מסויימים ישירות למפתח שפיתח את הפיצ'ר, אם כי שוב - אני ממליץ שר"צ הפיתוח יעודכן בכל מקרה.
   הסטטוס של הבאג צריך להיות בסוף שלב זה waiting for analysis, אלא אם ר"צ דוחה אותו והוא עובר ל-Reject והבודק מעביר ל-Agreed to Reject.
3. ר"צ הפיתוח מעביר למפתח הרלוונטי ב-assign.
   אין צורך בשינוי סטטוס.
4. המפתח בודק בצורה ראשונית ואז:
   א. הוא לא סבור שזה באג, ואז הוא משנה את הסטטוס שלו ל-Reject, וכמובן ממלא את הסבה לכך.
   במקרה כזה על פותח הבאג להחליט אם הוא מסכים, ואז מעביר אותו לסטטוס Agreed to Reject או שהוא מעביר ל-Waiting for Analysis.
   ב. הוא סבור שזה באג, מבין את הבעייה (עושה אנליזה), אך לא מתקן עדיין.
   הסטטוס יהיה Analyzed.
5. יש להחליט אם לאיזו גרסה הבאג יתוקן לפי החומרה שלו ולפי זמן התיקון והבדיקות, ולתת לו priority.
6. לאחר התיקון הסטטוס הופך ל-Resolved.
7. כשהתיקון מגיע לחדר הבדיקות הוא עובר ל-Integrated.
8. כאן הבודק מריץ את הבדיקה, ואז הבאג עובר ל:
   א. Closed, כלומר הבאג תוקן.
   ב. Reopen כלומר הוא לא תוקן.
   במקרה השני זה חוזר למפתח ומשם הכל ממשיך כמו מקודם.
9. לאחר תיקון הבא על הבודק לבדוק אם עליו להוסיף את הסנריו לגרם לבאג לתסריטי הבדיקות.

הגדרת חומרת הבאג (Severity)

באג הוא קריטי כאשר:

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

למשל אם אנו בודקים את ה-outlook ומוצאים שאין אפשרות לשלוח מיילים.
באג הוא מאג'ורי כאשר:

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

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

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

למשל אם אנו בודקים את ה-outlook ומוצאים שקבלה של מיילים המוגדרת לכל 10 ד' יש אי-דיוקים של עד 30 ש' לכל צד.
חשוב לזכור:

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

שערים (Gating) בכלל, ומעבר לבדיקות בפרט

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

טרמינולוגיה:

שער = gate, והישיבה = Readiness before X, כאשר X יכול להיות בדיקות.

מהו השער?

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

חשיבותו של השער:

לא ניתן להגזים בה.

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

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

אחריות:

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

Go, Conditional Go, No Go.

הדגש:

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

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

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

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

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

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

וודא שהמשתתפים המנדטוריים יגיעו לישיבה.

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

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

להערכתי יש לבצע את השערים האלה:

1. בין השיווק למהנדס המוצר.

2. בין המהנדס לפיתוח (כולל בדיקות).

3. אם יש אינטגרציה - בין הפיתוח לאינטגרציה.

4. בין האינטגרציה / הפיתוח לבדיקות.

5. בין הבדיקות למייצג של הלקוח.

שער לכניסה לבדיקות - readiness before testing:

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

הישיבה:

כל המשתתפים המנדטוריים מגיעים.

שומעים מהצד המוסר מעיין סיכום על מה שהיה, מה נעשה, בעיות וכד', דגשים ועוד.

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

אחרי הדיון נשלח מייל סיכום עם ההחלטה.

שלבים בתהליך כתיבת מסמך בדיקות (STD פרוגרסיבי)

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

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

1. האם הדרישה כתובה בצורה ברורה? אם אתם מוצאים את עצמכם משלימים נקודות מתוך הנחות שאתם עושים, אולי זה כיף אבל assumption is the mother of all fuckups. אל תתביישו, תשאלו. סביר להניח שחלק גדול מהאנשים גם לא הבינו ואולי התביישו לשאול, או גרוע יותר , הניחו הנחות.

2. מה הסיבה / המוטיבציה לדרישה? האם הדרישה עונה עליה? 

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

4. האם יש user stories ברמה הנאותה? 

5. האם יש case studies אם רלוונטי? 

6. האם דרישה זו מסתדרת יפה עם המוצר הקיים? עם דרישות נוספות? 

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

8. האם אכן נוח למשתמש - ה-flows, מיקום הכפתורים? לשון אחר: יוזביליתי. 

9. האם לא חסר משהו שהמשתמש מצפה לו, או יקל עליו. אותה משפחה כמו סעיף 7. 

10. אם ברור לכם שהטכנולוגיה לא קיימת ו/או שייקח זמן רב לפתח את זה. 

11. האם לא חסר מידע? האם יש קפיצות בדרישה? 

12. סתירות פנימיות: פעם כתובה דרך אחת ליצירת דבר מסויים, פעם דרך אחרת וכד'. 

13. מילים דו משמעיות, TBD, אחרי האישור של <> ועוד. 

14. האם יש מוקאפים? 

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

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

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

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

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

 Jun 28, 2015

אפיון טכני ברמה גבוהה (מהנדס מערכת)

(שלב ג' בתהליך הפיתוח)

מטרת המסמך ותוכנו:
- להציג את כל הדרישות הטכניות מהמוצר והגרסה, כולל תוכנה וחומרה.
- הצגת הארכיטקטורה ופירוק לרמות נמוכות.
- אמור לכלול ביצועים, storage, צריכת זכרון, זמני תגובה, ביצועי בסיסי הנתונים ועוד.
אל תקבלו משפט כמו: שיתמוך בכמות סבירה של משתמשים! אחרת הבדיקה שלכם לא תהייה בדיקה אלא benchmark. צריך להחיל מראש לאן שואפים, ואפשר ליצור פשרות אח"כ, אבל מתפקיד כותב המסמך לדעת מה הוא מאפיין! אותו דבר לגבי שאר הנתונים.
- דרישות כלליות של ה-GUI ושל תהליכיפ פנימיים (בדיזיין יהיה פירוט ברור יותר של ה-GUI).
- תרשימי זרימה לאורך כל המערכת.
- דרישות security
- דרישות לגבי התחזוקה
- דרישות לגבי מהימנות המערכת (עליה לעמוד בעומס של X פעולות לאורך Y שעות במשך Z זמן עם A שגיאות מותרות בדרגת חומרה B).
- ממשקים חיצוניים
- ממשקים פנימיים
- קינפוג חומרה ותוכנה
- מגבלות
- תמיכה לאחור (backwards compatibility)
- דרישות התקנה
- קווים מנחים להתקנות ולבדיקות


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


על הדרישות להיות:

1. מלאות וברורות מתוך המסמך עצמו (יש אפשרות לקשר למסמכים אחרים בכדי להבין תהליכים קודמים או קישור למסמכים מסוג שונה אבל לא שנצטרך לשאול שאלות לגיטימיות שהתשובות עליהן יפנו אותנו למייל או לאיזו תורה שבעל-פה).
2. נכונות.
3. חד-משמעיות.
4. עקביות עם שאר המסמך ועם המערכת.
5. ניתנות ל-traceability, כלומר כל דרישה היא סעיף, כל תת-דרישה היא תת-סעיף).
6. ניתנות לווידוא (על ההתנהגות להיות סבירה - לא ניתן לווידוא).

עצה שקראתי פעם הייתה לחפש ממש סימני שאלה, TBDים למינייהם, מילים כמו probably, could וכד'.
עצה אחרת ששמעתי היא לשאול לגבי כל דרישה את השאלות הבאות:
1. מה
2. מתי
3. איך
4. איפה
5. למה
6. מי
למשל הוספת פיצ'ר של שמירה אוטומאטית של מסמך.
1. מה קורה אם זה שומר בזמן שאני כותב / פותח תפריט מסויים וכו'
2. מתי השמירה מתבצעת והאם אפשר לקנפג את זה
3. איך המנגנון פועל מאחורי הקלעים
4. איפה יישמר הקובץ אם המסמך עדיין לא שמור
5. למה יש בכך צורך והאם הדרישה משרתת את הצורך, ואולי אפשר לשלב צרכים אחרים?
6. מי מוודא שזה קורה? האם יש מנגנוני אזהרה?
שאלת שאלות אלו יקלו עליכם בכתיבת המסמכים בייחוד בעניין של expected results.

תהליכי פתיחת באג

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

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

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

מהו דיווח הבאג (bug report)?
דיוח הבאג הינו מסמך טכני המתאר כשל ב-SUT שעלול לסכן את איכות חווית המשתמש.

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

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

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

תהליך פתיחת הבאג:

לשון זכר, הכוונה לכל המינים שיש.

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

אני גם מניח שמסמך הבדיקות עבר ביקורת והוא מדוייק ונכון.

אז הרצנו בדיקה והתוצאה שונה מהצפוי. מה עושים?

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

אם בין התוצאה של הבדיקה לבין הכתוב בסמכי הדרישות יש אי-תאימות, ברור שיש כאן באג! ייתכן שבתוכנה, אולי במסמך.

יש לדווח על בעיית של איבוד מידע או התקרשות (מהמילה crash) של המערכת אף אם חד-פעמית. ייתכן שמדיווח טוב יהיה לפיתוח מספיק מידע להבין את הבעייה! (יש לציין: לא משתחזר).

זכור, אתה הלקוח הראשון של המערכת!

2. שחזור. קודם כל, חזור שוב על הצעדים וודא שאתה מקבל את אותן התוצאות. תעד את הצעדים בצורה מדוייקת.

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

למשל אם הייתי בודק את ה-word, לכתוב הכנס את הטקסט הבא:
אני אוהב לשמוע את ג'ורג' הריסון.
ולשמור, ואז תקבל הודעת שגיאה X.
זה בודאי לא מספק. צריך לבודד את הבעייה עד שנבין שהגרש בעייתי, ואז האם תמיד או רק במקרים מסויימים (בתוך מילה, רק בגופן ספציפי, במערכת הפעלה מסויימת), והאם יש work around.

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

יש לצרף לוגים מתאימים, רשומות בבסיס הנתונים.

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

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

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

הנה כמה נקודות חשובות לגבי כתיבת הדיווח:
-היה מדוייק ותמציתי.
-היה ענייני- בלי הומור או האשמות (כגון: שוב הבעייה ה... חזרה).

כתיבה מקצועית של דיווח על באג

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

הסיבות לכך הן:

1. לא יקרה מצב שהפיתוח יבין משהו אחר (ואז הבאג יחזור לבדיקות ושוב לפיתוח וכו'... בזבוז זמן משווע).
2. שהבודק לא יהיה ואף אחד לא ידע על מה הבאג.
3. שהפיתוח יבין על מה הבאג אבל יבזבז הרבה זמן על מציאת פרטים שכבר היו אצל הבודק אבל הוא לא צירף (לוגים, קונפיגורציה).
4. שההשפעות שלו יהיו ברורות.
5. שיהיה תיעוד מדוייק של הבעיות לצוריך איסוף נתונים ולמידה.
6. וזה לא פחות חשוב: הפיתוח יעריך את העובדה שהבאגים ברורים, וגם יעריך את מידת המקצוענות של צוות הבדיקה.

לגבי 6, צריך להבין שתיאור הבאג הוא תחת האחריות שלנו, ואנו לא "עושים טובה" בכך שאנו מוציאים תוצר איכותי בתיאור הבאג, אלא שזה המקצוע שלנו וחובתנו!

הנושא:

כמובן שנושא הבאג חייב להיות מתומצת אבל גם שישה ברור מתוכו מה הבג.

זה, למשל, בסדר:

לא ניתן לשלוח הודעה קולית משורשרת ליותר מנמען אחד.

אפילו זה בסדר:

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

(ואז לפי ה-severity אפשר להבין אם המצב נדיר או לא, ואף אפשר לראות את פרטי הבאג).

אבל זה כבר לא:

יש מקרים שאי-אפשר לשלוח הודעה

וזה בטח שלא:

בעייה עם הודעות קוליות.

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

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

אז הנושא אמור להיראות כך (<> אופציונלי):

<גרסה ראשית>,<שם המוצר>,<גרסת המוצר>, <מספר build>, תיאור ממצה,<מספר הדרישה>

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

כעת לתיאור עצמו בגוף דיווח הבאג:

Testing Activity: Functional/Load/Automatic/Free/ATP/Scratch Installation/Upgrade
אמנם הבעייה יכולה להיות אותה בעייה, אבל יש הבדל גם מבחינת הדיבאג אם זה קורה רק בעומס או בבדיקה פונקציונלית רגילה. אם זה קורה בעומס יכול להיות שמקור הבעייה הוא דליפת זכרון או המחסן בזכרון, בעוד שבעייה פונקציונלית יכולה להיות בקוד עצמו.
Impact on System/Service (more than one word) :חשוב מאוד: לפעמים הבאג נשמע לא חשוב ולכן לא יטופל במהירות, אבל לעתים לבאג כזה יש השלכות אדירות, ואותן יש להוסיף. למשל באיזו נקודה לא חשובה (בקובץ שאינו נגיש ללקוח) מספר הגרסה שגוי. לא נשמע חמור, אבל עלולות להיות לזה השפעה מכרעת בעת ביצוע שדרוג של המערכת.

יש גם לציין אם יש דרך לעקוף את הבעייה

(work around)Steps to Reproduce:1.

....

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

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

Expected Result:
איך המוצר היה אמור להתנהג. גם בשביל להבין אל מול מה שקורה בפועל, וגם בכדי שיהיה ברור מה אנו מצפים. יש למלא סעיף זה רק אל מול מסמך דרישות או כשבטוחים בכל מאת האחוזים.
Analysis:
אם יש. בודק טוב יכול לתת מידע חשוב גם אם הוא אינו מפתח, למשל ייתכן שזה קורה כיוון שהמשתמש אינו מזוהה נכון.Additional Info (if exists/relevant):

Setup:
.
.
.

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

עוד מידע חשוב
Related TCs:

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

לא הכל רלונטי לכל מקום. יש להתאים, להוריד / להוסיף.

ראשי תיבות ומונחים

Ad Hoc Testing - Testing carried out using no recognized test case design technique.

ATP - Acceptance Test: Tests that are sometimes performed by a customers to determine whether or not a system has satisfied predetermined acceptance criteria. These tests are often used to enable the customer (either internal or external) to determine whether or not to accept a system.
Escape - a defect that was not found by, or one that escaped from, the test team.
GA - General Availability: product is released.
GFAT - General Factory Acceptance Test

GUI - Graphical User Interface

ICP - Individual Coaching Plan

MRD - Main Roll Definition

MRD - Marketing Requironments Definition

Sanity or Smoke Tests- typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is often crashing systems, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

SDD - Software Design Description

SDD (AKA TLD, SID) - Software Development Document

SDLC - Software Development Life Cycle
SOW - Statement of Work. This is a document used in the Systems Development Life Cycle. An organization desiring to have work done (i.e., the prospective customer) produces an SOW as part of a Request for Proposals. Software vendors or services companies (prospective contractors) respond with Proposals. The SOW specifies requirements at a very high level. Detailed requirements and pricing are usually specified at a later stage. SQA - Software Quality Assurance

SRS - Software Requironments Specifications

STD - Software Test Description
STP - Software Test Plan

STMP - Software Test Management Plan
STR - Software Test Results

SUT - System Under Test

SysRD - System Requironments Definition
TC - Test Case
TRD - Test Requirements Definition

UI - User Interface

לגבי מונחים:

מילון מונחים של ה-ISTQB.
אתר מקיף בנושא אפשר למצוא כאן.

פרוגרסיה ורגרסיה

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

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

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

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

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

-------------------------------------

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

-------------------------------------

במוצר מורכב, אי-אפשר לעשות בד"כ בכל גרסה רגרסיות מלאות על כל המוצר.

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

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

1. כאשר משתמשים בקוד בו נגעו גם לפיצ'רים ישנים.
2. מעבר בסיסי על הפיצ'רים המרכזיים של המערכת (אפשר בשלב ב-ATP).

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

גרף הממחיש את עלות מציאת הבאג מול הנקודה בתהליך

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

סוגי בדיקות הולידציה

יש שני סוגים של בדיקות וריפיקציה:

1. "קופסה לבנה", white box. אלו בדיקות שבהן נדרש הבודק בידע תכנותי. עליו למצוא בעיות ולהביא את הסיבות להן. בד"כ אנשי הפיתוח עורכים בדיקות אלה.
2. "קופסה שחורה", black box. בדיקות "חיצוניות" של האפליקציה מבלי להכנס לקוד.

בדיקות white box כוללות:

1. בדיקות יחידה, unit tests. הכוונה היא שכשמוצר מורכב מכמה חלקים, כמו שבד"כ זה קורה, והיישומים כוללים אינטגרציה בין החלקים, אז קודם כל בודקים חלק חלק בנפרד.
   למשל נניח שהמוצר הוא אתר אינטרנט, והוא מורכב מחלק שקשור לבסיס נתונים, חלק שקשור ל-GUI או לממשק הגראפי וחלק שהוא מנוע חיפוש. אם מוסיפים יכולת למנוע החיפוש אלו שינויים בכל התחומים הללו: יש להוסיף את האפשרות למשתמש ב-GUI, לשדרג את אלגוריתם החיפוש ולשנות בהתאם את בסיס הנתונים. אז לפני שמחברים את הכל ביחד כל פונקציה פיתוחית מתאימה בודקת את החלק הרלונטי שלה. לזה אין בד"כ ממשק משתמש וגם לכן דרוש מפתח.
   סיבות ותועלת:
   א. תיקון באג בשלב הזה יעיל וחסכוני לאין שיעור ממציאתו בנקודות הבאות בתהליך (אינטגרציה, בדיקות וכו'). גם כי זה "טרי" אצל המפתח בראש, גם כי ברור שהבעיה היא בחלק שלו (מה שלא ברור תמיד במוצר הגמור), וגם אם יש שינוי שקשור לקומפוננטה אחרת זה המקום החסכוני לעשות זאת.
   ב. לבודק ייקח הרבה יותר זמן להבין ולשחזר את הבעיה.
2. בדיקות אינטגרציה של היחידות (נקרא גם: Private Integration): בדיקות של החיבור בין המערכות, גם באחריות הפיתוח. על צוות הבדיקות לוודא שבדיקות האינטגרציה התבצאו במלואן, ואם משהו לא תוקן לקבל עליו מידע. מן הראוי שמהנדסי הבדיקות יעברו על מסמך הבדיקות של הפיתוח ויוסיפו אם צריך.

בדיקות black box כוללות:

1. בדיקות אינטגרציה "חיצוניות": במקרים של מערכות גדולות שיש הרבה סיכון ברבדים הנמוכים של האפליקציה: התקנה מסובכת, דרייברים חדשים, חומרה חדשה וכו' לעתים יש צוות אינטגרציה בעל ידע ספציפי בתחומים הללו, לפעמים גם ידע תכנותי. היתרון: מציאה וטיפול מהיר בבעיות שלא תמיד יכולות להתגלות ע"י הבדיקות. גם הפיתוח מתייחס אליהם אחרת, מהר יותר, כי הבעיות שהם מגלים בד"כ קריטיות.
2. בדיקות יוזביליות: לוודא את התאמת האפליקציה לדרך בה משתמשים בה משתמשי הקצה והאדמיניסטרטורים, ולא מאלצים את המשתמשים להתאים את עצמם לתוכנה.
   א. בדיקת קיום סטאנדארטים. אם לא הרשמיים שיוצאים ע"י האגודות, לפחות את הסטאנדרטים המקובלים.
   ב. גישתיות (Accessibility). האם המשתמשים יכולים לנווט ולצאת באופן אינטואיטיבי (או עם הסברים נאותים).
   ג. Responsiveness. האם המשתמשים יכולים למלא את רצונם, בזמן שהם רוצים ובצורה ברורה?
   ד. יעילות. האם המשתמשים יכולים למלא את רצונים במינימום צעדים וזמן?
   ה. הבנתיות. האם המשתמשים מבינים את מבנה המוצר, את מערכת העזרה ואת התיעוד שלה?
3. בדיקות פונקציונליות:
   א. שימוש נכון במוצר. בדיקה של הדרישות: אם עושים X קורה Y.
   ב. שימוש שאינו נכון. לחיצות חוזרות ונשנות על אותו כפתור למשל.
   ג. בדיקות GUI. מיקום המסגרות, אי-חריגה בשל טקסט רק.
   ד. פעילויות של משתמש קצה. חשוב ביותר. למשל משתמש "רגיל" מתחבר, הולך למקום מסויים, עושה פעילות כזו או אחרת, חוזר, הולך למקום אחר וכד'.
   ה. שימוש אפקי, או זרימה. מתחיל תהליך מסויים עם המשתמש למשל, הוא מכניס מידע, וידוא שהמידע עובר נכון בכל נקודה, שהמערכת אח"כ משתמשת נכון במידע וכד'.
   ו. מקרי קצה. הכנסת ערכים גבוהים או שליליים או נמוכים, תמונה במקום של טקסט וכד'.
   ז. בדיקה שכל היישומים הרשומים בדרישות נכנסו (ברור למה) וגם מה שאינו שם לא נכנס (לכרואה יופי, עוד פונקציונליות, אבל אם זה לא רשום זה לא ייבדק כראוי ויביא לתלונות מרובות של המשתמשים).
   ח. אינטגרציה עם אפליקציות אחרות. אם המוצר שומר למשל קבצי אקסל, יש לפתוח ולראות תאימות.
4. בדיקות מערכת:
   א. האם יש התראות לכל בעיה שצצה?
   ב. שימוש בבסיסי נתונים גדולים.
   ג. בדיקות עומס.
   ד. security.
   ה. ביצועים.
   ו. שימוש במשאבי מערכת.
   ז. התקנות.
   ח. recovery. של המערכת.
   ט. recovery. של נתונים.
   י. מהימנות. עבודה לאורך זמן.
   יא. רשיונות (גם של צד ג').
   יב. תאימות לדרישות.
   יג. האם זה באמת נותן ללקוח את הכלים שלהם הוא זקוק?
5. acceptness tests או ATP, או GFAT. בדיקות סופיות של המוצר מהקיט הסופי. התקנה וריצה על פונקציונליות מרכזית, קיימת וחדשה.

שתי קטגוריות עיקריות של הבדיקות

הכונה בהגדרות הרמה הגבוהה ביותר.*

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

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

*הרשומה עודכנה אחרי שהשתכנעתי מההערות למטה לגבי המינוח המקובל כיום (תודה למגיבים).