I started my career in IT as a junior front-end tester. I was ecstatic that I could get paid to “play around” with an application trying to break things and essentially hand over the broken pieces to someone else—saying, “I don’t know, can you fix it?” To be honest, it might be the friendliest introduction to the IT industry, because it’s so forgiving, either you stumble onto a defect (best case) or you think you stumble onto a defect and the application is working as designed (worst case).
I’ve worked on a variety of projects wearing multiple hats as a front-end tester, test lead, business analyst, and requirements lead. After a few years, I started working on larger engagements that staffed full-time testers…but I found myself guarding my testing skillset like a dirty little secret. It wasn’t long until I met other business analysts and developers who likewise took up short-term testing roles between projects. Curiously, they all replied similarly to praise of their natural talents: “Yeah, I’m a great tester…shh, don’t tell anyone.”
Why all the secrecy?
Based on my own experiences and discussions with other analysts, there are three main reasons consultants don’t broadcast their testing abilities.
Fear of being “Stuck” or “Labeled”
As a well-rounded Consultant (in any role), testing should be one of the skills in your bag of tricks. When deadlines are fast approaching and the project is behind schedule (which is more the rule than the exception), it is everyone’s responsibility to pitch-in and ensure quality in a product before it's shipped out the door. For some reason, I’ve found that many are afraid that if they show aptitude in testing, they will be labeled a “Tester” and never get to do anything else. This is not an unwarranted fear in an industry where the testing role is not always regarded with the same respect as project managers or developers. Testing is often a thankless role and it’s up to us to change that fact - take a moment to thank your testers today. It may be true that if you prove to excel in testing, you may be called upon from time-to-time…it’s a highly sought-after role for short-term engagements. If I’ve learned anything from household chores, pretending I’m awful at doing a task I don’t want to get stuck with (stacking and putting away Tupperware containers) doesn’t get me out of that duty, and at the end of the day, it needs to get done.
Testing can be a lonely business
It can be really difficult being a Tester, especially if you are the only one. You write test cases against requirements and if you find a defect, it will likely be a result of a missing/incomplete requirement or incorrectly developed code. While we all strive to be professional and try not to take things personally, it happens. Unless you are on a close-knit team, finding a defect always has the potential to begin a battle between the analysts and developers, where you (the tester) are caught in the middle. I can recall several occasions where an analyst protested that the system requirement was not missing information (“the functionality was implied in the business need”) and the developers still refused to develop functionality that wasn’t explicitly written in the requirements. I (the objective third party) ran the approved failed test case, and in the end, someone was unhappy with me.
Fear of being the last one to touch the ‘Hot Potato’
It’s been said time and again, but most notably by W. Edwards Deming, “Quality is everyone’s responsibility.” Analysts confirm the requirements and developers test their code, but as the gate keeper and the last one responsible for saying “Go” or “No-go,” testers can feel solely responsible for whatever happens next. Until a couple of months of operational use go by, you fear hearing the five words a tester dreads the most, “I thought we tested this!”
What can we do to change this perception?
As an analyst, engage your testers early in your requirements gathering/review process. Bringing testers into the fold once the business requirements begin to solidify will not only help identify gaps and untestable requirements sooner, but will also provide a tester with a better understanding of the business need driving those requirements and thus inform their test cases.
As a project manager, work with your test leads to understand their test planning/execution and communication strategies before finalizing the project schedule. This is especially important in Waterfall projects where the bulk of testing activities occur at the end of the schedule, right before a release, when stress levels are at their highest. This period looks like an obvious area to make up for schedule slippage, but cutting time out of the test schedule can feel a little bit like saying, “I know you are going as fast as you can, but we need you to go faster.” Agile projects are less prone to compressed test schedules since testing is continuous during iterative development, but it is extremely important to ensure open channels of communication between testers and developers to ensure defects are identified and addressed efficiently.
As a developer, try to engage your testers during code review or the unit testing process and try not to take it personally when they “think they found something.” Remember, your testers do not exist to find defects to make you look bad. They are there to identify defects before the end user does (so everyone looks good). Working closely with your testers can foster a partnership and turn “I think you might have an issue…” into “I think we might have an issue…”
As any role, make sure you recognize the value of different skillsets in all project team roles. It’s a common perception that testing is something that “anyone can do,” which is true, but like driving a car, just being able to do it doesn’t mean you are doing it well.
Make your testing abilities known. It’s “all hands on deck” when the deadline is looming and your original week of regression testing has been reduced to two days. As long as you aren’t testing code you developed or requirements you wrote, you can support your stressed-out bleary-eyed tester.