כמה טיפים לעבודה עם מכונות וירטואליות

מה זו מכונה וירטואלית?

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

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

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

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

יש מספר חברות שמייצרות VMs, אני מכיר יותר את VMware אבל רוב הטיפים להלן נכונים לכולם.

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

הנה דוגמא לעץ של snapshots שנשמרו במכונה וירטואלית המדמה ווינדואוס 10. ניתן לבחור להפעיל כל אחד מה-snapshots בעץ ללא קשר למיקומו

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

ניתן להכין מערכות הפעלה מקבצי ISO.

  

טיפים לשימוש: 

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

2. אם מריצים מכונות במחשב האישי, הוא צריך להיות חזק, ומאוד מומלץ להשתמש בכונני SSD.

3. השתמשו כמה שיותר ב-snapshots בזמן הבדיקות. לפעמים יש באגים שרק בעזרת שמירה העל snapshot יהיה ניתן לשחזר!

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

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

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

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

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

6. שמות משמעותיים ל-snapshots. אף אחד לא יזכור מה 59snapshot אומר.

7. כן, נדיר אבל אפשרי שיהיה מצב שה-VM לא מתנהג בדיוק כמו PC ובאג שנמצא שם אינו אמיתי. נדיר, אבל תדעו שאפשרי.

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

9. אפשר להסריט מתוך ה-VM וגם לצלם את המסך.

10. שימו לב לאייקונים למעלה - הם יכולים להועיל. 

When you have a new Image, this is what you want to install to prepare for the tests to come:

1. If you don't have a user with admin rights or a user with user rights, create them (start, right click on computer, manage, local users).

2. If you want a set that the users will not require passwords.

3. Login to the user, open the browsers, log off and relogin to the admin.

4. Make sure the VM configurations are set to get OS updates. From time to time update the OS.

5. Install any tool you think you might need, for example: install fiddler, install 7zip.

6. Set on the desktop or in windows explorer shortcuts to any directory you know that are going to use in the tests.

7. Save a snapshot.

8. If you use different divisions (for example one with IE & Firefox, one with IE and Chrome save them now.

קישורים מעניינים:

How to Install and Use VMWare Virtual Machine in Software Testing

מכונות וירטואליות בוויקי

הסבר על בדיקות תוכנה לחברים בצוות האג'ייל שאינם בודקים

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

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

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

מסמך זה זו התחלה, אני לא מתיימר לתמצת את הנושא.

  

הנה לינק למיינד מפ.

עצות לבודק שעובר לאג'ייל (או שכבר שם) - ראיון עם בוריס יוזבינסקי

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

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

הנה כמה אפשרויות פחות טובות:

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

- הבודק האוטרקי: בודק זה בא לעבוד וחשוב לו לעשות עבודה טובה, אבל הרבה יותר חשוב לו להיות המומחה הבלתי מעורער בבדיקות. אין צורך להתייעץ, אין צורך לשתף אף אחד.

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

הבודק השקט: זה שאני יושב עם הפיתוח בחדר לא אומר שאני צריך לדבר איתם!

הבודק הסקריפטופוב: לא לא! רק לא אוטומציה!

  

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

  

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

--------------------------------------------------------------------------------------------------------------------

הראיון

בוריס, ספר לי קצת על עצמך:

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

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

נטו OJT.

  

ולבדיקות נטו איך הגעת?

בתפקידי השני ב"פוליקום" במשרת סטודנט. עסקנו בתקשורת בפתרונות Tailormade לחברות גדולות כמו IBM. ואח"כ הגעתי ל-AVG.

מה מעניין אותך במקצוע הבדיקות?

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

איך קיבלת את הבשורה על המעבר לאג'ייל, לפני שזה קרה?

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

ואיך זה היה בפועל?

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

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

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

כשהיית בצוות הבדיקות לא יכולת ללמוד את הדברים האלה

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

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

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

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

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

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

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

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

האם ריבוי המשימות שלך לא מסיט אותך מהבדיקות עצמן?

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

מהי העצה שלך לבודק שעובד היום לאג'ייל?

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

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

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

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

--------------------------------------------------------------------------------------------------------------------

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

השאלה היא:

Are you up to it?

בדיקות יחידה, Unit Test

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

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

מסיבה זו אני אכנס מעט לתהלך שבד"כ אנו לא מעורבים בו, ה-unit test, להלן UT.

  

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

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

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

מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.

 

בדיקות יחידה, Unit Testבדיקות יחידה, Unit Test

  

מטרות: 

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

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

  

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

  

בדיקות טובות של UT הן:

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

כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.

  

נקודות נגד:

מאריך את זמן הפיתוח, לא תמיד קל ליישום.

  

הערה: נעזרתי בויקי באנגלית: https://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.

ביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'ילית

הספר הזה, Agile Testing: A Practical Guide for Testers and Agile Teams , יכול להיחשב כבסיס הידע של בדיקות התוכנה. נכון, קשור לאג'ייל, אבל גם מי שלא עובד באג'ייל ימצא הרבה דברים שיכולים לעזור לו, ברמה כזו ששווה גם לו (או לה) לקרוא את הספר.

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

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

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

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

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

בהתאם לזאת הסופרות מחלקות את הבדיקות לארבעה רבעים:

ביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'יליתביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'ילית

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

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

הרבע הראשון הוא כולו אוטומטי ונקרא לפעמים TDD, test driven development. אלו בדיקות של קוד שנכתבות לעיתים טרם נכתב הקוד.

הבדיקות כוללות unit tests, בדיקת החלקים הבסיסיים ביותר במערכת, ובדיקות של כמה יחידות כאלה שנקראות component tests.

הרבע השני גם תומכות בפיתוח, אך ברמה גבוהה יותר. בדיקות אלה נקראות גם business/customer-facing tests ובודקות את האיכות והפיצ'רים שהלקוח ביקש. כאן נבדק קוד שהלקוח אפיין. הבדיקות מדגימות את התנגדות התוכנה ברמה גבוהה.

מלבד בדיקות ה-UI, בדיקות אלו צריכות להיות אוטומטיות.

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

בדיקות שמבקרות את המוצר

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

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

אלו בדיקות ידניות בלבד.

אלו בדיקות UAT, אקספלורטורי ויוזביליטי.

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

- בדיקת ביצועים

עמידות (robustness)

Security

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

וזה צ'ק ליסט כפי שמופיע בספר: 

• Are we using unit and component tests to help us find the right design for our application?
• Do we have an automated build process that runs our automated unit tests for quick feedback?
• Do our business-facing tests help us deliver a product that matches customers’ expectations?
• Are we capturing the right examples of desired system behavior? Do we need more? Are we basing our tests on these examples?
• Do we show prototypes of UIs and reports to the users before we start coding them? Can the users relate them to how the finished software will work?
• Do we budget enough time for exploratory testing? How do we tackle usability testing? Are we involving our customers enough?
• Do we consider technological requirements such as performance and security early enough in the development cycle? Do we have the right tools to do “ility” testing?

בדיקות מונחות-הקשר - Context-Driven Testing

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

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

  

היכולת הזו, שהיא יכולת ניתוח נתונים והסקת מסקנות תלויי הקשר, עומדת בניגוד גמור למה שנקרא Best Practice (להלן BP).

בוויקי BP מוגדר כך:

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things.

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

  

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

  

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

  

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

doing the best we can with what we get

הרעיון של Context-Driven Testing, להלן  CDT,  קיים בבדיקות מאז ומתמיד ובעצם בכל נושא כשחושבים על זה 

(למשל תקראו סיפורים על מצביאים מפורסמים והשיטות הייחודיות שלהם לנצח). אבל מי שניסח אותו בתחום הבדיקות היו קם קאנר, ג'יימס באך ו-Bret Pettichord. ניתן למצוא את המניפסט באתר ייעודי של קאנר בנושא זה: http://context-driven-testing.com (הכותרת של חלק זה לקוחה משם). קשה להבין את המניפסט ללא הקדמה (לשון אחר, ללא הקשר, LOL), ולכן כנראה באך וקאנר הוסיפו את שאר החלקים. אני מקווה שכעת, לאחר שקראת את הנאמר כאן, המניפסט יהיה ברור יותר. אני ממליץ לקרוא את כל עמוד הבית, אבל אם זה אמ;לק בשבילכם, הנה שבעת הסעיפים של המניפסט:

1.    The value of any practice depends on its context.

2.    There are good practices in context, but there are no best practices.

3.    People, working together, are the most important part of any project’s context.

4.    Projects unfold over time in ways that are often not predictable.

5.    The product is a solution. If the problem isn’t solved, the product doesn’t work.

6.    Good software testing is a challenging intellectual process.

7.    Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

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

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.

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

שיטות אחרות	הסבר	CDT
context-aware	מסתכלים על משהו שנחשב כ-BT בתור נקודת התחלה ואז עורכים שינויים שיתאימו למצב הספציפי.	הבודק מסתכל על הדרישות של האנשים שדעתם חשובה במיזם והאילוצים המעשיים, כמו גם על ההזדמנויות שהמיזם מציב. מבחינתו, הסטנדרט הוא בגדר עצה ולא מרשם.
context-oblivious, context-specific או context-imperial	ב-Context-oblivious מדובר על בודקים בד"כ חדשים שמיישמים את מה שהם למדו ולא את מה שנחוץ. ב- Context-specificהכוונה לסביבה בה בודקים אמנם לפי הקשר, אבל יותר מסיבות היסטוריות ולא ממשיכים לשנות את השיטה בהינתן שהמצב משתנה במיזם. וב- Context-imperial הבודק מתעקש לשנות את הבדיקות לפי מה שנראה לו כ-BP.
Agile	יש דמיון בין השיטות, אבל באג'ייל עדיין יש סממנים של BP. למשל: בודק אג'ילי יכוון את בדיקתו למצב שיש Unit Tests. בנוסף באג'ייל מעדיפים מעט מסמכים ככל הניתן.	לעומת זאת, בודק CDT יעריך את איכות ה-Unit Tests באם קיימים או במידה שלא, ויבדוק בהתאם. יתר על כן, אין בהגדרה בודק אג'ילי ללא Unit Tests, בעוד שבודק CDT יכול להיות. בודק CDT גם ירגיש בנוח בסביבה מרובת מסמכים, אם זה מתחייב מהמצב.
standards-driven	בודקים מסוימים מעדיפים לעבוד לפי מודלים, למשל מודל ה-V.	בודק CDT פשוט עובד בהתאם למה שניצב מולו.

  

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

  

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

 When you say that something is a “best practice”, you may impress the uninitiated, or intimidate the inexperienced, but you just look foolish to people who believe in the possibility of excellence. Excellence in an intellectual craft simply cannot be attained by ignorantly copying what other people say that they do. Yet, the notion of a best practice is really just an invitation to be an ignorant pawn in someone else’s game of process manners– or it’s a trick to make people pawns in your own game.

ראיון עם מנהל מוצר

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

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

המשפטים המודגשים הם השאלות ששאלתי, תחתן התשובות שקיבלתי.

מהו תפקידו של מנהל המוצר?

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

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

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

  

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

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

  

הממשקים של מנהל המוצר למשל ב-AVG הם עם:

1.      המחלקה המשפטית.

2.      שיווק.

3.      UX.

4.      Compliance, למשל האם המוצר שלנו תואם את הדרישות של מייקרוסופט.

5.      עבודה מול התמיכה הטכנית.

6.      מנהלי מוצר אחרים.

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

8.      פיתוח.

9.      QA.

10.   הנהלה (מצגות והרבה).

  

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

  

איך יודעים מה להכניס למוצר? איך לדייק בטעם של האנשים או בצורך שלהם?

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

ab tests עונים לנו על השאלה מה המשתמשים עושים, ו- Usability tests עונים לנו על השאלה למה משתמשים עושים משהו.

כדאי שהגרסה הראשונה תהיה MVP – minimal viable product כדי שכמה שיותר מהר נצא לשוק ונראה את תגובה המשתמשים.

  

תמיד יש סכנה ש-MVP יהיה דל מידי וייפול על זה

זה בדיוק ה-V ב-MVP. צריך שיהיה למשתמש ערך מהמוצר הראשוני.

הדפדפן החדש של מייקרוסופט, ה-Edge, האם הוא לא מקרה של מעט מידי ערך ולכן הוא לא מצליח?

הבעיה של ה- Edge היא פחות הערך אלא שאין לו מספיק בידול בינו לבין דפדפנים אחרים – אין למשתמשים סיבה לעבור אליו.

אגב מוצר חדש, יש לך השערה איך בנוקיה ובמייקרוסופט לא הבינו ב-2007 את הפוטנציאל של ה-iPhone?

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

  

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

פרסומת עכשווית של אייפון. הפוקוס הוא על המשתמש

מהם המדדים של הצלחת המוצר?

יש לשים לב לשלשה דברים שיש להם השפעה על המוצר:

engagement, retention, monetization

engagement = כמה פעמים המשתמש משתמש במוצר

retention = כמה זמן מותקן המוצר אצל המשתמש

monetization = הרווח שהמוצר מפיק 

כאשר ה- retention ו/או ה- engagement עולים, לרוב זה משפיע גם על ההכנסות.

  

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

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

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

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

פורסם במקור ב-2016