Book review - Threat Modeling

This post is quite long, for sure it came out longer than I intended. The English version is still below, but you might need to scroll down a bit.

לפני כמה חודשים הגיע הזמן לעדכן את מסמך "מודל האיומים" (Threat modeling) של התוכנה שלנו. וכן, באנגלית זה לגמרי נשמע יותר טוב. בשל צירוף נסיבות אקראי למדי, יצא שאני האדם הכי מתאים בצוות לביצוע המשימה (למעט מנהל צוות הפיתוח, אני היחיד בצוות שהשתתף בתהליך בעבר, ובניגוד אליו אני יכולתי למצוא קצת זמן להקדיש לזה). חדור מוטיבציה ועזוז, ניגשתי למשימה רק כדי לגלות שאין לי מושג ירוק איפה להתחיל - גם עם המסמך אותו אני צריך רק לעדכן מול העיניים. אז התחלתי לחפש מידע - קראתי את הפרק הרביעי בספר הזה שהתגלגל אצלנו במשרד, קראתי הנחיות בדף ויקי פנימי שהיה זמין לי, וישבתי לדבר עם מי שכתב את המסמך המקורי אותו רציתי לעדכן, שאמנם עזב את הצוות, אבל נשאר בחברה בתפקיד אחר. הוא הסביר לי המון על התהליך ועל מה צריך לעשות וכך יכולנו לעדכן את המודל בצורה אפקטיבית. כשהתברר לשנינו שאני גם נהנה מתהליך מידול האיומים, הוא השאיל לי ספר Threat Modeling : Designing for Security שכתב אדם שוסטק (Adam Shostack). 

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

אז מה יש בו? הספר מחולק לחמישה חלקים, וכל חלק מכיל כמה פרקים:

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

• החלק השני מתמקד ב"מציאת איומים" ועוסק בהרחבה במודל STRIDE (שכבר הזכרתי), בעצי התקפה ובמאגרי התקפות\חולשות, כשלכל אחת מהשיטות האלה מוקדש פרק שלם. הפרקים שונים מאוד זה מזה מבחינת איכות החומר הכתוב ומבחינת התועלת שהצלחתי למצוא בהם. כך למשל, בעוד שהפרק על STRIDE מאורגן בצורה מופתית - לכל אחת מהקטגוריות מצורף הסבר קצר על מהות הבעיה, יחד עם טבלה שמציגה מגוון אפשרויות למימוש התקפה - הפרק על עצי התקפה משמעותית חלש יותר ולאחר קריאתו נותרתי בתחושה שאני לא יועד הרבה יותר על השימוש בהם מאשר ידעתי קודם. אולי זה קשור לטענה בסוף הפרק: "מאוד קשה ליצור עצי התקפה".  במקרה של ספריות ההתקפה, יש פחות צורך לחשוב - שימוש ברשימות כמו Owasp top 10 (רשימה עם עשר המתקפות הכי נפוצות\מזיקות באינטרנט), או בCAPEC לא דורש הרבה מאוד הסברים, והספר מציין, כמו שכדאי לעשות, שלעבוד עם רשימה מפורטת כזו יכול להתברר כלא מעט עבודה.
   לבסוף, כדי להזכיר לנו שהעולם מסובך יותר משנדמה לנו, הפרק האחרון בחלק הזה מתעסק באיומים על פרטיות ובכלים מחשבתיים שיכולים לעזור לנו לשים לב לפגיעה בפרטיות. בעיקר מצא חן בעיני הרעיון של הנוטריקון  LINDDUN. 
• החלק השלישי עוסק בניהול האיומים - החל בסוגיות כמו "מתי לבצע פעולות של מידול איומים?" או "כמה זמן להשקיע בזה?", דרך נקודות שכדאי לשקול בתיעדוף הטיפול ובדרכיםמקובלות לטיפול באיומים נפוצים.
  חמשת הפרקים שבפרק הזה ממוקדים יחסית, ומעניינים במידה כמעט שווה.
  הפרק הזה ארוך למדי, וסקירה מפורטת של כל הפרקים בו תהיה מתישה. לכן, אני רוצה להתעכב על שתי נקודות קטנות.
  הראשונה היא דוגמה לסיבה בגללה אני מוצא את הספר מאוד נגיש ומאוד קריא לציבור הרחב: בפרק השביעי מזכיר המחבר בדיחה מוכרת על שני אנשים (אליס ובוב, כי אנחנו מתעסקים באבטחת תוכנה) שבורחים מדוב, בוב עוצר לנעול את נעלי הריצה שלו, כי הוא לא צריך לרוץ מהר יותר מהדוב, רק מהר יותר מאליס. הספר מסביר שהאנלוגיה הזו לא טובה במקרה שלנו, או, כפי שהוא מנסח זאת: "... לא זו בלבד שיש דובים רבים ביער, אלא שהם מקיימים כנסים בהם הם מדברים על טכניקות שיאפשרו להם לאכול את אליס וגם את בוב לארוחת צהריים". והנה לכם - תמונה מנטלית שקל לזכור.
  הנקודה השנייה היא הפרק העשירי, בו מצאתי את עצמי מהנהן בראשי שוב ושוב - נושא הפרק הוא "איך לוודא שאיומים מטופלים", או, בתרגום לעברית, "איך מוודאים שעשיתי עבודה טובה?" זה נשמע דומה לבדיקות תוכנה? זה לא במקרה. בתוך הפרק אפשר למצוא את הציטטה שתמיד נתקלים בה - you can't test quality in, והכותב מבהיר שבאותו אופן בדיוק אי אפשר לבדוק אבטחה לתוך המוצר. מה שכנראה מצא חן בעיני הכי הרבה היה כשתחושת הבטן שהייתה איתי לאורך קריאת הספר קיבלה אישור כשהכותב טען שבעת מידול איומים, בודקי התוכנה הם "בעלי ברית טבעיים"בין היתר כי הם כבר מתורגלים בלחפש את המקומות בהם דברים עשויים להשתבש.
• בין הפרקים השונים בחלק הרביעי ניתן למצוא "ספר מתכונים לדרישות", שאמור לעזור בהתמודדות עם כתיבת דרישות אבטחה (או במצב בו דרישות האבטחה לא כתובות היטב, או בכלל), קצת על איומים בענן ובסביבות web, כמה שאלות לא פשוטות שכדאי להיות מודעים אליהן בזמן שמטפלים בזיהוי משתמשים וניהול זהויות, דיון עמוס למדי על שימושיות, ומעבר זריז על עקרונות בסיס בהצפנה והתקפות נפוצות (ההתקפה החביבה עלי היא קריפטואנליזה בעזרת צינור גומי,  שזו דרך אלגנטית לתאר את השיטה בה תופסים את הג'ינג'י עם המפתח ומפרקים לו את הצורה עד שהוא מספר לנו מה שאנחנו רוצים) ובהקשר הזה אנחנו מקבלים גם תזכורת לגבי פרטיות, הפעם - איך הצפנה יכולה לעזור לנו איתה. 
• החלק החמישי הוא סיכום, ומתוך שלושת הפרקים שלו - שני פרקים קצת "נמצאים באוויר" כשהם מדברים על "גישות נסיוניות במידול איומים" (כמו למשל, משחק בשם FlipIT), או ברעיונות כלליים כמו עומס קוגניטיבי או  תיאוריית הזרימה. הפרק השלישי ממוקד במטרה קונקרטית מאוד: איך להכניס מידול איומים לארגון שלך? כאן אפשר למצוא עצות פרקטיות על איך ניתן "למכור" את הרעיון להנהלה או למהנדסים מהם יצפו לעשות את העבודה, כולל תשובות להתנגדויות נפוצות. אם טרם השתכנעתם שיש קשר הדוק בין בדיקות תוכנה למידול איומים והתזכורת שיש בפרק הזה לא משכנעת אתכם, אחת ההתנגדויות שמוזכרות כאן היא "אבל אף אחד אף פעם לא יעשה משהו כזה". 

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

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

טוב, זה יצא ארוך יותר ממה שהתכוונתי, אבל זה נתן לי תירוץ לרפרף דרך כל הספר שוב, וזה בפני עצמו הצדיק את המאמץ.
אם אתם רוצים, אפשר לקרוא כמה עמודים (=כל הפרק הראשון והשני, עם עמוד מהפרק השלישי)  בחינם בגוגל ספרים. והכי חשוב, במילותיו של הספר - Go Threat model, and make things more secure.

-------------------------------------------------------

A while ago, just before I started writing this blog, we got to that point in the year where we should update our threat model (one of the cool things in working in a large company is that there are some mandatory procedures, and for some of them there actually is someone who is responsible of verifying they are done). By what seems to me as a sheer coincidence, I was the most suitable person to lead the threat modeling, as I was the only one who participated in the process last year besides our dev team leader who is awfully occupied (so, me being able to muster some free time trumps his superior knowledge and experience). Full of motivation to dive into this new and shiny field, I started out just to find out that I didn't have the slightest clue as to where can I begin - even when all I had to do was to update an existing document with the changes we made in the past year. So I starting looking for information and instructions - I read the fourth chapter of this book that was rolling around in the office, read an internal Wiki page that was supposed to help me, somehow, and then I sat down to talk with the guy that has composed the original document I was updating (who, despite having moved to another team, remained at hands reach and was happy to help). His knowledge and expertise helped me tremendously, and I was able to actually start updating our model and even add some improvements to the document (as this document was the product of his self-education, there were some things there that could have been done better, and unlike him - I had help from the first moment I dove into this matter). Anyway, once we both found out that I was enjoying the process, maybe more than I should, he lent me his copy of Adam Shostack's Threat Modeling:  Designing for Security.

It took me a while to do so, but I read this book front to back (excluding some of the appendices), and in short - that's a great book. It's a must-read for anyone who wished to learn a bit about the world of threat modeling, and it is a good source of knowledge for those who wish to learn about software security. On top of that, it seems to my inexperienced eye to be something useful even for those that are familiar with threat modeling. Finally, even if you believe that your product has nothing to do with software security, I think you'll find reading this book worthwhile. 

So, what's in it? 

• The book has five parts, each containing several chapters, the first of which was the most important for me - being completely inexperienced in that field - is labeled "Getting Started". The first sentence in the book (excluding the thirty odd introductory pages explaining what can the reader expect to gain, who are the intended audience and how to use that book - still it's the first sentence of the first chapter, so there you have it) is "Everyone can learn to threat model, and what's more, everyone should". with such encouragement, how can we not start threat modeling immediately?
  And indeed we do. Very quickly we are drawing a diagram of a software, and discussing a bit how to add information to the diagram without making it unreadable or over detailed. Once we have our diagram (In our case, A Data-Flow Diagram, or a DTD) we go on and start finding threats by playing "Elevation of Privileges" - a card game that was developed along with this book and is freely available to download (you can find it here). Naturally, you can buy a proper deck and save yourself the fuss of printing it. Once we are done playing, the book reminds us that we have four options to deal with a threat we found:
• Mitigate the threat - Add some control mechanisms and defenses that will make exploiting the weakness you found harder, limit the amount of damage an attack can do via this venue, etc. this is done in order to allow us to choose one of the other options comfortably. 
• Eliminate the threat - delete the relevant piece of code, block a vulnerable functionality - do something that will make sure that this vulnerability is simply not out there anymore. 
• Transfer the risk - you can transfer the problem to someone, or something else. For instance, you can decide to leave authentication to the OS, or just notify the user that "The software does not deal with this type of risk (A great example for this is Mailinator, a temporary email service, that have the following privacy policy in their FAQ page - "There is no privacy"). Obviously, such decisions should be business decisions, and you should be careful when deciding to transfer a risk, as you can do that to a limited extent only. 
• Accept the risk - Sometimes, it's acceptable to acknowledge a risk and respond with "I'll take my chances". This should not be your go-to approach, but if the risk is improbable enough (e.g.: The server drowning if the Netherlands dam breaks and the sea floods everything), or if the impact is low enough in comparison to the cost of fixing it (e.g.: protecting your server physically can cost you a small fortune to maintain something like this) , then just living with the risk might be acceptable. 

Done with that? Great. That's all folks, let's go home. The rest of the book is just some elaboration and expansion of what was done up to this point. The book then continues with a question I learned to like - "what's your threat model?". This short question can help learning quite a lot, despite having a short answer as well. Answers can be "a single attacker with a standard laptop", or "a disgruntled employee", "cyber-criminals" or "NSA, Mossad, MI5 and every other intelligence agency". Once you know what is the threat you want to protect yourself against, you can make good choices that will help defending against it. As the book mentions, a common answer to this question is "huh?", and this answer provides us with a lot of information as well. Specifically, it tells us that we need to start thinking and identifying the threats we are concerned about.  At this point, we get into more details and discuss a bit approaches to threat modeling. The book covers some unstructured & structured approaches to threat modeling (with a bit of focus on Data-Flow-Diagrams, or DFDs, which seem to be the author strong recommendation). While reading this, we encounter some useful terminology and concepts such as assets & stepping stones or trust-boundaries. 

• The 2nd section deals extensively with the analysis part, or, as the section is named "Finding threats". It starts by focusing on the STRIDE model (on which I already wrote a bit), and then goes to discuss other methods such as attack trees and attack libraries. Finally, just as a reminder, the section shifts its focus to privacy threats and some tools that may help us noticing those.
  The quality of the different sections vary greatly - while the STRIDE chapter is well organized and very readable, with several examples of how to apply each part of the STRIDE model, the one about attack trees has left me not much better off than where I first began. Perhaps it is simply a proof by example of the claim in the end of the chapter: "It's very hard to create attack trees". The chapter on attack libraries is somewhat in the middle - it's very clear, but a bit boring, since using lists such as OWASP top 10, or CAPEC requires very little explanation. The book reminds us that using attack libraries can be quite a bit of work.
  The chapter about privacy is great - it gave me the feeling that I now have the basic knowledge about some mental tools to address the issue, but also that there is so much more to learn about it by following the hints there (The one i liked best is the LINDDUN acronym). 
• The third part deals with "Managing and addressing threats", with all 5 chapters written in about the same quality. The section deals with a lot of subjects, from managing the threat modeling process, to defense strategies to available tools that can be used while threat modeling.
  In this section I want to delve on a short anecdote that demonstrates why I find this book so readable: When dealing with approaches to threats, the author mentions the story about Alice and Bob who were running from a bear, and Bob stopping to put on his running-shoes, justifying that he does not need to run faster than the bear, only faster than Alice. At this point, the author breaks the metaphor by stating that in the software vulnerabilities world, "not only there are multiple bears, but they have conferences in which they discuss techniques for eating both Alice and Bob for lunch".
  The tenth chapter is the one I found myself nodding the most, as it dealt with the question "How can I make sure my work is complete and that threats are dealt with?". Does it sound a bit like testing to you? it sure did to me. In this chapter we can find the always repeated truth "you can't test quality in" (which leads to "and neither can you test security in"). Perhaps the thing that got me most was when my gut feeling matched what I read in the book that stated that testers are "close allies" in threat modeling, as they are already trained to think of "what might go wrong?"
• The fourth section is dealing with "Threat modeling in technologies and tricky areas". This section is actually a mixture of various subjects that have very little in common, except being significant enough to have a chapter of their own. Among its chapters we can find "requirements cookbook" which contains possible examples of security requirements for us to write, Web & cloud common threats, some tough questions to consider when dealing with identities and accounts, a content-heavy discussion with tons of references about usability, some basic cryptography concepts and common attacks (the one I liked most was rubber-hose cryptanalysis, which is a fancy term to say "beat the cr** out of someone until they tell you what you want to know") and we get another reminder about privacy, this time about how can encryption help with privacy. 
• The fifth and last section is more of a summary. It has three chapters, two of which are somewhat intangible, speaking of ideas such as experimental approaches to threat modeling such a FlipIt, or about stuff like Flow theory and cognitive load. The most concrete chapter in this section is about bringing threat modeling into your organization, with practical advice for "selling" the idea to management or to the engineers who'll be doing it with you, and how to deal with common objections, and if you haven't yet become convinced that threat modeling is very much like software testing, and the reminder in this chapter was not enough, one of the  objections mentioned is "No one would ever do that".
  My impression was that the intangible chapters are meant for experts in threat modeling that are looking for ideas to stimulate their thoughts - For me, most of it went way above my head. 

By the end of the book there are five appendices, some short, some a bit longer:

• "Helpful tools" - This appendix contains some answers to "what is your threat model" and some of the common assets a software project might have. 
• Threat trees - This is an extension of chapter 4 (part of the 2nd section) and is really taxing to read. 
• Lists of potential attackers. Along with several generic lists, we have also the idea of using attacker personas along with some examples. Also, it's fun to read. 
• Rules for the card-game "Elevation of Privileges" that was linked above. 
• Four "case studies". They are not real, but are interesting to read. 

That's about it, and it definitely came out longer than I expected, but writing this post gave me an opportunity to go over the book again, and this by itself was totally worth it. 

Also, if you are interested, or think you might be interested, the first sixty-odd pages of the book are free to read on google-books. 

And most important, as the book states: Go Threat model, and make things more secure.

בשבחה של השפה On the importance of language

הקשבתי אתמול לוובינר של רקס בלאק, שנושאו היה Myths of exploratory testing. בסך הכל, היה די מעניין. 

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

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

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

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

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

---------------------------------------------

I participated yesterday in a webinar by Rex Black  named "Myths of exploratory testing". All in all - it was pretty interesting. 

However, the main thing I noticed was that his definition of "Exploratory tests" is very different than the one I'm used to. The spectrum I hear usually ranges between this approach and the less extreme one here. So, for me, it was interesting to try and guess why is Black reducing the term to unplanned testing that rely heavily on the tester's experience. My first thought was that he is creating a straw man that would be easy to attack. Not exactly a rhetorical trick I appreciate, but well... ok. My suspicion got a confirmation in the next slide when the myth we dealt with was "exploratory testing was invented in the 1990s". One of the claims was that as early as 1970 this technique was recognized and named "Error guessing". 

Sure. error guessing. Because the whole part of exploratory testing that are meant to find relevant information that interests our clients (=the testers' clients) is irrelevant since we are just looking for errors and silly mistakes¹. This went on for a few more slides, and I got this warm fuzzy feeling of  "I was right", until suddenly, our approach changed drastically and we were looking at "myths" that rejected common objections to exploratory testing, such as it being unmanageable or irrelevant. We even got to the point where Black stated that no testing effort could be complete without having some degree of exploratory testing in it. 

OK, my guess was wrong. what has happened here? What did I miss. During the Q&A part, I came to an understanding - Black is using the term "exploratory testing" to describe an activity very different than the one I'm used to when using this term. His definition is that exploratory testing is defined by the way it is executed and planned, while I think of it as something defined by the goal the tester have in mind (gathering information). By doing so, Black is ignoring the main thing in the definition of exploratory testing - in every definition since 1995 (according to this list, with the exception of the definition in use between 2001 and 2003), learning is a crucial part of it. 

I think that what we see here is an improper use of the term, which I think is problematic for two reasons: 

The first is that it creates a difficulty in understanding. As I have already mentioned here, inventing specific terms is a tool that enables us to communicate more concisely and convey our ideas with better accuracy, which enables us to refine our discussion and take it further. Moreover - naming something means that we can spot it more easily. By using the term in a manner which is not compatible with it's use inside the context-driven testing community (Note - I'm using "compatible", not "exact", since everyone has their own understanding of each term, but the deviation would normally be within the range that will enable others to say "ok... not necessarily the way I would word it, but it's generally what I mean") he is undermining the basis for an efficient conversation \ debate and creates confusion. Most of his observation on exploratory testing will be irrelevant for me, since he's talking about something completely different and using the same name. This in turn hinders our ability to further elaborate the ideas based on this term and creates unnecessary friction where each side is sure that the other is speaking nonsense and have no clue what they are talking about. 

The second reason I'm uncomfortable with the improper use of the term is that I think it's disrespectful. While there is no trademark (that I know of) for the term "exploratory testing', it is still identified strongly with the context driven paradigm (or, in Kaner's words - "school"), and in this case, it is also a rather important term, deprecated or not. Giving it a new definition without considering the current ones is disregarding those that did invest quite a lot of effort in defining the term inside this group.While redefining a term is an important part of keeping it relevant, the first thing one should do before using the term, and more so before redefining it, is to understand how it is being defined by the scholarly community in which it is prevalent, and how is it understood in practice. 

---

1 By the way - error guessing is a great tool, it just has a limited scope - which is a good thing for a tool, less so for a testing approach^↩

לכו לכנס!Go to a conference!

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

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

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

אבל חוץ מהאזהרה הקטנה הזו - לכו לכנס, רק ודאו שמדובר בכנס טוב.

-----------------------------------------

Some of you maybe didn't notice that, but I attended the European Testing Conference, and even wrote about my experience a post or two. If before this experience I thought participating in such a conference is probably a good idea, now I'm positively sure that every tester should do at least once in a few years. Moreover, no I can articulate the reasons why, which is exactly what I'll do: 

• First of all it is fun. In this aspect, a testing conference is no different than other conferences I attended in the past - professional or hobby oriented - people gather in a conference because they are interested in a certain subject and are passionate about it. It is fun being surrounded by people who share your interest and enthusiasm about something that matters to you. It would be a bit exaggerated to claim I went all day long with a stupid smile over my face, but the truth won't be that far from it.   
• Second, you get to meet cool people. The people at the conference already get a point for sharing one point of interest with you, which makes it very probable that enough of them will score higher than the average. Besides, you already have one subject you can speak about. 
• Third, you get exposed to new ideas - Sure, you won't like every idea you hear, and some won't be new to you. But enough of them will, or you'll see them applied differently than what you are used to. It's interesting, and it will make you better at what you do. 
• Fourth, it's a good place to look for solutions. Do you face a problem you don't know how to solve? Well, what a coincidence, there's a room full of professionals who might just know what to do, or know someone who faced a similar problem. Personally, I got some interesting advice to a challenge I face at home, and I think I helped with some ideas in at least two cases. 
• Fifth, you can argue about nonsense. Sure, the internet is there to let us vent stuff like "Who would win, Batman or Superman?", but sometimes this is just more fun to do in person. Or, you could leave silly debates and replace them with a conversation that might teach you how are things done in other places. 
• Sixth, it fills your batteries. In most workplaces I've heard of, there are at most one or two testers who care about what they are doing, and this position can be very lonely, and very frustrating. After all - why do I keep reading, attending webinars and experimenting when others just don't seem to care (or worse, they might actively make you feel bad about it)? Going to a conference is a good way of reinvigorating yourself by being reminded you are not alone, and by hearing all of the awesome ideas that just zoom around you in the air, or tapping to that energy buzz. 
• Seventh, it is a wonderful opportunity to try new things. Is there a subject you are interested in but had no idea how to approach? Some new buzzword that you don't get why is everyone so enthusiastic about it? Something you want to try in a controlled environment before trying this at home? Well, there might be a workshop targeted at this very subject, about something you didn't consider before but sounds cool, and maybe you can just gather some folks to make an experiment with you. I, for instance, found out that it was really fun giving a talk in front of an (small) audience, and to pass on some insights I had. I also found out that there are some things that are harder than they seem - like following orders. 
• Finally, come. They are distributing free giveaways. 

A word of caution, though - It's highly addictive. One of the main reasons I attended this conference was that it was reasonably priced. Or rather - I got it at a price I thought will be worth the expense, and then used it as an excuse to take a vacation, so the flight & hotel prices are actually part of my vacation expenses, and the conference only helped me decide where and when I'll be going (By the way, Romania is a nice place, Transylvania in particular). Now, after attending the conference, I think I would gladly pay twice, or even thrice that money to be in the next one. Or, as they have stated - see you next year in Finland.

One last thing - before investing in a conference, make sure it is a good one.

Tester, not a toolsmith.

(Once again, I'll start in English, as this is a response to something originating by a non-hebrew speaking writer. Specifically, a short discussion in the comments to this post)

Up until now, I had twice commented on James Bach's blog, and in both cases I had a short but very interesting discussion.or at least, interesting for me.
Putting aside the admirable amount of time and effort he invests in reviewing comments and responding to them quickly, I really like his care for using terms in a precise manner and trying to define them so they will be useful. One of the most important things I have learned in my university was that words are a thinking tool. Without having the proper word for something, it is harder to think about it, or even to see it. This way, when Roman Jakobson defined his six "functions of language" he has enabled a refined discussion about the interactions of these functions (for instance - can a "speech instance" have more than one functions? can it be phatic and referential at the same time? What would be a pure manifestation of the poetic function? A whole new set of questions that can now be discussed concisely and with everyone knowing more or less what everybody else are talking about.
Following the discussion I found two terms that I don't really like, one should be used is a slightly different meaning then the one used By Bach, and the other should just be abolished and never heard again.
The first is the term "Toolsmith". The second is "Technical tester".
The notion that some testers are good at creating tools is a really important one, since it gives visibility to yet one other type of activity done by a tester. However, when talking about a toolsmith, something sounds to me a bit off-key. When I hear the word "toolsmith" my understanding is that this is someone whose profession is to create tools. And you know what? Even though I spend some of my time writing code, creating tools is not my profession. Let's take an example from the movies, where we have two examples of people who make swords. The first one is Hatori Hanzo from kill bill, a master swordsmith with legendary skills, the other is Connor Macloed, the expert swordsmith who forges his sword (In the 3rd highlander movie). What was that? Connor Macloed isn't a smith?But he creates a sword! He's really knows stuff about sword making! At best, he's a warrior who knows quite a bit of swordsmithing, and this is where I have a problem with "toolsmith". Sure, as a tester who can code, I write tools that will help me - a script to do automatically and quickly what would otherwise take me a day of work, some automated regression checks, improvements to my test framework - you name it. But, even when I do all of that, I do it to improve my testing, since I'm a tester.
A toolsmith, on the other hand, is not a tester. A person whose main goal at work is to create tools is not a tester, even if these are test tools, even if this person does also some testing now and then.
During the discussion I used the term "artisan" as a replacement to toolsmith, and while I think it's slightly better due to specialized manner attached to this term, in retrospect I think it suffers from the same problem of focusing on the product instead of the end goal. If someone feels they are benefiting from being called a toolsmith - let them have it, me? I'm sticking with tester.

The second term, on the other hand, is outright damaging. Calling coding testers "technical testers" implies that non-coding testers are not technical, and apart from being insulting to testers that don't code, it is both incorrect and creating harmful misconceptions. Let's start with why is this incorrect:
First, while we are used to think of coders as "technical people", the two terms are not the same, and there can be someone who's technical despite not knowing how to code. Business analysts should be technical even if they can't code, since they will be those transforming the business requirements to technical requirements (I'm using business analysts, but I've heard this task being done by a wide array of roles - from product managers to architects), and if the business analysts are technical, what about the testers reviewing their work? or checking the design against their requirements? aren't they technical as well?
Second - investigating bugs requires technical skills. Sure, not all bugs require deep investigation, but providing useful information in a bug report often requires digging into logs, minimizing a "how to reproduce" scenario, DB checks - all of these are technical skills.
Third - When retesting a fix, only poor testers would repeat the same scenario mindlessly and be done with it. Better testers understand the nature of the fix and do a quick analysis of what could if affect. Again - technical skills.

I can go on with this list of "things testers are doing and are technical" for at least a couple more points (translating between developers and business people and ask good questions at design meetings and to that you can add security testing and code-reviews as well), but I think you see where I'm going.

Now, to the damage part -
I claim that this damages the following areas:
- Reputation of the testing profession.
- Non-coding testers ability to perform their job.
- Basic skill-set and development of testers.
- Inappropriate compensation to non-coding testers.

The first point is clear to me, but I'll try to explain it nevertheless: Testers work closely with developers. Most developers I know tend to appreciate "being technical" above many other traits when judging someone professionally. Why? Because they have a hard time talking with the non technical folks about what they do. When testers are by default "non-technical" (because all technical testers code), they will value less the non-coding testers, even without meaning it.
This, in turn, leads to the next point - Please raise a hand if someone ever told you "Don't busy your pretty head with this" (or anything similar). I had this response several times (not from my developers), and it's annoying as hell, and it hinders the tester ability to do their work. How can a tester perform better, when presented with "I've added an LRU cache", or "I tweaked the infrastructure a bit and stuff should now work faster"? Sure, you can always ask for more details, but the person that can give it to you won't do that if they are under the impression you won't understand it.
Now, for the basic skill set and improvement path - I have no idea how is it in other places, but around me, there's an assumption that anyone can do a non-technical job. Sure, not all of us are great at sales, but I can sure try and get a job at sales without having to prove anything - I might need experience for the high-level positions, but for entry level I need mainly to try. The same applies to testing - when someone asks "I want to get into high-tech, but don't want \ can't invest in learning, what should I try?" Probably the first answer will be "You can try QA". Meaning - we get a lot of skill-less people trying to get in the profession, and with some of them being persistent enough - they find their way in.
Next thing you know - you have a bunch of under-skilled  testers. But they will get better, won't they? No, they will probably not. The same culture that has let them in, is letting them stay without developing their skills very much. The lack of widespread concepts to improve in is not creating enough pressure on them to invest much effort. So they stay dormant. If testing was considered a technical skill, it would help because people believe technical skills easy to measure and important to advance in. By blocking the way for unskilled juniors, the paradigm will change to push people to hone the skills differentiating them from all those that were left out.
And the last point is, again, obvious.
As a coding tester, my salary is comparable with developers that have the same level of experience. My initial salary was close to double of non-coding junior testers' salary, and higher than that of some test managers. The value I brought to the company in my first year wasn't anywhere near that of my colleagues that can't code, but when one of them got fired due to personal issues, we couldn't replace him since we were not hiring non-coders any more, and his salary wasn't comparable to what was needed.

Sure, all of that isn't only because testers are considered non-technical, and there are sure some not good enough testers out there that justify being called "non-technical", but I believe testing is a technical profession (based on the skills required to perform tasks well), or at least, an "also technical" profession. And I also believe that the impression that it is not is contributing to the ill effects I mentioned above.
Oh, and while we're at it - stop using "manual testers" as well, it's almost as bad as non-technical, and it's defining a tester by the one skill they don't posses.



-----------------------------------------------------

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

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

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

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

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

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

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

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

אולי כדאי להתחיל עם תזכורת קצרה - למה זה לא נכון לומר שבודקי תוכנה שאינם מתכנתים אינם "טכניים": 

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

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

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

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

עכשיו, איזה נזק כבר נגרם מזה?

אני טוען שחלק מההשלכות הן: 

- נזק למוניטין של מקצוע הבדיקות. 

- לבודקים שאינם מתכנתים קשה יותר לבצע את העבודה שלהם. 

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

- שכר לא הולם לבודקי תוכנה (בעיקר אלו שאינם מתכנתים). 

ועכשיו לפירוט. 

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

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

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

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

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

ולסיום - נקודה נוספת שברורה מאליה. 

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

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

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

Last day of ETC2016

(no Hebrew, it will come later, I hope). (Forget it, it's too long, and all Hebrew readers that might care can deal with this text in English)

My second day at ETC2016, was just as amazing as the first day, or to be honest - it was even better. After going to sleep a bit late and getting up a bit late, I got to the conference just in time for the opening keynote, where I was quite happy to learn that I still have 10 more minutes, as everyone just assumed the day will start at 9:00 and not in 8:50 (it does make sense, doesn't it? Even if the schedule says otherwise), I used those ten extra minutes to grab a cup of tea and relax a bit.
The first keynote, by Chris Matts was dubbed "We don't need testers! what we really need is testers!", and it was really fun to hear - since Chris is a very skilled speaker (I will call anyone that can get a morning-dazed group of several dozen people to participate, move and laugh a good speaker). As the talk went on, we've heard about several subjects that seemed interesting at the time such as the cynefin framework, a seemingly nice idea titled "information arrival" that was used to examine the flow of a feature - from the initial requirement to deployment, and noticing that testing had that "looping" flow with development (apparently, we don't like loops), an interesting advice for those of us using Given-When-Then: start by writing the "then" part, and move backwards. This way you will lose less use cases as you won't be blinded by the fact that you have created a scenario resulting in the desired feature. For instance, lets look at the following use case:

• Given that a Gmail user is logged in, When the user clicks log-out, Then the user will be logged out.

Nice, isn't it? We have a test for the logout function.
But what about when a logged in user deletes their cookies? How many of you think you would have thought about it when GWT scenarios for the logout mechanism?  Some, maybe. But what if you have asked "what could cause a Gmail account to be logged out?" I certainly believe that much more people would have thought about this case.

Finally, came the point I found myself objecting the most. We had a short reminder about the 3 amigos approach to feature\requirement design, and noted that today those 3 amigos are a bit more like 6 amigos, as we have the product manager, the tester and the developer, but sometimes also the analyst, the architect, the UX researcher and UI designer, maybe someone from sales. Having that many people in the discussion means it needs to be moderated, and at this point we just went over each role and its stereotypical character flaws in order to say "they can't moderate" leaving us with which option? Naturally, our savior the tester!!  Now, don't get me wrong  - it's always nice to hear outright flattery. If someone wants to call testers supermen, I won't be the one standing in their way. But the loops we jumped through to get to this conclusion seemed to contradict my experiences, and to ignore the fact that we could have disqualified the tester from moderating using the exact same methods used to ridicule the PM and the developer. Besides that, I am still wondering what did Chris tried to convey in this talk. I think I have missed the message.

Anyway, next was a talk by Maaret Pyhäjärvi, that was intended to expose the audience to two things - How does an expert tester approach a new software, and the idea of strong style pairing. I can't really comment about the first part, as I volunteered to be the driver for this demonstration, and this took most of my attention and focus.
However, I am the only one who can say how was the experience to be the driver in that session (Unless someone could read my mind, in which case I don't want to know). That being the case, I want to share some of that experience.
The first thing I can say is - it is harder than it looks. And it was very intense - Trying at the same time to follow the instructions i was given (using a Mac,which I am not familiar with, added some complexity), trying to remember always to hold back and wait for instructions, and at the same time to try and follow what everyone else are following - the way the speaker approaches a new software. As it became clear very fast that I could not do all of that at the same time, I decided to drop it and try to focus on learning to drive and to be navigated. After a certain point, I've decided that I can't just do exactly what I was told, since focusing on discrete actions made me feel very detached. So I started communicating back - I did some actions that were intended to make me feel a bit more comfortable with the environment - I zoomed in a bit, and I started interpreting orders in a less strict way. For instance, when Maaret asked to see what happens when we click the "play" button (or was it "preview"? that green button that was below) and something started flickering like crazy in my eye I decided to understand that we were trying to examine the deliberate changes we made, instead of inspecting the complete and result, so I slowed the preview to allow everyone to see better the result.
This, by the way, was another thing that added difficulty for me in this situation: In addition to following orders and trying to half-follow a logic I was not familiar with, I also had in mind the fact that I was supposed also to help Maaret delivering her message, and that each action I choose to do, or not to do, will be something that the audience will see, and therefore my performance should be as good as it can be - whatever "good" means in this context I'm not familiar with.  Also I felt that a more experienced driver could take the navigator's instructions, and by the way of following them, provide some sort of feedback and maybe even tune in to the thought process of the navigator. I wonder if this is really the case, or just a feeling I had.
Oh, and in case you are wondering - no. I was not really aware of most of what I wrote here during the talk. I am not (yet) that good at self reflection. The main voice in my head was more like "Oh my, there are all those people here, looking at me. am I doing everything right? can I hide behind the screen a bit more? why am I messing up simple actions? was I instructed to do anything else and missed something?" The long, all aware, version is what I managed to analyze from it when inspecting it in a much calmer environment, where I was able to hear the smaller voices that got drowned by that very anxious one in real-time.
But, all-in-all, I really enjoyed the experience. And all I need to do is to wait for a video that I could watch and fill the parts I missed.

After a short break, I went to the event I had marked up in advance - the security testing mobbing session. Why was it marked up? Because it combined something I am interested in with something I was curious about. I assumed that in terms of security testing, I won't learn anything new, but I still enjoy going over the basics, especially when there are others around that are surprised to learn that most security testing is really very simple. AS for mobbing - I was curious to see a mob in action and try to asses by myself for what I can use it and for what I cannot.
Yes, of course I ended up being part of the mob. How else could I learn? by watching from the side?
The first driver, Abby Bangser surprised me in her first instruction: open chrome devtools. It surprised me because it is such a smart move that for some reason is never my first one - just by having the console open you gain visibility to many things, so unless looking for something very specific, it's good to have it open. The second move got me even less prepared: "in the devtools open the network tab and preserve the log". Again, I can see the reason behind it, or at least, guess  that reason, but in fact, I've never used that part of the devtools and in fact - I'm not even sure what does it do. Really interesting to see someone going to that tool by default. Then we went struggling on  - it seems that half of our mob knew a thing or two about web security testing (or at least, knew how to use fiddler and to inspect a bit under the hood of a web page), while the other half were less comfortable around this area. Since the actual security challenge was not important (go and check the site we've played with and pick a goal at random), I'll focus on the work we did as a mob. Once again, it is that much harder than it seems. letting the navigator decide, letting everyone in the mob to speak, driving according to instructions, bridging over skill gaps - a lot of social skills that were required just to make this format work. Then we encountered a problem of focusing too strongly, so we didn't even see the obvious answer (a cookie with a boolean named isAdmin), we actually needed help from the audience to notice what was staring us in the eyes because our discussion was so much focused on a previous success we had.
We had two rounds with a short time to reflect on our quite poor first performance between them, and In the second round I was much more aware of what I was doing (especially what I was doing wrong), and I think our mob functioned a little bit better. True, we had encountered a technical problem with our test environment, but we tried to tackle it as a mob, and I was quite happy with the progress we made in such a short time. After the mob was done, I had a nice talk with Abby about our shared experience, and about the difficulties and thoughts each of us had about this mob.
My main conclusion from that, besides the realization that mobs require quite a lot of practice before they perform well, is that doing the scary thing and putting myself under the light is really worth it - I think I got more out of both sessions than those that only watched them.

Next, after lunch, came a talk by Claudia Rosu about "A developer experience to testing" which was very interesting. It took me a while to understand that - but this was the first time I saw someone describing the use of test cases as part of a development process. What I mean by saying that is that the way she was describing it, she was approaching the whole idea of writing test cases in a way that is almost the opposite way than the one I'm familiar with. Usually, when I write tests, I try to think "what can go wrong? what might go missing? what should I double-check? Where are the risky areas?" and then I set out to see that those things won't happen, and if happened, that they are fixed. The questions she was asking were with a completely different tone: "What should I be doing? What interfaces I need to create that? Am I understanding my client properly? What are the implications of the feature I'm working on?", "How can I work safely without fear of breaking things unintentionally?". Those questions are the ones that the developers I work with usually try to work out in their design pr the coding phase (which are often combined).
At first, when I understood this, my reaction was "So, she's basically writing test cases without testing", but fortunately, I was nowhere near my computer, so I could think about it some more and see that I am plain wrong. What she was doing was exactly testing, only in a way I was not familiar with - She was learning her product and her customer, and was even oriented towards searching for problems.
I am curious, though, about the difference between these two approaches - which is better for which task. I suspect that "my" approach will be better at spotting the non-functional requirements, as the other approach uses testing as part of the functionality creation process, but this isn't necessarily the case.

After that - open space, where everyone can be a speaker! 30 minutes slots, several different places (somewhere between 4 and 6), and way too many interesting talks at the same time.
I started by going to Gita Malinovska's session where she asked the participants about their test frameworks, and specifically  about mobile application automation tools and frameworks. We had an interesting discussion about the architecture of such a test environment, with a bit about the difference between record &playback tools and what we called "coded" tools (and thanks to the guy from Ranorex that I forgot his name), One thing this short discussion taught me was that there is much confusion in what consists of a test tool, and what belongs to each level of the framework. One of the participants considered IntelliJ as part of their testing framework (and in a manner of speaking, it is), and someone other wasn't sure about the differences between JUnit, appium, BDD-like language, end all of the rest. Maybe it is a point worth clarifying.

After that - I gave a talk. I was so hyped-up the first day that I found myself wanting to contribute something to the party, and the open space gave me an opportunity to do that.
The subject I chose was Threat modeling. My goal in this short talk - to convince everyone that security testing is not scary, and that everyone can, and should do that (this notion, by the way, is taken from a book by Adam Shostack, named "Threat Modeling", more details on this book will come in a future post I've been writing for ages now). We went quickly over the problem of "what is a threat?" and I presented Microsoft STRIDE model (Which I already mentioned here, and remember: there's English below all of those undecipherable Hebrew letters) as a tool to help us think about threats. Now, The best way of showing them that everyone can do threat modeling was to start doing it. right? I thought so also. I still do. I asked from a volunteer to draw an abstraction of his product on the board. Easy, ha? everyone can threat model any system, right? We got a really tough system. At least by the description we had, it was s system passing messages back and forth with very minimal processing, no database, and very simple looking logic. I needed time to think, and I needed ideas. As always, when in trouble - stall. I delegated the thinking to the others and asked them "Do you have all the information you want? What else would you want to know if you were to test this application?". Some very good questions were raised by the other listeners, and what really saved me was Mieke Gevers' question: "are you using HTTP or HTTPS?". I used this question to point that there was a spoofing threat if they are not signing their certificates with a strong enough cryptographic hash algorithm (SHA-1 that was very popular up until recently was declared not secure enough), and once we found that the system has some log files I asked about the potential of Tampering by log injection attacks. I think we ended the session with 3 or four potential threats before our time was up and Anne-Marie Charrett entered the room with her robots.
In retrospect, there are several points I could do better.The first was to focus on the trust boundaries we drew. Another thing I think I should have done is to start looking for threats using the STRIDE types (e.g.: Is there a way to tamper the log files? Is there a spoofing threat between the server and the client? etc.). At any rate, I thought it went pretty well, considering I was winging the talk as it went, and I was very happy to see on the conclusions post-it board a note "Threat modeling is testing" and another one saying that security testing was very nice" (though the latter wasn't necessarily a response to my talk, security testing is indeed very nice).
Anyway, to Anne-Marie and her robots.
She brought two calculator\space vehicles toys and asked us to find out what is the effect of a specific button. So we set up to work, raised some hypotheses, and started working toward disproving some of them and collecting enough data to enable us to make predictions. I had the pleasure of teaming up with Gita Malinovska, Abby Bangser, Dan Billing and I'm certain I'm forgetting at least one or two others, and watching them think was very interesting, as each has their own notions and way of thinking. Besides, we got to play with toys that move and make noise. What could be better?

After all of this rush, there was the final keynote by Erik Talboom who spoke about SoCraTes (Software Craftmanship & testing) and spoke about the journey he made from being a developer who suffered when working with testers, to the point that he took a testing course to understand testers better. The talk was well presented and did great in referencing to other talks in order to connect some of the dots and tie his subject to shared ideas we all heard. One thing he said, though, sounded a bit odd for me (so, armed with my insights from the day, along with my natural chutzpah (By the way, there really should be a word for this in English, spelling Hebrew words in Latin alphabet just feels wrong), I rose up and asked - Erik's suggestion was to abolish the roles, since they impose reasonless limitations about what a person should or shouldn't do. I found it odd, since my experience taught me that roles are a great tool for growth and focus - Just by giving me the title "Security advocate", I became aware and more tuned in to the security issues we had, and quite frankly - Part of the reason I'm able to see the flaws that my developers miss is that someone told me "you are hired as a software tester" (They used QE engineer, but I'm ignoring that since they clearly meant to say tester). When I listened to Erik's response, I realized we were using the same word to indicate different things. For him, roles are what I would call "Job descriptions" - a list of things to do that implies also a list of things that are "not your responsibility". On the other hand, I used roles in a way he would probably have used something like "goals" or something similar - Titles that are used to set some end goal (or multiple end goals), leaving the details of "how" to the individual that was assigned with this goal.
This talk ended, and with it also the conference, and I stayed to chat a bit, and extend the conference as much as I could. At this point, Richard Bradshaw referred me to watch this video that seem to have some very interesting insight about the impact of job titles. I'm not sure how exactly, but suddenly I found myself standing in a room with only four other - Maaret & Llewellyn who were closing up the event, Christina Ohanian who was finalizing this amazing drawing and Tania Rosca who was kind enough to chat with me instead of going home for about 30 minutes.
And then - the conference ended.
For real.
At least, if you don't count the dinner some of the folks gathered to, which was also great. I ended up talking with Erik hörömpöli (that has a series of mini-posts about the conference, here's one of them), and listened to Franzisca Sauerwein speak with some others (Whose names are sadly slipping from my mind). I say "listened" since they were speaking several meters above my head and I was trying to figure out what was going on. By the end I found a quiet moment and asked Franzisca to translate the whole thing for me, which she kindly did (as well as added some references for me for the future).

With that, I end this my story of the 2nd day of the European testing conference 2016 - it was as packed as it probably appears in this lengthy text (thank you for all who stayed until this point), and it was even more fun, I couldn't stop smiling for several hours after everything ended, and that's always a great sign.
Probably there will be a third, shorter post, in which I will try to summarize my impressions of the event as a whole, but we will see about it later.

First day at ETC2016

(no Hebrew, it will come later, I hope).
So, My first day at ETC2016, and what a day it has been!
I'm still recovering from the amount of new information and thoughts that were crammed into my head, not to mention all of the great people I met (and the few great people I mustered the courage to speak with).
What did I have there? Two awesome keynotes, one perspective changing workshop, one really enjoyable lean coffee, one talk that introduced me to a cool new idea, and two talks that were good, and surprisingly enough, in that conference, or at least today - "good" felt like it just doesn't stand up for the high standards set by just about everyone else.
As my thoughts are still fuzzy from all of that rush, I'll just go quickly through my experiences - I made an attempt to keep some notes in each talk, but I'm a lousy note-taker, so it is probably better if I look at them while they still mean anything and re-organize them.
After registration, with me walking around trying to find some other folks who didn't know a single soul in the conference beforehand (which didn't go that very well, but at least it was short),
Then began the first keynote by Linda Rising, the subject was "the power of an Agile mindset". She began her talk with a short disclaimer about her slides being public and free to use as anyone would like, as probably we will wish that someone we know would have been here to hear it too. And she was right - ten minutes into the talk I knew exactly who should be hearing this talk. I still hope that there will be a video published with this talk, as I think I've seen a video camera posted.
The talk was about the difference between having a "fixed" mindset and "growth" mindset - the first assumes that skills are inherent and unchangeable, the other assumes they can be nurtured and grown, and that anyone can improve by investing effort. She presented a study that found that having the "growth" mindset drives people to perform better, and achieve better results. Also, for the parents around, especially for those with girls - be careful when you give compliments. Saying "how smart &  perfect you are" is pushing your child to the fixed mindset. What she suggested was to comment about the effort invested, something along the lines of "wow, you have really put yourself to the task".
Where does Agile come along? Linda made a claim that the core values of the "growth" mindset are very similar to the Agile core values - embracing change, constantly improving, accepting failure etc.
I left this talk wondering about how can someone educate themselves to have that mindset, and whether I can do anything to help them do so, as it will definitely help them a lot.

Reading recommendation: Fearless change, mindset (and apparently, audible are giving a free audio-book version of it, if you don't have an account and join their 30 day trial)

Next, after a very short recess, I attended my first "regular" talk, where Thomas Sundberg talked about why everyone who invests in automation should strive to focus mainly on the low level checks, or, as they are more commonly known "unit tests". His argument was quite compelling, and even though I've heard it before, he made a good case for it, and showed an interesting perspective about the fairly known "test pyramid" where he attached different attributes to the layers of the pyramid - at the base you could find stuff like "precise", "fast" and "reliable", while at the top there are "business logic" alongside "long" and "fragile" (I probably missed some and mis-worded some of the terms, my apologies). Despite that, I'm not sure I really buy into that idea of focusing on the unit level. There's something at looking at the trees that makes me feel as if I'm missing out the forest. Probably it has a lot to do with the fact that my experience is in automating system level checks, and that every time I looked at a set of unit-tests written by our developers they were very naïve, and almost always were a bit to simplistic for my taste. I think I can understand the reason behind investing in low-level checks, but I don't feel it. I also feel that testing a whole system tends to force me watch out for the unknowns. a unit I can grasp and understand completely. two units integrating? I can probably manage. The whole system? Not a chance in the world. I believe that this way I'm less prone to assume I have some sort of a "perfect coverage", so when the unexpected occurs, I will be more open to noticing it.
Oh, his main case for that sort of investment was simple math - connecting all the pieces together means that you have to multiply the paths inside each component as you integrate them, if you break your tests early, you are only adding the paths, which scales much better.

After a short coffee break, I went to a workshop by Alexandra Casapu, under the subject of "Examine your test skills". We got a cool testing challenge (here's a black box. go ahead and figure out what it does", and she literally brought some black boxes to play with, which was awesome), and after 20 minutes or so of playing with it, or, as I suspect most of us ended up saying: "But we've only just started to understand what's going on" we were asked to stop and think about the different skills we have used to solve the challenge. Let me tell you one thing - it was very hard to start and break down my simple "oh, I just played with it a little bit" to actual skills I applied unconsciously (or "tacitly" as I hear occasionally from Bach, Kaner, Bolton and just about everyone around them). Next, we got to compare our lists with our team members (did I mention we were split into groups?) and then to categorize the skills, which was really important too, since it allowed us to find some other skills we used (or could have used), and to identify areas in which we invest more than others (maybe it's a sign for interest, maybe it's a hint we should change our focus).
My main takeout from this session is a decision that will be tough to maintain, and I got it in the form of a quote: "Get out of the execution mode!" (I think Alexandra was quoting someone else, but I'm not certain about it, and quite happy to attribute this to her ). Pausing from time to time gives us time to reflect on what we have done and think of ways to improve. It also gives us the language to talk about testing (I have Alexandra's word for it, since I have yet to experience it firsthand, but I totally see this happening).
Next, I was a bit late for a talk by Abby Bangser with the title - "Truth - the state of not yet proven false", which was a really nice talk about how our mind fills gaps automatically and how this filling-up is based on our expectations. There's not much to do in the way of preventing it, but if you are aware of it happening, you can definitely take some steps to minimize or overcome the ill-effects of those unconscious blind-spots. An idea I really liked as a way to fight that sort of bias was by using personas, by telling ourselves a nice story about the user who will be using the software. Some automated tools could help us vary the data we use (The example in the talk was and automated web-form filler that came up with semi-random input). Definitely some nice things to think about.

Next was lean coffee, which was a great experience. I'm used to think of myself as allergic to strict formats, and I felt that the five minutes limit sound always came just at the wrong moment, but this did enable us dropping subjects fast and get a nice coverage of our topics during the hour of the lean coffee (which felt like ten minutes). I really enjoyed hearing both the concerns and thoughts. We went over various stuff - from usability testing tactics for a software specifically targeted for doctors, to choosing a test strategy, to inspiring other testers to learn (and much more). Plus - I actually got to talk to some people and now I feel a bit more comfortable approaching them, and though names are a problem (I did manage to remember Claudia Rusu's name since she also gives a talk, and Gita Malinovska with whom I paired during the workshop as well, I think there were also two Adrians, but at this point I decided the world was trying to confuse me and focused on listening to people ideas). I ended up talking a bit with Claudia about the subject she just raised when the buzzer announced the end of the lean coffee, and without noticing I found myself late to Emma Keaveny's talk about "dark patterns". Whenever your application is deceiving the user, making it harder to choose the "right" option, or coerce the user to do something they wouldn't normally do, you are using a dark pattern. A really cool subject, and something I will have to remember looking for when testing in the future. For me, all the bits and pieces connected perfectly when I realized that this is very similar to some of the concepts of usable security. There we ask "Is the default behavior is the more secure one?". When looking for dark patterns the question is similar - is the default behavior is in the best interest of the user?" . I think it might prove a great rule of thumb to identify dark patterns.
Oh, and by the way, if you ask me - the most notorious use of a dark pattern I have ever seen is the flash player update. Why should I uncheck something to avoid downloading a second piece of software to my PC??
Reading materia: Evil by design, darkPatterns.org.

After the talk I stayed to speak a bit with Emma and two or three others (including one that worked for Adobe  - the company that was my go-to example for using a dark pattern with the antivirus bundled with each flash player update). That was really cool, and we were late to the closing keynote by Anne-Marie Charrett with the misleading title "How to conduct great experiments". The talk did mention some experiments, and it seem that they were great, but it was so much more. It was a transition of paradigm - from test management to test leadership (and the bottom line, that left my jaw right down on the floor, was that the difference is that managing is a regulatory activity that promotes stability, while leadership looks for and drives constant change and evolving), which had to pass through redefining the role of the testers in the company, focusing on what is most needed and delegating or dropping other activities that could be done by others, or that are not as important to have. It also spoke about the difference caused by the test team size, and added a creative solution of dispersing the test team\department and driving it to become a practice rather than a designated owership (practice, in this case, is like the medical practice - where one might go and consult the doctor about their health, but the ultimate responsibility to eat, sleep and exercise properly is the individual's, not the doctor's).

Then - retrospective. How do you do retrospective of a full day for ~100 people?
Here, have a look.


By then, the day has ended, and I was happy to get to my Hotel and rest a bit. This day was intense.
Only I didn't. at 9  PM we met at a nice bar\café and had some good mingling time. I ended up talking a bit with Richard Bradshow, and having another chat with Emma Keaveny, and got a chance to thank Llewellyn Falco and hear from him about some of the purposes of the lean coffee (to get people to talk with each other). There was so much more going on there, but it was a bit late for me, and everything just got mixed up in my head to a really nice feeling that I can't pull details from, but certain that it was good.

If any of the others I talked with during this day and are not mentioned hear ever read this - please don't be offended I didn't have your names here. Some of them I actually do remember, but this post is already long as it is, and cramming a whole day to a single post is almost as hard as is cramming all of those ideas into my thick skull.

So, thank you everyone for a great first day.