פשוט אמרו לא

 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" כבר השליכו את הטענה הזו מהחלון לגבי רוב המקרים), שמציאת באגים היא אחת המטרות של בדיקות תוכנה או שהדרך הנכונה להתקדם היא בעזרת תהליך ארוך וכבד. הסילבוס עדיין מתמקד בתיאור של איך דברים נראים באופן שטחי וכמעט ולא מתייחס לשאלה "כיצד נכון לעשות" ואין בו אפילו זכר לשאלה הכי חשובה "למה עושים" (למעשה, הנקודה היחידה בה שואלים למה היא "למה חייבים לבדוק תוכנה", וזה דווקא המקום בו צריך לשאול - מתי צריך לבדוק ומתי לא). הסילבוס עדיין לא עוזר לבודקי תוכנה לתקשר עם אנשים מחוץ למקצוע, ולמעשה מקשה על התקשורת בכך שהוא משתמש בחלק מהמונחים בצורה שונה מזו שמקובלת בתעשייה. הוא עדיין מתמקד יותר מדי בתוצרים ומסמכים מיותרים ולא מספיק בתועלת שאמורים להשיג בזמן הכתיבה שלהם, והוא עדיין מכוון כדי לאפשר לאנשים לא מיומנים עם אפס הבנה של התחום לנפנף בחתיכת נייר חסרת משמעות ולהציג אותה בפני מעסיקים עתידיים.

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

still not polished.

 

עברית

5 years ago, I welcomed the new release of ISTQB CTFL new syllabus with an honest (if a bit hostile) reading. This may, ISTQB have released version 4.0 of the CTFL syllabus, and after hearing about it from a colleague, I thought to myself that it would only be fair to give it the same respect. After all, for reasons unbeknownst to me, there are some very good professionals who identify with this organization, so maybe they have managed to get something decent from under their hands. 

There is one significant improvement in this version only 50 pages of non-skippable content (such as refrences, appendices, copyright and the like) compared to 76 in the previous one, which can explain how I managed to go over it in 1 hour and 55 minutes (this time, as I was reading in the train, I did not use pomodoro, but rather a time tracking software name "super productivity"). Amusingly, I ended up with a similar number of comments (59, compared with the 57 from last time), and my conclusions are still the same - it is a terrible piece of content, and I'm sure that each and every one of the people who were involved with it (let alone all of them together) could produce something better from under their hands. 

as before, the underlying problems are the business model and the assumptions it forces on the document: Teaching something in less than 19 hours (which is still 2 hours and 10 minutes more than 2018), must either rely on previous knowledge or experience or be extremely shallow and inefficient. Some of the topics mentioned in the syllabus are multi-faceted and complex, grokking them takes time and practice. Narrowing it to a 40 multiple-choice questions for people without any prior knowledge? that's simply impossible to do. 

Aiming to people with some experience (and adding this as requirement to the certification, in a similar manner to what ISC2 does with its CISSP certification) would enable much more focus to this document. As it is, though, the syllabus still tries to be an introduction to working in tech and a description of the heaviest test procedure fathomable (Heck, they even mention the notorious IEEE 29119). Mentioning that it's ok to tailor it to your needs? nah, why not pretend it's the golden standard? much more fun this way. 

As this document is a major revamp of the previous, there are some new things in this version. The buzzword bingo is even more noticeable. With terms such as shift-left, devops, CI/CD sprinkled just about everywhere. Naturally, it's devoid of meaning. 

Even worse is the homage to some other terms that are by now well established in the testing profession. Those would be the test-pyramid and the agile testing quadrants. both terms are oddly placed under the section of test planning. Why? There are more things in heaven and earth, Horatio. 

Their description of the pyramid is probably the worst botch I've seen in trying to describe or use it. Its existence is mentioned, but we skip completely questions like "how to use it". Then comes this: 

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.

 while most of it is technically correct, have you noticed how they shift the whole issue to a comparison of "how many are needed to get full coverage" (one might also ask, coverage of what?) instead of mentioning that those are completing each other, or that this is an observation on what a healthy set of tests usually looks like, it's now hinting that you can get the same done with a few large tests as you can with a lot of smaller ones.

Treating the agile testing quadrants is even worse: instead of treating it as an observational, descriptive model that can expose some gaps in the way we think about tests or in what we actually implement, in the hands of the ISTQB authors, it has become a prescriptive model.
for instance:

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

Naturally, the ISTQB treatment of exploratory testing still represents an utter lack of understanding of it. It's still treated like an after-thought, not really planned testing, and it being placed under "experience based techniques" is probably the best sign of this misunderstanding - it's not a technique, it's a complete approach to testing, and it is not any more "experience based" than the approach where we try to write our test plans ahead of time. The main difference is that the exploratory testing approach admits that experienced people perform better. During exploration we employ all of the formal looking techniques that can be performed ahead of time, as well as other heuristics that are more readily available during test execution.

so, summing it up: 

CTFL certification still has negative correlation to one's ability to function in a professional testing situation. The syllabus still promotes a lot of misconceptions about testing - that it should have some "level of independence" ("accelerate" has thrown this claim out of the window for most cases) , that finding bugs is a goal and that a slow and heavy process is the best way to go forward. It still focused on telling the "what" and very rarely the "how", the most important "why" is not present at all (The only place is when the question "why is testing necessary", and there the question should be "When is it needed, and when not "). It still does not help testers communicate with non-testers, and I would say that it even hinders such efforts by choosing to use terminology in a way different than what is common in the industry. It still focuses too much on the useless artefacts produced and not on the value we should aim to get when creating them and it still aimed to enable untrained, unskilled people hold a piece of worthless paper and present it to future employers. 

Or, briefly - it's still a scam.

 

This too is a way to learn a lesson.

 עברית

Recently we've engaged with a consulting company to help us build a product in our core business. 

A terrible idea, right?

In our defense, there were some compelling(?) arguments to act this way. We knew the risks of employing a company under contract to build something we care about, and were willing to pay the price.

So, things have started moving. As the main reason we didn't do the work was that we were too busy with other stuff happening, the consulting company has started working pretty much unsupervised for a few months. When we finally joined the effort we could see a lot of design work that has been done, with some proof of concept code for various parts - it was not a lot, but it was as much as could be expected given the requirements we gave them and our availability until then. At least, this is what I thought until I examined their "tests". Starting with a review of the code, I found a couple of robot-framework scripts that are executing a browser against the UI defined in Figma, and only running in theory. But, we are starting to work on a new project and some work has been done by the contractor, so we should at least give it the benefit of the doubt, right?

So, we had a talk and I started asking the basic questions - Where in the SDLC are those tests expected to run? against which of the multiple repositories? how should the product be deployed? how often? who are the intended authors of future tests? who are the intended consumers of the results?
Based on the work I've seen, I didn't really expect them to have answers, but I could use this to start an internal discussion about how do we want to approach testing in the new product. While it was rather easy to name the gates that a piece of code should pass on its way to production, we found that some things needed to be defined better, and that we needed to choose a lot of new technologies, or at least review the existing ones to see if they fit. 

We talked about what is a "component test", should we run full system tests on pull requests to some services, how to incorporate contract tests to our process, and so on. 

As we are trying to answer those questions we find that the decisions we make are influencing the rest of the product - from our branching strategy to the way we architecture our product and deployment. There are some difficult questions that we need to answer in a short time, but it's quite interesting so far.

Key takeaways?

First, never fight a land war in Asia. 

First, when you plan your testing strategy, take time to figure out your context - who should be doing what, what results are important, and what limitations will hinder your progress.

Second, Especially if you are a service provider, be very explicit about how you expect your work to integrate with other parts of the development process. Have a discussion about what you will need, what you will provide, and how will this impact the work of others. If you can't have a discussion, share your thoughts with the other people involved. 

Third, your choices will change the way the entire team works, it will have an impact on both the processes you employ and the architecture of your product. In this sense, it's no different than choosing a tool, a programming language or the roles of people in the team. And just as is the case in those other examples, it is a two way street and choices make there will impact how you do testing.

גם זו דרך ללמוד לקח

 ENGLISH

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

רעיון ממש רע, נכון?

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

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

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

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

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

 

אז, מה אפשר ללמוד מכאן?

קודם כל, לא להשתתף במלחמה יבשתית באסיה

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

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

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