In any software project, the need to take ad-hoc decisions is very common. Even after having meticulously planned a project, there is a good chance that you might come to a crossroads.
The most challenging part would be to decide which road to take. What is my best option? Where will I benefit the most? Shall I take the shorter route or the longer one? Any decision maker must be able to answer all these questions before going ahead and making their decision.
It is very important to identify who is empowered to make these types of decisions. Is it just the team leader or the project manager? Not necessarily. It depends on the nature of the decision. For the most part however, all the team members must feel empowered to take those day to day decisions which although minor, their importance must never be overlooked.
One of the projects I worked on recently was a document management system for a law firm. Now, everyone who has ever touched a document management system knows that it needs to be tailored for its users. As a result, there will often be a lot of correspondence going on between the users and the team.
Unfortunately for us, the users did not always have answers to our questions. There were a number of scenarios which they had never thought of and consequently left all these decisions in our hands.
This looked like a job for a super tester. I put on my superhero costume (which I keep in my bottom desk drawer just in case something that requires superhuman abilities crops up) and got to work.
There I was, carrying out my own research on law firm practices, and trying to figure out what to do with those unthought-of scenarios. At that moment, I realized the responsibility I had towards my fellow team members. They were depending on me, the tester, to decide what they needed to do. They seemed quite comfortable with the idea. I was not.
I managed to put together a good number of test cases that the developers could work on. After having looked at them, no one raised any particular questions or queries. Everyone seemed to have trusted my decisions and my ideas. I felt empowered. I knew that I would be accountable (read – to blame) for anything that goes wrong, but I wasn’t afraid anymore. I had the backing of the team, who knew perfectly well that those decisions had to be taken by someone, and they would have done the same if they were in my shoes.
Through experience, I’ve noticed that a few companies overlook the idea of software testing entirely. That is not to mention the way they treat their software testers, if they have any. Luckily, I’ve found my place in a company where software testing is highly valued not only by management but also by most developers. Hence, whenever I have to make such decisions, my judgment is trusted.
The power to take decisions makes my job easier, and if I’m reliably informed, I’m not scared or hesitant to make decisions, because I know they’re needed for the work to progress.
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.