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

 

English

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

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

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

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

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

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

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

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

What is the value proposition of a tester?

עברית

In the previous post I have laid out my reasoning about why most places should not have dedicated testers, eventually. Despite that, I'm working as a tester, and investing effort in becoming a better one. How does that align with my claim that having dedicated testers is a bad business decision? Am I just cheating my employers by performing some task that looks important but have a negative value?

Naturally, I'd like to think I don't do that, which leads me to try and articulate both my motivation in performing a dedicated tester role, and the value testers (including myself) are bringing to the organization, even if the extremely special conditions that make dedicated testers a good idea don't apply. 

First and foremost, quite naturally, is being a transition guide. In essence, I believe this should be a part of the role of any tester - it might be a minor part when one is learning the ropes, or it can be a significant one when someone is filling a leadership position, but it should almost always be there. Saying that most organizations don't need testers is not the same as "send all of your testers home, now". Some organizations will survive such a change and even thrive, but for others, and I guess most, ripping the tourniquet (as I heard Alan Page refer to it once) will lead to a period of chaos resulting in founding another test team and declaring the experiment a failure.  An organization needs to get to a point where responsibilities that were part of the dedicated testers' mandate are being covered skillfully by other parts of the process or organization. Some call this "whole team accountability" or something along those lines. I might not be very good at this yet, but pushing towards this change is something I enjoy doing, and I believe it is creating benefit for my workplace, even if I still have a lot to learn. Figuring out the process improvements, dropping small bits of education here and there and building some of the safety nets that allow for faster, more informed SDLC is a super interesting challenge. If I want to be a central figure in those transitions I need to have a strong testing foundation that I can leverage to help dealing with the hurdles and surprises that are inevitable in these situations.

In fact, in my ideal world, it's not that there are no testing experts at all - some of the problems are difficult and require deep testing skills and knowledge, and for tackling those, an expert is needed. For instance, consider the following example: at my previous workplace I have to come up with a testing strategy for a new, AWS native product. It involved a lot of constraints - on the resources that would be available to develop and test, on the different teams that would participate and on the cadence we wanted to operate at. Just to agree on those, I had to lead some discussions with management and the lead programmers and make sure we were in agreement about how the work should look like - who is best positioned to perform which task and what complications each choice added to the rest of the system - In short, I had to articulate the testing needs and contributions in a language that would fit other software professionals, and take their input to adjust. When suggesting solutions I leveraged some ideas I've heard about in conferences (such as using contract testing to enable independent development of components, or using approval testing to speed up complex validations), at the very least, to create some options for us. I then went on to discuss how to design our system so that we could deploy most of it without creating endless AWS accounts, which for a product that assumes it manages an entire account, is far from trivial - which required strong system modeling, and balancing between ease of test system deployment and fidelity to the real world (as well as other tradeoffs). Without my testing skills and familiarity with the testing community and the ideas flowing in it - all of which are beyond what your average senior developer would usually have - I would have done a poorer job. Those difficult problems will mean that every now and then an expert tester will be needed. Probably at similar numbers to software architects (which need not be different people, I can easily imagine a world in which solving difficult testing problems is part of the architect's tasks.
My personal motivation is quite simple on this point - those difficult testing problems are something I like to tackle, and building my skills towards it makes a lot of sense. If when we get to my ideal world it'll turn out that those are handled by a software architect? well, I'll be starting this learning journey with the testing part covered and work on building the rest of the necessary skills.

But, I'm not only trying to become a better tester myself, I also strive to help others do the same. What justification do I have there? Some people might make the same choices as I did (do?) and in such case, no more defense is needed, but most people probably would have other goals and intentions. For those, I'd point that while teaching people to be better testers, I actually teach (and learn) various testing skills. which, in contrast to the tester role, are necessary. This knowledge will help also when teaching non-testers to how to test better.

So, we have difficult problems and we have a transition guide. Pretty hollow, so far - I have claimed that the difficult problems are less than 5% of the actual work, and helping a transition happen isn't much of a big deal if the value currently residing in the dedicated tester role is nonexistent, right? So, what are the responsibilities that make a tester valuable during this transition journey? Or, in other words, what is the value proposition of a tester? Here's my list. As can be expected, none of these items can be addressed only by having a dedicated tester and I would claim that it's usually better to either hand them over to another role or to change the process so that it is no needed anymore, but building those alternatives takes some time and conscious effort - exactly why we need a transition guide.

• Risk seeking: Developers can sometimes be bold, maybe even too bold for everyone's good. It's really important to be bold if you want to tackle hard problems and not daring to make the first step. It does, however, needs to be balanced to avoid bold decisions that drive us off a cliff. An easy way to do that is to have someone who is looking on what we're building and asking "what if...?". That look for potential misuse of the application and raising them so that the risks can be either mitigated or consciously accepted. 
• Design stakeholder - This is tied to the risk-seeking perspective: A tester is a force in the team pushing for a design that is easier to monitor, that deals with expected failures, perhaps something that is simpler or broken down to simple modules. Things that might evade a team that is focused on fast delivery on the short term - all those choices a tester might be the right person to advocate for, or to put pressure towards using them, should, if done properly, accelerate the team eventually, they just seem like needless hassle when only the immediate term is taken into consideration.
• Safety net building. Some people call it feedback, but a tester does, in some places, build a set of tools that can detect errors and broken parts of our application. Building those tools is an expertise in itself,  that is not yet common enough among software practitioners, very much like it was with unit tests a decade (or two? probably closer to two) ago. 
• Translating between the technical and business layers. Brendan Connolly wrote about this about a decade ago, and it is as true now as it was then. Testers usually navigate between two semantic worlds - the developers one, and both sides of the business world - requirements and customer support. As such, they are probably the best suited to translate between the layers. A customer opens a bug? the tester can translate it to something actionable by a developer. There's an ambiguous requirement? A tester might be able to help put it in technical terms that are easier to understand and communicate with the product manager to make sure nothing is lost in translation. Sometimes you even need someone to translate between two development teams, each with its own context and viewpoint.
• Calming upper management. Sometime, you just need a magic 8-ball that will tell you that everything is going to be alright. Most testers will face some time in their career the question "is it ok to release?", when the  other side just wants to hear "yeah, we're good, you can trust me". No, it's not a call to lie - just to know that sometimes your stakeholders want the bottom line - either all is good, or there's something they need to know about.
• Evaluating operational properties - performance, security, and all of those other side effects to a program's functional development. Since programmers tend to focus on the functional aspects of their work, it takes more time and maturity to add the operation properties to the scope of concern and testing. It's also a harder testing task, so a specialist will be required there for a little longer. 

There are two roles that I intentionally didn't put in this list, not because they never happen, but because I don't think they are part of the tester's value proposition (And I would claim they might actually be harmful). Those are:

• Verification of functional correctness - the developers working on the features are big kids. They should be able to tell if they done a good enough job. Having a tester whose job is to find stupid mistakes is both a waste of talent and a call for developers to abdicate their responsibility.
• Regulatory scapegoat. While some regulations might refer to testers, if that's the only reason for keeping them, - the organization is probably harming itself and would be far better off by showing the auditor that the regulation is satisfied by their process. Scapegoat needed?  Have some manager tick a box in the form and "take responsibility" on the outcome. In fact, it could be the very same person who is setting up the procedures required for this regulatory mandate. For cases where an "independent" validation is required,  a well functioning test team is not really aligned with the spirit of the regulation since it's too close to the development. In such cases, and auditing company (or department) is much more aligned - someone whose interest is not to ship the product but rather to make sure they can't be blamed for not doing their due diligence. 

למה אני ממשיך לעשות את זה?

English

 

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

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

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

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

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

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

 

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

Why do I keep doing this?

עברית

Yesterday, I volunteered a couple of hours to help review the translation of an ISTQB paper into Hebrew. Specifically, the "CT-AI" syllabus. I did it mostly because someone asked and I thought it won't hurt to give it a little time a small part out of wanting to see how bad they managed to get it, and a tiny fraction of hope that maybe this time it won't be as terrible (spoiler - it was).

So I got an excuse to read parts of the document (I didn't bother with the entire thing, just a random chapter or two and the example exam), and it's the same problem all over again - a silly multiple choice questionnaire that you can pass with some common sense and guessing. One bonus point is that the syllabus mentions some practical hands on exercises that can be done. No, of course there's no enforcing of this, but a serious training vendor could, in theory, cram some useful learning that will not be needed for the certification exam but is, officially, expected. Self learners and less reputable training providers? they will probably skip those exercises. 

Also, very much like CTFL, CT-AI also misses the mark completely, but it does so on a more profound level. To be more specific -  It aims for the wrong goal. Most of the syllabus is aimed at "how to test a neural network" (it does recognize that there are other types of "AI" in the form Bayesian algorithms or oven simple decision trees, but almost all properties they attribute to "AI" are more in place with neural networks than with other sorts of machine learning algorithms - which is ok, most people saying "AI" today do mean a neural network of a sort). Now, neural network development (or, "training" is the parlance goes) is testing. The data people let the computer run until it passes their defined test cases and then they declare it done. They might tweak with the network's geometry, weighting or calculations, but most of your work will be collecting the right data, and evaluating the model's performance. This sort of testing usually involves some heavy math and big data techniques - both are not really something mandatory in a tester's background. For testers, such as me, who don't have those math skills sharpened, their contribution to testing the model itself will be fairly limited and will be inferior to that of the data people.Testers who do have shaken the dust of the relevant math (or learned it from scratch) - don't need this basic mess of a certification. 

A better goal for this certification would have been to accept the fact that most testers won't spend their time testing models but rather test systems with embedded "AI" in them and deal with the complexity of a nondeterministic element in the system. Only caveat with that? Testers have been doing that for years, and it's not really different than simply testing, so you can't scam more money out of people. 

 So, sadly, no surprises here - somehow the ISTQB organization has managed yet again to get a bunch of really smart people to produce a piece of work that has a negative value. It's a waste of time for everyone involved in writing, teaching, or learning it. It has unrealistic goals that are unmatched by the weak certification conditions. 

 And one last thing - The first (and currently latest) version of the syllabus was out in October 2021, riding the wave of "deep neural network" that seemed to be in every start-up name. ChatGPT was out a mere year later, and today  most of the material in this syllabus might not be outright obsolete, but it's heavily dated, as the capabilities of "AI" have leaped and our understanding of how we might use such systems has evolved quite a bit.

As for why do I keep doing this - mainly, it comes to a strange dissonance - while I do think that ISTQB is harming our profession, in a strange turn of events, the local chapter, ITCB, is doing some good by being the center of  the local testing community - organizing meetups, releasing a quarterly magazine and maintaining a podcast - so I keep around those people and when they ask for help, I'm sometimes there, even if it means paying the devil his due. I should probably make better judgement in the future.