לפני שאני נכנס כאן לעובי הקורה, חשוב לי לומר דבר אחד: קל מאוד לפטור את הסילבוס הזה ב"כתבו אותו אנשים שלא מבינים דבר וחצי דבר בבדיקות תוכנה ועסוקים בבבירוקרטיה בלתי פוסקת כתחביב". זה לא המצב. לפחות ברשימת הסוקרים והמעירים נתקלתי בכמה שמות של אנשים שאני מכיר ומעריך במישור המקצועי. אני מניח שהבעיות שהפריעו לי נבעו מסיבות אחרות.
נתחיל עם השורה התחתונה - הסילבוס החדש אינו גרוע פחות מגרסת 2011 למרות ניסיונות להסתיר את ריח העובש בהתזת כל מיני מונחים "חדשניים" התחושה הכללית זהה, והערך הכללי של קריאת הסילבוס הוא שלילי.
הקשבתי להרצאה של רקס בלאק על הסילבוס החדש, וכיוון שהוא נשמע יחסית מרוצה ממנו, החלטתי שלא סביר מצידי להמשיך ולהשמיץ את ההסמכה הבסיסית בלי שלפחות קראתי את הסילבוס המעודכן. אז הקדשתי לזה קצת זמן. כמה? לא המון. הכרחתי את עצמי להתרכז בעזרת פומודורו, ובסך הכל סיימתי לקרוא את הסילבוס בתוך שבע עגבניות של עשרים וחמש דקות. כלומר - כמעט שלוש שעות. תוך כדי הקריאה כתבתי לעצמי הערות בצד - חמישים ושבע מהן (על פני תשעים ושישה עמודים, למרות שדילגתי על תוכן העניינים, מעקב הגרסאות וכו'). מתוך ההערות האלה, בשני מקומות שמתי לב לשיפור שמצדיק אזכור כאן: נוסף סעיף (1.4.1) שמדבר על "תהליך הבדיקות בתוך הקשר", וגם בסעיף 5.3.2 - דו"ח בדיקות, יש הכרה בעובדה שדו"ח בדיקות צריך להיות מותאם לקהל היעד. שאר ההערות היו קיטורים, הערות שליליות ותזכורות לעצמי לקרוא בהמשך דברים (הרוב, לצערי, היו הערות שליליות).
אז מה בעצם יש לי נגד הסילבוס הזה? ובכן, מצאתי טיוטה מ2016 שלא הגעתי לפרסם, אבל כל מה שיש שם עדיין נכון. בקצרה, הבעיה שלי נוגעת לשני מישורים: נכונות ועמידה בציפיות.
נתחיל עם החלק של עמידה בציפיות. CTFL, מעבר להיותו רצף של ארבע אותיות, משמעו "בודק תוכנה מוסמך, רמת בסיס". אני לא יודע מה איתכם, אבל כשאני שומע "מוסמך" אני מצפה למישהו שיש לו את הכישורים הנדרשים למקצוע מסויים - חשמלאי מוסמך אמור להיות מסוגל להחליף מפסק בבית, עורך דין מוסמך אמור להיות מסוגל לייצג מישהו בבית משפט. המוסמכים אולי לא יהיו הטובים ביותר באזור, אבל את העבודה הבסיסית הם יהיו מסוגלים לעשות.
מוסמכי CTFL, מצד שני, מגיעים לשוק העבודה בלי שום יתרון על פני אדם אקראי מהרחוב - הם למדו שחייה בהתכתבות. הם לא נתקלו מעולם בפרוייקט תוכנה, אין שום דבר במהלך ההסמכה שדורש מהם תרגול או ניסיון (רוב הקורסים הארוכים מנסים לספק תרגול כזה או אחר, התוצאה, עד כמה שיוצא לי לראות, נלעגת) והקשר בין התהליכים התיאורטיים שנלמדו לטובת המבחן לבין המציאות הוא אפילו לא קשר מקרי - זה קשר שלילי.
שנית, ההסמכה הזו קלה מדי. ארבעים שאלות אמריקאיות? מתוכן צריך קצת יותר מחצי כדי לעבור? רוב השאלות דורשות קצת שינון ותו לא? מי שמצליח להיכשל צריך להתבייש ולשבת בפינה. להסמכה קלה יש שני חסרונות: היא לא עוזרת לאנשים חיצוניים להבדיל בין מי שמוכשר לעבודה ובין מי שלא, והיא יוצרת רושם מוטעה כאילו המקצוע הזה קל מאוד. עד כמה קלה ההסמכה הזו? הסילבוס החדש מגדיר (במבוא, בחלק 0.7) שנדרש מינימום של קצת פחות מ17 שעות כדי להעביר את החומר הנדרש (וזה יותר זמן מאשר נדרש בסילבוס של 2011). כן, פחות משבע עשרה שעות. לצורך ההשוואה, קורס מבוא למדעי המחשב, משהו שאין ספק שמי שסיים אותו לא מסוגל לעשות הרבה בכל מה שקשור לתכנות, נמשך בין 78 ל84 שעות אקדמיות, שהן 58.5 עד 63 שעות מלאות, ועדיין לא ספרתי את עשרות השעות שמושקעות בתרגול ובשיעורי בית. האם בדיקות תוכנה הן עד כדי כך יותר קלות מאשר כתיבת קוד? אני בספק.
עד כאן לגבי ציפיות.
עכשיו לגבי נכונות - משהו רקוב בממלכת דנמרק. אני לא מדבר על טעויות בפרטים קטנים כמו ההתעקשות להתייחס לבדיקות "קופסה לבנה" כאל "סוג בדיקות" (זו טכניקה לפיתוח מקרי בדיקה, ובעזרתה אפשר לגזור בדיקות משני הסוגים האחרים המוזכרים - בדיקות פונקציונליות, ובדיקות תכונתיות - מונח שאני חושב שאתחיל להשתמש בו במקום "בדיקות לא-פונקציונליות" שאני לא מחבב), אני מדבר על טעות יסודית בגישה. הסילבוס מתייחס לעולם התוכנה כאל עולם הומוגני למדי בו יש תהליכים שמתאימים לכולם ולכן מנסה ללמד "מה" במקום "למה". הגישה הכללית של הסילבוס היא ציווי (או "הוראה", אבל המילה הזו כפולת משמעות כאן) ולא דיון. בכלל, נראה שמילת הקישור החביבה על מי שאחראי לטקסט היא "באופן מיטבי" (למשל, בעמוד 23, בתרגום חופשי שלי: "באופן מיטבי, ישנה נעקבות דו כיוונית בין תנאי הבדיקה לרכיבים המכוסים מתוך בסיס הבדיקות"). שימוש בניסוחים כאלה מדכא חשיבה עצמאית ומעודד צייתנות עיוורת. באמת, כשאני קורא במסמך הזה את הטענה השגויה "הסילבוס הזה מייצג פרקטיקות מיטביות שעמדו במבחן הזמן" (עמ' 91, כחלק מההסבר על הצורך בעדכון הסילבוס) אני מתחיל להבין למה לבאך ובולטון יש כאב בטן בכל פעם שמישהו מזכיר לידם את המונח הזה - מה שיש בסילבוס לא "עמד במבחן הזמן", הוא התעפש והתאבן. אחת הדרישות הבסיסיות מבודק תוכנה היום היא להיות מסוגל להסביר למה הוא עושה משהו, ולשקול את האלטרנטיבות - יש פרוייקטים בהם כדאי מאוד להשקיע הרבה עבודה בתכנון מראש ובכתיבת מסמכים מסודרים - אם מישהו יכול למות במקרה של תקלה, נניח. אבל יש כל כך הרבה פרוייקטים בהם בזמן שאכתוב את הניירת הדרושה, המתחרים כבר יכבשו את השוק, אז להשקיע בכתיבת הניירת שאף אחד לא יקרא?
בכלל, רוב הסעיפים בסילבוס מתוייג בK2, שזו רמה של "להבין מה זה", הרמה שהייתה יכולה להפוך את ההסמכה למשמעותית ולכן הייתה צריכה להיות על רוב הסעיפים היא K4 (ניתוח), שלא נמצאת בסילבוס בכלל (בגרסה של 2011 הרמה הזו הופיעה בהקשר של בדיקות קופסה לבנה, ובסילבוס הנוכחי היא נעדרת לגמרי).
בקיצור - לא התרשמתי מהשינוי אפילו לא קצת. הוא קוסמטי בעיקרו ולא נוגע באף אחת מהבעיות שהיו. הדבר היחיד ששונה הוא שמדי פעם זורקים כאן את המונח "הקשר" בלי להתעכב על מה המשמעות של הקשר. במלוא הכנות? לא נראה לי שמי שיסתמך על הסילבוס הזה כמקור השכלה ראשוני יוכל לזהות הקשר אם הוא ידרוך על אחד בטעות.
אז איך זה קרה? איך חבורה כזו גדולה של אנשי מקצוע מצליחה להוציא מתחת ידיה מסמך שהדרך היחידה לתאר אותו היא "מחפיר"? אני יכול רק לנחש - מה שקורה כאן הוא שמנסים "לתקן" ו"לעדכן". אז משפצים קצת פסקאות, מוסיפים ומסירים נושא או שניים, אבל הבסיס השבור נשאר - כמו בתרגיל חשבון שהסתבך, הגענו (מזמן) לנקודה בה הדרך היחידה לתקן היא למחוק הכל ולהתחיל מחדש.
I spent some time reading the 2018 ISTQB CTFL syllabus, here are my thoughts.
Before I start, though, there's one thing I want to say - I went over the list of reviewers and found some names of people I know, and really appreciate. The easiest thing to do with this syllabus is to dismiss it as something written by a bunch of detached incompetent buffoons, this is not the case. The people I recognized are professional practitioners of testing, and they are damn good at what they do. I assume that the issues I have with the syllabus are despite them being involved and not because of it.
After listening to Rex Black's webinar about the new ISTQB CTFL syllabus and hearing how satisfied he was with it, I decided I cannot go on smearing the CTFL program without at least reading the updates and seeing if some of the issues I have were addressed. Short answer, for those not intending to read this long(ish) rant - The new syllabus is no less terrible than that of 2011.
When reading the syllabus, in order to keep myself on the task and not wandering off, I timed the reading using 25 minutes Pomodori. Seven of them, to be more precise (which amounts to almost 3 hours), as I was reading I wrote down some comments for later. all in all, out of the 96 pages (including Table-of-contents, references and appendices) I have 57 comments, mostly because I got to the point where I was saying the same thing over and over, so I narrowed my scope down to comments that would help me write this blog post. Out of those comments, 3 are positive to some extent, two of them are actually worth mentioning here: The addition of section 1.4.1 "Test Process in Context", and a (rather trivial) recognition that the test report should be "tailored based on the report's audience" (page 72). The rest of the comments were rants, tasks and (mostly) negative comments.
All in all, I can say that the 2018 version of the syllabus is not less terrible than the 2011 version despite some glitter that was sprinkled on top of it. However, despite trying to mask the moldy scent by throwing a buzzword or two around - it still is very much the same in terms of both content and approach.
So, what do I have against the ISTQB CTFL syllabus?
As I was certain I have already written something about it before, I went looking at my old posts. I found a forgotten draft from 2016, it's a bit old, but everything there is still relevant, so here's a short summary: I think that the syllabus is not living up to the expectations it creates, and is fundamentally incorrect.
The expectations part is the easy one - CTFL, besides being a four letter word, is "certified tester (foundation level)". I don't know about you, but when I hear the word "certified" I expect someone that can actually do the job they are certified for. A certified electrician should be able to change a fuse and a certified accountant should be able to deal with a small business's tax report. They might not be the best of their profession (after all, they are just starting) but they are more proficient than a random person from the street. The people "certified" by the ISTQB (disclaimer, I have the foundation diploma somewhere in my drawer) are the equivalent of people learning to swim by reading a book. They don't have any real advantage over someone that is not "certified", they have never encountered a real software project, there is nothing during the certification process that requires any practice and the correlation between the material learned and reality isn't even random - it's negative.
Second thing is that the certification process is way too easy. 40 multiple choice questions? With passing grade at 26 "correct" answers? Where most of the questions require nothing more than memorization? Anyone who manages to fail this test should be ashamed of themselves. An easy certification has two main drawbacks: It fails in helping people identify the professionals from the amateurs, or the good professionals from the less competent, and it promotes the idea that the subject for which the certification is is easy and not challenging. How easy is it? The 2018 syllabus defines a longer minimal learning period which is higher than that of 2011, and gets to the laughable number of 16.75 hours. Just for comparison, The course "introduction to computer science" at the university takes between 78 to 84 academic hours (or 58.5 to 63 full hours) of frontal instruction (I've left out the significant time spent on homework), and no one assumes that after such a course the student is capable of any real programming work. Is testing this much more easy than programming? I doubt it.
Now, for being incorrect. Something is rotten in the state of Denmark. No, I'm not speaking about small concrete mistakes such as referring to "white box" as a "testing type" (it's a technique to derive tests and create any of the other "types" of tests the syllabus mentioned, once you have a test idea written down, it's not always possible to trace it back to the technique that was used to get to it), I'm speaking of an Intrinsic flaw in attitude: The syllabus refers to the world of testing as a rather homogeneous and understood space, and thus is prescriptive where it should be provoking discussion. It tries to teach what to do and skips almost entirely both the "why" and "when not to" parts. It seems that the favorite conjunction in this document is "ideally" (e.g., in page 23: "Ideally, each test case is bidirectionally traceable to the test condition(s) it covers". Really? is this property still "ideal" in a project where the requirement is "make it work"? or in a project that will have a significant makeover within six months?). Such language discourages thinking and creates the illusion that there is a "correct" generic answer. Check for instance this section in appendix C - "While this is a Foundation syllabus, expressing best practices and techniques that have withstood the test of time, we have made changes to modernize the presentation of the material, especially in terms of software development methods (e.g., Scrum and continuous deployment) and technologies (e.g., the Internet of Things)" [page 91, emphasis added]. Note how despite saying "we changed stuff" the message is "those are eternal truths". When reading this I can really relate with the stomachache Bach & Bolton express each time someone mentions "best practices" in their vicinity. Most of the stuff in the syllabus have "withstood the test of time" by fossilizing and growing mold. One of the requirements from a software tester today (I would say "a modern software tester", but this term is better used to indicate this) is to be able to communicate why some activities are needed and what are the trade-offs. Yes, even in the foundation level, as so many testers find themselves as lone testers in a team or even a small start-up company. There are cases where writing extensive documentation and planning well ahead of time is completely the right thing to do (for instance, if someone could die in case of failure) but in many other cases, by the time I'd be cone creating my bidirectional matrices my competitors would have already released similar functionality to the market and had time to revise it based on customer feedback. So, should I invest time in writing those documents no one will read?
Generally, most sections in the syllabus are labeled K2 or lower (K2 is defined as "understand", but it is more like "understand what a thing is" and not the complete grokking one usually relates to this term), The level that could have made this syllabus any valuable is K4 (Analyze, which was removed in 2018 version, and was applied only to code coverage in the 2011 syllabus) with a minority of some K3 (apply).
All in all - I was completely unimpressed by the 2018 syllabus. It does meet my expectations, but I'm very saddened by that. The changes are, almost entirely, cosmetic. The main difference is that the word "context" is thrown around a lot - I don't believe anyone who learned by this syllabus would be able to recognize context if it punched them in the face.
So, how did this happen? How come that a large group of involved, highly professional testers can get such a shameful document out, and even be proud of it? I can only guess - what I think has happened is that the task at hand was to "update" or even "fix" the 2011 syllabus, so people get to updating paragraphs, fixing sentences or even completely re-writing an entire sub-section. But, as the saying goes, you can't polish a turd (actually, you can). Like a math problem that went astray, this syllabus got (a long time ago) to the point where the best option is to throw everything away and start over.
All in all, I can say that the 2018 version of the syllabus is not less terrible than the 2011 version despite some glitter that was sprinkled on top of it. However, despite trying to mask the moldy scent by throwing a buzzword or two around - it still is very much the same in terms of both content and approach.
So, what do I have against the ISTQB CTFL syllabus?
As I was certain I have already written something about it before, I went looking at my old posts. I found a forgotten draft from 2016, it's a bit old, but everything there is still relevant, so here's a short summary: I think that the syllabus is not living up to the expectations it creates, and is fundamentally incorrect.
The expectations part is the easy one - CTFL, besides being a four letter word, is "certified tester (foundation level)". I don't know about you, but when I hear the word "certified" I expect someone that can actually do the job they are certified for. A certified electrician should be able to change a fuse and a certified accountant should be able to deal with a small business's tax report. They might not be the best of their profession (after all, they are just starting) but they are more proficient than a random person from the street. The people "certified" by the ISTQB (disclaimer, I have the foundation diploma somewhere in my drawer) are the equivalent of people learning to swim by reading a book. They don't have any real advantage over someone that is not "certified", they have never encountered a real software project, there is nothing during the certification process that requires any practice and the correlation between the material learned and reality isn't even random - it's negative.
Second thing is that the certification process is way too easy. 40 multiple choice questions? With passing grade at 26 "correct" answers? Where most of the questions require nothing more than memorization? Anyone who manages to fail this test should be ashamed of themselves. An easy certification has two main drawbacks: It fails in helping people identify the professionals from the amateurs, or the good professionals from the less competent, and it promotes the idea that the subject for which the certification is is easy and not challenging. How easy is it? The 2018 syllabus defines a longer minimal learning period which is higher than that of 2011, and gets to the laughable number of 16.75 hours. Just for comparison, The course "introduction to computer science" at the university takes between 78 to 84 academic hours (or 58.5 to 63 full hours) of frontal instruction (I've left out the significant time spent on homework), and no one assumes that after such a course the student is capable of any real programming work. Is testing this much more easy than programming? I doubt it.
Now, for being incorrect. Something is rotten in the state of Denmark. No, I'm not speaking about small concrete mistakes such as referring to "white box" as a "testing type" (it's a technique to derive tests and create any of the other "types" of tests the syllabus mentioned, once you have a test idea written down, it's not always possible to trace it back to the technique that was used to get to it), I'm speaking of an Intrinsic flaw in attitude: The syllabus refers to the world of testing as a rather homogeneous and understood space, and thus is prescriptive where it should be provoking discussion. It tries to teach what to do and skips almost entirely both the "why" and "when not to" parts. It seems that the favorite conjunction in this document is "ideally" (e.g., in page 23: "Ideally, each test case is bidirectionally traceable to the test condition(s) it covers". Really? is this property still "ideal" in a project where the requirement is "make it work"? or in a project that will have a significant makeover within six months?). Such language discourages thinking and creates the illusion that there is a "correct" generic answer. Check for instance this section in appendix C - "While this is a Foundation syllabus, expressing best practices and techniques that have withstood the test of time, we have made changes to modernize the presentation of the material, especially in terms of software development methods (e.g., Scrum and continuous deployment) and technologies (e.g., the Internet of Things)" [page 91, emphasis added]. Note how despite saying "we changed stuff" the message is "those are eternal truths". When reading this I can really relate with the stomachache Bach & Bolton express each time someone mentions "best practices" in their vicinity. Most of the stuff in the syllabus have "withstood the test of time" by fossilizing and growing mold. One of the requirements from a software tester today (I would say "a modern software tester", but this term is better used to indicate this) is to be able to communicate why some activities are needed and what are the trade-offs. Yes, even in the foundation level, as so many testers find themselves as lone testers in a team or even a small start-up company. There are cases where writing extensive documentation and planning well ahead of time is completely the right thing to do (for instance, if someone could die in case of failure) but in many other cases, by the time I'd be cone creating my bidirectional matrices my competitors would have already released similar functionality to the market and had time to revise it based on customer feedback. So, should I invest time in writing those documents no one will read?
Generally, most sections in the syllabus are labeled K2 or lower (K2 is defined as "understand", but it is more like "understand what a thing is" and not the complete grokking one usually relates to this term), The level that could have made this syllabus any valuable is K4 (Analyze, which was removed in 2018 version, and was applied only to code coverage in the 2011 syllabus) with a minority of some K3 (apply).
All in all - I was completely unimpressed by the 2018 syllabus. It does meet my expectations, but I'm very saddened by that. The changes are, almost entirely, cosmetic. The main difference is that the word "context" is thrown around a lot - I don't believe anyone who learned by this syllabus would be able to recognize context if it punched them in the face.
So, how did this happen? How come that a large group of involved, highly professional testers can get such a shameful document out, and even be proud of it? I can only guess - what I think has happened is that the task at hand was to "update" or even "fix" the 2011 syllabus, so people get to updating paragraphs, fixing sentences or even completely re-writing an entire sub-section. But, as the saying goes, you can't polish a turd (actually, you can). Like a math problem that went astray, this syllabus got (a long time ago) to the point where the best option is to throw everything away and start over.
