QA אחד, הרבה מפתחים | כרמלה גול

איש איכות אחד, הרבה מפתחים??

שיקוף ותקשורת

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

דרך טובה להתכונן לפגישת שיקוף כזו היא לעשות 2 רשימות:

* האחת - מיפוי של כל פעילויות האיכות שצריכות לקרות בצוות, עם הערכות משך הביצוע של כל פעילות.

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

יעילות עבודת איש איכות 

דבר ראשון שכדאי לעשות בפגישה הוא לבחון כיצד ניתן לייעל את הלו"ז של איש האיכות.

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

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

האם יש תהליכים שניתן להפוך לאוטומטיים כגון איסוף נתונים על KPI, ובכך לחסוך זמן?

אולי אפשר לנקוט בשיטת הrisk based testing ולוותר על הרצת בדיקות בעלות חשיבות נמוכה?

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

עתה ננסה למצוא פתרונות יצירתיים למשימות שאיש האיכות עשוי לא להגיע אליהן.

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

אולי יש תחום שנמצא לו מישהו חדש שיהיה אחראי עליו. נגיד הproduct owner יכול להיות אחראי על קידום zero bugs policy. או מפתח שיהיה אחראי על האוטומציה. אולי צוות התמיכה יכול לעזור בתחקור באגים מהשטח.

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

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

טיפוח ה-Quality Mindset בצוות 

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

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

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

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

הגדרת DoD

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

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

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

דוגמא לצ'קליסט פעילויות איכות לפי שלבי SDLC

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

   DemoפינתExploratory

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

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

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

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

בדיקות חוקרות לכולם

בנקודות מסוימות של המוצר כגון שחרור גרסה ראשונית או משמעותית, או פיצ'ר תשתיתי גדול, ניתן לארגן יום בדיקות חוקרות למוצר (exploratory testing, bug hunt, bug bash).

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

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

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

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

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

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