Think Like a Tester

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 5: Line 5:
A software tester, however, has no sense of protection. A software tester functions more like a reporter; we are objective seekers of the current state. We have no attachment to a program working well or working poorly. It is what we find; we are observers.
A software tester, however, has no sense of protection. A software tester functions more like a reporter; we are objective seekers of the current state. We have no attachment to a program working well or working poorly. It is what we find; we are observers.
-
Software testing often asks, what if? Switching from thinking about the positive proof that the code works to a more curious and destructive mentality: what if I try this?
+
Software testing often asks the question "what if?" Switching from thinking about the positive proof that the code works to a more curious and destructive mentality: what if I try this?
If you want to find the cracks, breaks and vulnerabilities in your code, try to think like a software tester. Let go of your protective instincts. Realize that when you find the weaknesses in a program, you have an opportunity to strengthen and improve the product. Testing is about thinking destructively so that you can construct a better product.
If you want to find the cracks, breaks and vulnerabilities in your code, try to think like a software tester. Let go of your protective instincts. Realize that when you find the weaknesses in a program, you have an opportunity to strengthen and improve the product. Testing is about thinking destructively so that you can construct a better product.
Line 13: Line 13:
Once you begin detaching from your protective instincts and begin thinking about all the “what if” activities you can try with your software, you’re thinking more like a tester. A tester’s mentality takes time to cultivate. A tester’s mentality is not a negative mindset as much as it is a curious and creative mentality that wants to explore and find possible issues.
Once you begin detaching from your protective instincts and begin thinking about all the “what if” activities you can try with your software, you’re thinking more like a tester. A tester’s mentality takes time to cultivate. A tester’s mentality is not a negative mindset as much as it is a curious and creative mentality that wants to explore and find possible issues.
-
It might be best to attempt to disconnect from the feelings of ownership and begin by thinking like a consumer of what you've built. Realize that users don't necessarily know what they're supposed to do and so they naturally make "mistakes," enter unexpected data, exposing software defects in their wake.
+
It might be best to attempt to disconnect from the feelings of ownership and begin by thinking like a consumer of what you've built. Realize that users don't necessarily know what they're supposed to do and so they naturally make "mistakes", such as entering unexpected data, thus exposing software defects in their wake.
To embrace a different mentality, begin by trying to suspend or discard these thoughts:
To embrace a different mentality, begin by trying to suspend or discard these thoughts:
Line 26: Line 26:
That's great, but if it doesn't work on other people's PCs or environments, it’s not a usable product.
That's great, but if it doesn't work on other people's PCs or environments, it’s not a usable product.
-
Use your knowledge to an advantage. As the creator, you know what and where error conditions and messages have been built. Challenge those areas. Software defects often lurk at the boundaries, poke at the boundaries. Then push on the boundaries.
+
4. If they do that, it's their problem.
 +
No, it's the organization's problem, so it's your problem too.
-
Break past the desire to protect. Be willing to unravel and even destroy. And then like whacking at a piñata with a stick begin to delight in seeing the product unravel. Yes, you've destroyed what you built but now, you can build it even better.  
+
Use your knowledge to an advantage. As the creator, you know where error conditions are being handled. Challenge those areas. Software defects often lurk at the boundaries, poke at the boundaries. Then push on the boundaries.
 +
 
 +
Break past the desire to protect. Be willing to unravel and even destroy. And then, like whacking at a piñata with a stick, begin to delight in seeing the product unravel. Yes, you've destroyed what you built but now, you can build it even better.  

Revision as of 16:56, 22 January 2010

It is a natural desire to protect and defend what we build. If we don’t love our own work, who will?

A developer’s mentality is to create and protect. If we build code that functions well, why would we try to destroy our efforts?

A software tester, however, has no sense of protection. A software tester functions more like a reporter; we are objective seekers of the current state. We have no attachment to a program working well or working poorly. It is what we find; we are observers.

Software testing often asks the question "what if?" Switching from thinking about the positive proof that the code works to a more curious and destructive mentality: what if I try this?

If you want to find the cracks, breaks and vulnerabilities in your code, try to think like a software tester. Let go of your protective instincts. Realize that when you find the weaknesses in a program, you have an opportunity to strengthen and improve the product. Testing is about thinking destructively so that you can construct a better product.

How do you think like a tester if you’re the developer who built the code?

Once you begin detaching from your protective instincts and begin thinking about all the “what if” activities you can try with your software, you’re thinking more like a tester. A tester’s mentality takes time to cultivate. A tester’s mentality is not a negative mindset as much as it is a curious and creative mentality that wants to explore and find possible issues.

It might be best to attempt to disconnect from the feelings of ownership and begin by thinking like a consumer of what you've built. Realize that users don't necessarily know what they're supposed to do and so they naturally make "mistakes", such as entering unexpected data, thus exposing software defects in their wake.

To embrace a different mentality, begin by trying to suspend or discard these thoughts:

1. Why would anyone do X? They might, accept this.

2. But the user isn't supposed to do X. Forget it; users can do what they want.

3. But it works on my PC. That's great, but if it doesn't work on other people's PCs or environments, it’s not a usable product.

4. If they do that, it's their problem. No, it's the organization's problem, so it's your problem too.

Use your knowledge to an advantage. As the creator, you know where error conditions are being handled. Challenge those areas. Software defects often lurk at the boundaries, poke at the boundaries. Then push on the boundaries.

Break past the desire to protect. Be willing to unravel and even destroy. And then, like whacking at a piñata with a stick, begin to delight in seeing the product unravel. Yes, you've destroyed what you built but now, you can build it even better.  

Personal tools