There’s been talk at work for the last couple of weeks now about an imminent contractor cull. These words came to fruition last week as it was relayed to me variously by other contractors and finally by the project manager for the product under test that all bar three of the current contractor workforce would be finishing at the end of the month. I was one of the three.
By the middle of this week, two of the three were let go also. I was now in the enviable, yet somewhat tenuous position of being the only contractor out of 12 [9 developers & 3 testers] to have retained my role (albeit with revised responsibilities). To what (other than being mightily blessed!) can I attribute this good fortune? Clearly developers are surplus to requirements at the moment, but what about testers?
I certainly don’t claim to be any better or more qualified than any of the other testers I work(ed) with, but here are some things that I think may have worked in my favour:
- The development team are my friends! I try my utmost to maintain a close working relationship with individual developers and the development team as a whole. This isn’t always easy or even possible, but it’s something I try to do nonetheless. I come in for a goodish amount of heckling from the developers, being seen as the guy whose job it is to “Hulk-SMASH!” their code when it’s delivered to me. But like most good development teams, they appreciate the feedback and insight I can provide in respect of their work, and they particularly appreciate it when I ask them for input into what they think needs to be tested.
- Clear and consistent reporting of test metrics. There are some who question the value of test metrics, and I understand their arguments. Rex Black is very much in favour of providing clear metrics, and although I may not agree with all of the specifics of his approach, from a consulting perspective I’d certainly concur with his assertion that management want to know what’s happening and appreciate it when you make their lives a little easier by providing them with timely, concise and relevant information.
- Engage third party suppliers. I think project delivery can sometimes be frustrated by test analysts that are afraid to go above and beyond the role of testing code, and challenge assumptions or mistakes that have been made in respect of requirements and design. Going down this route can open you up to some criticism and I’ve certainly been accused of “making up requirements” by developers on occasion, but even if/when you’re wrong – I think this can help you on several fronts:
- Becoming a subject matter expert on the product under test – challenging the requirements or design means you need to know what you’re talking about;
- Building a relationship with the supplier means they’ll be more likely to communicate information that you may otherwise have remained unaware of;
- Builds your reputation and standing within the team – see .
- Build a good reputation. This is closely related to the previous three points, and ultimately comes down to being trusted to fulfil your responsibilities by doing everything within your ability and ideally going above and beyond the call of duty when necessary. Of course, being seen to be going above and beyond doesn’t hurt on occasion either!
Like I said above, I don’t claim to be an expert by any means I and the above points are simply my reflections on some of the attributes that I believe project teams want testers to display. Being involved in some external activities that contribute to the software development community can’t hurt either. Organising a local tester meetup for example… 😉- Simon
P.S If you're interested in learning more about performance testing, checkout my Performance Testing 101 course here.