Think Like a Tester

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: Learn to think like a tester During the process of creating and building software, there is a mentality, a natural way of thinking to prove and protect what you've built to show to yours...)
Line 1: Line 1:
-
Learn to think like a tester
+
It is a natural desire to want 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 well, why would we try to destroy our efforts?
-
During the process of creating and building software, there is a mentality, a natural way of thinking to prove and protect what you've built to show to yourself and later to show to other people that the program you built works.
+
A software tester 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.
-
As a developer, testing during the creation process is more likely to be about verifying that something works as opposed to trying to intentionally break and find flaws. It is necessary to prove what works. This is what is meant by the expression, happy path testing. Testing that follows the expected path of a user; a user who is trying to use the software with no intention of provoking or finding issues. Walking down the happy path should prove the software works. The happy path approach to testing is a worthwhile and necessary part of the building process.
+
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?
-
But once the happy path is proven, it's time to think from a different point of view. Its time to seek flaws. Its time to put on a critical hat and think about how to expose the flaws. What happens when the user doesn't follow the expected path? What happens when a user enters unexpected data? Or the software program is under stress? How does the software handle error conditions? It's time to think critically and to be a bit destructive.
+
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 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.
-
Software testing often asks, what if? Switching from thinking about the positive proof that the code works to a more curious and destructive mentality, takes a mental mind shift.
+
Hhow do you think like a tester if you’re the developer who built the code?
-
When you're not the person who builds something, your point of view is different. The software tester naturally approaches testing a product from a different point of view than the developer, the creator.
+
I'm not sure that I can summarize a mentality that has taken me a couple of decades to cultivate; a mentality that is embedded deeply and naturally now that nearly every object and experience I encounter as part of ordinary life, I think with a curious approach continually asking, what if?
-
What if you're a developer that wants to build solid strong code that doesn't crumble under difficult conditions?
+
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.
-
If you want to find the cracks, breaks and vulnerabilities in your code, you can try to think like a software tester. Let go of your protective instincts about the code and look for the flaws. Realize that when you find the weaknesses in a program, you have an opportunity to strengthen and improve the product. Testing is actually about thinking destructively so that you can constructively improve a product.
+
To embrace a different mentality, begin by trying to suspend or discard these thoughts:
-
Its worth the mind shift. So how do you think like a tester?
+
1. Why would anyone do X?
-
I'm not sure that I can summarize a mentality that has taken me a couple of decades to cultivate; a mentality that is embedded so deeply and naturally now that nearly every object and experience I encounter as part of ordinary life, I think with a curious approach that continually asks, what if?
+
They might, accept this.
-
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.
+
2. But the user isn't supposed to X.
-
To embrace a different mentality, begin by trying to suspend or discard these thoughts:
+
Forget it; users can do what they want.
-
1.Why would anyone do X? They might, accept this.
+
3. But it works on my PC.
-
2.But the user isn't supposed to 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, its not a usable product.
+
-
Use your knowledge to an advantage.
+
That's great, but if it doesn't work on other people's PCs or environments, it’s not a usable product.
-
As the creator, you know what 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. And then like whacking at a pinata 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 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.
 +
 
 +
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 22:48, 13 December 2009

It is a natural desire to want 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 well, why would we try to destroy our efforts?

A software tester 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?

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 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.

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

I'm not sure that I can summarize a mentality that has taken me a couple of decades to cultivate; a mentality that is embedded deeply and naturally now that nearly every object and experience I encounter as part of ordinary life, I think with a curious approach continually asking, what if?

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.

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 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.

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.

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