מחפש צרות | מיכאל שטאל

מי צריך בדיקות תוכנה? 

את תחום דרישות התוכנה הכרתי כבר בפרויקט הראשון אליו הצטרפתי בתור בודק תוכנה. זה היה לפני כ-23 שנה, ואנחנו פיתחנו מודם לכבלים. חברות הכבלים בארצות הברית, מתוך רצון להבטיח שמודמים שיחוברו לרשתות שלהם אכן יעבדו כמו שצריך, הקימו תאגיד שהגדיר תקן מפורט עבורם (תקן DOCSIS). התקן הכיל כ-3500 דרישות מפורטות, והתאגיד סיפק טבלה מסודרת עם כל הדרישות. פעולה זו חסכה מאמץ מכל מי שעסק בפיתוח מודמים: במקום שכל ארגוני הפיתוח היו צריכים לזקק את הדרישות מהתקן בעצמם - כולל הטעויות ואי ההבנות - הם קיבלו רשימה מוכנה ורשמית.  דרישות אלה הגדירו למפתחים במדויק את הפונקציונליות הנדרשת מהקוד, ועבורנו, הבודקים, מה בדיוק צריך לבדוק. מצד אחד, זה היה קאדר. לכל דרישה היה צריך לכתוב לפחות תסריט בדיקה אחד, ולעיתים רבות – יותר מאחד. מצד שני, זה היה נהדר. על מנת לעבור את תהליך ההסמכה (certification) המחמיר של תאגיד חברות הכבלים, היינו חייבים לבדוק כל פרט במוצר. העובדה שכל הפרטים הוגדרו היטב בדרישות עזרה מאוד למפתחים לא לשכוח משהו, ולנו, הבודקים, להיות בטוחים שבדקנו הכל.

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

אחרי ששחררנו פרויקט עם 12 גרסאות סופיות (כל פעם מצאנו עוד באג קריטי ברגע האחרון), ההנהלה החליטה שצריך להבין מה לשפר, ועלי הוטל להוביל את החקירה. המסקנה העיקרית הייתה שאנחנו צריכים לנהל דרישות בצורה יותר מקצועית. אחת מהאנליזות המשכנעות ביותר הייתה התפלגות בעיות השורש שגרמו לבאגים בחומרה גבוהה או קריטית. הנתונים הראו שכ-20% מהבאגים החמורים וכ- 36% מהבאגים שנסגרו כטעות (“not a bug”) נבעו מבעיה בהבנת הדרישות, אי ידיעת הדרישות או דרישות מעורפלות. כשהסתכלנו על מספר כל הבאגים בפרויקט, היה מדובר על מאות באגים שאפשר היה לשייך אותם לבעיה בדרישות. 

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

למה להשקיע בניהול דרישות?

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

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

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

וכל זה קורה לפני שארגון הפיתוח יכול לראות איזושהי תועלת בכל ההשקעה. אמנם אנשים כמוני מבטיחים להם שבסופו של דבר המאמץ הזה יתבטא בפחות באגים, פחות אי הבנות ופחות צורך לקודד מחדש חלקים בתוכנה. אבל אם הם לא השתתפו אף פעם בפרויקט שניהל דרישות כמו שצריך, "לפי הספר", ההחלטה לנהל דרישות באופן מלא מחייבת את מנהלי הפיתוח לעשות "קפיצת אמונה" (leap of faith): לקיחת הסיכון של הקצבת זמן יקר לצורך ניהול הדרישות, ועמידה בפני הטענות של הצוות שכל הפעילות היא בזבוז משווע של משאבים. ולמה לקחת את הסיכון? הרי הם הצליחו בעבר לשחרר תוכנה גם בלי זה!

עדויות מהשטח

בשנה האחרונה, עיקר העבודה שלי מתמקדת בשני תחומים: הגדרת תהליכים וכתיבת הניירת הנדרשת לאישור של מוצר רפואי בארצות הברית, וניהול דרישות עבור המוצר. שני תפקידים שממלאים לי פחות או יותר את היום, כשניהול הדרישות לוקח בערך 50% מהזמן שלי. וכל זה על מוצר שהוא בעצם די קטן (אנחנו עומדים עכשיו על כ-600 דרישות; נגיע כנראה לאזור ה-800. תשוו את זה ל-3500 של מערכת מודם כבלים).

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

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

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

- מה היתרונות בניהול דרישות?

- מה החסרונות?

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

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

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

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

מעבר למשוב מהחברים, גם לי יש כמה הארות בעניין, אחרי עבודה של כשנה עם דרישות:

- צריך להחליט לאיזו רמת פירוט יורדים בכל תכונה של המוצר ולשמור על אותה רמה פחות או יותר בכל הדרישות. למשל: אנחנו שומרים קבצי וידיאו, ומידע על הקבצים עצמם (מטה-דאטא). האם לרשום דרישה אחת ("המערכת תשמור מטה-דאטא עבור קבצי הוידאו" ולפרט את רשימת הפרטים  - ויש 20 כאלה בתיאור הדרישה) או לרשום 20 דרישות נפרדות ("המערכת תשמור את הרזולוציה של הקובץ"; "המערכת תשמור את אורך הקובץ בשניות" וכו' וכו').

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

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

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

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

מה הבודקים יכולים לעשות?

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

מתנהלים טוב יותר, ואולי זה ישכנע אותם לעבור לניהול דרישות מסודר.

תרגול נוסף בנושא:

1) EARS: Easy Approach to Requirements Syntax

 https://www.slideshare.net/TechWellPresentations/bw6-terzakis

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

http://benderrbt.com/Bender-Requirements%20Based%20Testing%20Process%20Overview.pdf 

Source (most likely): An Information System Manifesto, James Martin

3) קארל וויגרס (Karl Wiegers) כתב כמה ספרים קריאים בתחום.

4) ספר שממש מהנה לקרוא:

Exploring Requirements: Quality before Design

By: Weinberg, Gerald M.,  Gause, Donald C.

5) סדרת המאמרים המשעשעת (ובעלת הערך) של ג'ואל ספולסקי על דרישות:

https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother