I’ve been in Software Testing and Quality for almost 10 years now, and a disturbing trend I tend to hear every now and then, are individuals on the test team complaining and whining that they are unable to test because there aren’t any written requirements available.  I’ve seen these same individuals refuse to begin any testing effort (not even willing to launch the system) without having the written requirements in front of them, and waiting for somebody to produce these requirements before even launching the system, not realizing the valuable time they’ve just wasted, time that could have been used to test.  Of course, I believe a big part of this approach and expectation could be due to their uninformed belief of what software testing (and their job) really is – but more on that later.

Even before I practiced and got better at approaching situations where I was asked to test and told there were no written requirements, I believed in getting the information I needed in order to test.  In the last few years I’ve began referring to it as “information hunting”.  This information could be anything relevant to the situation at hand, from the manner in which to access the system under test, to who the end users of the system will be.

If I find myself in a situation where there are no written requirements, I am going to go “information hunting” to find out more about the project and testing situation I am in.  If I find myself in a situation where there are written requirements, I’ll be sure to read & analyze them and I will also go “information hunting”.  You see, there is SO MUCH more to software testing than just the requirements. I’ve seen many systems in the past, with tons of written requirements and numerous test cases mapped to each of the requirements, yet when I actually used the system myself and tested it – it was less than positive experience using the system and there were many problems present, despite of all those test cases that had been mapped to each of the requirements and “passed” by whomever was assigned to run the tests.

Now going back to what and how some people on test teams view their role and job – some people just don’t see software testing as anything more than validating the requirements – but that’s not software testing.  Software testing is about providing important information about the quality of the system under test.  One of the many things I’ve learned from Michael Bolton is that you don’t need explicit written requirements in order to launch a system and begin to question it, observe its behavior and learn about it – so that you’re to provide important information about the quality of the system you are testing.  This is such a huge part of Software Testing that I believe is missing on many software test teams – the understanding and appreciation of the skills required to be a valuable software tester, the use of the brain, and actually thinking while interacting with the system under test.

When I go “information hunting” I want to learn and get more information about the current test situation (every test situation is different) that I find myself in.  I carefully put together and analyze all of the information I am able to gather about the testing needs and the system, so that I can create and share my test approach with my managers and project stakeholders – and carry out good testing.

I like to find out the reasoning justifying the cost behind the development effort.  What are the information needs of my stakeholders for this specific test effort at this specific time?  What is the purpose of the system and what are the goals that the system is setting out to accomplish?  Who will be the end users of the system?  How will the users use the system?  Why will they use the system?  What will they use the system for?  When will they use it?   Who are the developers with whom I will be collaborating with and can/will they answer my questions about technical changes and possible impacts to consider in my test approach?  Who can I work with to discuss the risks?  Who can I work with to discuss security and performance expectations?  Which other systems and components will be impacted?  There is more information I may look to seek out depending on the specific situation and circumstances surrounding the system under test (for example test environments, remote team members, third-party involvement).

Using the information I hunt down, I am able to think about the system and how I am going to approach my assignment of testing it.  The answers to my “information hunting” questions have a direct impact of what I test and how.  I am always thinking when I test, while I observe my interactions with the system, and the behaviours I observe within it.

Within the past few years I have also studied and learned different test skills, the use of judgement, oracles, and heuristics and to incorporate them into my testing, in order to help me find and report important quality related information.

I don’t need explicit written requirements to start testing, nor do I heavily rely on them in order to do my job well and to be a valuable contributor to the team.