העמדה של קבוצת הבדיקות היא בעייתית. יש לה בעצם זכות קיום בגלל טעויות של אחרים, או בלשון אחר, בעולם מושלם היינו מובטלים (סליחה מראש על אי-העקביות). מול מרבית אנשי מקצוע בכלל אין פיקוח של צד שלישי, אלא של המנהלים שלהם. וגם במקרה האחרון המנהלים עשויים למנוע ביקורת מסיבות אישיות (חברות למשל) או פוליטיות. גם במקומות שיש שם מבקר, הוא עומד מול כל החברה ולא ספציפית מול גורם X, וגם כאן שיקולים שלא מן העניין עלולים להתערב.
לעומת זאת אנחנו אנשי הבדיקות מבקרים בעיקר את אנשי הפיתוח ביום יום. כל באג שנפתח זו בעצם אמירה שמישהו פישל, ואי-אפשר לטאטא את זה כי זה יפגע בחברה עצמה. למנכ"ל "מותר" לטעות, כך גם לאנשי השיווק (לא שהם אינם פגיעים אלא לא באופן כזה חד-חד ערכי). אבל מפתח שטעה – יקבל באג.
אני מתחיל בזאת כיוון שזה הרבה פעמים עומד בבסיס מערכת היחסים של הבדיקות-פיתוח. לא רק בעבודה הפרונטאלית אלא גם מאחורי הקלעים, המנהלים שלהם מודדים אותם בין אם פורמאלית ובין אם לאו לפי כמות הבאגים שנפתחים להם. הלחץ עליהם כפי שאפשר להבין לא קטן, וזה גורם למתח מתמיד בין הקבוצות. אפשר להקצין ולומר שהצלחה של הבדיקות = כשלון של הפיתוח.
עכשיו יש שתי אפשרויות: לקחת את המתח הזה למקום לא טוב: הבודקים הם ה"רעים" יאמרו המפתחים; הפיתוח סנובים וחסרי הבנה בסיסית של תהליכים, יענו הבודקים.
אבל אפשר לקחת את המתח ולעשות לו סובלימציה לכיוון של מקומות טובים: להתמקד על המטרה (מוצר איכותי שיצא בזמן) כקבוצה אחת וללא משחקי אגו, כשההצלחה (והכישלון אם יהיה, אבל באווירה כזו הוא נדיר) היא של כולם.
לכן חוק מספר אחד: תפקיד הבדיקות הוא להוציא מוצר איכותי ולא למצוא כשלים של מפתחים. אני מקווה שהניואנס ברור. בכל אופן הוא לא סמנטי אלא מהותי: אנו עובדים עם הפיתוח להוציא מוצר כמה שיותר טוב. אנו שמחים למצוא בעיות אבל לא קופצים במשרד בקריאות שמחה, ולא מאשימים. אנו מודאים את שורש הבעיה וחומרתה, ורק לאחר מכן מדווחים עניינית וללא שמחה לאיד. ואם זה show stopper אפשר להסתנכרן עם הפיתוח קודם להודעה.
אבל רצון טוב זה לא מספיק. בכדי שנוכל לעזור ובכדי שהמפתחים (וכלל החברה) יעריכו אותנו עלינו להיות מקצוענים ומקצועיים לעילא ולעילא. אלו חלק מהדברים ששמעתי מאנשי פיתוח שהפריעו להם בעבודה מול הבדיקות:
· הם לא מכירים את המערכת עד הסוף.
· כל פעם אני מסביר לבודקים מחדש על הפיצ'ר הזה שוב ושוב.
· לא ברור בכלל מדיווחי הבאגים מה הבעיה, אין לוגים וכד'.
וזה מביא אותי לחוק מספר שניים: קבוצת בדיקות חזקה ומקצועית (כלומר גם כבודקים וגם בטכנולוגיה) לעולם תזכה לכבוד והערכה מקבוצת הפיתוח. וזה דבר בסיסי, וזה כולל עמידה על הרגליים האחוריות אם צריך.
אני מאמין ששני החוקים שלעיל הם בסיס לשיתוף פעולה פורה.
לא תמיד אנשי הפיתוח מבינים את המבנה הנכון של התהליך ולמה בודקים מתרעמים על אי-נכונות של מסמכי ההתקנה (בהנחה שזה תפקיד הפיתוח להוציא אותם), ויש כאלה שחושבים שאנחנו פשוט מקבלים מוצר ומתחילים לבדוק ספונטאנית, או שהם לא מבינים מדוע הם צריכים לעשות בדיקות Sanity לפני מסירת המוצר לבדיקות – הרי הם (אנחנו) "בדיקות", לא? זה לא בהכרח נובע מזלזול או עצלנות, אלא מבורות. לכן חוק מספר שלש הוא: הסבר להם את תהליך הפיתוח כמו שאתה רואה אותו וסגור אתם על משהו שמתאים לחברה שלך, מבלי לוותר על עקרונות המקצוע.
לאחר מכן ארגן לחברה פרזנטציה של תהליכי הפיתוח והבדיקות. גם כדי לסגור את הנושא, גם למען השקיפות. בנוסף ברור לנו שאנחנו מקצועיים, צריך לשדר את זה הלאה כי אנשים פשוט לא יודעים. כדאי גם מדי פעם לאסוף את האנשים הרלוונטיים ולספר להם על התקדמות איכות המוצר, בעיות וכד'.
מעבר לזה, דבר עם הפיתוח באופן קבוע, נניח פעם בחודש. תבוא מוכן עם דברים שמפריעים לך, והם יבואו עם מה שמפריע להם. חוק רביעי: ערוץ פתוח וכן עם הפיתוח.
וכל זה כמובן מבלי לוותר על שום דיווח על תקלה ("לא צריך משה בחייך 2 דקות ואני פותר את זה, סמוך על יוסי אחיך". אח"כ כשזה לא יכנס לגרסה זה לא יהיה נעים לא למשה ולא ליוסי), מבלי לוותר למישהו כי "ככה זה עובד יותר טוב" וכו', ואם יש בעיה קריטית אל תמנע מלדווח עליה. הרעיון הוא לא לומר: "מסכנים המפתחים הם בביקורת תמידית", אלא "בואו ונעזור להוציא מהפיתוח את המיטב".
אין תגובות:
הוסף רשומת תגובה