Tuesday, January 10, 2017

התוכנייה יצאה לאור, ואני בפנים!

Nordic testing days' program is out, and I'm in it!


Nordic testing days has published their program, and I'm so very happy to be part of it. I will be speaking about threat modeling, and hopefully encouraging at least one attendee to take a step towards involvement in their product's security. But, enough about me - seeing the great list of topics and speakers really invokes the impostor syndrome, is it really me standing within all of those cool subjects and great speakers (most of the speakers I have yet to hear, but those that I did hear in one format or the other were very good). Probably, even including public speaking, the most difficult task for me in this conference is going to be choosing between colliding talks - Maaret Pyhäjärvi's talk on incremental improvement collides with one of Alan Richardson's talk on javascript, Franziska Sauerwine's talk on refactoring Junit tests collides with Erik Davis' talk on starting an automation project (this one has been decided for me, since my own talk collides with Franzi's talk as well) and those are only the speakers I have heard talking in the past. Choosing a talk to attend in the rest of the time isn't going to be any easier.
So, hats down for the NTD team, you did an excellent job so far.

Tallin, here I come!


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

טאלין - הנה אני מגיע.


Tuesday, January 3, 2017

State of testing survey is here again

Just a short shoutout -State of testing survey is here for the fourth time. Answering it does not take long, and the results are interesting.

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

Sunday, January 1, 2017

ועוד מילה על הסמכות

Another word on certification

כתבתי כאן על הציפיות שלי מהסמכות, וגם קיטרתי קצת על כמה ש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.