אל תקרא לי מהנדס Not an Engineer

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

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

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

כל השאר, לדעתי, שגוי מן היסוד. 

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

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

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

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

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

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

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

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

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


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

The other day, I attended a webinar by Rex Black (is "attended" the correct word for a webinar?). As I think I have already stated - I find his questions very interesting, and most of the time I don't like his answers even a bit. The subject was "Why does software quality (still) suck?". The answer, in short (if we skip the part of "not enough time and budget" which is a general truth) is divided to three parts : 

1. Because software engineering has not yet matured to true engineering.
2. Because we don't know how to measure quality, so we cannot improve in it. 
3. Because software testers are not properly certified. 

I want to start with a short point of agreement - Rex Black has defined this webinar as a rant. That was very correct. 

All of the rest, however, is fundamentally wrong. 

First of all - I do not necessarily agree that the quality of software is low. During most of the webinar, Black uses "defect density" as an indication - until the point where he claims that this isn't a very strong measurement (Since two, very different quality products, can have the same defect density) and says that the main reason of using it is that it is easy to measure and that we don't really have other accurate measurements. Well, I'm a regular user of software. And when I look at the software I use, I can't really say that they are low-quality. Yes, there are bugs, sometimes really annoying ones (at work, my notepad++ is crashing randomly on my work computer. I claim it is still of higher quality than the regular notepad that is stable, to the best of my knowledge), but still, my PC loads reliably, does what I expect it to do and have a pretty decent user experience. Even my five years old phone, that suffers from both wear and weak hardware, is doing its job, more or less. So why insult them with claims of low quality? 

Second - if we claim that we don't know how to measure quality, on what basis is Black claiming that the quality of software sucks? What lies beneath this claim is the fact that even without measurements we can provide some rough, generally acceptable, estimates of software quality. We might not be able to put an exact number to it, but we can T-shirt size it, and if we set up to improve our quality, we can conduct a series of experiments and see if the quality improves. We might miss small improvements, but we will notice bigger improvements, so not being able to measure quality isn't really a reason for poor quality (from this point onward I will accept the claim that software quality sucks for the sake of the argument). 

And now we got to the point that bothered me the most - software development is not yet a true form of engineering. 

This has two part - the correct part, and the wrong part. 

the correct part is that software engineering is very different than other types of engineering that we are familiar with. Other engineering professions are about creating processes and applying (or supervising) them in order to get consistent results in a predictable cost, software engineers are improvising their way forward. 

The wrong part lies in the "yet" part. There are several reasons that lead me to believe that software development (and testing in particular) isn't, and shouldn't be, an engineering field but rather somewhere between a craft and a social science. 

1. An engineering profession is operating in a rather stable environment. This environment might be extremely hostile, but is is largely constant - the type of problems do not change drastically or rapidly. Car engineers, avionics engineers or architects are dealing with the same problem again and again - the physics that enable an airplane to fly are constant, the road conditions for cars are pretty much the same as they were in the last 50 years. The solutions might vary, but something that worked in the past, will still work today, and is still a valid measure to compare against.
   The software world, however, is changing rapidly. If the first computers were standalone devices, the proliferation of the internet has changed everything, then mobile came and flipped it all upside down, and now we have IoT to change it all again. Moreover - even if we remain in the same world - an OS update might change some of the assumptions that were made when the software was developed (such as - running with admin privileges does not require special approval), or a browser update can make my site look horrible. Even if nothing changed on my computer - it is sufficient that a cryptographer finds a new flaw in an encryption algorithm to suddenly render my software insecure. In such instability, I don't think it's feasible to create an engineering practice. 
2. A software is a set of rules that operates in a human environment. Some bugs are simply a matter of preference. Google thought that sending a cute Minions animated .gif is a great idea for April 1st, and some of the users agreed. Some others, however, didn't. It is a problem of balancing different wills and needs of different people, which is really a matter of taste, or of some psychological \ sociological researches. It is not, and cannot be, an exact science, at least as long as people are involved. 
3. Engineers solve the same problems over and over. A bridge should carry such and such weight, withstand earthquakes and winds in a given range, be as pretty and cheap possible. Once a solution that satisfies those conditions is found, it can be reused and adjusted over and over. In a software project - each time the software solves a different problem. Even when working on the same project, each new feature is addressing a different problem - the common parts are quickly extracted to libraries. The equivalent of "build a bridge" is something like "open an HTTPS connection" - but software is the whole ecosystem - it's about the parts that cannot be reused but have to be invented. The engineering equivalent of just about every software isn't the final model, but rather it is the first prototype. 

for theses reasons (and probably some others I just forgot to mention), I don't think software development should ever be similar to engineering professions

Now, the third reason mentioned by Black is that software testers aren't properly certified. This claim manages to be at the same time true and twice false. 

It is true in the part that there isn't any common way to join the testing profession or some formal training that is widely accepted. I always feel a bit sad when I hear all those "how I fell into testing" stories (am I the only one who set out of the university and actively looked for a testing position?), but as long as there isn't any clear path a tester should tread, it will probably still be the main way testers find their profession. I think that having some strong certification path can be beneficial both to the testing profession and to the software industry. 

it is wrong once in that that not having a certificate isn't an excuse. Ok, so testers start with a disadvantage. I still expect from an experienced professionals to be good at what they do. A tester with 3 years of experience should be able to provide for the testing needs of a company in a sufficient manner, and a tester with ten years of experience should be able to do testing well and have that added value that might have been easier to achieve with a strong certification.

It is wrong a second time since when Rex Black speaks about certifications, one cannot overlook the certification program that he is involved in - the ISTQB certifications. I'll spare you the usual rant about ISTQB as a certification program (I promise to have a post about it sometime soon), but for now, let's face the bottom line of that rant - The ISTQB certificate (and I refer mostly to the CTFL) isn't providing value, and companies that have a decent percentage of  their testers with CTFL or more advanced certificates are not known for having a better quality products. 

All in all, despite (or maybe because?) I didn't agree with any of the points, it was a very interesting webinar. I strongly recommend listening to Rex Blacks webinars - check up one or two, and see if it makes you think. There's a webinar usually once a month, and the next one is next week.

בדיקות בסוף השבועWeekend testing

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

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

אז מה היה לנו שם? 

התחלנו עם הצגה קצרה של כל הנוכחים (סדר גודל של עשרים איש) ומשם ניגשנו לעניינים. 

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

בשלב הזה קצת נמאס לי - לא הבנתי מה המטרה של השיחה הזו, והיא נמשכה יותר מאשר היה נראה לי סביר. 

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

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

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

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

בסך הכל - זו הייתה חוויה מעניינת. 

כמה נקודות קטנות לשיפור -

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

ולסיכום - הצטרפו למפגש הבא, זה כיף. 

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

I participated in Weekend testing Europe today. The subject was "Heuristics in testing". By chance, I just gave a short introduction talk at work about the same subject, so I came prepared after reading a bit and thinking a lot. And now I get an opportunity to consciously use some of it and see other testers do the same? Super-green. 

So, bottom-line first - I had a great time and I learned a bit. There are also some small things that could be improved. 

Or, in more details: 

We've started with a short presentation of the participants (somewhere around 20 people), and then we got to business. We've spent about 40 minutes in defining heuristics, presenting some heuristics that some of the participants work with, and toss around some interesting links. 

I had two problems with this discussion - 

First, despite having a very diverse group of people, it seemed that all of us (including me) were reading out of the same textbook. 

Second - it felt very out of focus. I assume that the original purpose was to align everyone around the same concepts and terms, but it turned out too lengthy and erratic to do that effectively. In fact, it seemed that we spent some of the time throwing acronyms one at another and then breaking them to the words behind them. Why? just because. So we've discussed SFDIPOT and (F)EW HICCUPPS, and then, since I didn't like the fact that we were practically equating heuristics with fancy acronyms, I threw in the dead bee heuristic and someone else added the Lévy flights, which is a nice way to describe the strategy of "test until bored, then go test someplace else". But then again - both of those examples come (to the best of my knowledge) from the same source. 

At this point, I started wondering if it would be too rude to ask publicly what are we trying to achieve by the current activity, but I was lucky - before I decided, we went to the next step: Testing an application. Which one? this. We broke into small teams and set out with the goal of trying to write a test plan using SFDIPOT. 

Somehow, I did manage to find a team, and we were three - Dolores, a tester from Vienna (originally from Spain), Kirill, a tester from Russia (I think) and myself. We spent a little (too much) time on setting up a new Skype group for us and creating a shared mindmap which we then - off to work!

We invested some time looking at the application (which we were unfamiliar with) and then I blinked for a bit - and found that Kirill managed to add a ton of leafs to the map. He explained that he was writing things as he went by, to be organised later - which we agreed was a good strategy, so we gave it five more minutes before turning to organize what we've found.  While we were sorting  things I noticed it didn't seem as if we were using SFDIPOT, so I pushed a bit to fix this (after all, the whole purpose of this exercise wasn't to create a test plan, but to practice using heuristics). I must say - it's not surprising that we didn't use SFDIPOT. None of us had experience using it, we were facing a completely new application, we were communicating by chat and had zero experience of working with each other. With all of those around, and the very short time we had, we get a difficult task, so naturally we resorted to doing things the ways we knew and felt comfortable with. It took a conscious effort to shift the focus to the heuristic we tried using. 

All in all - an interesting experience. 

Some points that I think could be improved: 

1. The theoretical part was a bit too long to my taste. Clearly defining a goal and shortening the discussion in half would have made it that much better for me. 
2. During the mission we got, we should have focused more on the task of using the heuristic. Perhaps it would have been easier if we split it up to smaller bits such as "try to map the structure of the application" or "what types of data do you think there are?"
3. I could have benefited from several minutes of reflection within the group, perhaps with a question or two from the moderator. 
4. Just before the end, Amy (the moderator) mentioned that she saw me doing something that interested her and we had a short chat about it. I'm sure I wasn't the only one doing interesting things, and would have loved hearing about some of the approaches used by others. 
5. I'm not entirely sure I am comfortable using this specific heuristic in this context. While working with it I got the feeling that I should know a bit more about the application before trying to use it. Perhaps it can be done in a more controlled environment with closer guidance, but in the current setup, I felt a bit too lost. 

To sum it up - go and join the next event. It's fun. 

לדבר זה דווקא בסדרTalking is not always hard

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

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

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

And today, in our list of things that look so obvious in retrospect - it is apparently that much easier to give a talk about a subject that I have a lot to say about. In the last time I tried to present a subject at work, one could summarize my whole speech in "Personas seem to be cool". Sure, I tried to elaborate a bit and did some research, but it was not a subject I had experience with or something that "clicked" naturally. I mainly liked the idea of using personas following Abby Bangser great talk that provided an excuse I liked to use them.

This time, however, The research was much more fruitful, and the subject immensely more vast. I gave an introduction to heuristics in testing. My initial idea when I have just started was that heuristics are some odd acronyms that are useful (I had FEW-HICCUPPS in mind) and I wondered what else might be that simple and useful. I could also point out Galumphing and click-frenzy, which are two terms I picked up from James Bach. My assumption was that heuristics and odd acronyms are pretty much the same thing. Then, I started reading and found out that the definition of heuristics is actually "just about anything that can help you solve a problem". It seemed at the same time very reasonable and completely meaningless - can there be anything significant to say about something that is as wide as "everything you can think about"? So I thought and thought - and hit a brick wall.
OK, what do I have to lose? I sent an email to James Bach describing my attempt to get a grip around heuristics, what I've done and what I'm trying to figure out, and he was kind enough to answer me (that's so great from his side to just answer a random guy from the internet who drops in with a question - I don't have enough words to thank him for that). Not only he answered, he took the time to go with me through some back and forth thinking about how I understood the term, and what value is in my definition (and whether it is worth the extra complexity I tend to add in), and by the end I made the journey from "It's too big of a subject to be meaningful" to the point where I accepted the claim that trying to narrow down the subject might actually be less effective and introduce some difficulties. It also helped me see that within this large subject there are areas that I want to focus on first.
And so I continues my reading a bit and ended up with a ton of things to try and cram into a one hour talk - Even if we put aside the fact that some of the common heuristics can be discussed for several hours each, between discussing the definition of heuristics and trying to convince the audience that it is worth investigating time learning to use some heuristics and consciously thinking about it, i had very little time left to even go over some of the examples I thought worth mentioning.

In retrospect, I think this is the ideal situation before presenting a talk - when I know much more than there is in the presentation I can elaborate according to requests, and I can use the slides as an aid instead of relying on them as information source.
I also think that since I wasn't that focused on finding something to say I did better in some of the points that I noticed the last time. I still had my presentation too crowded, but I manged to give some attention to most of the attendees and I knew exactly what do I want to say in each slide (including a silly joke I planned).
I still have a lot to improve on the talking part, but I am going there. Besides - it was fun, and giving a talk is an opportunity to learn a bit more on a subject.

כשאבטחת תוכנה מתנגשת עם הדרישות 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.