יום ראשון, 24 באפריל 2016

ביקורת ספר: Explore It!

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

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

יום שבת, 16 באפריל 2016

חסרונות בבדיקות באג'ייל והתפקיד של ארכיטקט הבדיקות

גם היום האג'ייל עדיין נחשב לצורת הפיתוח המובילה ואפילו טרנד, וכמו כל טרנד יש לו חסרונות.
אחד מהחסרונות הינו שאמנם הצוות הוא מולטי דיסציפלינרי אבל הבודקים נמצאים בכ"ז במקום שונה. איש C++ ואשת .net יכולים לדבר על קוד, על מבנה נכון של קוד, על לולאות כאלה ואחרות. בודקים באים מעולם מושגים שונה. אם בודק יתייעץ עם מפתח ממוצע על אקספלורטורי טסטינג במקרה הטוב הוא יקבל תגובה כמו 'הא? you're talking to me?'.
  
זה נכון שבאג'ייל האיכות היא של כולם, אבל גם זה ברבדים שונים (איכות הקוד, יוניט טסטס, האינטגרציה וכד').
בנוסף, בודק אג'ילי אמור להיות סופרמן, או סופרוומן:
  1. להיות בקשב עם הפיתוח.
  2. לעזור להם בזמן הפיתוח עצמו.
  3. ללמוד על הפיתוחים החדשים.
  4. לתכנן בדיקות (גם אם לא בעומקים של הכתיבה של הווטרפול).
  5. לבצע בדיקות.
  6. להתנתק בכדי לעזור לאיזה בעיה בפרוד.
  7. לפתח אוטומציה (אם הוא לא יודע עדיין).
  8. לדווח על באגים.
  9. לבדוק אותם.
  10. להשתתף בטקסי האג'ייל.

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


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

אולי לא נשים לזה לב אם רק עברנו לאג'ייל (נחשוב שאלו תחלואי הלידה או שפשוט איש לא יבין שהבדיקות פחות טובות) אבל הלקוחות ישימו לב.
  
מה אפשר לעשות אם כן?
 photo by Tim Gouw

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

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

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


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

מהצד של הארכיטקט: 

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

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