למה אנחנו בודקים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.