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