XRAY for Jira: סוגי הדוחות השונים (בהיי לבל)

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

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

XRAY for Jira: מהרפוזיטורי לאקסקיושן

 ה-XRAY, בהיותו בנוי בתוך הג'ירה ויורש של תכונות רבות שלה, הוא גמיש ומאפשר לעשות את אותו הדבר בדרכים שונות.

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

בשך כך בניתי סרטון הדרכה שבו ניתן לראות דרך שנראית לי מאוד נוחה שבה ניתן לעשות את התהליך הזה:

מטסט ריפוזיטורי להעביר טסטים לטסט פלן ומשם ליצור טסט אקסקיושן.

XRAY for Jira: Parameterized Tests הסבר על הפיצ'ר החדש (וידאו)

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

חלק ראשון - פרמטרים רגילים:

חלק שני - פרמטרים קומבינטוריאלים:

Test Management Tools battle in Jira: SynapseRT VS Xray - קרב מנהלי הבדיקות בג'ירה

סיפרתי על ההעברת הבאגים מה-Quality Center לג'ירה בעבר. אבל מה עם הטסטים?

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

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

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

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

מטריקס הביאו שתי אפשרויות: synapseRT ו-Xray.

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

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

https://drive.google.com/file/d/1-APc1lM6pVrGtyCZ_vX6NkbtGmRfAZqs/view?usp=sharing

בודק יקר, לעולם לא תבדוק כמו שמשתמש מתנהג

"By that experience Tukey and I discovered that what goes on in different people’s heads when they think they’re doing the same thing—something as simple as counting—is different for different people."

Feynman, Richard P.. "What Do You Care What Other People Think?": Further Adventures of a Curious Character (p. 59). W. W. Norton & Company. Kindle Edition. 

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

זה לא המקרה של בדיקות תוכנה.

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

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

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

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

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

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

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

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


פתרונות?

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

תעלומת החולצה הכחולה

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

  

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

  

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

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

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

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

תעלומת החולצה הכחולהתעלומת החולצה הכחולה

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

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

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

  

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

תרגול "רטוב" של כישורי הבדיקה שלכם

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

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

הלינק: http://adam.goucher.ca/parkcalc

אין דיזיין, לכן אקספלורטורי קלאסי.

כמה באגים מצאתם?

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

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

• קודם כל אם באמת הכוונה להציג למישהו, אז צריך להחליט מראש מה היו בדיוק הסנריו שיוצגו, ולעשות את מרב הבדיקות עליהם ועל סביבתם הקרובה. אבל זו הייתה רק דוגמא.
• 30 דקות: כן חשוב לדבר עם מנהל המוצר ולהבין את מטרת המוצר, שימוש "רגיל" של משתמש קצה וכד', לרשום שימושים חשובים / נפוצים.
• 30 דקות: לדבר עם הפיתוח (שמן הסתם יודע יותר מאיתנו כי בלי להסביר לו הוא לא יוכל לפתח) שבוודאי יודע היכן המקומות הפגיעים ומה חשוב שיתבצע. לצרף לרשימה הקודמת.
• לנסות לקבל כמה שיותר expected results שאפשר מהגורמים לעיל.
• 15 דקות: לסגור את הרשימה של הדברים חשובים ביותר לבדיקה ולסדר לפי סיכונים.
• לוודא שכולם בסביבה וזמינים לעזרה מיידית.
• 45 דקות: מעבר ראשוני על התוכנה. פשוט לעבור עמוד עמוד, תפריט תפריט, ובזריזות. נכון שזה נשמע כמו בזבוז, אבל זה ייתן לך קצת פרספקטיבה על המוצר ויאתר בעיות בסיסיות ביותר. אפילו פונקציה חשובה פחות כמו מה חדש תתגלה כחשובה מאוד אם היא מקריסה את המערכת או מראה טקסט של מפתח משועמם שהיה צריך לכתוב כמה מילים כתופסי מקום והא כתב משהו על המקצוע של אחותו של העמית שלו.
• עברו שעתיים יקרות מאוד, כי בעיות צריך לתקן ואח"כ לבדוק, אז מתחילים לחפור. מתחילים בפעולות קלות ועוברים לקשות. רבע שעה ראשונה עדיף שר"צ הפיתוח או מנהל המוצר יישבו איתך ופשוט יעקבו אחריך. את התוצאות צריך לשמור, אפילו ב"קצרנות" על נייר. כל דבר שלא ברור תוך 5 דקות - בניגוד לבד"כ כשמומלץ לנסות ולהבין יותר לעומק - ללכת לפיתוח/מנהל המוצר ולשאול. כל באג - לכתוב ולתת עדיפויות. באג שחייבים לתקן, ללכת במיידי לפיתוח, להציג, לוודא הבנה ושהתיקון מיושם במקום, לחזור ולהמשיך בבדיקות.

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

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

הבעיה של בדיקה רק לפי תסריט

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

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

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

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

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

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

בסופו של דבר, אלו הנתונים:

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

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

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

באג ה-32, או: איך לבודד באג

בתפקידי הראשון בתחום, ולמעשה בשבוע הראשון, בדקתי אפליקציה אשר מתממשקת ל-Outlook, כלומר אתה פותח את האאוטלוק ומוצא מודולים נוספים שאנחנו הכנסנו בתחום של CTI, שזה Computer Telephony Integration.

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

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

לקח: האם בפועל זה יעבוד?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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