כשאבטחת תוכנה מתנגשת עם הדרישות when functionality and security collide

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

Source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNShgx0IUkQft6Va0lhX3K3yjUbVgLUFO-0KkQ43jakGIQWH08SuuiunZtOO1dy7C0Ku1t0cnAb3KSx_1cTmxcigUP02blRsnI4DV2Tovy1We_EEAKwiZdFTx5OWGTVbOHjA4BWfXMb7E/s1600/dont+track.png

 כעת לחיצה על הכפתור מובילה לדף חדש בכתובת שנראית פחות או יותר ככה:  https://<blog_name>.blogspot.com/b/statsCookieManage (זה אינו קישור!)
אני מניח שאחת הסיבות לשינוי הזה נובעת מתלונות רבות שהיו על כך שהתכונה הזו לא עובדת (האינטרנט מלא בהן, פשוט לכו לחפש). יכול להיות שיש גם קשר לעבודה עם עוגיות צד שלישי והניסיון לצמצם את השימוש בהן, אבל בכל מקרה - מה היא השאלה הראשונה שעולה בראשו של בודק תוכנה שרואה את ההתנהגות החדשה הזו? נכון מאוד! האם אני יכול לעשות את אותו הדבר בבלוגים שאינם שלי? חמש שניות לאחר מכן, קיבלתי תשובה - אני יכול לגשת לדף הזה, ולפחות למראית עין, ההשפעה של סימון "אל תעקוב אחרי הצפיות שלי" זהה למה שקורה בבלוג שלי. 
תגובה ראשונה - מצאתי באג!
ושנייה אחר כך - רגע, אולי זה בכוונה? 
מצד אחד, המוצר אינו עקבי ביחס להיסטוריה של עצמו, שכן בעבר ניתן היה לגשת לאפשרות הזו רק דרך ממשק הניהול, וממילא רק לבלוגים שאני מנהל.  בנוסף, מה יקרה אם כולם יבחרו לסמן את התיבה הזו? ספירת הכניסות תהפוך ללא אפקטיבית. לכאורה - תקלה. 
מצד שני, יש בזמן האחרון מודעות גבוהה יותר לחשיבות של פרטיות הגולשים. אולי האפשרות הזו גלויה בכוונה? אולי רוצים לאפשר למי שהפרטיות חשובה לו לא להיספר בתוך מניין המבקרים בבלוג? זו כנראה לא הדרך בה אני הייתי נוקט, אבל אולי כך אמור האתר להתנהג? 

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

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

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

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

I don't know how many of you have noticed, but Blogger has changed the way the "don't track your own pageviews" work.
At first, it looked like this:

Source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNShgx0IUkQft6Va0lhX3K3yjUbVgLUFO-0KkQ43jakGIQWH08SuuiunZtOO1dy7C0Ku1t0cnAb3KSx_1cTmxcigUP02blRsnI4DV2Tovy1We_EEAKwiZdFTx5OWGTVbOHjA4BWfXMb7E/s1600/dont+track.png

Now, the user is redirected to a new page  https://<blog_name>.blogspot.com/b/statsCookieManage (This is not a link!), I guess that one of the reasons, or maybe even the only one, for this change was the number of complaints that the previous implementation was broken and many people complained about it (google it), probably due to most browsers making the life more difficult for 3rd party cookies. Indeed, the new mechanism does redirect to the blog domain, so it shouldn't cause many problems on that aspect. 

Anyhow, what's the first question that pops to a tester's mind when faced with such a feature? Indeed, it is "can I use this feature on blogs not under my control?". So, quickly after making sure to work around what seems to be another bug (This new feature does not seems to be working across regional domains, so I made sure to check both .com and .co.il ), I went to another blog I follow and got the relevant URL, and Lo and behold - nothing blocks my way. 

Also, as far as I can tell - the behavior seems to be the same (Sure, I couldn't go and check the actual stats, but I got an identical cookie to present). 

My first reaction: "Yay! I found a bug!". 

And a second later - "Wait a second. maybe this is on purpose?"

On one hand, this feature is not consistent with its history, and therefore, also with my expectations as a user - before, it didn't seem that I was able to opt-out of the tracking of blogs that I don't own, and as a blog owner - I actually look now and then at the pageviews stats and would be very sad if my readers would hide this way. 

But, on the other hand, privacy is a really strong trend these days, and perhaps it is an improvement that enables user to control who sees them and who doesn't. It might not be the way I would do things, but maybe this behavior is intentional?

Certainly, this problem is not unique to cases where I'm completely out of the loop and have no idea of the business model behind the product. I might find myself facing the same question when working on the product I'm testing. Should we present a helpful, informative, error message, or prevent an attacker from enumerating our current users by checking the error message? Is encrypting another piece of information worth the impact on performance?  Should we provide the customer support useful information or protect the end-user privacy? The decision is not always obvious. 

In this particular case, I think it's safe to assume a bug - if this was a privacy enhancement, it should have been accessible from any blog I read - not only from the management section. So, instead of a (security) requirement trumping another requirement, I think that the root cause is just that it is a case where a requirement is having an unexpected effect on another. 

At least, I got a nice thinking exercise out of it. 

Do you have ideas that helps to determine when there was a conscious choice to prefer a requirement over another,  and when it's simply a bug? 

Also, noticing requirements collision is not always easy - it is very easy to miss the fact that our two-factor-authentication may actually be really annoying to  the user? or that when we collect data to improve our services we might be collecting that hinders the user privacy? 

How would you suggest to spot conflicts between transparent requirements (transparent requirements = properties of the software that are not "it does X", but rather "it is...", most illities are transparent, as is performance and responsiveness) and functional ones?

למה אנחנו בודקיםwhy do we test?

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

ארבע הנקודות הן:

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

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

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

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

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

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

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

איזו תמורה מופקת בעזרת בדיקות תוכנה?

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

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

איך בדיקות תוכנה יכולות לחסוך כסף?

כנראה שהדבר הראשון עליו חושבים בהקשר הזה הוא הגרף השחוק הזה:

(מקור: http://thesupertester.com/?p=123)

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

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

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

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

In RBCS archive I found a webinar recording with a great question: Why do we test? Or, to be precise - why is it that companies pay us for? While it's true that this question was actually mostly a pitch for promoting the idea of writing a test policy document (For some reason, Rex Black's answers tend quite often to be "write a document"), but while describing the creation of the document he gives four "typical objectives" for testing:

• Find defects, especially important defects
• reduce risk to an acceptable level prior to a release
• build confidence in testing and the software
• provide information to make informed decisions throughout the lifecycle

One reason I don't like these answers is that if you look at them closely, you'll notice they are all the same - Find bugs and tell whomever needs to know. The 4th answer could be a bit more than that, but usually when framed this way it means just "find bugs" as well. 

Also, I think I have a better answer that I heard at the very first time I heard about software testing, at the University. The professor, Michael Stahl asked during the first lesson, just after presenting some disastrous bugs, with the question "why we test?". As you can imagine, the answers in the class ranged between "to find bugs" and "to make sure the software is of good quality". Then, with a smile, he moved on to the next slide, with the concise and simple answer - "Because it costs less than not testing".

Frankly, I like this answer better than I like Rex Black's answer, but when I gave it some more thought, I found out that this answer also isn't complete.
The way to look at this, I believe, is the other way round - instead of trying to inspect the testing actions and try to figure out what is it that companies are willing to pay for, it might be easier to examine what companies pay for, and try to figure out how our activities fall into these categories.
That being said, I'm no economics expert - I might be missing whole areas that I'm unaware of. Still, I feel rather comfortable to take a guess just from my observations. I think we can say that a company is paying when something meets one of the following criteria:

1. It must. If there is some regulation or law that forces it to pay. Maybe its a product in the avionics industry and it is required to prove MC\DC, maybe it's an e-commerce site that has to go under PCI audit, maybe there's a government contract with a clause demanding something. Software testing might be part of those conditions, and software testers in such conditions don't really need to ask the question - they know exactly what it is they are hired to do, and that should be their top priority. However, being forced to pay isn't exactly what I would call "willing to pay", so I don't want to elaborate on that more than I already have. 
2. It might be done to build or maintain a reputation, or to get publicity. This is why companies sponsor conferences, give charity or perform any number of otherwise not beneficial activities. Sometimes, this image, or reputation is calculated so that it will have a positive impact on revenue, but other times it can be just something that is important to the CEO, or even a fashion trend. Again - I don't think this is the category to look for testers activities.
3. It gets something in return. In the software world, this is the domain of the developers who create the products that the company is selling. Note: the revenue generation is secondary here -   People (and companies) pay willingly for things they want, even if they don't create profit. A painting to hang on the wall is a good example for that, as is a meeting with a psychiatrist. I think that testing does produce something that companies want, but since testing does not create an artifact (unless you are selling test cases, in which case - shame on you!) - trying to estimate the actual value of testing is as difficult as trying to calculate the financial value of what you gained at the last meeting with the psychiatrist. 
4. In the case where paying for something actually (or potentially) reduces cost. Hiring a night-guard to make sure no-one steals from your warehouse, or hiring a manufacturing manager in order to make the manufacture line more efficient and stop losing time & materials. As I said before - I think that this is the main value testers bring. 

Well, if software testers create value and reduce costs, perhaps it is a good idea to look at how we can do that. The list below is by no means exhaustive (If you have ideas I missed - I'd love to hear about them), but this is what I was able to come up with. 

What value is generated by software testing?

I think that if we look at the bottom line, the concrete value from testing really is someone sleeping better at night. It can be the product manager that has more confidence in the decisions taken, or the developers who know that someone will look after their work (whether it is a good or bad thing is a matter for another discussion). 

It might sound a bit demeaning to regard testing like that, but despite the simplistic choice of words, it is by no means a simple task as the number of people wanting to sleep soundly is quite high. I had the opportunity to hear Joel Monvelisky speaking on software testing as an information providing service - to Prouct managers, developers, support, sales - you name it. Each of these want different information, and in a different format. In fact, even people with the same role might ask for different information - One may just want to hear "trust me, everything is fine" (or the flip-side - "There are some problems we encountered and we think the impact will be about two weeks of delay"), and another may prefer to have a detailed report of what was tested and what were the results.

How can software testing reduce costs?

Probably, the first thing that comes to mind in this context is some version of this well known (and somewhat stale) graph

(Source http://thesupertester.com/?p=123)

Of course, in addition to saving direct financial costs, this also serves to protect brand name & reputation, which can be translated indirectly to financial costs.

However, I don't this is the only way to reduce costs, nor do I think it is the most significant one, especially in agile, continuously updating contexts. Instead, I want to point out several other activities that software testers do and reduces costs:

•  Brendan Connolly has a great post about Testers = Translators. Every failed communication is incurring costs, resolving, or avoiding this miscommunication is preventing this cost both,
• Ann Marie Charrett has mentioned almost as a side-note in a great talk she gave, the potential of testers to carry information between teams.
• Testers  are normally a good source of information to many other functions in the company (note - this is not the information we provide as our "product"). There isn't a day where we don't sit down with our product manger to explain (or, in severe cases - investigate together) how our system behaves, or with someone from support to help them with a problem they are having difficulties with, or with our developers that want to know how a part of our system works and on what some planned change might have impact (Or, my favorite question - why is something behaving in a certain manner). . 
•  We push for a straightforward solution that is easier to maintain. If we insist on having consistency in the behavior of different features, proper logging and reasonable communication scheme between our components - the end result is a product that is easier to maintain. True, this is "The responsibility" of the developers, or of architects (if such exist), but we are already look at that direction. We participate in design &code reviews, and as part of our tests we are reading the logs and checking the database (if you don't - why not?), so why not pay some attention to these parameters as well? 
• Automation used for testing can be used for other tasks. As testers we have invested a lot of effort (or had someone else invest that effort for us) in order to have that magnificent test framework and now we have a set of tools that do a lot of the tedious tasks for us, so why not share it?  Just last week I sat with one of our analysts and we used our framework to create a one-time script. After about a day and a half we have completed a work would have taken her about a week of work not to mention the frustration of doing the same tedious actions or the inevitable human mistakes.

And on top of all that, I think we should always remember that we are a part of a team that has one goal - to get a product out to the market. If you see a task that needs doing and is within your capabilities - go and do it. Even if it is not a testing task. 

קשה לדבר Talking is difficult

לכל דבר יש פעם ראשונה, גם להעברת הרצאות. 

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

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

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

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

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

Everything has a first time, even public speaking. 

Last week I gave a talk at work - not very public, but still way more public than what I'm used to. The subject I chose was something that caught my eye following a talk I heard at a conference. Specifically, I talked about using personas in testing. It wasn't the subject of the talk I heard, but Abby Bangser's talk gave me a great reason to use personas in testing, and while I'm far from being an expert on the subject, I wanted to introduce the idea to the rest of the testers, as well as to start a tradition of knowledge sharing. Besides, I want to make people at work to see the value I found in going to a conference.
So, I invested some time in creating a power-point slideshow and came to the talk feeling more or less prepared.
What can I say? I think that while it went more or less fine, I learned quite a bit.
First of all, there seems to be a significant difference between talking in front of one's team, when everyone are sitting around the same table, and "giving a talk" - even if the audience is only two or three times larger. The first difference is that while standing in front of an "audience", suddenly I find myself in a position of responsibility - it is no longer a situation where there is a shared discussion I happen to lead, or an idea I'm sharing interesting stuff with my team, it is "a talk" where I'm responsible for everything that happens on. Stressful.
Under stress, apparently, odd things happen. My ability to improvise is significantly hindered, many points where I originally thought "Here I'll speak about this and that, and it'll be fine" just flew straight out of my head, as well as the order of the slides and what I wanted to say before each of them. Also, probably due to the slight stress, I found that I rushed through my slideshow in a pace that surprised me - I intended the slideshow to take the better part of an hour - and ended up finishing it in ~20 minutes (sans the Q&A part).
In addition, I found out that my GMing skills need to be tuned for this type of event. For about 17 years one of my hobbies have been playing RPGs, and not of the boring computer stuff. As part of this I also got from time to time to take the role of the game-master and build my own game (usually a short one-timer). Thanks to that I acquired many skills that are relevant for public speaking - Controlling my tone & my stance (and being aware of them), pacing my talk, reading the most dominant responses of the participants and making sure that everyone are involved. I'm not very good at all of these, but I do have some basic skills that I was counting on. It appears, however, that when in the situation of public speaking, those skills need to be tuned a bit differently. Noticing signals from a large audience is not "more of the same" as looking for signals in a small group - the signals are a bit different, as are the tools I can apply. On the other hand, the skills are basically very similar - by the end of the talk, when I forgot to be afraid and became more confident, I found that I was using some of the tricks I picked up upon this path in order to get people to be more involved (yes, including the infamous trick of picking the person who seems least interested and asking them a question). The little feedback I got confirmed my feeling that I ended the talk in a better state than I began.
Finally, in order for this post not to be only me letting out steam - some points I'd like to improve on in the next talk I give:

• Simpler slides with less written text. I want the slides to remind me what I wanted to say, not to say it instead of me. 
• Be better prepared - I want to practice what I'm going to say, not only go through it in my head. Most of the chances are that this preparation will go out of the window when the talk starts,but something will surely stick. 
• I want to be better aware of the audience mood and make more people feel that I'm talking to them. In particular, I want to reduce the number of times I looked up to the ceiling or to a corner just to clear my thoughts. 

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". כלומר - יש לנו הרבה מאוד אנשים חסרי כישורים שמנסים להיכנס לעולם הבדיקות. חלקם עקשנים מספיק או סתם בני מזל ומצליחים להיכנס פנימה. 

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

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

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

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

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

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