ביקורת ספר: Lesson Learned in Software Testing

הספר Lessons Learned in Software Testing: A Context-Driven Approach פורסם בתחילת 2002 (31 בדצמבר 2001, ליתר דיוק) על ידי הסופרים קם קנר, ג'יימס באך, וברט פטיצ'ורד.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה מיוחד בבדיקות מובייל - ומה צריך לבדוק בפועל

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

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

על הסביבה - מכשירים ומערכות הפעלה
אפליקציות באנדרואיד מפותחות בג'אווה. ב-iOS הן מפותחות ב-swift ו Objective C.
יש 3 סוגי אפליקציות:
- אפליקציות נייטיב - נכתבו בשפה שבה אפליקציות בנויות על המכשיר (נניח ג'אווה באנדרויד). כך קל יותר לאפליקציה להשתמש במשאבי המערכת ובפיצ'רים שלה.
- הייבריד: גם בשפה של מערכת ההפעלה וגם בטכנולוגיות ווב כמו HTML ו-Java Script.
- אפליקציות ווב: מורצות ע"י דפדפן.

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

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

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

אפשר לשכור מכשירים או מעבדות מבוססות ענן כל עוד מדובר גם במכשירים אמתיים.

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

http://www.keynote.com/solutions/testing/mobile-testing

http://mobilelabsinc.com/

https://www.perfectomobile.com/

https://saucelabs.com/

https://testobject.com/https://www.xamarin.com/test-cloud

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

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

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

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

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

וכן:
שימוש במיקרופונים.
מצלמה.

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

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

יוזביליטי - מבחר מקורות:

https://www.nngroup.com/books/mobile-usability/ ספר

http://www.neobytesolutions.com/mobile-user-interface-and-usability-design-principles/

https://www.usability.gov/what-and-why/index.html

https://www.thinkwithgoogle.com/topics/create-better-mobile-user-experience.html#mobile-best-practices

https://www.nngroup.com/articles/mobile-usability-update/

https://www.nngroup.com/articles/ten-usability-heuristics

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

צריכת הסוללה
חשוב לבדוק את צריכת הסוללה של האפליקציה שלך.
בדיקה אחת היא במכשיר "נקי" לפתוח את האפליקציה ובזמן שהיא נראית בטלפון להניח אותו שיעבור ל-standby (כלומר ריצה ב-foreground). יש לבדוק על מספר מכשירים. יש לבדוק ריצה ב-background. בדוק את מצב הסוללה במכשיר מדי פעם.
יש לבדוק מצבי סוללה בזמן שימוש ביכולות של הטלפון כמו GPS. יש לוודא שהאפליקציה מפסיקה להשתמש בהם כשהיא לא צריכה אותם יותר.
בדיקת של תקשורת מיותרת. ניתן לבדוק עם:

http://www.telerik.com/fiddler

או

https://www.charlesproxy.com/

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

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


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

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

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

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

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

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

רזולוציות ו-densities.

רשתות שונות
(LTE, 3G, EDGE, GPRS, WiFi)Airplane mode
סגירת תקשורת בעת תקשורת לשרת, אח"כ פתיחת תקשורת ורפרוש
ספקים שונים

חתימות נכונות

יוריסטיקות למובייל:
SFDEPOT
FCC CUTS VIDS
I SLICED UP FUN
COP FLUNG GUN

מיינדמפ

http://www.ministryoftesting.com/2012/06/getting-started-with-mobile-testing-a-mindmap/

או

http://www.ministryoftesting.com/2012/05/mobile-testing-course-pictures-and-a-mindmap/

הקישור בספר אינו נכון, אגב.
וגם:

http://thetestingmap.org

עוד על איכות של מובייל:

http://www.appqualityalliance.org/

לגבי הדברים שאינם מיוחדים למובייל (מיקום, סנסורים וכד') כדאי לבדוק כמו בדיקות של PC.

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

http://www.testplant.com/eggplant/testing-tools/eggplant-mobile-eggon/

http://www.routinebot.com/

http://www.sikuli.org/

https://testobject.com/

יש כלים לזיהוי ע"פ קואורדינטות:

https://www.perfectomobile.com/

https://www.oracle.com/corporate/acquisitions/cloudmonkey/index.html

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

http://appium.io/

http://calaba.sh/

https://google.github.io/android-testing-support-library/

https://github.com/robotiumtech/robotium

http://selendroid.io/

http://docs.seleniumhq.org/

יש האפשרות של Capture and play עליה הסופר אינו ממליץ אחרי שניסה מספר אפשרויות כיוון שהיא לא אמינה בעליל. סומכת יותר מידי על ה-UI וזקוקה לתחזוק מתמיד.
ניתן להשתמש כנק' פתיחה לזיהוי האובייקטים.
לדעת המחבר ההבטחה שחברות מסוימות נותנות שקוד אחד יכול לרוץ על מספר מערכות הפעלה כמו אנדרויד, OS ווינדואוס פשוט אינו נכון.

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

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

בכדי להתחיל לכתוב אוטומציה באנדרואיד יש לדעת את היררכיית ה-view שלו ואילו קומפוננטות ואלמנטים ואיך האלמנטים מאורגנים על המסך ומה הם מייצגים למבנה הלוגי של האפליקציה. מידע נוסף - כאן.
יש כלי בשם UI Automation Viewer שמזהה את ה-ID של כל אלמנט.
בנוסף יש בספר 28 שאלות שיכוונו אותך לכלי המתאים ומידע על כלים אשר אותם לא אביא כאן (בכ"ז צרי להשאיר לכם איזה "אינסנטיב" לרכוש את הספר). אבל מכל הכלים המומלצים לאנדרואיד הם: רובוטיום, ספון, אפיום וסלנדרויד.
ב-iOS יש הכלים האלה: ios-driver, appium and Keep It Functional.

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

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

*למשל:

עוד חומר מעניין - ספרים של Eran Kinsbruner  מחברת Perfecto
https://www.amazon.com/s/ref=dp_byline_sr_book_1?ie=UTF8&text=Mr+Eran+Kinsbruner&search-alias=books&field-author=Mr+Eran+Kinsbruner&sort=relevancerank
הבלוג של ערן: http://continuoustesting.blog


עוד ביקורות קצרות על ספרי בדיקה שקראתי.

KPIs (Key Performance Indicators)- מתי כדאי, איך ואיזה

In God we trust; all others must bring data. W. Edwards Deming

חשיבותה של המדידה

בחברה מסוימת בה עבדתי הייתה בעיה: אחוז הפתיחה מחדש , ה-reopens, של באגים היה ממש גבוה.

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

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

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

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

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

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

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

לפי ווקי:

"מדדי ביצוע מרכזיים (באנגלית: Key Performance Indicators, בקיצור: KPI) הם מדדים על פיהם אומד הארגון את רמת ביצועיו. אלו יכולים להיות מדדים כלכליים ולא-כלכליים.

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

Add caption

אנחנו נתייחס ל-KPI של בדיקות.

אילו סוגי מדידות יש?

יש שתי סוגי מדידות.

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

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

If you can’t measure it, you can’t manage it. Peter Drucker

אילו מדידות חשובות?

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

לא בטוחים? הנה כמה נקודות למחשבה:

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

יש הגדרה ברורה ופשוטה (KISS).  

מקורות המידע אמינים.

השם ברור ומתייחס למדידה.

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

איך מודדים?

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

איך מציגים?

ויזואלית. בשעה שמציגים את הנתונים מומלץ להיות מוכן עם המידע הבא:

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

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

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

סכנות

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

אז צאו מהזחיחות ופתחו עיניים :)

תכיפות

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

מדידות בעידן אג'ייל

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

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

דוגמאות למדידות:

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

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

- המדידות שאני מתייחס אליהן הן של תהליכים ולא אנשים.

כללי
ה-KPI	איך	למה (או: מה יצא לי מזה)
כיסוי הדרישות מול תכנית הבדיקות	כמה דרישות מכוסות וכמה לא, כמה בדיקות יש לדרישה (1 - לא הגיוני, גם 100 לא).	בא להראות שלא פספסנו דרישות. מצד שני זה עלול להיות מטעה, כיוון שיכול להיות מספר סביר ביותר אך זה לא אומר שהבדיקות החשובות בפנים.
התקדמות הבדיקות	יכול להיות ב-burn down chart.	מסביר אם אנו עומדים בזמנים. בהחלט נתון עוזר, אבל רק כשלעצמו הוא לא אומר הרבה. כך גם נדע אם טעינו בהערכה ונוכל ללמוד להבא. בנוסף, נדע מחיר ריאלי של עבודה. טיפ: על כל תזוזה יש לכתוב הערה כי מרוב שהסביבה שלנו דינמית אפשר לשכוח אח"כ מדוע עוכבנו.
כמה בדיקות עברו וכמה לא	מערכת	כדי לדעת אזורים פחות טובים, אבל אני מעדיף לראות באגים ולא את זה כיוון שזה מורכב להבין מתוך "עבר / נכשל" מה זה אומר.
זמן אי-עבודה	רישום ידני	הרבה פעמים העבודה נעצרת בגלל חוסר תמיכה, מעבדות לא כשירות, חוסר דרישות ועוד. יש לכמת ואח"כ להתחיל למצוא פתרונות מהקריטי לקל.
דיווחי באגים
ה-KPI	איך	למה (או: מה יצא לי מזה)
גרף באגים פתוחים מול סגורים	שני קווים לאורך ציר הזמן	מדד ותיק אבל יעיל לפעמים. בא להראות את רמת המוכנות של הגרסה לשחרור. אמור להתחיל עם 0 סגורים והרבה פתוחים, הסגורים יעלו הפתוחים יצטמצמו, עד ששני הקווים יפגשו, ולבסוף מעט פתוחים הרבה סגורים. אפשר לציין בציר ה-X את תאריכי קבלת ה-buildים כדי לראות את השפעה שלהם מול קצב פתיחת הבאגים. גם בודק את יעילות הבדיקות או ניהול גרסה: הרבה באגים שנפתחים בשלב מתקדם: האם הייתה תכולה חדשה או הבודקים לא מצאו באגים משום מה בהתחלה?
מספר ה-reopens	אמור להיות במערכת	האם הפיתוח אכן תיקן את הבאג? האם תיאור הבאג היה מקצועי?
מספר הבאגים אל מול מספר דיווחי הבעיות מהשטח + באגים שהיו קיימים בגרסאות קודמות	ע"י ציון מיוחד בדיווח הבאג עצמו	יעילות של בודקים.
כמות ה-rejected bugs	אמור להיות במערכת	אם אין הרבה, אין בעיה. אם יש כדאי להבין מה הסיבה. -          האם חוסר הבנת הבודקים של המערכת? אולי כדאי לשפר את הידע הטכני והקשור לבדיקות -          אולי הבאגים אינם מתוארים בצורה מקצועית? -          אולי המפתחים כשלו כאן? -          שינוים תכופים בדרישות? -          בעיות שאינן משתחזרות? חשבו על לוגים טובים יותר למשל.
באגים פר פאזה של חיי מוצר.		למשל כמה באגים על דרישות, דוקומנטציה וכד'.
באגים לפי קומפוננטה או מרכיב לוגי כמו אפליקציה / שרת	רישום בדוח הבאג	אם יש מקום "מועד לפורענות" אולי כדאי להתעכב עליו יותר, אולי רה-פאקטורינג בא בחשבון.
באגים לפי ההשפעה שלהם.	רישום בדוח הבאג	פונקציונלי, התקנה ועוד. עוד דרך להבין ממה המוצר סובל מנקודת ראות גבוהה.
שינויי חומרה ודחיפות של באג	מערכת ניתור הבאגים אמורה לתת פתרון	האם הבודקים נוטים לדרמטיזציה של באגים או להמעטת ערך? אם הראשון, האם זה כיוון שבאגים חשובים לא מקבלים דחיפות גבוהה ונותרים בבקלוג? או אי הבנה של המערכת?
חומרה של באגים, דחיפות וכד'	מהמערכת	מצב הגרסה
אוטומציה
ה-KPI	איך	למה (או: מה יצא לי מזה)
כמה זמן לוקח לאוטומציה לרוץ מול בדיקות ידניות	רישום זמן של הקוד בתחילת וסוף ההרצה	יראה כמה זמן וכסף חסכנו
ROI במקרה של בדיקות ידניות מול אוטומטיות	מעקב אחרי שעות הפיתוח ואח"כ לפי המדד הקודם	כמה זמן השקענו בפיתוח אוטומציה ותוך כמה זמן תחזור ההשקעה
כמות התחזוקה	מעקב אחרי שעות התחזוקה	גם כאן להבין כמה זה עולה לנו והאם זה יעיל
באגים שלא נבעו מהמוצר	האם יש הרבה רצות שנכשלו בגלל באג באוטומציה ולא במוצר	נבין אם יש בעיה ובזבוז של זמן
זמן אי-עבודה	מדידה של זמן שהאוטומציה לא רצה בגלל בעיה בתשתיות	נבין אם יש בעיה ובזבוז של זמן
כיסוי הבדיקות האוטומטיות מסך היקף הבדיקות	אם יש מסמכי בדיקות אפשר לסמן מה אוטומטי ואז לכמת את מה שנשאר	גם בשביל PR וגם בשביל להבין כמה עשינו, כמה נשאר, האם הפרויקט הצליח וכד'.
כמה באגים האוטומציה חשפה והבדיקות הידניות לא	סימון בדיווח הבאג	למשל בדיקות רג'יסטרי שבודקים ידניים לא יבדקו כיוון שזה סיזיפי.
כמה באגים הבדיקות הידניות חשפו והאוטומציה לא	סימון בדיווח הבאג	האם האוטומציה יעילה