Advice to New and Experienced Testers
As part of an interview for the Empirix QAZone website, I was asked a series of questions. Here's one of them and my answer.
"What are some of the recommendations that you have for folks starting a career in testing/QA there? Also, do you have any tips that you could share with some of our “newbie” QAZone member to help them prepare for growth and success?"
I would advise all testers, experienced and newcomers to recognize that the testing discipline, unlike development, is not technology-focused. It is an information business, a people business and a business business. What do I mean by that?
The purpose of testing is to collect, analyse and disseminate information. Testers do not write code, they do not put bugs in and do not take bugs out. In this respect, we do not improve quality or add value to the products we test. We are however responsible for providing the most valuable information required by developers (to fix bugs), project management (to understand achievement and product-risk) and stakeholders to recognise business value. In this one respect, testing is all powerful – it is the single source of knowledge of achievement in software projects.
Testing is a people business. By this, I mean that most system and acceptance testers need excellent interpersonal skills, particularly communication skills. Testers need at one time or another to communicate with, negotiate with, influence and advise end users, developers, technical/environmental support, project management, business and stakeholder management, internal and external auditors, outsource companies, customers, client services, and product managers. Interpersonal skills are, in that kind of environment, more important than technical skills.
A business business? Ultimately, testing exists to detect bugs to protect end users, but we should look to a higher goal: to inform business user and management decision making. The stakeholders who must decide to release, accept, delay, re-think or re-plan software projects are critically dependent on the information produced by testers. In this respect, testers are the best friend of business and stakeholders. Obvious, really – isn’t it?
So I have these suggestions for all testers:
- Understand the value of the information you provide to your projects. Focus your attention on learning what information your stakeholders need and in what form, and pursue a test strategy designed to optimize that information service.
- Recognize the importance of interpersonal skills. Hone them, practice them, evaluate and refine them. Seek out good communications skills training and enroll.
- Acquire friends in your business. Ask them what their fears are for success and what information they need to make their acceptance decisions with confidence. If you work for a product company, your strongest advocates will be in Product Management or Customer Services.
- Find a coach. This might be your boss, but could be a colleague or even a stakeholder. Seek out an adviser and leader who will give you a lead, push you and encourage you. In particular, find a coach that will advocate your role as an information provider and decision enabler.
Comments
"Ultimately, testing exists to detect bugs" and to prevent bugs. Is it ultimately defect prevention rather than defect detection and removal?
Paul says: Thanks Martin. I think we've been mired in the notion that testers find bugs as our primary objective for way too long. The problem is it stereotypes us as nothing more than an adjunct to developers and/or end-users. Developers have the technical insight to test better - but they don't. End users could test much better if they were so inclined, by bringing their business experience to bear.
As it is, both communities feel they could test better if they wanted to. But testers fill a (an almost clerical) gap. This holds testers as individuals back but it also holds back the state of the art, as we are too focused on the technicalities of test, not the products and value of test. Ingenuityis great, but we should be selling information and gaining influence with the higher-up. We can't do that is we just focus on tests, defects, incidents etc. etc....
Posted by: martin jamieson | November 13, 2007 11:33 PM
"recognize that the testing discipline, unlike development, is not technology-focused."
This has not been my experience at all. Testers who "just find bugs" aren't the way effective testing is done. The best testers I know do two things. First, they report product quality. Second, they are highly technical.
My advice to new testers would be to follow this pattern.
1. Get good at finding bugs.
2. Get good at using those techniques to report the quality of the products.
3. Get good at pushing quality upstream.
The advice in your article is really a good way to fulfil #3 on that list. It's not the only way. Very technical leaf node testers can drive quality from the leaf nodes upwards by developing relationships with other technical people like dev and design.
If management isn't working in the products best interest, work with them and work around them at the same time. Hack the org.
Posted by: Dustin Andrews | November 30, 2007 11:40 PM