Intro to Software Testing: What is the purpose of testing?

Is the purpose of testing to enforce quality, to find bugs or to automate as many test cases as possible?

If the answer is yes to all three, how can all these be considered testing?

Can software testers be the enforcers of quality?

If this is your cup of tea, then yes, this can be your role. Being the enforcer of standards, recommendations and guidelines can be rewarding when what you're enforcing helps to release better software.

Can software testers make it their mission to find bugs?

Some testers really do enjoy finding things wrong and pointing them out. Bug hunting has a special thrill and no one can deny that getting bugs fixed means better software.

Can software testers be software developers?

Absolutely!

In fact, that's probably where the highest industry demand is at this moment for software testers. Developing that time-saving tool that helps other testers or developers, or developing an automated test suite that frees up testers for other types of testing will likely help release better software.

Is a software tester all of these roles? How can software testers be all of these things?

The common theme connecting all three examples and arguably all software testing is that software testers are meant to provide information to assess risk about the software being tested.

It can be in the form of bug reports, it can be in the form of metrics or it can be in the form of reporting on whether the software allows a user to achieve a particular scenario. Software testing can take so many more forms, but every form it takes must provide a measurement of the risk.

How do the enforcers fit in?

Enforcers of quality may punish those who fail to comply, or they may merely report compliance. In either case, the information being provided is whether a particular recommendation is met and this is information the team can use to make decisions.

What about the bug hunters?

Bug hunters may believe they are assuring the quality of the software under test.

However, the team may choose to postpone the bug, reject it or fix it. The truth is bug hunters aren't really assuring anything.

If a tester finds a bug and it's rejected by the team, was anything assured? No.

Does that mean the bug was a complete waste of time? For me, the answer is again no.

Unless the issue being raised is truly useless, the bug provided information about the software. Information the tester felt was risky enough to ensure the team was aware of it. Despite that the team chose not to pursue the bug, it offered more information about the software than before the bug was reported.

...and the automation specialists?

My current belief is that as long as your automation provides the team with new information to assess risk about the software... you are testing.

More about the value of automation in another post though. 🙂

So, what is the purpose of testing?

To provide information so that the team can assess the risks:  

• Risks to the schedule.
• Risks to the user experience if the the software is released as-is.
• Risks to the company's reputation (just to name three).

Thinking in terms of providing information to assess risks unifies much of what is considered testing and is a good ruler for determining if what you're doing is testing.