תפקיד ה-Domain Expert בעולם האג'ייל – רון עובדיה

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

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

מבדיקות ידניות לאוטומציה

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

לפני כעשור, עוד בזמן שעבדנו בשיטת RUP - Rational Unified Process ושיחררנו גרסה כל שלושה חודשים, בא אליי מנהל המוצר כמה שעות לפני שחרור הגרסה עם בקשה ״קטנה״ ורצון לתמוך בסוג נוסף של מטבע שלדבריו, לדברי מנהל הפיתוח ולדברי ה-CTO של החברה, אין כמעט סיכון, ״תוך שעתיים אתם מסיימים את הבדיקות״. רק לאחר 3 שבועות(!) מרגע זה שיחררנו את אותה גרסה לאחר אין ספור מהלכים של בדיקות רגרסיה מקיפות אחרי כל באג משמעותי שמצאנו ותיקנו. זאת רק דוגמא קטנה לצורך מאד גדול של בדיקות רגרסיה שליווה אותנו לאורך שנים.

כמות הבדיקות גדלה משמעותית וכך גם כמות העובדים בצוות. היינו מאד יצירתיים ומתוחכמים אבל תמיד הרגשנו כ״שומרי הסף״, אלו שנמצאים בסוף התהליך ומחפשים איפה פספסו משהו. בשלב מסוים הבנו שללא אוטומציה יהיה לנו מאד קשה לשמור על איכות המערכת ונכנסו לעולם האוטומציה. לאחר השקעה של מספר חודשים שבה בנינו תשתית אוטומציה והכשרנו את כל אנשי ה-QA לתפקיד של מהנדסי אוטומציה, הצלחנו להגיע לכיסוי משמעותי של המערכת על ידי בדיקות אוטומטיות שעזרו לנו להוציא גרסאות איכותיות יותר ובקצב גבוה בהרבה. ההתרגשות הייתה גדולה מאד!, במהלך הדרך למדנו והשתכללנו (השתדרגנו מסלניום ל-Playwright), עברנו מ-RUP ל-Agile scrum  ואנשי ה-QA היו חלק אינטגרלי מצוותי הפיתוח, אבל עדיין משהו היה חסר.

שמעתם על Shift-Left?

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

על המושג Shift Left שמעתי לראשונה בכנס ה-QA GEEK WEEK של ג׳ון ברייס וזה סקרן אותי מאד והתחבר לשינויים שהלכנו לקראתם.

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

עלייתו של ה-!Domain Expert

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

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

הגדרת ה-Acceptance Criteria גם היא נעשית בשלב מוקדם ומוסכמת על כל המעורבים (QADE, המפתח, איש ה-Product וראש הצוות). ה-QADE אחראי על כתיבת תכנית הבדיקות (Test Plan) בשיתוף פעולה עם המפתח, ועליו לוודא שהתוכנית אכן בוצעה ואין שום מגבלות או באגים המונעים את שחרור הפיצ׳ר בגרסה הקרובה. לאחר כשנה וחצי שהצוותים עבדו בצורה טובה ובשיתוף פעולה עדיין משהו היה חסר…

QADE -> DE

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

ו-Acceptance Criteria, החלטנו לעבור לשלב הסופי (כרגע..) ולהכריז על התפקיד Domain Expert!

אנשי ה-DE הופרדו מהעבודה היומיומית עם המפתחים והחלו לעבוד ישירות מול אנשי הProduct וראשי הצוותים. אין יותר "Gate Keepers"! 

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

המשימה שלנו כצוות Domain Expert היא להבטיח את ה-Delivery של המוצר שלנו באיכות גבוהה על ידי קירוב וגישור של הפער בין בעלי העניין במוצר לצוותי הפיתוח. נשיג זאת על ידי הבנה מעמיקה של התחום העסקי, אימוץ חשיבה מערכתית ומתן Acceptance Criteria ברורים ומוגדרים היטב. בנוסף, אנו נתרום לשיפור מהימנות המוצר וביצועיו באמצעות ניטור מקיף הן בתהליך הפיתוח והן בסביבת הלקוח וכן סימון אזורי סיכון על מנת להתמקד בהם בתהליך הפיתוח, הבדיקות והניטור.

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

יתרונותיו של ה-DE

המודל שבנינו עבור ה-DE מביא עמו יתרונות רבים ומשמעותיים:

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

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

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

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

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

• מעורבות גדולה יותר בתהליכי הפיתוח, התורמת לשביעות רצון גבוהה יותר ולשימור טוב יותר של עובדים.

• DE הוא כיום גורם מפתח וקריטי להצלחת המוצר ואיכותו הסופית.

חסרונותיו של ה-DE (כמו בכל דבר, גם פה יש)

• עלויות גבוהות יותר הכרוכות בהכשרה ותחזוקה של DE ברמה גבוהה.

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

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

• עומס מידע ומורכבות גדולים יותר דורשים מעורבות צמודה יותר של הנהלת הצוות.

מסתכלים קדימה...

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

בנוסף, אני צופה כי תפקיד ה-DE ימשיך להתרחב ולכלול היבטים נוספים מעבר לאיכות המוצר עצמו. לדוגמה, הבטחת חוויית משתמש אופטימלית ויעילה (UX), ניטור ביצועים ויציבות המערכת בסביבות הלקוח (Performance & Reliability) והיבטי אבטחת מידע ופרטיות (Security & Privacy).

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

לסיכום

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

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

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

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

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

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