מיגרציה מ-Quality Center ל-Jira חלק שלישי: המעבר של הבאגים

חלק קודם

הפעם אספר על ההעברה של הבאגים לג'ירה, על המיגרצה עצמה.

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

הצורה בה מייצאים מ-QA ומייבאים לג'ירה

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

במהלך התהליך, יש ליצור מיפוי בין השדות (העמודות) של ה-QC לאלו של הג'ירה, ועל כך בהמשך.

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

דבר אחר שלא ניתן לייצא הוא את את ה-attachments לקובץ האקסל, ולצערי באופן עקרוני לא ניתן ליצא אותם.

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

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

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

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

למה רק אותן - בכדי לא להקשות על המיפוי.

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

1. האם שמות המשתמשים ב-QC זהים לאלו בג'ירה? למשל ייתכן ששמות המשתמשים ב-QC הם שמות שנשמרים לוקלית בשרת, ואילו הג'ירה מחוברת ל-Active Directory, כלומר למאגר שנות העובדים כפי שניתן לראות ב-Outlook למשל.
זה הזמן למפות את השמות של ה-QC ל-AD.

2. יש שדות ב-QC ששם מאוחסנים מספר ערכים שונים, כמו למשל ה-label בג'ירה שבו ניתן לשמור מספר מילות מפתח.

לדוגמא: שדה ב-QC בשם labs ששומר ערכים של כל המעבדות שבהן הבאג משתחזר - lab a, lab b.

בתהליך המיגרציה, אחרי המיפוי של השדות, כל הערכים בשדה ה-labs ימוזגו לערך אחד של "lab a lab b".

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

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

להלן דוגמה:

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

אני השתמשתי בתוסף בתשלום לשם כך בשם ablebits.

מידע חשוב: הערכים שעובדים בשדה בעצם נשמרים, כלומר שכנדווח על באג חדש כבר בג'ירה, נוכל לבחור בין המעבדות lab a, lab b, lab c וכן lab d, ערך אחד או יותר, לפי הגדרת השדה בג'ירה.

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

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

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

אם סיימנו כאן, נעשה המרה של קובץ האקסל ל-CSV.

תהליך ההמרה

למידע מפורט לחצו כאן.

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

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

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

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

המיפוי

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

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

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

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

למשל: פריוריטי ב-QC היא מילולית (למשל: showstopper, High, Medium and low) והג'ירה מספרית (1 עד 4). במקרה הזה נמפה בין הערכים ובג'ירה showstopper יופיע כ"1".

המיגרציה

במסך הבא ההמרה תעבוד.

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

זהו זה לגבי הבאגים. אני מקווה להמשיך בנודע ל-test cases בעתיד.

מיגרציה מ-Quality Center ל-Jira חלק שני: הכנות למעבר של הבאגים

לחלק הראשון

הערה כללית: המאמר עוסק במיגרציה עצמה ומניח שהקורא מכיר את המונחים הבסיסיים בג'ירה וב-Quality Center (להלן QC).

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

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

הכנות כלליות

יצרתי עץ מסמכים ב-Confluence, עוד מוצר של Atlassian שנועד ליצור עבודה משותפת בין גורמים שונים וכלי לניהול מסמכים וידע.

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

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

הכנות בג'ירה

פרויקט

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

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

Issue Type

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

שדות

אחרי יצירת ה-Issue Type, הדבר הבא היה ליצור את השדות שהחלטנו שאנחנו כן נעביר מה-QC ושנשתמש בהם גם לדיווחים חדשים.

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

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

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

הפתרון שלנו נחלק לשניים:

1. הפתרון הטכני: Cascading Fields - שדה שבא עם ג'ירה. הוא מחבר שתי רשימות בלבד, אבל בהחלט פתרון לחלק מהנושאים שהיו לנו. ישנו פתרון אחר בתשלום מה-מרקט שנותן להכניס מספר רב של רשימות מקושרות. אפשר להשתמש בשדה רב-ערכי כזה בשאילתות JQL ובתוספים של דוחות כמו Rich Filters וכן eazyBI. כדם יש פתרונות בייבוא של שדות כאלה מה-QC לג'ירה.
2. הפתרון ההתנהגותי: כאמור וברוח האג'ייל אנו רוצים לפשט. אולי לא באמת יש צורך בכל הרשימות האלה.

אנחנו השתמשנו בשני הפתרונות במקרים שונים.

חלק מהשדות ב-QC היו מנדטוריים ואת חלקם הפכנו לכאה בג'ירה (המינוח בג'ירה הוא Required field).

יצירת Workflow (להלן WF)

החלטנו לא לשנות מאוד את ה-WF כיוון שמה שהיה היה סביר ולא מורכב מידי.

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

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

במאמר הבא אעבור על המיגרציה בפועל.

מיגרציה מ-Quality Center ל-Jira חלק ראשון: אסטרטגיה

הגיע היום גם אצלנו לעבור מה-Quality Center, להלן QC, שהיה בעבר של מרקיורי, אח"כ של HP וכיום של מיקרופוקוס, לג'ירה.

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

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

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

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

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

חלק ראשון: אסטרטגיה

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

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

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

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

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

ריכזתי ב-Confluence את כל סוגי ה-defects שיש לנו, את כל הפרוצדורות וה-workflows שאנו משתמשים בהם.

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

בחלק הבא נעסוק בחלק היותר טכני של המעבר.

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

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

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

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

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

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

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

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

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

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

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


פתרונות?

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

הניסיון שלי באוטומציה במערכות גדולות

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

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

השאלה הראשונה הינה באיזו אוטומציה מדובר - בדיקות יחידה (Unit tests)? בדיקות קומפוננטה? בדיקות קצה לקצה (E2E)?

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

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

האסטרטגיה

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

אמינות

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

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

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

דוחות

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

דיבגביליות

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

קלות ההרצה

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

יעילות

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

מהירות

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

רובסטיות של הקוד

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

הדבר החשוב ביותר באסטרטגיה

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

עוד כמה פרטים:

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

סיכום

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

משפט השדה של בודק התוכנה

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

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

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

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

הפלואו היה שכאשר ביצעת חיפוש, סרגל הכלים הוסיף את המקור לכתובת האתר ומשם משצר בבסיס הנתונים. לדוגמה, חיפשת את המילה "כלב" מטאב חדש. החיפוש יתבצע ותראה את התוצאות בדיוק כמו בחיפוש Google, ולכתובת האתר יתווסף פרמטר כמו source=NewTab (או source=AddressBar במקרה החיפוש היה דרך שורת הכתובת, וכו').

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

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

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

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

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

לאחר ניתוח הבעיה, מצאנו את הסיבה:

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

2. בעיית הנתונים שחסרו נבעה מכך שבטבלה החדשה חסרו כמה עמודות.

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

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

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

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

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

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

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

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

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

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

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

מה אתם חושבים? האם החמצת הבאג היתה באשמתי? האם התנהגתי נכון?

STR מי מה ומתי

STR = Software/System Testing Results/Report

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

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

מדוע צריך STR?

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

אחריות:

מנהל הבדיקות / הבודק בקבוצת האג'ייל.

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

דוגמא ל-STR מתוך Testrail:

מחזור החיים של ה-STR?

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

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

הצורה האופטימלית:
ל-STR להכיל מבנה זהה של מסמכי הבדיקות כולם, כולל כל ההיררכיה - מרמת החלוקה לתת-מוצרים וה-tests groups עד לצעדים הבודדים.
בכדי שיהיה לנו ערך מהתבוננות ב-STR על כל צעד יש לרשום: עבר / נכשל / לא הורץ / blocked.
אם צעד נכשל יש לרשום: מס' באג, את חומרתו, ולציין את הסטטוס שלו. יש להדגיש באגים פתוחים. אם הבאג נסגר - יש לעדכן את המסמך.
אם לא הורץ - מדוע? בגלל באג / חוסר בזמן / עוד לא הגענו אליו. כדאי להוסיף מועד הרצה עתידי (גם כשזה בגלל באג כלומר blocked).
כדאי להשאיר מקום להערות.
עדיף כלי מדורג, כלומר כזה שיכיל את כל הבדיקות עד לרמת הצעד הבודד, אבל שניתן לצפות בו ברמות שונות. כלומר: סך ההרצות, רמת נושאי הבדיקה עד לצעד הבודד. אם test case עבר, אין צורך שכל הצעדים יהיו פרושים כ-default.
כמובן שאם יש אפשרות לשמירת גרסאות זה מצוין, כאשר הכוונה של סבבים. כלומר אם הריצו מסמך פעמיים שיישאר תיעוד של שתי ההרצות ולא רק של האחרונה.
בנוסף יש להכניס כל מידע רלוונטי: סביבת הבדיקות, קונפיגורציה, גרסאות ועוד.

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

מה עוד ניתן לצרף ל-STR?
אני הייתי מצרף את הסטטיסטיקה (כלומר גרפים) שתמחיש את מצב תוצאות הבדיקות:

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

מה גורלו של ה-STR?
בסוף גרסה עוברים עם מנהל הפרויקטים וכל מי שמעורב בגרסה ברמה הניהולית כולל איש SQM* אם יש על הנושאים הפתוחים ב-STR ומחליטים אל מול ה-STR ושאר נתוני ה-exit criteria אם הגרסה בשלה לצאת.

אם מישהו בכל זאת רוצה תבנית של טופס STR "כמו פעם" - https://strongqa.com/qa-portal/testing-docs-templates/test-report

*SQM - System Quality Manager - אחראי לאיכות תהליכי פיתוח רוחביים, לא לבדיקות.

פורסם במקור: Jul 1, 2015 ועודכן כעת.