Friday, August 11, 2017

תזכורת על חשיבות התזמון

Reminder about timely feedback

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

------------------------------------------------------------------------------------------
One of the things commonly said about software testing is that it is the business of providing information - focusing on timely & relevant information. 
However, this doesn't always work out well. Yesterday, in Thursday, I spent several hours reviewing a document sent to me by a colleague. One of my comments was "the scope of this document is wrong" and another one was "I'm missing some sections about this, this and that". Knowing that these changes mean quite a bit of work I hopped over to the room next door and had a little chat with the author. We both agreed that the changes would make the document better, but a review meeting is already set to Sunday, and it isn't easy to get the relevant people in one room, so moving the meeting is quite expensive, even ignoring the other stress factor that want this review done (some very pushy project managers and possibly a miscommunication with some customers). Making those changes would require a bit more than half a day (Weekend in Israel is Friday & Saturday)  and we both agree that presenting the document as is would be better to presenting a better version of it later. Still, now both of us are bummed because we know this could have been better had I come up with this feedback a couple of days earlier. 
The sad part is that I don't think there's much to learn here. It's a reminder of why timely feedback is important, but given a similar situation I would probably behave in a similar manner, postponing the review to deal with more urgent (and more important) tasks. Most of the times, my comments might be numerous and require some work to fix, but it is usually less than half a day.  Maybe, had I skimmed the document... but it took me about half an hour to realize that the structure of the document was wrong, so I think it wouldn't have helped. All in all, that's the meaning of risk - something might go wrong, and I have accepted this risk. 
Ah, well, that's the sad part about heuristics (I used "if it was urgent and important, someone would be nagging me" heuristic) - they sometime fail. 

Tuesday, August 1, 2017

Rant



No Hebrew this time, ranting once is more than enough.

Every now and then, there's a deluge of memes and semi witty remarks on what appears to be testers favorite subject - bugs. Usually, bugs created by the oh-so-incompetent developer.
Well, I have a request for you - If you are about to create, post, retweet, or in any other way share such a hilarious pun - please don't.
Yes, I'm sure that everything is done in good spirits, and it's only a harmless way of venting out.
And yet - Stop.
Besides creating and enforcing a useless barrier between testers and developers (which, I hope everyone posting such stuff is aware of this side effect), this unproportional focus on bugs also portrays testing in the very narrow aspect of bug-hunters. It diminishes every other aspect of testing - exploration, collaboration, risk-analysis, facilitation & acceleration of shipping stuff - and focuses on obvious bugs, probably the single most superficial thing there is to testing.  
So yes, sure, a joke. Sometimes it's even a funny one.  Just remember that humor is one very effective way to convey ideas and make them stick.
So i would appreciate it if you would stop doing that. Thank you.

</rant>

Also, I have a challenge for you - Find some memes about testing that aren't about bugs or bashing developers, and share them the next time you encounter some of those.

Here's one I found: A bit of an internal testing joke, but still.


Monday, July 24, 2017

שני דברים שצריך לדעת

Two things you should know


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

-----------------------------------------------------------------------
  1. The European Testing Conference has published a call-for collaboration (which other conferences might name "call for papars\participation", and the people at ETC are serious about this difference).
    If you have not done so yet, you should submit your ideas there - It's a wonderful conference, the organizers are amazing, and they are jumping through hoops to make the content submission as easy and accessible as possible.
    Don't want to speak? well, it's time to get a budget (from work or by yourselves) and wait for the early bird registration to open. You want to be there. Trust me on that. 
  2. Have you read recently the Wikipedia page on software testing? Did you notice that it could be immensely improved?  Well, Alan Page is doing something about it. Come join the party!


* picture on top was found here.




Sunday, July 23, 2017

זה לא צריך לעבוד

This shouldn't work

Over a month ago, the closing keynote of NordicTestingDays was given by Kristjan Korjus from Starship Technologies and he told us about their product - a small(ish) delivery robot meant to help with "last mile delivery". The general idea is ingenious - creating a self-driving, fully autonomic delivery bot is an extremely difficult task, but creating a mostly automated delivery bot with some human support when needed is a bit more feasible (still not easy, though).
Well, What happens when one brings such revolutionary idea to a testing conference? Naturally, you get a whole lot of questions challenging the validity of the idea. In fact, most people I've spoken with directly after the keynote did not seem to be convinced that it was a good idea at all.
However, while participating in the European Testing Conference I got to listen to Liz Keogh who, during an amazing Cynefin talk, mentioned that people tend to react to new ideas with four words: "That won't work because...". She also mentioned the value of this reaction in a complicated space and that this is one of the things testers are very well practiced on.
So, back to the the subject - A room full of testers, a new idea. Question after question that can be phrased as a "that won't work because..." statement (with one exception of "how can I become a robot-walker?").
What I liked in Liz's view about "that won't work because" is that it is a valuable to say when creating something since it allows people to consider possible setbacks and prepare for them - to lower the risk of probing (Which is, as far as I understood, Cynefin word for "quick experiment"). That this statement is balanced by the dreamers (traditionally, the dreamers are either in the developer or product manager roles, testers are most of the time hired as professional skeptics) that focus more on "imagine how great it would be if it did work", which is why new ideas are tried out and thus have a chance to succeed (you can't succeed in something you didn't do). Since the experience of TWWB was so strong for me in the room, I want to try an exercise in taking the other view and trying my imagination on the success of the delivery-bots presented at the conference.

So, what are the benefits of having a robotic delivery?
  • First is the obvious cost reduction factor, where a robot, over time, costs less money than paying a human, so everything will have the potential of being cheaper as lower costs are embodied in the final price of a product.  
  • Second, the risk of violence against the delivery person will be mostly gone (and violence against the robots isn't a major concern since they can call the police, and each one has 9 cameras that will record perpetrators).
  • Third, a robot could deliver ice-cream without any de-frosting concerns (why wouldn't a robot be also a miniature freezer, or have heating capabilities to keep the pizza warm?)  
  • Next, it will save people the need to interact with a complete stranger just so that they can have some food, or get a package. This will be great for people with social anxiety, but also imagine picking up your pizza delivery without bothering to get dressed - some people will find this appealing. 
  • Taking it a step forward - how will it interact with the world? Currently the robot had not yet mastered stairs, will we see smart buildings opening their elevators for it? Will we see hatches in doors for more than just cats? 
  • What about sending a package to a friend? I can totally imagine a business that will enable people to send small packages to friends - a small gift you made for your friend and want to surprise them with? The lunchbox your child forgot at home? The book you need to return to the library? Now you can get them to them without having to carry it all by yourself out in the rain. 
  • Following your delivery today has probably some legal issues  - is it ok to track a person while they work, especially when they are not working for me? Tracking robots and wouldn't pose the same privacy issue. I could probably track the bot from my phone with no problem. 
  • Oh, and finally, I just can't wait to see how well will the robots function with a 4 year old toddler sitting on top of it (after all, Roombas feature as cat-rides).

I could probably go on and try to create a very bright picture of how this world would look like - but I found out something interesting - as I was compiling this list of cool things, my tester habits took on a different angle, and accepting the delivery bots success as a given, I started imagining all sorts of difficulties such a success might present, it's not exactly TWWB, but rather "this idea might be less than great" -
  • The current robots drive on the pavement, alongside pedestrians, do we want a lot of those boxes rushing along between our legs? How long will it be until separate lanes would be required? 
  • Will there be a new service of "set your robot right after it has fallen (or pushed) on it's side?
  • Who is to blame if a robot gets to a bicycle lane (which, in some places, might be also where pedestrians should walk) and a cyclist falls and gets seriously injured? what about an old pedestrian who fell because of such robot and broke a hip? 
  • Will branded delivery bots be the target of vandals angry at your company? Will we see accusations of attacking the delivery system of the competing business? 
  • With 9 cameras and a human "emergency" operator, will we see a phenomenon of the operators spying on their ex-partners? How common will be instances of accidental spying? And how large will be the operators screenshot collection of people in embarrassing situations?
  • Speaking of spying, will the police have access to the footage if the bot witnessed a crime? Alexa was already a target of such request.
  • Will a fleet of such robots create a significant load on the phone\internet operators? 
  • Such bots are remotely operated - once hacked (and currently, it looks like every other piece of IoT, so it will probably be easy to hack) could it be derailed to the road and used to create Traffic jams and accidents? 
  • Will we see "suicide bots"? Just imagine one bot carrying a bomb in the middle of a crowded street. 
Am I saying that the current suggestion of a robot last mile delivery is a bad idea? Not necessarily (ok, I am saying that a bit, but please recall that the same was said about the telephones, cars and personal computers, and I personally don't get how twitter is a thing, so I wouldn't take my word on what has or hasn't a chance) - I have no idea  which of the possible outcomes will actually come to be (tying back to Liz's Cynefin talk, this is an extremely complex space). What I am saying is that as testers, the tendency to see fail points is useful - but during this exercise I found that seeing blockers in our way isn't all that there is to it. If we are to reduce risk by thinking of the bad stuff that might (or might not) happen, there's also some value to guessing what might happen when we succeed. And it doesn't have to be just around innovative ground shaking ideas, thinking back a few years, we had a feature we thought is great, but a week after it was released more than half of our customers called in furious and demanded that we remove it, this is also a possible outcome. Don't let such thoughts stop you from developing  new stuff, but make sure that you prepare for some of the outcomes you can guess.



-------------------------------------------
הרצאת הסיום של NordicTestingDays ניתנה על ידי קריסטיאן קוריוס מStarship Technologies, והוא סיפר לנו על המוצר שלהם - רובוט לא מאוד גדול שמטרתו להקל על המשימה של שילוח בק"מ האחרון (אין לי מושג ירוק איך לתרגם את last mile shipping, אבל שיהיה). הרעיון הבסיסי הוא די מבריק -  בנייה של רובוט אוטונומי לגמרי שידע להתמודד עם האתגר המורכב הזה היא משימה קשה להחריד. אבל בנייה של רובוט שידע להתמודד עם המקרים הקלים ואת השאר ישאיר למפעיל אנושי - ובכן, זה כבר קצת יותר בר ביצוע (גם אם לא פשוט בכלל). 
אז מה קורה כשמגיעים עם רעיון חדש ומהפכני לכנס בדיקות? מקבלים מבול של שאלות שמצביעות על פערים, בעיות ותוהות האם הרעיון הזה בכלל לגיטימי. למעשה, מעט האנשים שדיברתי איתם אחרי ההרצאה לא נשמעו משוכנעים בכך שזה רעיון טוב. בכל מקרה, זה התחבר לי להרצאה אחרת ששמעתי בEuropean Testing Conference, שם Liz Keogh דיברה על קנבין (מאייתים את זה Cynefin, וזו עוד אחת מהמילים שנכתבות בצורה אחת ונקראות בצורה אחרת לגמרי). ליז הזכירה את הנטייה של אנשים להגיב מהר מאוד ב"זה לא יעבוד כי...", וציינה שבודקי תוכנה מתורגלים מאוד בגישה הזו.
בכל מקרה, בחזרה לנושא המקורי - רעיון חדשני, חדר מלא בבודקי תוכנה, זמן השאלות. כצפוי - מבול של שאלות שאת רובן אפשר היה לנסח כהצהרת "זה לא יעבוד כי..." (עם חריגה אחת בולטת של "איך אפשר להתקבל לתפקיד של מלווי רובוטים).
מה שמצא חן בעיני במיוחד באמירה של ליז על זלי"כ ("זה לא יעבוד כי", ארוך לי לכתוב את זה) זו הגישה לפיה לאמירה הזו יש מקום של כבוד במרחב המורכב (complex) בו צריך לגשש כדי לנסות לראות אם דברים פועלים, כי זו דרך לצמצם את מידת הסיכון אליה נחשפים. האמירה הזו מאוזנת על ידי החולמים (באופן מסורתי, אלו יהיו מנהלי המוצר או מפתחי התוכנה, לבודקים משלמים עבור סקפטיות מקצועית), שמתעלמים כמעט לגמרי מהמכשולים ועסוקים בעיקר בלדמיין "כמה מגניב זה יהיה כשזה יצליח". כיוון שאווירת זלי"כ בחדר הייתה מאוד משמעותית, אני רוצה לתרגל דווקא את הלך המחשבה השני ולנסות לחשוב אילו השפעות חיוביות יהיו לרובו-שליחים.

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

Tuesday, June 27, 2017

I don't find test-cases very useful

Well, Randall Munroe (the XKCD guy) has it right. Someone wrong on the internet is a great motivator. I was flipping through my reading list, when I encountered an article with the oh-so-daring title "You Don’t Have Test Cases, Think Again". Well - The people at PractiTest blog usually write deep thoughtful posts, so there is probably a catch hiding in the post that will lead to an interesting thought trail. Also, reading through my phone, I casually skipped the warning notice at the top of the page and went on reading. As I read through, it became clear to me that I completely disagree with the content there. Hence - this post here.

Probably the easiest thing would be to be the friendly neighborhood bully and pick up on some of the many mistakes there are in the post that indicates that the author either has no understanding of what exploratory tests are, or  he is using a very private and skewed definition of ET (some candidates are the claim that there is no test planning in ET, the axiom "good tests have well defined and agreed upon pass criteria in advance" or my favorite: "[...]some Exploratory gurus assiduously disdain requirements; so they’re very unlikely to get involved with intermediate development deliverables prior to executable code"), but I prefer to avoid public ranting and patronizing people I don't know, so instead, I'd rather say why I don't think in terms of test cases and why I usually avoid this language.

I'll start with the obvious truth - some of what I do can be described in test-cases language. While I'm "testing" (or "exploring", if you prefer this term) I'm doing a lot of checking that can be translated to test-cases language, as can some of my more vague observations (e.g. "this doesn't look comfortable") could sometimes be translated to a test case without stretching it (in fact, once a problem is spotted, defining a test case around it is usually easy). So, yes - if someone insists, I am "executing test-cases" and I'm doing it wrong in as many ways as shorthand writing is doing calligraphy wrong.
And that's, in short, is the reason I try to avoid using the language of "test cases" - It comes with a lot's of baggage. When I say "test case" I'm also saying "heavy predefined documents" and "step-by-step instructions", which is not what I'm trying to convey. When I talk about my testing, I focus on getting my team to agree on what we should test, on what risks do we want to address and I rely on my skills. During my work I will use checklists, I will review any source of information I have (and get those I need) and have my team review both my intentions and my work. Heck, we've recently spent a full week reformatting data into excel sheet just so that we could deal with an unusually large testing problem. And yet - I don't say "test cases".

Another matter I want to address is the odd dichotomy created between "exploratory testing" and writing a test case. When you think about it closely, it is pretty much the same thing. When I spent some time writing down very detailed test cases, I could never do it without actually having the software and performing it at the same time, and I have yet to meet a tester who wrote a test plan without "winging it". Sure, some of us improvise magnificently using all sorts of techniques  - from equivalence partitioning to combinatorial testing to personas and use cases - but all of that charade is simply masking the fact that we apply our experience, skills and gut feelings to choosing the data and the techniques that will be applied (no, I'm not saying those techniques are a sophisticated fraud, they are valuable, very much so sometimes, but the skilled tester will know when to apply each technique or tool and when not to).
I want to ask you to think of the following question: what would be the result of exploratory testing a requirements document?
...
...
...
...
Done thinking? have your answer? Great. Unless, of course, your answer was "exploratory testing must have a working product to act upon", which is simply wrong. But in any other case, great.
My answer is - test plan. When I test a requirements document (for those who use the ISTQB vocabulary, please recall that a review is a form of a static test), I come up with a model of how the software is supposed to function, with questions pointing at gaps in this model, or inconsistencies in the requirements, I compose a list of risks that we might want to put some safeguards against (some of them may be "test this area once it's done and look for that sort of glitches") and I add my knowledge and experience back to the team. I was definitely testing, and since I was learning about the product during this activity, I would say it falls under the definition of "exploratory" part as well (Also, if we avoid quoting anonymous "gurus" and stick with quotes we can trace, I tend to agree with Bach & Bolton's definition, according to which all testing is exploratory).
So, if we accept that writing a test plan is, in fact, an act of exploratory testing, why do we claim that executing the results is any different? And why do we insist on separating test execution from test planning? Sure, there are cases where we might want to plan more beforehand - to make sure we don't forget or to fight off some of the bias that we might have after testing the same thing for a while, but there are other cases where we might not want to do so. Relying on skilled testing allows us that freedom of doing what we think is right for our project. Which leads us back to why I don't like using the term "test case" - it just draws the focus from what's important.


---------------------------------------
מה יש לומר רנדל מונרו (ההוא מXKCD) ידע על מה הוא מדבר. יש מעט מאוד דברים שגורמים למוטיבציה כמו לראות מישהו טועה באינטרנט. הפעם, רפרפתי דרך רשימת הקריאה שלי כשהגעתי לבלוג של פרקטיטסט ושם היה המאמר עם הכותרת ההו-כה-מבריקה "You Don’t Have Test Cases, Think Again". נו, מילא. בדרך כלל אני מוצא שם פוסטים מרתקים, אז אולי יש פה ניסיון לתפוס את תשומת הלב כדי לגרום לי לחשוב. כמובן, כיוון שקראתי דרך הפלאפון, דילגתי בקלילות מעל האזהרה שהייתה כתובה באותיות של קידוש לבנה בראש העמוד והמשכתי לקרוא - מצפה לרעיון מעניין. ובכן, מהר מאוד הבנתי שמעניין זה לא יהיה, כי כל המאמר מבוסס על חוסר הבנה משווע של (הדרך בה אני חושב שצריך להבין) בדיקות חוקרות, ואפילו של בדיקות בכלל. ולכן (ובדחיפה קטנה מצד יואל) - הפוסט הזה. 

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

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

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

אני רוצה להציג את השאלה הבאה: כיצד יראו התוצאות של בדיקות חוקרות של מסמך דרישות?
קחו רגע לחשוב על זה. 
...
...
...
...

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

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

Monday, June 12, 2017

Nordic testing days - closing it all up


So, second day of NTD 2017... The scary part where I get to speak. At least, it was directly after the keynote, so I would have most of my day worry-free. 
Fiona Charles's keynote raised an important matter - As testers we should be responsible for our ethics - both towards the company that hires us, but more importantly, to the public that our product affect, and to ourselves. In a perfect world, everyone would be doing the right thing, so there will be no ethical dilemmas. Sadly, our world is not perfect, and we are asked to lie, or help in covering up information, or take part in a product that we think is morally inappropriate (my personal "no way I'll work there" include gambling sites, porn and most ad-services). In such cases, we have to know when to say "no". "No" to lying. "No" to deception. Also, it is very important to know that there are levels of saying that no. Most of the times, this no should be voiced internally - Letting the product owner know that the tests indicate a very high risk in releasing the software, asking again if we are comfortable with *this* business decision, going over your manager's head to make sure your concerns are not ignored irresponsibly, even resigning when you think the company is acting immorally (but not illegally) . Sometimes, when there's something more serious is on the line, it means that we should notify external entities - turn the external auditor's attention to the flaw that might cause a safety-critical component to malfunction, anonymously tipping the police when acts of fraud are being sanctioned by the CEO,  or even going to the media to reveal how irresponsibly the company is handling their user data despite all warnings and attempts to fix this. 
My main takeaway from this talk is that it's always easy to know what is the right thing for others to do. Especially in retrospect. Knowing the right thing to do yourself, and having the courage to do so - is not always that simple. Let's hope we won't face such dilemmas ourselves. 

Then, after the break, there was my talk. Was I nervous? yes. I think it went well, and some of the questions I got at the end indicated that my message had indeed reached at least some of the audience (my message, in short - threat modeling is very much like testing, so go and do that. 

After that, I could enjoy the rest of the conference worry-free, and went on to listen to some very good talks (such as Carly Dyson's talk on her insights from being a consultant, Melissa Marshall's thoughts about integration tests or Gwen Diagram's talk on logging and monitoring). 

Finally, was the closing keynote. Usually, I really like the keynotes - where you get great speakers with ideas that are inspiring and thought provoking. This one, sadly, was neither. The speaker, Kristjan Korjus, showed us a really interesting product - a robot that is meant to facilitate "last mile delivery" and make delivery a lot less expensive. It is, to borrow the Cynefin terminology, a very complex situation, and thus probably the most interesting situation, when the way forward is by probing fast and learning in retrospect, so I'm assuming that any of the directions there could have made out a great keynote that will give people something to take home except "oh, look, a cute robot". Instead, we got something that looked a lot like a sales pitch, and I'm not even sure who is supposed to buy what. 

Anyway, after the keynote and thanking the amazing conference team for their magnificent work we've moved to a nice bar for the after-party, where we got to say goodbye to those flying soon after the conference ends, and chat a bit more over dinner with those that were staying another night.
Yes, naturally we met a bit more with people at a(nother) pub for some more chats and fun. 

The last day where I could say it was still a bit conference-y was when we met the next morning for breakfast and final goodbyes. I then went with Sven for a day-trip in the countryside (where I took the picture you can see above). A really nice way to take a slow cooldown from a conference. 

So, all in all - it was a great conference. A lot to consider, great experiences and even greater people. If you are making a list of conferences you want to attend, this one should be very high on your list. 

Friday, June 9, 2017

Nordic testing days - day 1

So, the tutorials day is over, and the first day of talks began.
For starters, it was a lot more crowded. With ~500 attendees, it's the largest testing conference I attended, and the atmosphere is absolutely electrifying. A lot of things to learn and experience, and a whole lot of new people to meet.
With so much going on, I could probably babble about the experiences I had for quite a while, but instead I want to pinpoint some of the highlights of the day.
First to be mentioned is Franziska Sauerwein's workshop on refactoring JUnit tests. I'm quite comfortable with Java, so I came with the expectation of learning new coding habits by watching other people's (in this case - Franzi's) way of coding. And indeed, that is mostly what I got. The workshop went pretty well, at least as far as I can determine, and I got out with several pointers on how to improve some of the code I am writing (also, need to check Hamcrest, with which I was not familiar before). A workshop that makes a very clear promise, and then delivers it exactly.
Similarly, Kevin Harris's talk about losing third of the testers and surviving that. When a crisis happens, you must adapt, and Kevin shared with us some of the extreme measures they had to take to cope with this change. Some of them, probably, are better off when done with the luxury of time at hand - and even if they don't, they sure seem like the right thing to do (others, on the other hand, are crisis-only action, so I hope not to ever need them, but I'm stacking them in memory just in case).
The final keynote of the day was given by Alan Richardson, and was all about taking control of the way each of us treats testing. It was not a new message, but it sure was very inspiring and super important for new testers, while remaining not less important reminder to the rest.
And so, the day was concluded.
Or was it?
A conference dinner shortly followed, and then some sort of a party - with disco-lights and drummers. I took the chance to get some 20 minutes of quiet time before returning for the lightning talks and the Powerpoint karaoke - both of were real fun. I especially liked Gwen Diagram's lightning talk which was a very fast-paced,foul-mouthed ode to rapid development named "me and Mr. T".

A long day, and quite a fun one at that. Now, for the final day of the conference, where I'll be presenting my talk.
How did the Romans say? Ave, Imperator, morituri te salutant.