כתבתי
כאן על הציפיות שלי מהסמכות, וגם קיטרתי קצת על כמה שCTFL לא באמת מספקת אף אחת מהציפיות האלה. עם זאת, בשבוע שעבר נתקלתי בדוגמה לתועלת (קטנה) שהצלחתי להפיק מההסמכה הזו, מה שהוביל למחשבה נוספת על הציפיות שלי מכל תעודה, ומהסמכה בפרט. ומעשה שהיה כך היה: במהלך ריאיון עבודה ביקשתי מהמרואיין לתאר בדיקות של משהו, וקיבלתי אוסף של מקרי בדיקה שנראו לי חסרים ולא מתוכננים במיוחד (כך שהיו שם כפילויות ומקרי בדיקה לא רלוונטיים). לא ממש הצלחתי לכוון את המועמד לתת תשובה מסודרת יותר, ואז ניצלתי את השורה בקורות החיים שלו בה היה כתוב "הסמכת ISTQB". מצויין - השתמשתי בשורה הזו בקורות החיים כקרש קפיצה לבקשה לחלק את הבדיקות למחלקות שקילות ולראות אם זה יעלה פערים כלשהם. כשהמועמד לא הכיר את המונח, הופתעתי.
אבל, זה הזכיר לי שאחד הדברים שבחינות הסמכה (וגם סתם תעודות של קורסים מוכרים) מספקות הוא היכולת לבנות ציפיות. לכל קורס או תעודה מוכרת - לא משנה כמה קל לקבל אותם - יש רשימה של דברים שסביר לצפות ממי שמחזיק בהם להכיר ולזכור גם עשר שנים לאחר מכן. בדרך כלל מדובר ברשימה לא מאוד ארוכה. באופן מעניין, ככל שיש פחות ידע שמועבר במהלך הלימודים, רשימת הדברים שצריך לזכור לאחר מכן יכולה להיות ארוכה יותר - אם מישהו טרח לשנן את הפרטים הדרושים כדי לעבור את בחינת CISSP, אני כנראה יכול לצפות להיכרות שטחית עם מודל OSI ולהבנה בסיסית של ההבדל בין הצפנה לפונקציית גיבוב, ואולי גם להיכרות עם שמות של תקנים שאפשר לקרוא עליהם אחר כך, אבל כיוון שיש כל כך הרבה ידע שצריך להידחס לראש לפני הבחינה, התשובה לשאלה "מה סביר שיישאר לאורך זמן" נעשית מגוונת יותר ותלוייה בתחום ההתמחות הספציפי של המועמד. לעומת זאת, בבחינת CTFL קל מאוד להצביע על רשימת הידע שצריך להישאר - מעטים האנשים שזוכרים איך לחשב
סיבוכיות ציקלומטית בלי לבדוק את הנוסחה בגוגל, ומי שמבזבז את תאי הזיכרון שלו על מודל V או W מבזבז מקום. לעומת זאת, סביר לצפות מכל בודק תוכנה, ובפרט ממי שלמד אי פעם לבחינה הזו, להכיר את שלוש ורבע הטכניקות לגזירת מקרי בדיקה שמלמדים בקורס (מחלקות שקילות וערכי גבול, מכונת מצבים וטבלת החלטות) ולהבין שקופסה שחורה ושקופה (לבנה) אלה לא סוגי בדיקות אלא שתי קטגוריות לטכניקות תכנון בדיקות.
השפה המשותפת והידע המשותף הופכים את את התקשורת במהלך ראיונות עבודה (וגם במהלך העבודה היומיומית) לקלה יותר - אבל אם אתם בדיוק שולחים קורות חיים לכל מיני מקומות, שימו לב שאתם זוכרים את רשימת הידע המינימלית לגבי כל קורס או הכשרה שמוזכרים במסמך. מי יודע, אולי המראיין יחליט להיטפל דווקא לשורה הזו?
ואגב, כשמדובר על הסמכות חלשות, להכניס שורה עליהן לקורות החיים יש בעיקר חסרונות - ההסמכה עצמה לא תרשים אף אחד גם אם תזכרו את כל הידע הסביר ועוד קצת, אבל אם תפספסו משהו - העדות לכך שלמדתם את זה בעבר תשמש נגדכם.
---------------------------------------------------
I wrote
here on my expectations of certifications, and took the opportunity to rant a bit about how ISTQB's CTFL fails to meet those expectations. However, in the last week, I encountered an example of a (small) benefit that I can draw from any sort of diploma, even if it's called a "certification" and is a weak one. This has led me down a short thought trail about one other thing I expect of any sort of formal education. The story is rather simple: The other week, I was interviewing a candidate for the team I work in and, as is quite common, I asked the candidate to describe some test cases for something (in this case, a piece of pseudo-code he has just written on the whiteboard), and got some scattered test instances that seemed both redundant (i.e. several tests did the same basic check) and lacking (i.e.: there were some important categories I thought were missing). I tried to get the candidate to add some structure to what he was doing, hoping that the structure will help him either justify or change his testing. going (again) over his CV, I saw "ISTQB certified", and decided to use that piece of trivia as a way to move towards a bit more theoretic discussion. "I see you are ISTQB certified", I said. And after receiving a confirmation I continued "Why won't you divide those test cases to equivalence classes? feel free to add more equivalence classes if you feel the need".
O_O
Apparently, the candidate did not know what equivalence classes were. I noted my surprise, and went on to explain the term in 30 seconds and an example.
Later, I thought about it a bit - We don't demand any formal testing knowledge in our job description. Had a university graduate come and said "I don't know what equivalence classes are" I wouldn't have cared. From an experienced tester, I kind of expect to know what it is, and if someone holds a CTFL certificate, I know for sure that they have learned it at some point in their life.
And that's what any sort of diploma provides - the "permission" to expect a person to have certain pieces of knowledge - For every test, no matter how easy or absurd it is, there is a body of knowledge that it is reasonable to expect those who passed it to know. Interestingly enough, The more packed a test is, the shorter this list becomes. For a CISSP, I can probably expect to know most of the OSI model, to know the difference between encryption, hashing and signing, and probably to know some names of protocols and standards to google. A person will remember more than those in order to pass the exam, but most of it will be in short term memory that is erased after the exam (I, for instance, have already forgotten the stages of CMMI, how high should a fence be to deter a bypasser and other such trivia) - and the more there is to remember, there is less place for real understanding and long term memory. For the ISTQB foundation level exam, there's not much to know - and while I don't expect anyone to actually remember how to calculate
cyclomatic complexity, and anyone who bothers to remember the V or W models is wasting memory cells, I feel I can safely assume that equivalence classes, boundary values , decision tables an state machines are ways to derive tests that the person holding the certificate is familiar with, at least by name and concept. I can also expect that person to be able to explain what is the difference between black box and white\opaque box (and to know that those are not testing techniques but rather categories of test derivation techniques). This list of expected knowledge is creating a language that facilitates communication in job interviewes, but also in the daily routine work.
So, next time you send a CV with any claim of education - make sure you remember the expected knowledge of each such claim. Who knows? maybe the interviewer will decide to pick up on that line and use it to grill you a bit.
And also - if this piece of education is a weak certification, you can almost only lose from having it - it won't impress anyone who's worth their salt, and if you don't remember it well enough, it will be held against you.
