Mike Kelly’s blog

Every tester has a credit score. You use it every day. Each time you ask a programmer or analyst a question, when you talk to a project manager about your status, when you write up a defect, or when you deliver some other artifact, you are potentially impacting your credit rating.

This week in our online Rapid Software Testing class the topic came up, and it reminded me to relate a recent experience where I upped my street cred. It’s worth relating because I think it’s an often overlooked aspect of testing. As a tester, many times your effectiveness is relative to your current credit rating. Much like buying a house, even if you have the right information at the right time, you may be overlooked or have to go through a difficult process because of past mistakes or oversights.

In a recent meeting, we had an odd mix of people in the room. We were researching a high profile issue. We had executive management, middle management, project management, architects, technologists, performance testers, key programmers, infrastructure, operational monitoring, and me. I was lucky enough to get called in the night before. This was the status meeting.

At the meeting, several topics were bounced around, many of them works in progress. One of them involved pulling transaction times from a production log. Someone in the room had just pulled down the production log before the meeting. As we discussed the work in front of us, the issue of who would parse the log came up. The super smart Java programmer in the room and I, the tester, were sitting across from each other. We gave each other the “I have it” stare. I threw down the gauntlet and said I would do it.

(I might be exaggerating a bit here, but hey, it’s my blog and this is how I want to remember it! We did look at each other, and I did say I would do it. The tumbleweed and high-pitched whistle may or may not have been there.)

Once I had the task, I popped open SciTE and got to work. Here is where the cool part comes in. Standing behind me was one of the more respected architects within the company. A smart, likeable guy, who everyone respects and looks up to. He was looking at my screen.

During the meeting, while the conversation continued, I coded. I filtered most of the conversation, listening/responding only when I absolutely needed to. When I wasn’t focused on the conversation, I wrote a Ruby script. Because the architect was looking over my shoulder, I refused to spend a lot of time looking up methods online (pride dictated I had to do it without seeking help), so the code was a bit more complicated then it probably needed to be. In about 10 minutes, I had the finished script and ran it.

@sourceFile = ‘C:\\file.log’@

@infile = File.open(sourceFile, “r”)@
@responseTimes = []@
@thread9Begin = 0@
@thread9End = 0@
@thread10Begin = 0@
@thread10End = 0@

@#Log file entries look like this…@
@#12:28:29.494 COL D 10 (java_extensions.cxx:1442): ****** BEGIN@
@#12:28:32.914 COL D 10 (java_extensions.cxx:1442): ****** END@

@#0 - 12:28:29.494@
@#1 - COL@
@#2 - D@
@#3 - 10@
@#4 - (java_extensions.cxx:1442):@
@#5 - ******@
@#6 - BEGIN@

@infile.each { | line |@
@currentLine = line.split(’ ‘)@
@if currentLine[6] == ‘BEGIN’ then@
@if currentLine[3] == ‘9′ then thread9Begin = currentLine[0] end@
@if currentLine[3] == ‘10′ then thread10Begin = currentLine[0] end@
@end@

@if currentLine[6] == ‘END’ then@
@if currentLine[3] == ‘9′ then thread9End = currentLine[0] end@
@if currentLine[3] == ‘10′ then thread10End = currentLine[0] end@
@end@

@if (thread10Begin != 0) and (thread10End != 0) then@
@responseTimes.push(thread10Begin.split(’:')[0] + “, ” +@
@(((thread10End.split(’:')[0].to_i - thread10Begin.split(’:')[0].to_i)*60*60*1000) +@
@((thread10End.split(’:')[1].to_i - thread10Begin.split(’:')[1].to_i)*60*1000) +@
@((thread10End.split(’:')[2].to_i - thread10Begin.split(’:')[2].to_i)*1000) +@
@(thread10End.split(’:')[3].to_i - thread10Begin.split(’:')[3].to_i)).to_s)@
@thread10Begin = 0@
@thread10End = 0@
@end@

@if (thread9Begin != 0) and (thread9End != 0) then@
@responseTimes.push(thread9Begin.split(’:')[0] + “, ” +@
@(((thread9End.split(’:')[0].to_i - thread9Begin.split(’:')[0].to_i)*60*60*1000) +@
@((thread9End.split(’:')[1].to_i - thread9Begin.split(’:')[1].to_i)*60*1000) +@
@((thread9End.split(’:')[2].to_i - thread9Begin.split(’:')[2].to_i)*1000) +@
@(thread9End.split(’:')[3].to_i - thread9Begin.split(’:')[3].to_i)).to_s)@
@thread9Begin = 0@
@thread9End = 0@
@end@
@} #infile.each@

@infile.close@

@puts responseTimes@

The best part, it worked the first time I ran it. I copied the results over to Excel, turned my laptop, and presented my results. The meeting wasn’t even over and we could talk about the actual data. I got a small verbal pat on the back by the person asking for the information, and we moved on.

Fast forward a day or two…

At another meeting, on a completely unrelated topic, with a room full of different people (except for the architect), we were talking about implementing a new process for an automation issue. As part of that issue, we would need to write some Ruby code to populate some data via a web service.

At one point, I volunteered to write the code to populate the data. That drew some looks from the programmers in the room (I’m just a tester you know). It was at this point that the architect stopped the meeting for a minute to relate what he saw me do in the meeting, writing the code in a hostile environment and it working the first time.

That’s the best feeling in the world. Someone else, not even a close friend, stopping a meeting to give you a vote of confidence. And because he has high street cred in the programmer community, I now have higher street cred in that community. It’s was more influential then if I had found ten super obscure technical bugs. Probably more influential then if the developers had actually seen me write the simple script (I included it so you could see how simple it is - and I’m sure it could be simpler).

So what’s your street cred? How do you build it? How do you cash it in?

On a recent project where we were implementing a service oriented architecture (for the first time on a large scale) we wanted to leverage the design of the system to test early. The plan was to have testers run local servers, get the latest complete code (after developers were done and everything was unit tested), and run component level tests based on risks identified by the test team. We would use automation and manual testing to flush out edge conditions, mapping errors, and un-captured exceptions.

On schedule, several of the developers indicated their code was complete at a status meeting. I configured my local server to run the code and began my testing. Surprisingly (or perhaps not) this caused some problems. Developers were quick to come over and say things like:

• “You can’t test in a development environment!”
• “We’re not done with that functionality (even though we said we were).”
• “I’m still unit testing, the code won’t work until I’m done unit testing.”
• “We are working over 30 tickets, things can break at any time.”

This was taken by some people on the project as a reason to stop our test-often test-early strategy. I would think each of these indicate a reason why you would want someone testing in the development environment. Let’s address these one at a time:

“You can’t test in a development environment!”

Actually I can. It’s really easy. I just update the code, compile, and start a server. We have the technology. Is there some reason I shouldn’t test in development? Isn’t the whole idea to find issues earlier when they are supposedly easier and cheaper to fix?

Ok, that’s my smart ass inner voice. That’s not what I really said (but I really wanted to). I think I really said something like:

“I understand this is something we are doing for the first time on this release. Changes like this are painful as the team learns to deal with new ways of working. We need to test in development if we want to have any chance of hitting our release date. If we wait until all the development is done, we will need to do two months worth of testing in three weeks. We just can’t do that.

Can you help me make this easier on you? What can I do to lower the visibility this adds to your work and the pressure that added visibility results in? How can I provide feedback to you in a way that doesn’t cause problems for you?

Once the developers (or most of them) accepted we were going to do this testing, they started to warm up to it. After the first couple of weeks (very emotional weeks) we actually hit a groove. By the end of the release, we had very close relationships with many of the developers.

“We’re not done with that functionality (even though we said we were).”

Our testing exposed a misunderstanding about project progress. What management thought the status was and what the actual status was did not match. We were told it was done, but it was not. This enabled management to correct their misunderstanding of project status so they could plan and react accordingly. This - aside from all the testing related issues identified - is valuable information. People hold meetings and purchase expensive tools to find out what we found out in 5 minutes of testing and asking questions.

Code does not lie. It works or it doesn’t.

“I’m still unit testing, the code won’t work until I’m done unit testing.”

This is closely related to the above point. Up to this point, developers were in the habit of telling management they were done when they were done coding, not done unit testing. This caused a perception problem. I also have a suspicion that this was a sneaky way of asking for more time in a politically correct way. Who’s going to say you can’t do more unit testing?

Some of them were reporting they were still unit testing when they were still writing code. They looked farther along then they were. On the other hand, the developers who really were unit testing when we started our functional testing welcomed our scrutiny. “Find a bug if you can!”, they said. Sometimes we did.

“We are working over 30 tickets, things can break at any time.”

This is the, we break the build on a regular basis argument. That’s a fine argument, except that like most teams, we’re not suppose to break the build. Ever.

This statement means that developers regularly checkout code, make changes, then check it back in, and then test. This was a “deeper” problem. The developers should have been testing the code before they checked it back in. Some were not. There was an automatic expectation of failure on any code that was checked in, not an expectation of it working. Note, this expectation was the expectation of the development team.

This problem solved itself as we started reporting those defects (normally the same day). The added visibility provided by our defects for these types of issues tipped us into a more positive workflow of testing before integration.

All said and done, we worked side by side with the development team for a little over two months. When our testing stopped, the traditional functional and system level testing began. We had automated hundreds of tests at the component level. We had validated many of the mapping documents. We had become active participants in design meetings (not all of them, but enough that we felt like we had a small victory). And by the end of our testing, we had developers (again not all of them) coming over to us and asking us to review their work. After the initial growing pains of the added visibility to the status of the code, most of the emotions died down, and we were able to release some great software.

This morning, while working on an article for data-driven testing with IBM Rational Functional Tester, I found a bug with the Google Web Search feature: Book Search.

The Book Search feature works like this, you enter the search text books about /something/ and the first Google result returned should be Book results for books about /something/.

In my article, I wanted to show an example of converting a record and playback script into a data-driven script. After recording a script that executed several of the Google Web Search features, I played it back to make sure it worked. It failed the first time I ran it. I then proceeded to test the feature by hand, clicking search repeatedly with the same search text in the box (my search text was books about software testing). It failed roughly fifty percent of the time.

My guess is the problem is a deployment problem, not a code problem. I’m guessing Google has a lot of servers running search and a couple of them just don’t have the right code or the feature enabled. I don’t know. Either way, this seems like something easy to catch. I found this with the lowest form of automated testing life - a record and playback script. I found it the first time I ran the script. I found it with only one value to test the feature. The total cost for me to create and run the test was about 15 minutes (for more then one feature). If I had been using an open source tool like Watir I might have found it even faster, without the additional cost of the enterprise tool.

Why didn’t Google catch this? Even if it is a deployment problem, it’s not like they can’t test this feature once they’ve deployed. A test like this doesn’t change any data in the system.

While at a movie theater over the weekend, I noticed a couple of new self-service ticket machines. They look and function similar to ATMs: select your movie, slide your credit card, and print your tickets. Simple enough.

Inspired by James Bach, while I was waiting for a friend to show up I took a couple of minutes and tried to see what bugs I could find in the system. I’m sad to say I did not find much. I found only three problems that I would qualify as defects, and two issues that I would want to get clarification on before I wrote them up as defects.

Defect 1: The system would allow you to select up to ten tickets for each type of ticket you could purchase (adult, child, senior). While testing the limits of ticket selection and the proper calculation of the total amount, I noticed that if you max out the number of tickets for senior and child priced tickets, the system beeps at you each time you try to select more then ten tickets. However, when trying to select more then ten tickets priced for adults, there is no beep. This is a small issue, hardly worth the time it took to find it, but it should still probably be fixed.

Defects 2 and 3: I like these a lot. After I was done playing around with the system I had a chance to do some usability testing by watching people interact with the system. I noticed one case in particular that showed serious defects. A lady using the system selected her movie, entered her debit card information, and started waiting as the screen displayed “Please wait while processing your transaction.” At this point the system was attempting to connect to whatever service it uses to process credit cards. As luck would have it, at that moment credit card processing for the theater went down. I know this due to the very vocal population of customers at the ticket counter. Unfortunately for the lady making her self-service purchase, the ticket machine seemed to have hung as well. It just sat there saying “Please wait while processing your transaction.” No message saying “Timed out while connecting to service. Please try again.” No message saying, “Trying your transaction again, please wait.” Nothing. It just sat there.

After about five minutes, the lady finally lost her patience and started pushing the cancel button. She pushed it once. She pushed it a second time - harder. She then pushed it five times in rapid succession. She then put all of her weight into the pushing of the button and kept the button down for several seconds. This processed continued for some time. I counted her push the button over 40 times. Still the screen read, “Please wait while processing your transaction.” So much for cancel… She then left the machine and went to the ticket counter for help.

The first defect is around error messaging in general. No indication was given to the user that a problem was encountered. Other observations gave me the impression that performance was acceptable to users under normal operating conditions. And after the ticket counter informed everyone that credit card readers were working again, I did not notice anyone else have performance problems with the ticket machine. My conclusion is that the machine encountered an error, but did not let the user know.

The second defect is that no indication was given to the user that her request to cancel had been received. Had the system simply said “Canceling request. Please wait while disconnecting from bank service.” I think the user would have been satisfied that the system was still working, and would have waited for her transaction to cancel. Because she was not informed that the request had been received, she continued to pound on the keyboard. Note that her ticket purchase was canceled when the credit card service was restored. This was confirmed at the ticket counter.

Issue 1: The system was set up to limit ticket purchases to only movie times that were in the future. That is, if I wanted to watch a movie that started ten minutes ago (because I don’t want to watch the thirty minutes of previews) I could not use the ticket machine. I would have to go to the counter. However, if I started my transaction before the movie time, and the movie start time elapsed while I was processing the transaction, I was allowed to continue.

Like I said, I don’t think this is a bug, I would just want to check to ensure that this is in fact the behavior that was intended. I think I would want to know more about the conditions for the removal of a movie time from the list, and then go back and do more testing.

Issue 2: The system allowed me to purchase a child ticket for an R rated movie. You need to be either 18 or accompanied by an adult to see an R rated movie and I had not purchased an adult ticket. Again, I can think of scenarios where this would not be a problem: adult buys ticket in advance, when adult and child come to theater adult then buys child’s ticket, etc…, but I would probably ask questions on this as well.

At PNSQC this week I attended Johanna Rothman’s workshop titled Interviewing with Ease (based on her new book Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People.) During the workshop, a group of gentlemen from Envision mentioned a technique that they sometimes used during an interview to assess an interviewees testing abilities. Their technique? They ask the interviewee to test a stapler.

I found this to be quite an interesting challenge. How would you test a stapler? It’s simple and easy to understand (no industry specific knowledge required). There is no underlying technology you need to know. Heck, odds are you’re even an expert user!

Well I thought I would take a whack at it. The following is my attempt to test a stapler. If you actually have the patience to read all of the tests I thought of, then please comment on tests that I missed (I’m curious to see how complete my list is). If you don’t read all of them, that’s fine too. But scroll to the end and read the last couple of paragraphs after the list where I talk about the significance of this exercise.

I chose to test the Stanley Bostitch B660-Black Anti-Jam Desktop Stapler. Following the exploratory process, I thought I would take a minute and learn about the company whose stapler I’m testing and a little bit about staplers in general.

Based on that information, and that information alone, I came up with the following tests:

Requirements based testing:
Dimensions:
1. Is the stapler 1 inch and/or 43.18 mm tall?
2. Is the stapler 2 inches and/or 61.72 mm long?
3. Is the stapler 6 inches and/or 176.28 mm wide?
4. Does the stapler weigh .5 lbs and/or 0.23 kilos?
5. When packaged, are the packages dimensions 1.73″ x 6.79″ x 2.45″?

Color:
6. Is the stapler black?
7. Is it ok for the anvil and the staple magazine to be silver?
8. Is it ok for the company logo on the front to be white? (After all, the logo on the top is in black…)

Features:
9. Does the stapler open 180 degrees for tacking?
10. Does the anvil have a clincher for curling staples in?
11. Does the anvil have a clincher for curling staples out?
12. Can I change the anvil settings (most likely by rotating the anvil)?
13. Can I see the staple supply indicator?
14. If the stapler is full, does the stapler indicator show staples?
15. If the stapler is empty, does it not show staples?

A quick glance at the stapler tells me that I can see seven staples in the indicator, and that the indicator does not show the first staple in the stapler. Based on this I can ask the following questions:
16. Is it ok at the staple indicator reads empty with fewer than five staples?
17. How many staples should the staple indicator show?
18. Should there be a staple indicator on both sides of the stapler (there are currently, is this redundant)?

19. Does the stapler hold 210 standard staples?
20. Does the stapler hold 211 standard staples?
21. What are the defined dimensions of a standard stapler? (I tried to find this but I had a problem. I can find the staple “leg” size, but not the standard length and width.)
22. What is Anti-Jam technology? (I looked but could not find anything specific.)
23. What is an acceptable jam rate to be called Anti-Jam? (For example: is it one jam per 100,000 staples?)
24. What factors affect the Anti-Jam technology?

Warranty:
25. What constitutes normal wear (for the stapler as a whole)?
26. How did we gather the normal wear statistics (for the stapler as a whole)?
27. Based on normal wear statistics (for the stapler as a whole), set up a test lab and a mechanized staple apparatus (a test harness if you will) to push multiple staplers to test the affects of our normal wear requirements. What do our normal wear performance results look like (for the stapler as a whole)?
28. What do we define as neglect?
29. Where did we get our definition of neglect?
30. What tests can we run to test neglect? (For example: If we define neglect as leaving your stapler in a bathtub full of water (do not ask how it got there!) for three weeks and then returning it because it rusts, should we test for the effects of rust on our product?) (I see many tests relating to neglect, but I need to know more about what we mean by neglect.)
31. What do we define as abuse?
32. Where did we get our definition of abuse?
33. What tests can we run to test abuse? (I see many tests relating to abuse, but I need to know more about what we mean by abuse.)
34. What do we define as an accident?
35. Where did we get our definition of an accident?
36. What tests can we run to test accidents? (I see many tests relating to accidents, but I need to know more about what we mean by accident.)
37. What is the normal wear on a driver blade? How long should one last?
38. Based on normal wear statistics, set up a test lab and a mechanized staple apparatus (a test harness if you will) to push multiple staplers to test the affects of our normal wear on driver blades. What do our normal wear performance results look like?
39. What is the normal wear on a bumper? How long should one last?
40. Based on normal wear statistics, set up a test lab and a mechanized staple apparatus (a test harness if you will) to push multiple staplers to test the affects of our normal wear on bumpers. What do our normal wear performance results look like?
41. What is the normal wear on an o-ring? How long should one last?
42. Based on normal wear statistics, set up a test lab and a mechanized staple apparatus (a test harness if you will) to push multiple staplers to test the affects of our normal wear on o-rings. What do our normal wear performance results look like?

Packaging:
43. Is there a copy of the requirements in the packaging?
44. Is there a copy of the warranty in the packaging?
45. Is the product clearly identified on the packaging?
46. Are the packages dimensions 1.73″ x 6.79″ x 2.45″?
47. Is the packaging easy to open for our standard consumer?
48. Is our packaging harmful to the environment?
49. Does our packaging contain any claims we did not test against?
50. Does the packaging/website/catalog show similar information?
51. Is the packaging and warranty printed in the same language as the stapler is sold?

Parallel testing:
52. How well does this stapler compare to other staplers we make?
53. How well does this stapler compare to our competitors stapler?
54. How do our performance stats (see below) correspond to our competitors?

Scenario testing:
55. Use the stapler in a typical corporate office day for your average knowledge worker.
56. Use the stapler in a typical office day for a secretary.
57. Use the stapler in a typical day for a teacher.
58. Use the stapler in a typical day for a student.
59. Use the stapler in a typical day for a waiter.
60. Use the stapler in a typical day for a checkout clerk.
61. Use the stapler in a typical day for shipping yard attendant.
62. Use the stapler in a typical day for an event promoter.
63. Use the stapler in a typical day for a construction foreman.
64. Use the stapler in a typical day for an editor.
65. Use the stapler in a typical day for a writer.

Usability testing:
66. Is the design self-consistent?
67. Is the feature set the minimum necessary to meet the stated requirements?
68. Is this product similar to competitor’s products with the same or similar requirements?
69. Do we have customer complaints on this or similar products that we can use as tests?
70. Do we have customers who can beta test this product for us?
71. If the standards for a “standard” staple change, how hard will it be to retrofit our staplers?
72. How long does it take a user to re-load the stapler?
73. How long does it take a user to figure out how to tack the stapler?
74. How long does it take a user to figure out how to use the stapler?
75. Does our stapler contain text telling us what type of staples it takes?
76. Does our stapler contain text telling us what make and model number it is?
77. Did the users want an automatic stapler?
78. Is this the most attractive color of black? Should it be flat instead of gloss?
79. Is the font on the packaging the right type and size?
80. If our stapler comes back to us with a defect, how hard will it be to fix and ship back to the customer?
81. Who are our users? What are they looking for in a stapler?
82. In what environment will they be using our stapler?

Function testing:
83. Is this an appropriate implementation of stapler technology?
84. Does it have a base?
85. Does it have a body?
86. Does it have a rear pivot?
87. Does it have a pivot spring?
88. Does it have the ability to engage a tacking function?
89. Does it have a staple magazine?
90. Does it have a staple pusher?
91. Does it have a magazine tension spring?
92. Does it have a ramhead?
93. Does it have a drive blade?
94. Does it have a staple exit?
95. Does it have an anvil?
96. How loud is the sound of the stapler stapling? Is this acceptable?
97. What happens if I staple materials other then paper?
98. What happens if I staple nothing at all?

Fault Injection:
99. If I remove the rubber sheet from the base, will the stapler still work?
100. If I remove the rubber sheet from the base, will the stapler slip off my desk while I apply pressure to staple something?
101. If I remove the spring that rotates the anvil, can I still rotate the anvil?
102. If I remove the spring that rotates the anvil, will the anvil remain on the desired setting?
103. If I remove the spring that rotates the anvil, will the stapler still staple correctly?
104. If I flatten one of the small metal tabs that keep the stapler from tacking, is the other tab sufficient to keep the stapler from tacking?
105. If I remove both of the small metal tabs that keep the stapler from tacking, does the stapler still staple correctly?
106. If I remove the spring attached to the staple pusher, can I still staple?
107. If I remove the staple pusher head, can I still staple?
108. If I remove the drive blade, can I still staple?
109. If I remove the anvil, can I still staple?
110. If I remove the body, can I still staple?
111. If I remove the o-rings, can I still staple?
112. What happens if I clog the staple exit? How big of an obstruction does it need to be to stop the stapler from working?
113. If a staple is jammed, how easy is it to remove the staple?
114. If I remove the spring below the staple magazine, can I still tack?
115. If I remove the spring below the staple magazine, can I still staple?
116. If I remove the spring above the staple magazine, can I still staple?
117. If I bend the staple magazine, can I still staple?
118. What if I use a staple other then a standard staple?
119. What if I staple something other then a paper-based product (plastic, wood, etc…)?

Stress testing:
120. At what temperature does the plastic melt? Is that acceptable?
121. At what cold temperature does the stapler cease to function (springs, rear pivot, etc…)? Is that acceptable?
122. How many pounds of pressure, while using the stapler in the recommended way, does it take to break the materials of the stapler? Is that acceptable?
123. What different types of staples will work in the stapler?
124. Does the stapler work under water?
125. Does the stapler work in the desert or on the beach (effect of sand on moving parts)?
126. Does the stapler conduct heat (what if I leave it on the stove and then try to move it)?
127. Does the stapler conduct electricity?
128. How impact resistant is the stapler?
129. If I drop it from my desk what happens?
130. What if I drop it from the second story?

I bet you never thought of that as impact analysis!

Performance testing:
131. How long does it take a user to switch to tacking mode?
132. How long does it take a user to switch to standard mode?
133. How many staples can be stapled in the stapler’s use-full life?
134. How many times can the anvil be rotated before there is a noticeable degradation in the anvil spring?
135. How long does it take to successfully complete a single staple in tacking mode?
136. How long does it take to successfully complete a single staple in standard mode?
137. How many times can the stapler be switched between standard and tacking mode before there is a noticeable loss of “grip” on the tacking limiting tabs?
138. How many times can the stapler be reloaded with staples before there is a noticeable loss of functionality on the staple pusher spring?
139. How many staples can a drive blade drive before there is a noticeable affect of stapler performance (loss of ability to drive staples, clogs, etc…)?
140. In tacking mode, how far does a staple travel if shot in the air? (I don’t know if this is a requirement, but I want to know if I desire to sell this to college students for staple fights.)
141. How many pieces of “standard” paper can be stapled before there is a noticeable effect on performance?

Regulations:
142. Is there some governing body that must approve the safety of our product?
143. Do we require any documentation for them as proof?
144. Does our stapler tell us what country it was manufactured in?

And that’s all I came up with in the hour I had allotted myself (I was assuming I had an hour in the interview).

What I hope to illustrate by all this is the following. This is a simple stapler. I came up with 144 tests in about an hour. I’ll grant that some of the tests are impractical, and some are probably not worded the best or need more information, but it’s still 144 tests. Your average piece of software is infinitely more complex then a stapler. And odds are your software interacts with more then one user at a time, relies on more then one input, has more then two states (maybe four if you’re picky), has more then a handful of features, and runs in an operating environment with things happening then your top desk drawer.

As testers, we are faced with an impossible task. We can’t possibly test everything, even if we knew what everything was we needed to test. Our job is one of discovery. That we can look at a stapler and ask how it could be better, look at an online shopping cart and ask how it could be more secure, or how a life-support system can be more reliable, is a wonderful thing! Someone pays you to break stuff, give developers a headache, and if you’re the bottleneck for your project - you get all the attention! Why doesn’t everyone want to be a tester?

Either way, today I asked the question “how far does a staple travel, if shot in the air?” And that makes today a good day for me.