פשוט אמרו לא

 ENGLISH

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

כבר בהתחלה, אפשר לשים לב לשיפור אחד ניכר - המסמך החדש קצר יותר. במקום 76 עמודי תוכן ממשי (לא כולל מראי מקום, זכויות יוצרים ושאר מילוי תוכן שאין טעם לקרוא) יש הפעם רק 50 כאלה, מה שיכול להסביר איך הצלחתי לסיים את קריאת החומר בתוך שעה ו55 דקות בהשוואה לשלוש ומשהו שעות שזה לקח לי בפעם הקודמת. הפעם, כיוון שחלק מהקריאה התבצע ברכבת, לא מדדתי את הזמן באמצעות פומודורי, אלא בעזרת כלי בשם super productivity שאפשר לי למדוד זמן שהקדשתי למשימה הזו. באופן משעשע, סיימתי את הקריאה עם מספר דומה של הערות שוליים שכתבתי לעצמי (59 הפעם, כלומר שתיים יותר) וכמו בפעם הקודמת - רוב ההערות היו שליליות. המסקנה הבסיסית שלי אחרי קריאת הטקסט - זו עדיין פיסת תוכן מאוד לא טובה ואני בטוח שכל אחד מהכותבים (וקל וחומר כולם יחד) יכולים להוציא תחת ידיהם משהו טוב יותר. 

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

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

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

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

Tests in the bottom layer are small, isolated, fast, and check a small piece of functionality, so usually a lot of them are needed to achieve a reasonable coverage. The top layer represents complex, high-level, end-to-end tests. These high-level tests are generally slower than the tests from the lower layers, and they typically check a large piece of functionality, so usually just a few of them are needed to achieve a reasonable coverage.

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

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

Quadrant Q1 (technology facing, support the team). This quadrant contains component and
component integration tests. These tests should be automated and included in the CI process

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

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

או, ממש בקצרה - זו עדיין תרמית.