LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

סקירת כלי ניהול בדיקות ובאגים: Lean Testing

נכתב על ידי 
ראשון, 23 אפריל 2017 12:44
דרגו כתבה זו
(3 הצבעות)

LeanTestingLogo

          Lean Testing

     כלי לניהול בדיקות ובאגים:

 

טוב אז אני אתחיל ואכתוב שהסיקור הזה נולד אחרי פוסט שהעליתי בפייסבוק בחיפוש אחר כלי/מוצר שיחליף
את Lean Testing בחברה שבה אני עובד.

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


קצת על הכלי:

Lean Testing הינו כלי לניהול בדיקות ודיווח ומעקב אחר באגים.
הכלי מפותח כחלק מסל שירותים שמציעה חברת crowdsourced testing אשר כמו ששמה מציין מספקת שירותי crowd source בתחום הבדיקות.
הכלי הינו כלי חינמי כאשר בגרסה זו הוא מספק כמעט את כל השירותים הקיימים מלבד מספר אפשרויות "משחק" וקוסטמיזציה אשר נפתחות רק לאחר שמשלמים סכום חודשי שיכול לנוע בין $5 ל- $30 תלוי ברמת "חופש הפעולה" שהארגון צריך.

אז זהו עם ההקדמה, עכשיו תכלס.

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

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

דבר שני: כמה מאמץ יצריך הכלי מהאדם שהולך להטמיע אותו בחברה בתהליך ההטמעה וכמובן מה המהירות שבה הכלי יוצר הרגשה של "אני בבית עם הכלי הזה – איך חייתי עד עכשיו בלעדיו?" אצל המשתמשים בו.

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

יאללה מתחילים :)

1. פרקטיות ושימושיות הכלי, האם הוא יתאים למה שאני מחפש?

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

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

  1. הכלי צריך להיות כלי שמבוסס כולו ב- cloud בעל גישה נוחה במחשבים ובטלפונים ניידים כאחד.
  2. הכלי צריך לכלול גם יכולת של ניהול בדיקות וגם של דיווח ומעקב אחר באגים ללא צורך בכלי נוסף.
  3. הכלי צריך לספק תצוגה ברורה של סטטוס, כמות וההתקדמות בעבודה על הבאגים.
  4. הגישה לכלי צריכה להיות מהירה ואינטואיטיבית, לא אמורה להיות דרך שבה משתמש יכול "ללכת לאיבוד".
  5. הממשק של הכלי חייב להיות יפה (כן....) ולספק למשתמשים חווית שימוש חיובית כאשר הם משתמשים בו.
  6. מעבר בין סטטוסים של באגים צריך להיעשות בכמה שפחות לחיצות.
  7. הכלי צריך לספק ממשק נוח ומהיר לדיווח באגים, כזה שלא ירתיע אנשים (שהם לא אנשי QA) מלדווח באגים.
  8. הכלי צריך לספק ממשק נוח ומהיר לכתיבה והרצה של בדיקות ידניות – כולל סיכום תוצאות.
  9. אינטגרציה עם Slack, Github, Bitbucket ושליחת התרעות במיילים.
  10. --עדיף אבל לא חובה-- יכולת הרצת בדיקות אוטומציה.

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

אני כן אוסיף ואכתוב שכמו ששמתם לב נושא ה- traceability בין הבאגים לדרישות לא עלה בין 10 הנקודות שבחרתי לציין וזאת מאחר והנושא לא הוגדר כ- Dealbreaker בגלל האופי שבו החברה עובדת. באותו הזמן שבו אנחנו הרצנו את הפיילוט ל-Lean Testing רץ גם פיילוט לכלי נוסף אשר נועד לניהול הדרישות והספציפיקציות - "notion.so" (סיקור נפרד יבוא בהמשך).

עכשיו כדי להסביר איך הגענו למצב שבו אנחנו מחפשים כלי כמו Lean Testin,ה-"למה?" שבסיפור.

לצערי אני יכול לסכם את זה במילה אחת - Jira.

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

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

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

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

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

 

2. "אני בבית עם הכלי הזה – איך חייתי עד עכשיו בלעדיו?"

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

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

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

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

- הנה צילום מסך של  Dashboard מפרויקט Demo שיצרתי כ- POC לשאר מנהלי החברה:

LT Dashboard

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

 

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

LT Bugs interface

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

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

  1. Closed
  2. Resolved
  3. New
  4. In Progress

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

 

- לחיצה על כל אחת משורות הבאגים המוצגים תפתח את מסך הצפייה/עריכה של הבאג:

LT edit bug

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

 

- בשני המקרים מסך דיווח הבאגים שנפתח הוא זהה ופשוט:

LT new bug

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

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

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

בסיום דיווח הבאג ולאחר שמירתו יופיע הבאג במסך הצפייה/עריכה של הבאג.

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

  • למשתמש (גם בגרסה שבתשלום) אין יכולת להוסיף שדות למסך הצפייה/עריכה של הבאג.
    קיימים שני שדות אשר מתווספים באופן אוטומטי למסך זה כאשר הסטטוס של הבאג משתנה לסטטוס Resolved (השדה Fixed in version) וכאשר הוא משתנה לסטטוס Reopen (השדה Reopened in version).
  • אין אפשרות לשמור template של דיווח באגים, אך לעומת זאת במידה ונעשה clone לבאג הדברים היחידים שנהיה צריכים לעדכן הם שדות הטקסט החופשי והצעדים לשחזור (במידה והם שונים).

 

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

- נתחיל עם ה- Dashboard של ממשק ה- Test Suites:

LT tests dashboard

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

  • תוצאות של ריצות קודמות
  • שינויים אחרונים שנעשו ב-test case.
  • התחלת ריצה חדשה
  • עריכה/הוספה של בדיקות

 

- נעבור למסך ההוספה/עריכה של בדיקות:

LT test case write

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

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

 

- נמשיך למסך יצירת Test Run:

LT test run start

נקודות חשובות:

  • הוספה ידנית של בדיקה או הוספה לפי קטגוריה (component).
  • תצוגה של ה-priority שניתן לבדיקה כשכתבו אותה (הפסים בצד ימין).
  • היכולת להוסיף גרסה חדשה גם מהממשק הזה!
  • שיוך בדיקה לאדם אחר בצוות הבודקים על-ידי שינוי הערך בשדה Create as.

 

- לסיום מסך הרצת הבדיקות:

LT test run actual

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

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

אבל בשביל להיות הוגן הנה כמה כותרות:

  • יצירת קבוצות (פרויקטים) בשביל Beta Testers חיצוניים
  • הרצת בדיקות אוטומציה עם Selenium IDE
  • שילוב של Mobile SDK
  • Conversations לכל פרויקט
  • וכמובן הגדרות הארגון והמשתמש.

 

ועכשיו לחלק השלישי והאחרון...

 

3. היכולת להיות עצמאי עם הכלי לעומת קהילה אקטיבית ותמיכה טכנית...

"למה???!!!"

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

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

אבל כמו שכולנו לומדים בחיים, "שום דבר הוא לא מושלם" וככה גם Lean Testing.

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

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

"ככה זה כאשר המוצר הוא לא מה שמכניס את הכסף לחברה" אמר לי חבר ומנטור יקר.

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

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

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

 

אז לסיכום:

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

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

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


ציונים:

מענה לצרכים של החברה: 8/10
נותן למשתמש חווית שימוש טובה: 10/10
תמיכה וקהילה: 3/10

סה"כ ציון: 7


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

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

meme small

שונה לאחרונה ב שני, 24 אפריל 2017 09:13

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • How to avoid missing a bug

    I found Kristin‘s article about how she forgot to retest a bug very funny. Not because it is a joke but because I recognised myself in her story. When others find a bug in 5 minutes, that were there just under my eyes during my one hour session, I cannot avoid feeling bad. And often, those bugs are not tricky ones, they follow a clear pattern, as if the tester would know where the bugs hide — which can be a developer, some developers are very good at testing.Bugs are gregariousWell, in fact, it is exactly how issues behave. Bugs follow predictable patterns: they like to hook to some behaviours or some modules in the product or some kind of features. When one of those actions or place reveal an unexpected behaviour, you can bet a cookie that you will find similar ones if you continue digging. And you will have a delicious breakfast next day. Same issue elsewhere, other issues near to the first one. Bugs, like zombies, feel stronger when they piece together. And when you think of it, this is obvious: the same bugged code can be called in several parts of the application. Some contexts are not well handled by some frameworks or browsers. (Please be patient, I’ll come with concrete examples in the last section.)The power of heuristicsThe fact to find patterns in bugs and to foresee, not with certainty but at least with confidence, a possible weakness in the context of an application has a name. It[…]

    19.09.2019 | 3:51 קרא עוד...
  • Five Blogs – 19 September 2019

    The (best) five blogs I read today. Check them out. How To Spot a Faker Written by: Matt Heusser If Strategy Is So Important, Why Don’t We Make Time for It? Written by: Dorie Clark 10 Brain Training Exercises To Boost Your Brain Power Written by: Michael Gornam What can testers and developers learn from each other? Written by: Lisa Crispin Testing in DevOps Written by: Matthew Bretten Quote of the day: “If you think adventure is dangerous, try routine. It is lethal.” -Paulo Coelho You can follow this page on Twitter

    19.09.2019 | 12:45 קרא עוד...
  • Don't No

    Don't No We've all been there: frustrated by a request from a stakeholder for what we take to be significant new work without regard for the scale of it, the time it would take, or the current backlog.Recently, a colleague in that situation and ready to scream "NOOOOO!!!!" asked for my advice. What I said boiled down to this: Step back and think of at least three ways that the request could be interpreted. Sketch rough ideas for how you could do each of them, at what cost, with what compromises.  Share them with your stakeholder to clarify their desires and help them to guide the next steps. This is essentially Jerry Weinberg's rule of three and orange juice test so I claim no great novelty here. What I do claim is that I feel a lot better when I follow these steps than when I instinctively reject some request based on poor assumptions and no conversation, landing myself in a needlessly defensive position.P.S. just to make this harder, don't forget that you could also be misinterpreting and underestimating requests that you say "yes!" to. It just doesn't usually feel so bad (at the time).Image: https://flic.kr/p/2etM44v

    19.09.2019 | 12:39 קרא עוד...

טיפים

  • מבט מערכתי לבודקים – Systems Thinking
    מבט מערכתי לבודקים – Systems Thinking מבט מערכתי לבודקים – Systems Thinking התכונה או מערכת אותה אנו בודקים - אינה מנותקת משאר העולם, תיקון בנקודה אחת – עשוי להשפיע ולפגוע בנקודות אחרות, ולכן על הבודק להכיר את המערכת והקשרים בין חלקיה. כמו…
    קרא עוד...
  • לא יודע מה לבדוק?
    לא יודע מה לבדוק? לא יודע מה לבדוק? עצור,  קח הפסקה קלה, ענה על השאלה:   "למה אני בודק?"   טיפים מחברי ITCB-AB
    קרא עוד...
לרשימה המלאה >>