The blackest of my requirements documentation nightmares

Every software project starts with some form of requirements or specifications document. The contents of such a document are agreed upon during workshops with clients and stakeholders and in which details, use case scenarios and technicalities are hammered out and discussed thoroughly. This is the meat and potatoes of the software in question and it describes how it will work in practice. Or at least, should work.

The unpleasant role of the software tester is to swallow the contents of this document in whole and start the biblical task of writing test cases and scenarios.

From personal experience, I’ve realized that often, said document might have been written or compiled without the consultation of people who truly know what they need, and therefore what it is they’re doing. Consequently, it is quite common that a lot of ‘what ifs?’ and ‘why nots?’ are raised after going through all the specifications. Numerous e-mails are sent out to different people and everyone starts throwing in their version of what they think the solution might be. You end up with countless different answers scattered all over the place.

Pretty soon, the situation descends to one in which you’re pulling teeth for pleasure, all while trying to bring the requirements or specifications document all together somehow.

I’ve had my share of teeth-pulling. To make it worse, in the case I’m describing, I was not even part of the project when it started. This made my job a lot like being thrown into a battlefield with no weapon and then being told to search for the pieces that make up a rifle among the dead bodies and debris. Only then, after finding and assembling all the pieces together, are you prepared to fight.

Apparently in this case, a whole month from the start of the project, a finite list of requirements did not exist, which is rather strange for a supposed Agile project. Of course, no requirements meant that not a single test case had been written either. I gritted my teeth and got stuck in.

When I joined the project, all I had to work with was a bunch of emails which I had to make sense of, various short documents, Excel sheets and some knowledge that resided in someone else’s head. That was all. Concerned about time, costs and all that jazz, the project manager was already pressuring me to start testing, but before I had any test cases, I obviously couldn’t.

So as it turned out, straying away from my obligations, I had to compile the requirements document myself. Obviously, this is no easy task when you also have to look for clues and evidence like a desperate Sherlock Holmes, and of course, exploratory testing would have been a better idea, but needs must, and you try telling the project manager you need a week for exploratory testing when they’re pressing for project delivery like, yesterday.

As expected, this task took an incongruous amount of time. At least I did manage to pull it off and now I had the full list of requirements consolidated in one single document. Luckily, the system was not a very large or highly complex one. If that were the case, I’d still be writing requirements now.

Surprisingly, this also helped me to better understand the scope of the project and I was now fully armed and ready to start writing my test cases. Crisis averted. Whoop whoop!

I know now, however, that in future what might help to avoid such mishaps is having a central repository where all requirements reside in an organized manner. This can be very beneficial not only for software testers, but for developers, designers and project managers alike.

So yeah, if only my team used something like ReQtest back then, I’d have been done in an afternoon or so.

Want to avoid Johnny’s blackest requirements documentation nightmare? Read all about requirements here – 

7 Requirements you should never overlook – https://reqtest.com/blog/newsletters/7-requirements-you-should-never-overlook/

How user stories can help you write clear and testable requirements
– https://reqtest.com/blog/how-user-stories-can-help-you-write-clear-and-testable-requirements/

Requirements Management in Agile Projects – https://reqtest.com/blog/requirements-management-in-agile-projects/

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.