יום שישי, 27 בדצמבר 2013

מבנה קבוצת הבדיקות בחברת AVG ישראל

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

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

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

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

3. כתיבה מתודולוגית של ה-STD כולל את תהליכי הריוויו הפנימיים והחיצונים וכד'. העברה של הפרוגרסיה לרגרסיה וכד'.

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

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

6. ייצוג בישיבות.

7. פוקל פוינט של המוצר.

8. עזרה בדיבאג של בעיות וניתוח שלהן.

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

10. ניהול מאגר הידע (וויקי).


הגדרת תפקיד הבודקים:

1. כאמור למעלה הבנת המוצר "מוצרית" וטכנית. זה עוזר מאוד ובא לידי ביטוי בבאגים איכותיים.

2. הרצה מדוייקת. של ה-STD.

3. תפוקה מסויימת.

4. פתיחה טובה של באגים.

5. יכולת מעבר דינמית בין משימות.



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

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

יום שבת, 14 בדצמבר 2013

מי אחראי למערכת ניטור התקלות?

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

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

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

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

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

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

בתמונה - מחזור חיים של באג.



יום שבת, 7 בדצמבר 2013

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

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

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

לכן הכנסנו תהליך עם שתי נקודות עיקריות:
א. אסור בכל מקרה למפתח לשנות את הבאג לסטטוס סופני (כמו Invalid, Won't Fix, Works For Me ודומייהם). אם ישנה אפשרות לגבות את זה בהרשאות - מה טוב.
ב. גם בודק לא יכול לסגור באג, אלא רק אנליסט, ואנליסט שאחראי לתחום. במקום בו אין הפרדה בין בודק לאנליסט, רק בודק שהוא expert בנושא או ר"צ יכול לסגור באג.
איך עושים את זה? ע"י סטטוס מתאים בבאג (למשל ב-bugzilla ע"י הוספת Keyword). את הסטטוס מוסיף הבודק לאחר שהמפתח משכנע אותו בהערה מתאימה בדיווח הבאג.
פעם ביום האחראי פותח פילטר מתאים, רואה את הבאגים שיש לסגור ומחליט על הצעד הבא - לסגור או לפתוח מחדש.
אני רוצה להזכיר לקוראים המלומדים, שאנחנו יכולים ואף חייבים לעיתים לשתף את מנהל המוצר בהחלטה לגבי המשך הטיפול בבאג. לא הכל הוא בטווח סמכותנו.
אני יכול לומר שעל בסיס יומי כמעט אנחנו פותחים מחדש באגים שאחרת היו נעלמים במערכת.

יום שבת, 30 בנובמבר 2013

מטריצת בדיקות הרגרסיה על גבי קונפיגורציות שונות

הבדיקות ב-AVG, במחלקה שלנו, כוללות בדיקות על מערכות הפעלה רבות (מ-XP ועד ל-WIN8) ודפדפנים רבים (כל ה-IE, שלוש גרסאות FF ושתי גרסאות Chrome).
מצד אחד הרצת מלוא הבדיקות על פני כל הווריאנטים שלמעלה יצרו צוואר בקבוק צר בבדיקות הרגרסיה. מצד שני, יש לנו עשרות מיליוני משתמשים. אנחנו לא יכולים להרשות להשאיר למשתמשים, כולל כאלה שיש להם XPx64, באגים, בעיקר באגים חמורים שעלולים למנוע מהם פעילות חלקה (מקרים כגון תקיעת הדפדפן למשל). אז מה עושים?
החלטנו לפתור את הסוגייה הזו כך:
מתוך הרגרסיות עשינו מיפוי וסידור לפי חשיבות של תסריטי בדיקה:
1. תסריטי בדיקה קריטיים. למשל כאלה שאנחנו לא יכולים לחיות עם בעייה בהם, כמו איבוד קשר עם המשתמשים, וכאלה שיש להם פוטניאל פגיעה במשתמשים. בנוסף הוצאנו ממערכת מעקב התקלות שלנו את הבאגים לפי מסמכי הבדיקה, וסימנו את אלה שמייצרים לנו את מירב הבאגים. בנוסף, בדקנו כמה באגים התגלו רק באחד מהקונפיגורציות (למשל באג שקורה רק ב-IE8).
2. תסריטים חשובים.
3. תסריטים בעלי חשיבות משנית.

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

כשאנחנו מחלקים את הבדיקות להרצה אנו שמים לבדיקות מהמעלה השנייה שלש מופעים של דפדפנים כרגרסיה מלאה - איד IE, אחד FF ואחד ב-CH, ועדיף או הגירסה הנפוצה לשהם, או הבטא. כל השאר מקבלים את מסמכי ה-Sanity. במערכות הפעלה אנו מסיינים (עושים assign) את זו הפופולרית ואולי עוד אחת כרגרסיה מלאה.

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

יום שבת, 13 ביולי 2013

קריאה ביקורתית של הדרישות של מנהל המוצר / המרקטינג

קריאה של הדרישות של מנהל המוצר צריכה להיות ביקורתית ולאתר טעויות. מניסיוני, רוב האנשים לא עושים את זה כמו שצריך.
קריאת המסמכים צריכה להיות אקטיבית, ולא פאסיבית (פאסיבית במובן של לההשקיע אנרגיה בהבנה בלבד).
בזמן הקריאה יש לחשוב, מול כל דרישה / סעיף, על הדברים הבאים:
0. האם הדרישה כתובה בצורה ברורה? אם אתם מוצאים את עצמכם משלימים נקודות מתוך הנחות שאתם עושים, אולי זה כיף אבל assumption is the mother of all fuckups. אל תתביישו, תשאלו. סביר להניח שחלק גדול מהאנשים גם לא הבינו ואולי התביישו לשאול, או גרוע יותר , הניחו הנחות. אחרת, זה מה שיקרה*.
1. מה הסיבה / המוטיבציה לדרישה? האם הדרישה עונה עליה?
2. אם כבר אז ולידציה: בדיקה שהמוצר אכן תואם את ציפיות הלקוח ושהדרישות היו נכונות מלכתחילה.
3. האם יש user stories ברמה הנאותה?
4. האם יש case studies אם רלוונטי?
5. האם דרישה זו מסתדרת יפה עם המוצר הקיים? עם דרישות נוספות?
כלומר מישהו יכול לחשוב על פיצ'ר מדהים שבאופן עצמאי יעבוד מצויין, אבל זה לא מסתדר עם המוצר כפי שהוא היום. דוגמא? יש לך אתר קניות והדרישה היא להקל על תהליך הרכישה דרך העברה בנקאית. דא עקה שהאפשרות הזו בוטלה באתר לגמרי...
6.  האם אכן נוח למשתמש - ה-flows, מיקום הכפתורים? לשון אחר: usability.
7. האם לא חסר משהו שהמשתמש מצפה לו, או יקל עליו. אותה משפחה כמו סעיף 6. כמובן שיש וניתן לצלול כאן לרבדים רבים נוספים (יש עזרה מתאימה, קל למשתמש להבין למה הוא במקום שהוא נמצא בו וכד').
8. אם ברור לכם שהטכנולוגיה לא קיימת ו/או שייקח זמן רב לפתח את זה.
9. האם לא חסר מידע? האם יש קפיצות בדרישה?
10. סתירות פנימיות: פעם כתובה דרך אחת ליצירת דבר מסויים, פעם דרך אחרת וכד'.
11. מילים דו משמעיות, TBD, אחרי האישור של <> ועוד.
12. האם יש מוקאפים?
13. אולי ממש הגדלת ראש, אבל אם יש זמן: איך המתחרים התמודדו עם בעיות דומות? האם הם הצליחו? האם יש משהו שאפשר ללמוד ממנו?

*

יום שני, 15 באפריל 2013

רשמים מאלקס


אני מזהיר מראש שזה פוסט קצת פרסומי.

לא מזמן טסנו אודי, המנהל שלי, ואני, ללבוב, אוקראינה. בלבוב ממוקמת חברת ה-outsource שאנחנו ב-AVG ישראל עובדים אתה ושמה eleks.
מאוד מומלץ לבקר את החברות הללו, גם אם בסך הכל אתם מרוצים מעבודתם. כדאי לראות את תנאי העבודה שלהם, תהליכי העבודה, רמת שביעות הרצון של העובדים (אצלנו, למשל, אין מתאבדים כמו במפעלי אפל בסין למשל ;) ). אפשר להתרשם ממקצועיותם של החבר'ה ומהמשמעת העצמית שלהם.
בנוסף, כמו שאומרים, ערך הפגישה הוא בפגישה עצמה. תמיד הקשר יעמיק אחרי שפוגשים אנשים פנים-מול-פנים.
שם החברה היא אלקס. אנחנו עובדים עם בין 8 ל-20 בודקים ביום. לוחות הזמנים שלנו צפופים, המוצר מורכב והאמת היא שהדרישות שלי די גבוהות. בשנה וחצי שאני עובד איתם גיליתי מוטיבציה ויכולות מקצועיות לא מועטות. היו גם מקרים אחרים פה ושם, אבל זה יכול לקרות (ואני בטוח שזה קרה) גם לנו.
בלבוב הסתבר לנו שהחברה מונה 700 איש. הם מתעסקים בפיתוח ברוב הפלטפורמות, בבדיקות כולל פונקציונליות, לוקליזציה (גם תרגומים), סקיוריטי ועוד.
האווירה שם מאוד טובה. מדובר בחבר'ה צעירים בעלי מוטיבציה, אוהבים לבלות כמונו, רק שהם עובדים בצורה שקטה יותר.
מחלקת הבדיקות אצלנו מורכבת מאנליטים ובודקים. האנליסטים אחראיים לפיצ'רים מסוימים (לכל תהליך כתיבת מסמכי הבדיקות כולל הכתיבה עצמה והניהול שלה, כי יש אלמנטים של ניהול: לוודא שהדרישות ברורות, לתת אינפוטים חשובים, לוודא שהכל מוכן לבדיקות עצמן ועוד) והבודקים מריצים את הבדיקות עצמן. יש לנו מחלקה אוטומאטית, שאותה אינני מנהל.
הבודקים מאוקריינה היו תחילה יותר בתפקיד של בודקים. היום אני נותן להם משימות מכל הסוגים.

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

יום רביעי, 6 במרץ 2013

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

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

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

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

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

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

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

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

רשומות פופולריות