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

האם האג'ייל מילא את הבטחתו בנוגע לבדיקות התוכנה?

מוטו: שיטה שתצליח צריכה להתאים לבני האדם, ולא להתאים את בני האדם לשיטה.

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

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

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

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

להלן הכישלונות של Agile מבחינת הבדיקה:

הבידוד של הבודקים

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

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

היעדר ביקורת

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

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

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

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

מנהיגות

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

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

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

קריירה

אולי לא קשור למשימות היום-יום, אבל מתכנת בעולם Agile יכול לשנות את עמדתו להיות CTO למשל. מה התפקיד הבא של הבוחן?

בהשפעת המחויבות הקבוצתית

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

תצוגה ברמת המערכת

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

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

דברים אחרים שמנהלי QA עשו וחסרים ב- Agile

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

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

"Test automation is a craft (discipline) of its own, requiring specific skills. It takes time, effort, and dedication to become good at it and therefore isn’t something that can be done “on the side,” even if you're the best developer ever."

Arnon Axelrod - Complete Guide to Test Automation, p34

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


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

הכנה לקבלת build חדש

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

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

מעבדה:
- מעבדה מוכנה: מערכות תקינות, אודיט, מה שאמור להיות מותקן אכן מותקן ועובד.

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

Build מוכן - לפי חשיבות:
-  Sanity.
-  ווריפיקציה של באגים.

-  פרוגרסיה.
- רגרסיה.

טסקים יומיומיים:- פיקוח על באגים.
- פיקוח על ביצוע הבדיקות.

Clean Pass

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

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

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

בניית מערך בדיקות

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

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

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

וכמובן על צוות הבדיקות: במה הוא טוב, במה פחות, מקצועיותו ככלל ויכולתו האישית של כל בודק ובודק.

תחילת העבודה:

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

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

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

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

הטוב ביותר לקחת את המסמך של הבעיות, נניח אקסל, ולמלא בו את הפרטים הבאים:

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

נניח:

מס': 1. בעיה: 12% באגים מתגלים אחרי שלב הבדיקות. מטרה: 5%. אחריות: *, הדרך: א. הצלבת הדרישות והבדיקות, ב. בדיקה סופית מקיפה וכד', תוכנית מקיפה תהיה מוכנה ב1.6, תמומש ב1.7

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

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

בדיקות קומפוננטה

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

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

יתרונות:

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

חסרונות:

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

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

Orthogonal Defect Classification - ODC - חלק שני

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

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

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

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

נניח ש-80% מהגרסה, וזה מצב הבאגים שנפתחו מבחינת ה-impact:


1. Installability : 18/2
2. Serviceability: 23/13
3. Standards: 4/0
4. Integrity/Security: 6/0
5. Migration: 15/2
6. Reliability:30/11
7. Performance: 2/1
8. Documentation: 9/2
9. Requirements: 13/3
10. Maintenance: 1/1
11. Usability: 4/2
12. Accessibility: 8/0
13. Capability: 38/8
למשל בעיות התקנה: 18 דיווחי באגים נפתחו, 2 עדיין פתוחים.
אפשר לראות ששלושת הבעיות העיקריות שהתגלו היו ב- Capability, ב- Reliabilityוב- Serviceability.
עכשיו אפשר לפרק ולהצליב עם מידע כמו הקומפוננטות הרלוונטיות בהן יש יותר בעיות מהסוגים הנ"ל, לשאלה אם הבעיות הן בקוד חדש או ישן וכד'. מכאן התובנות צריכות להיות שלכם.

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

דבר מעניין שאפשר לעשות הוא לסווג את מסמכי הבדיקות לפי ה-impact. ואז נשאל שאלות כגון אלה:
• האם מרבית הבאגים התגלו ב"ריצה" על המסמכים או בבדיקות חופשיות?
• האם אנו בודקים מספיק את נושא האמינות ושאר המקומות המועדים לפורענות?
• האם אנו מדוחים על באגים בדרישות
וכו'.

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

Orthogonal Defect Classification - ODC - חלק ראשון

המאמר המקורי מכאן.

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

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

תהליך הישום של ה-ODC:

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

מיון ואימות של הבאגים

ישנן שתי נקודות של מיון.

הראשונה כשהבאג מתגלה. מגלה הבאג ממלה מאפיינים של הפעילות (activity) בה התגלה הבאג, מה שעורר (trigger) אותו, והשפעה (impact) שלו.

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

השנייה היא בעת תיקון הבאג. המאפיינים הם המטרה (target), סוג הבאג (type), המתאר (qualifier), מקור (source) וותק (age).

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

למידע נוסף לחצי כאן.

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

הערכת המידע

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

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

מי שרוצה כללים יותר פרקטיים ליישום ילחץ כאן.

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

הבדיקות מול סביבות העבודה השונות: פיתוח, בדיקות ולקוח

בעיקרון יש שלש סביבות של עבודה הרלוונטיות לצוות הבדיקה:

סביבת הפיתוח;
סביבת הבדיקות (ידוע כ-staging);
סביבת לקוח (ידוע כ-production).


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

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

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

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

סביבת הבדיקותבין אם היו סבבי בדיקות בסביבת הפיתוח או בין אם לאו, יש לעבור סב מסודר של בדיקות בסביבת ה-staging. ייתכן שיהיו בעיות שכלל לא נתקלו בהן בסביבת הפיתוח ולא רק בשל הקונפיגורציה השונה. בסביבה זו מצופה רמת בשלות מצד המוצר (בין עם עזרנו לפיתוח ובין אם נתנו להם מסמך שאומר: X, Y ו-Z צריכים לעבוד אחרת אין לנו מה לעשות עם המוצר). כאן עושים סבב בעוד הפיתוח עסוק בתיקון הבאגים החדשים ושאריות של באגים קיימים אם יש. מידי פעם יש לעלות גרסה חדשה מסביבת הפיתוח לסביבת הבדיקות עם תיקונים. אם אכן המוצר בשל אין צורך בהעלאה יומית בכדי לחסוך את האריזה וה-sanity, שאותו יש לקיים על כל עלייה של build חדש.
אין חובה לבדוק את כל הבאגים שנסגרו בסביבת הפיתוח אלא את המשמעותיים. ההנחה היא שממילא תוכנית הבדיקה כוללת את כל התסריטים כולל אלו שיצרו את הבאג מלכתחילה, או שמדובר בבאג שיש רק סיכון נמוך שיחזור או שהשפעתו בטלה בשישים.
בדיקות קיט: בסוף תהליך הבדיקות יש לנקות את סביבת הבדיקות, לקחת את דיסק התקנת המוצר ולהתקין כמו כל לקוח לפי ההוראות ולוודא שה"דבר" עובד (כן, שוב sanity).

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

טרייסביליות

כיום יש כלים טובים (למשל ב-Quality Center) למעקב אחרי דרישות. אני אתייחס לצדדים החשובים, תהא ההטמעה אשר תהא.

אביא כאן את העיקר:

1. כל הדרישות חייבות לבוא משלב ה-MRD עם סעיפים, סעיף פר דרישה, ת-סעיף לתת-דרישה, וכל סעיף צריך להיות עם סמן ייחודי (נניח MRD-403-24-001, MRD זה המסמך, 403 זו הגרסה, 24 הסעיף ו-01 הוא תת-הסעיף). מומלץ לקפוץ בין מספרים בהפרש מסויים, למשל מ-01 ל-05, למקרה שמשהו ישכח.
2. יש למפות כל דרישת השיווק (MRD) לדרישה של מהנדס המערכת (SysRD). לכן דרישות המערעת אמורות להיות:
   SysRD-403-24-01 בהתאמה. אם יש יותר סעיפים כאן אפשר להוסיף בסוף a, b וכד'.
3. יש למפות כל דרישת מהנדס מערכת לדרישה של הפיתוח. שוב - אותו פורמט של מספרים.
4. יש למפות כל דרישת מהנדס מערכת לדרישה של בדיקות. שוב - אותו פורמט של מספרים.
5. מסמך הבדיקות יכלול קישור גם למהנדס המערכת וגם למסמכי הפיתוח.
6. יש למפות את הבאגים למסמך הבדיקות.

מה יוצא לנו מזה?

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

הגדרות: בדיקת תוכנה

1.The process of executing a program with the intention of finding errors.

2.The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product.

3.Process of evaluating a system or a component to determine whether the product of a given development phase satisfies the conditions imposed at the start of that phase.

*SUT - system under test