חשיבות ה-Traceability | ניקיטה יריומין

אתם עוקבים?

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

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

אבל בינינו - כנראה שעבור רובנו עקיבות היא מילה נרדפת לעבודה סיזיפית ונטל פרויקטאלי.

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

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

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

בפרויקט השני, הוגדרה מראש טבלת אימות ותיקוף (Validation and Verification) – טבלה הממפה בין סעיפי דרישות המערכת הכלליים לבין האופן בו יש להוכיח את איכותם (על ידי קיום ניסוי פרטני, ביצוע בדיקה והצגת דו"ח, הוכחת שימוש ברכיב שכבר נבדק, וכו'). בפרויקטים בטחוניים, נהוג שטבלה זו מוגדרת על ידי הלקוח של הפרויקט. מכיוון שבמקרה זה לא היה לקוח – צוות הפרויקט הגדיר את הדרישות בעצמו. עיון קצר בטבלה זו מאפשר להבין שבפרויקט צריכים להתבצע מספר ניסויי ביניים מרכזיים שלכל אחד מהם מטרה אחרת, ניסוי מסכם של הוכחת היכולת הכללית, ומספר סבבי בדיקות תוכנה למודולים שונים. אירועים אלה נפרסו על תכנית הפרויקט, ומתוכם נגזר ה-(STP(Software Test Plan. מכיוון שבכל אירוע כזה הוגדרו סעיפי הדרישה הפרטניים שיש לבדוק, וסעיפי דרישה אלה היו מקושרים למסמכי אפיון ודרישות פרטניים לרכיבי המערכת – העקיבות הייתה מובנית, וצוות הפרויקט לא היה צריך להתאמץ כדי לייצר אותה. תרחישי הבדיקה נכתבו בהתאם, ובמהלך כתיבתם עלתה מספר פעמים ההבנה שנכתבות בדיקות שעתידות להיכשל, שכן לא הושקע בפיתוח של רכיבים כאלה ואחרים. הבנה זו הובילה לשינוי מידי במיקוד הפרויקט והשלמת פיתוח היכולת החסרה, שכמובן כבר לקח בחשבון את הבדיקות שנכתבו.

ניחשתם מי הפרויקט הכושל?

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

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

כמובן שהעקיבות לבדה לא הייתה מה שגרם לפרויקט הראשון להיכשל וגם לא לפרויקט השני להצליח. העקיבות הייתה רק סימפטום. כמו בכל פרויקט (ובכלל, כל דבר בחיים) – אם אנחנו לא יודעים למה אנחנו עושים את מה שאנחנו עושים – רוב הסיכויים שלא נצליח. רישום עקיבות רק לצורך תיעוד, החלפת תשתית ממשק המשתמש של המערכת מבלי להתייחס ל-Backend שלה, ומציאת באגים ללא כוונה או תכנית לתקן אותם – כל אלה מעידים על כך שהייתה כאן תכנית ללא כוונה ברורה. מנגד, בפרויקט השני המטרה הייתה ברורה והוגדרה היטב. מתוך הגדרה זו היה טבעי לבצע עקיבות לאופן היישום והבקרה על התוצר. אבל מה שיפה באמת, זה שבפרויקט השני, עצם הביצוע של העקיבות היה הדבר שאילץ את הפרויקט להתמקד בדברים הנכונים. בתחילת הפרויקט, לאחר שה-STP הוצג לצוות לראשונה, הפרויקט הבין שמתוכנן להתקיים ניסוי שנכון לאותה נקודת זמן לא תוכנן הפיתוח של הרכיב שהיה צריך להיבדק שם, וכאשר פורטו הבדיקות המתוכננות בניסוי זה, מהנדס המערכת סיכם ש"הבדיקות האלה יכשלו, כי אנחנו לא מפתחים את זה כך, וזו טעות". בשיח של רבע שעה סביב הנקודה, הוחלט להסיט את מאמצי הפרויקט לפיתוח אותה היכולת בשלב מוקדם יותר. בדיעבד, החלטה זו הייתה אחד הדברים שהובילו להצלחה בניסוי הצגת התכלית הסופי. בנוסף למקרה זה, היו עוד מספר מקרים בהם ביצוע העקיבות הוביל להגדרה של דרישות מפורטות יותר, ולפיתוח של כלים מיוחדים שנדרשו לטובת קיום הבדיקות בפרויקט. העקיבות גרמה לנו להבין במה צריך להתמקד, בהתאם למטרה הסופית של הפרויקט.

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

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

לפני שנסכם, חשוב להתייחס לעקיבות בעידן האג'ילי. כאמור, שני הפרויקטים שהזכרתי נוהלו לפי מודל מפל המים – אז מה יכול ללמוד מזה ארגון "זמיש" (זריז וגמיש)? אז תתפלאו – השיטה האג'ילית מאלצת אותנו לבצע עקיבות כל הזמן, מבלי לקרוא לזה כך. מה היא הגדרת Definition of Done ו-Acceptance Criteria אם לא עקיבות בין הדרישה לתוצאה הצפויה של הבדיקה? מה הוא מימוש איטרטיבי ומדורג של יכולות נכון מאוד – דרך להוכיח שאנחנו בודקים את מה שרצינו שיפותח – או במילים אחרות – עקיבות. כמובן, שבעבודה ב-Agile יש אתגר אחר בהיבט העקיבות, והוא ניהול המעקב אחר השינויים התכופים שקורים במוצר. מה שאמור לתת מענה לכך הוא עבודה צמודה בין צוות הפיתוח לאנשי ה-Product שצריכים להגדיר מה נכון ומה כבר לא, ובהתאם לכך להתאים את בדיקות הרגרסיה (שבשאיפה הן אוטומטיות) לרכיבי המוצר ה"וותיקים", שפיתוחם הסתיים כבר מזמן.

לסיכום, אני רוצה להעלות שתי נקודות למחשבה:

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

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

עקבתם? עכשיו תורכם לחשוב איך זה עוזר לכם בעבודה שלכם. בהצלחה!