גם היום האג'ייל עדיין נחשב לצורת הפיתוח המובילה ואפילו טרנד, וכמו כל טרנד יש לו חסרונות.
אחד מהחסרונות הינו שאמנם הצוות הוא מולטי דיסציפלינרי אבל הבודקים נמצאים בכ"ז במקום שונה. איש C++ ואשת .net יכולים לדבר על קוד, על מבנה נכון של קוד, על לולאות כאלה ואחרות. בודקים באים מעולם מושגים שונה. אם בודק יתייעץ עם מפתח ממוצע על אקספלורטורי טסטינג במקרה הטוב הוא יקבל תגובה כמו 'הא? you're talking to me?'.
זה נכון שבאג'ייל האיכות היא של כולם, אבל גם זה ברבדים שונים (איכות הקוד, יוניט טסטס, האינטגרציה וכד').
בנוסף, בודק אג'ילי אמור להיות סופרמן, או סופרוומן:
- להיות בקשב עם הפיתוח.
- לעזור להם בזמן הפיתוח עצמו.
- ללמוד על הפיתוחים החדשים.
- לתכנן בדיקות (גם אם לא בעומקים של הכתיבה של הווטרפול).
- לבצע בדיקות.
- להתנתק בכדי לעזור לאיזה בעיה בפרוד.
- לפתח אוטומציה (אם הוא לא יודע עדיין).
- לדווח על באגים.
- לבדוק אותם.
- להשתתף בטקסי האג'ייל.
וגם:
- למצוא כלים חדשים שיועילו לבדיקות.
- לדווח על ההתקדמות של הבדיקות, על מצב הגרסה.
- לחשוב איך ניתן לשפר את העבודה.
- להתעדכן על מתודולויות חדשות.
האם יש פלא שקשה לבודקים במתודולוגיה הזו? לדעתי לא משנה איך "נשחק" עם הנתונים, יש כאן overload של משימות על הבודקת, ומתמטית בסביבה לחוצה של התחום שלנו, חלק מהתחומים לעיל נפגעים.
לדעתי הדברים הראשונים הם סעיפים 12 עד 14. אבל לא רק.
אנחנו בני אדם, ולעיתם השיפור שלנו נוצר לא רק מרצון ותשוקה פנימיים, אלא גם מתנאים חיצוניים. למשל כשיש תחרות בין חברות הרצון שלהן להשתפר גדול הרבה יותר מאשר כשיש מונופולים, וכולנו לצערי מכירים את זה ממחירי מוצרי המזון למשל. ואיך זה קשור לנושא? אם אין מי שיבדוק את התכנון של הבדיקות, יאתגר, יבדוק את הצורה בה הן כתובות, ישאל שאלות ויציע רעיונות, כנראה שהם יהיו פחות טובים. זה נכון גם לגבי שאר העניינים של הבודק.
שימו לב שחלק מהנקודות למעלה היו מבוצעות בעבר ע"י או בשיתוף של ראש צוות הבדיקות.
הדבר עלול לגרום לבעיות לא מעטות:
- דגרדציה של הבדיקות.
- דגרדציה של הבודקים.
- עמידה במקום מבלי לשפר עניינים פנימיים של בדיקות (בניגוד לישיבת רטרוספקטיב שבה דנים על הבדיקת יותר מ"בחוץ").
אולי לא נשים לזה לב אם רק עברנו לאג'ייל (נחשוב שאלו תחלואי הלידה או שפשוט איש לא יבין שהבדיקות פחות טובות) אבל הלקוחות ישימו לב.
מה אפשר לעשות אם כן?
- להקצות זמן לפיתוח הבודקים.
- קורסים, ספרים
- לגרום לבודקים מצוותים שונים לדבר זה עם זה (פורום בדיקות למשל).
- אם יש בצוותים האג'יליים איזה מוביל או ר"צ, לגרום לה או לו להתעניין בבדיקות יותר.
- ליצור פוזיציה של מישהו בעל ידע עמוק בבדיקות שגם מכיר או מסוגל להכיר את המוצרים טכנית ומערכתית.
מספר 5 הוא בעצם חלק גדול מהתפקיד שאני ממלא כארכיטקט בדיקות.
אז מה בעצם ארכיטקט בדיקות עושה?
בהקשר למה שכתוב למעלה:
- היא מייעצת לבודקים על כל עניין (טכני, או הדרך הטובה לכתוב בדיקות מסויימות)
- מייבא מתודולוגיות חדשות.
- כלים חדשים.
- אחידות עבודה בחברה.
- מעבר על הבדיקות האוטומאטיות, על התסריטים הידניים.
- הדרכה (בין אם על ידו או מציאת קורסים מעניינים).
- למידה על פיתוחים חדשים ותכנון בדיקות ברמה הגבוהה (high level).
- מוודאת את הטסטביליות של המערכת.
- מפתח אסטרטגיית בדיקות.
- שיפור תהליכים.
בנוסף, אנחנו עוזרים בגיוס (ראיונות מקצועיים), מחליטים בעבודה של כמה צוותים מי יבדוק מה ואיך, משמשים כפוקל פוינט של הבדיקות.
ועכשיו מה?
ברגע שכל הנאמר נעשה ונעשה טוב, ניתן באמת להנות מהיתרונות של האג'ייל מול הווטרפול ושיפור הבדיקות.
מהצד של הבודקים:
- הבודקים יושבים עם הצוות וכך משיגים מידע ומקצועיות שלא היו להם כשהם ישבו בצוות בדיקות נפרד.
- הם אכן עוזרים לפיתוח (איתור באגים כמעט בזמן כתיבת הקוד, שיתוף בתסריטי הבדיקות כך שהמפתחת תתייחס אליהם בזמן כתיבת הקוד).
- יש להם יותר זמן לאוטומציה.
- הבדיקות שלהם תורמות יותר למוצר.
מהצד של הארכיטקט:
- ברגע שאין לו ניהול ישיר של בודקים היא יכולה להתעמק יותר בבדיקות עצמן.
- הראיונות שלנו מקצועיים בלבד וכך אנו מגיעים עמוק יותר.
- יש לנו זמן להתעדכן בדברים מעניינים בעולם כמו מתודולוגיות.
- זמן למצוא כלים.
- זמן למצוא שיפורים.
- לקבוע את אסטרטגיית הבדיקות.
אין תגובות:
הוסף רשומת תגובה