אם אתם מסתובבים מספיק זמן בתחום הבדיקות, חמש-שש דקות לפחות, סביר שתשמעו מישהו שיזכיר את המטרה העליונה, הדבר האחד שכל בודק תוכנה צריך לשאוף אליו - נעקבות מלאה. מה זה "נעקבות"? האמת, זה אכן לא מונח שגור בשום מקום, ובדרך כלל הפעם היחידה בה תשמעו את הגרסה העברית של השקר הזה תהיה בקורס שמנסה לעזור לכם לעבור את המבחן המיותר של ISTQB CTFL. בדרך כלל, קוראים לזה בלע"ז traceability והמשמעות של זה היא שלכל דרישה אפשר לגזור בדיוק מה הן הבדיקות שמבוצעות כדי לאתגר אותה. גם אם לא שמעתם את המונח עצמו, מישהו אולי ביקש מכם "מיפוי" של הבדיקות לפיצ'רים, או רצה לדעת אילו אזורים מכוסים ואז נסחף קצת. תסתובבו מספיק, תשמעו בקשות כאלה. אולי זה עניין מקרי, אבל מהמעט שיצא לי לראות, יש מתאם הפוך בין מידת הניסיון שיש למישהו בבדיקות תוכנה לבין הסיכוי שלו להשמיע את המושג הזה. אלא אם, כמובן, המישהו הזה הוא מדריך בקורס ואז הוא חייב לפחות להזכיר את הרעיון. במבט ראשון, הרעיון הזה נשמע מדהים - אנשי הבדיקות מפעילים את הקסמים שלהם, ואז יש לנו רשימה שאומרת לנו אילו בדיקות קשורות לאיזו דרישה, וכאשר יש תיקון, או פיצ'ר חדש, כל מה שאנחנו צריכים לעשות הוא ללכת לרשימה הזו ולהריץ את הבדיקות הרלוונטיות. מדהים! מה שלא מדברים עליו בהקשר הזה הוא העלות של יצירת ותחזוקת עץ כזה אל מול הערך הצפוי, שבעולם של פיתוח תוכנה מהיר במעגלים קצרים הולך ומצטמק (ולא שהוא היה כזה גבוה מלכתחילה).
הבעיה הראשונה היא בשאלה "איך לייצג את דרישות המוצר שלנו?" אם יש לנו מוצר בגודל שאינו טריוויאלי, יש לנו כנראה הירארכיה וחלוקה לקטגוריות בין הדרישות, כי אחרת לא נצליח למצוא את הידיים ואת הרגליים שלנו בתוכן. בחירת ההירארכיה הנכונה היא סיפור לא פשוט בפני עצמו. למשל, בואו נדמיין פלטפורמת בלוגים, כמו זו שאני כותב בה עכשיו את הטקסט הזה. זה סביר למדי לחלק את הדרישות לכאלה שקשורות להצגת הפוסט ולכאלה שזמינות למי שכותב את התוכן. אולי יש הרשאה שלישית למנהלי הבלוג, אבל כרגע נניח שהכותב והמנהל הם אותו אדם. אז עץ הדרישות שלנו עשוי להיראות כך:
איפה, בתוך המודל שלנו, נשים את הדרישות שקשורות להערות? מצד אחד, לקוראים יש יכולת לכתוב ולקרוא תגובות, אולי גם לערוך, אבל למנהלים יש יכולת לאשר או להסיר הערות, ולקרוא אותן בצורה מרוכזת. האם יהיה נכון לפצל את הפיצ'ר הזה ולפזר את הדרישות שלו על פני העץ? אולי יהיה נכון יותר להוסיף קטגוריה שלישית של פיצ'רים שמשותפים לקוראים ומשתמשים? אולי יהיה נכון יותר לחלק את העץ שלנו בצורה אחרת לגמרי? נניח, משהו כזה:
ואם חילקנו את זה כך, איך אנחנו מייצגים תחת הדרישות להערות את המידע החשוב "הדרישות האלה רלוונטיות לקורא בלבד, אלה רלוונטיות למנהל ואלה משותפות"? זו לא שאלה של מודל "נכון" יותר מהשני, השאלה היא עם איזה מודל אנחנו נוכל לעבוד בקלות רבה יותר ואיזה מודל מייצג בצורה טובה יותר את הדרך בה אנחנו חושבים על המוצר. כך או אחרת יהיו לנו בחירות לא פשוטות עם השלכות על המשך העבודה. כדאי לזכור, אגב, שזו הייתה הדוגמה הפשוטה. רוצים אתגר משמעותי יותר? איך תייצגו את הדרישה "הסשן של המשתמש צריך להישמר עד לפעולת log-out יזומה"? או "כל הדפים צריכים לעמוד ברמת נגישות של WCAG level 2 (AA)"?
בקיצור, זה לא פשוט לבנות את העץ, אבל זה בסדר - אנחנו לא חייבים לעשות כאן עבודה מושלמת. רק כזו שתהיה טובה מספיק כדי להפיק ממנה ערך, ונאלתר משם. מוכנים לאתגר הבא? מה אנחנו עושים בין גרסאות של מוצר? שומרים רק את העץ האחרון? שמים את זה בגיט ומנהלים גרסאות? האם אנחנו יודעים להשוות בין גרסאות שונות של העץ?
ואם כבר הגענו לזה - זה עץ דרישות, מי מתחזק אותו? האם אנשי המוצר שמוסיפים דרישות למוצר יעשו את זה על גבי העץ? האם זו דרך הגיונית להציג דרישות לצוותי הפיתוח כשהן מפוזרות על פני כל העץ? האם צריך לבקש מהם לעשות עבודה כפולה? עד כה, ראיתי רק מקומות בהם תחזוקת העץ "נפלה" על צוותי הבדיקות, מה שאומר שהדרישות לפיצ'רים חדשים לא ממש התאימו לעץ והיה צריך להשקיע זמן ומאמץ כדי להתאים אותן: בכל פעם בה נוסף פיצ'ר חדש, מישהו מצוות הבדיקות היה צריך לעבור על הדרישות ולמצוא את המקום הנכון להן בתוך העץ, ולפעמים לפרק דרישה אחת לשתיים, שלוש, או חמש דרישות נפרדות מפוזרות על פני כל העץ. כמובן, המאמץ הזה לא הפך את העץ לרשמי בשום צורה, ובמידת הצורך היינו צריכים לחזור ולמצוא את הדרישה המקורית במסמך שקיבלנו.
הצעד הבא - שימוש בעץ כדי להגיע ממנו לבדיקות הספציפיות, הוא ממש פשוט - בתנאי שאנחנו משתמשים בכלי כבד לניהול בדיקות כמו למשל quality center של מיקרופוקוס (לשעבר HP) או QAComplete של smartbear. אני בטוח שיש עוד כמה כלים, אבל לא התעדכנתי בחמש השנים האחרונות בערך לגבי כלים ספציפיים בתחום. אם משתמשים בכלי כזה, אנחנו יכולים להוציא דו"ח כיסוי לכל דרישה, ולכל חלק בעץ, יחד עם תוצאות הריצה והבאגים. אם אתם משתמשים בכלי כזה, אתם גם יודעים טוב מאוד כמה הוא יקר לשימוש, ולא רק במחיר הרישיון. עדיין תהיה לנו את ההתלבטות של איך לייצג את הדרישה לתמוך ב30 שפות ולתפקד היטב גם על טלפונים חכמים, אבל נניח כרגע שזה לא החלק הדרמטי. העלות המציקה באמת היא להמשיך ולתחזק את הקשרים האלה. הוספתם עוד מבדק אוטומטי? ברכותי - יש לכם עוד חמש דקות מיותרות של ליצור עבורו רשומה בכלי הזה ולקשר אותה לכל המקומות הנכונים. אם אנחנו רוצים לקבל את הקסם שבנעקבות נצטרך להשקיע זמן ומאמץ בתחזוקת העץ לאורך חיי המוצר - שינויי דרישות, שכתוב, החלפת טכנולוגיות ומה לא.
בקיצור, יקר.
מצד שני, "יקר" לא תמיד אומר "לא משתלם". יכול בהחלט להיות שהערך שאנחנו מקבלים מכל כאב הראש הזה לחלוטין מצדיק את ההשקעה. אז בואו ננסה להבין מה אנחנו מקבלים אם כבר הצלחנו ליצור כזה עץ לתפארת.
ניקח את המערכת עליה כבר דיברנו ונוסיף לה פיצ'ר אחד של ניסויי A\B לפוסטים כדי לבדוק מה מבין הפרסומים שלנו אפקטיבי יותר. כיוון שכבר יש לנו עץ שבנינו בלי יותר מדי פשרות מוזרות אנחנו מוסיפים את הדרישות הרלוונטיות לעץ ומגלים שהתחומים המושפעים הם עריכת וקריאת פוסטים, אנליטיקה, ניהול משתמשים וcaching (כי "הטמנה" זה מה שעושים עם פסולת). גילינו את ההשפעות האלה ממש מהר בזכות העץ שלנו. אנחנו גם יודעים בזכותו אילו מבדקים צריך לעדכן או להריץ מחדש, ואיפה יש לנו פערים שאנחנו צריכים לכסות עם מבדקים קיימים. אנחנו גם לא מבזבזים זמן בכתיבה מחדש של מבדקים רק כי לא ידענו שהם כבר כתובים.
אז כמה זמן חסכנו בפועל? נניח שפעולת הוספת הדרישות לעץ כבר חושפת בפנינו בחינם את הדרישות שלא כוסו וצריכות להשתנות בלי שום מאמץ אנליטי נוסף. כתיבת המבדקים האוטומטיים והרצת הבדיקות הקשובות לוקחת את אותו הזמן ואנחנו משלמים עוד מחיר קטן יחסית כדי לקשר את המבדקים החדשים לעץ המוצר ואז סיימנו. לעומת זאת, אילו היינו עובדים בלי עץ, היינו עושים מה שסביר להניח שרוב הקוראים עושים היום - מתחילים בניתוח הדרישות ותכנון הבדיקות הנדרשות, חיפוש במאגר המבדקים שכבר יש לנו כדי לראות מה מכוסה ומה צריך לעדכן, ואז עוברים דרך אותם צעדים של תכנון, עדכון וביצוע המבדקים עצמם. מבחינת זמן שהשקענו, ניתוח הדרישות ללא הצורך לשכפל אותן לתוך העץ שלנו היא פעולה מהירה יותר. כמה מהירה יותר? זה משתנה, אבל נראה לי שחיסכון בזמן של 10% זו הערכה שמרנית. חוץ מזה, יש את עניין איתור המבדקים הקיימים ועדכונם. כאן מתחבא, לפחות בפוטנציה, בזבוז זמן רציני - אם יש לנו מאות ואלפי מבדקים, ואנחנו מחליפים בודקי תוכנה כמו גרביים, זה עשוי לקחת ימים שלמים, בהשוואה לתוצאה המיידית שקיבלנו בעזרת העץ. למעשה, סביר שלא ננסה לחפש ופשוט נכתוב מחדש את הכל ונתמודד עם הכפילויות. חוץ מדבר אחד - אנחנו חיים בעולם האמיתי. בעולם הזה סביר להניח שיש לנו מישהו שכבר עובד עם המערכת שנה, שנתיים או עשר, וידע לכוון אותנו בתוך עשר דקות למקומות הרלוונטיים. זה עדיין יותר חיפוש, אבל הוא קצר באופן משמעותי מהמחיר של תחזוקת העץ. בנוסף, אם חלק הארי של המבדקים שלנו אוטומטי - הרצה שלהם תיתן לנו מענה לגבי "מה נשבר" כך שנדע לעדכן. בקיצור - גם על הנייר אנחנו מאבדים זמן ברוב המקרים.
אבל אולי הרווח אינו בזמן? אולי הוא ברמת הוודאות שיש לנו שעשינו את העבודה היטב? יש לא מעט ערך בידיעה שאנחנו משקיעים את המאמץ במקומות החשובים, והסיכוי שנחמיץ משהו חשוב נמוך יותר. חוץ מזה, בעזרת מודל כזה נוכל ליצור דו"ח כיסוי בכל רגע בו נזדקק לאחד כזה. אולי אפילו נשתמש בו כאחד הקריטריונים בישיבת Go\No-Go הרבעונית בה אנחנו מחליטים לדחות את שחרור הגרסה כי לא הספקנו.
רגע, מה? אנחנו כבר לא עושים כאלה דברים? מחזורי פיתוח מהירים וספרינטים קצרים? CI\CD? שינויים קטנים ומשוב מלקוחות בשטח? אנחנו חיים בעולם בו רוב המבדקים שנערכים למוצר שלנו הם אוטומטיים ורצים באופן תדיר, כך שאנחנו יודעים אם הם נשברים. כיוון שאנחנו מוסיפים שינויים קטנים בכל פעם, קל לנו לנתח אותם בצורה טובה, ואם בכל זאת פספסנו - יש כלי ניטור שיעזרו לנו למצוא את התקלה בשטח ונוכל להוציא תיקון מהיר. כך שגם האספקט הזה נופל בחשיבותו.
ונכון, לא כולנו עובדים במערכות היפר-אג'יליות עם כל הנצנצים האלה, ואולי אנחנו עדיין תקועים במחזורי פיתוח ארוכים, מוציאים גרסה פעם באף פעם ועיוורים לגמרי למה שקורה אצל הלקוחות שלנו. אבל אם אנחנו במצב כזה, אנחנו רוצים לשנות אותו ולעבור למודל פיתוח אג'ילי יותר, פשוט כי זו הדרך העיקרית לשרוד ולשגשג בשוק היום. אם אנחנו רוצים לפתח התנהגויות כאלה - למה לאמץ כלים ותהליכים שמובילים אותנו בכיוון ההפוך?
כמובן, לכל כלל יש גם יוצא מן הכלל, וישנם מקרים בהם יכול להיות שממש נרצה לבנות עץ דרישות פורמלי ולהשקיע את המאמץ הנדרש. סיבה אפשרית אחת היא אם מישהו מכריח אותנו - אולי אנחנו נמצאים בתעשייה עם רגולציה כבדה במיוחד כמו רפואה או טיסה, או בכל סיטואציה בה המשמעות של כישלון אצל לקוח היא שמישהו עשוי למות. יכול להיות שבמהלך ביקורת נצטרך להראות עץ נעקבות מלא, ואם זה כך - כל הארגון יתיישר לעבוד עם המודל הזה, מה שגם יוריד את המחיר של תחזוקה (לא לאפס, אבל בתקווה מספיק). האם זה אומר שבהכרח נרצה להשתמש בעץ דרישות במצבים כאלה? אין לי מושג. אני לא יודע אם ישתמשו בזה למשהו חוץ מאשר כדי לעבור את הביקורת, או אם יש דרכים קלות יותר לנהל את המידע הדרוש. כך או אחרת כשאנחנו מגיעים לסיטואציה בה אנחנו שוקלים לקחת על עצמנו כזו משימה ענקית, כדאי שנשאל את עצמנו מה אנחנו באמת שואפים להרוויח, והאם הרווח הזה שווה את העלות ואת המאמץ.
No comments:
Post a Comment