When writing a good software testing strategy, you should provide an answer to the question, “What is Software testing?”. Your definition of software testing will probably be similar to those offered by most of your mainstream resources including ISTQB, Wikipedia or blackboxtest.com which include statements such as: “investigation and evaluation of software product quality”; “executing programs or applications with the aim of detecting bugs”; or “examining software to determine whether or not business requirements have been met”; The list goes on but you can see a common theme which defines software testing as performing a set of actions against software products in order to observe results.
The definition I’ve used for software testing up to now follows the status quo and reads something along the lines of,
“Assessing the quality of a software product based on it’s response to user, system or environmental inputs.”
The definition expressed in basic terms states, the software product receives input A and response B is the result. If B is good, the test passes. If B is bad, the test fails. Too many failed B results after a round of testing indicates that there are quality issues to be addressed by the design and development team. If you end up with enough good B outcomes to satisfy an agreed acceptance criteria, then the project can move forward to the next stage or perhaps the product can go live.
It’s so simple, so straight forward… so boring, so absolutely mundane. Why would you even consider a job as a software tester to end up spending your days entering values into edit boxes and hitting buttons to see what happens? We could train animals to do that. At the very least, a computer program could do that pretty easily, couldn’t it?
After reading the above you may have already started to update your CV and begun packing the contents of your desk pedestal into a crate to make way for your replacement chimp. Now please stop all that. Put everything back where it was, save whatever changes you made to your CV and close MS Word. Have a good think about what you’re really being paid to do. Think about the art, the science and the psychology involved in what you do or should be doing every day.
The truth of the matter is, whenever you create a test case, you are engineering a virtual reality environment, with virtual reality users, and virtual reality events which take place in a virtual reality world. You my friend, are the engineer of this virtual reality world. It is your world, you are the architect. Your goal is to place elements into this world that will eventually be replaced with real users who will do the same things with the software under test as your virtual reality users. The virtual reality events that you simulate during your test cycles will look very much like the real events that will be processed by the software product once it is launched. The replica world you create while you are testing is a microcosm of the real world which the application will occupy once it is released into the wild.
Sure, you’ll invoke inputs to the software being tested, but those inputs, that test environment, those variables you assign are the result of your almighty mind controlling the very essence of time and space within a universe which you build and destroy at will.
So the next time someone asks you what you do for a living, you can just tell them you’re a tester but that’s only part of the story. Tell them that you are a
“Virtual Reality World Engineer”.
Tell them that and tell them you create and dismantle virtual worlds every day. Tell them that you’re a software universe virtual god because my friend, that’s the truthful answer.
Log in using your favourite account and write your comments here