This is a terrific article, worth repeating a section of it:
So: you want to have an influence on quality, and on the team. Want to know how to influence the programmers in a positive way?
- Tell the programmers, as James suggests in the interview, that your principal goal is to help them look good—and then start believing it. Your job is not to shame, or to blame, or to be evil. I don’t think we should even joke about it, because it isn’t funny.
- You’re often the bearer of bad news. Recognize that, and deliver it with compassion and humility.
- You might be wrong too. Be skeptical about your own conclusions.
- Focus on exploring, discovering, investigating, and learning about the product, rather than on confirming things that we already know about it.
- Report what you’ve learned about the product in a way that identifies its value and threats to that value.
- Try to understand how the product works on all of the levels you can comprehend, from the highest to the lowest. Appreciate that it’s complex, so that when you have some harebrained idea about how simple it is to fix a problem, or to find all the bugs in the code, you can take the opportunity to pause and reflect.
- Express sincere interest in what programmers do, and learn to code if that suits you. At least, learn a little something about how code works and what it does.
- Don’t ever tell programmers how they should be doing their work. If you actually believe that that’s your role, try a reality check: How do you like it when they do that to you?
Want to know how to influence the managers?
- Provide them with the information they need to make informed decisions, and then let them make the decisions.
- Remain fully aware that they’re making business decisions, not just technical ones.
- Know that the product doesn’t necessarily have to hew to your standard of quality.
- It’s not the development manager’s job, nor anyone else’s, to make you happy. It might be part of their job to help you to be more productive. Help them understand how to do that. Particularly draw attention to the fact that…
- Issues that slow down testing are terribly important, because they allow bugs the opportunity to hide for longer and deeper. So report not only bugs in the product, but issues that slow down testing.
- If you want to provide information to improve the development process, report on how you’re actually spending your time.
- Note, as is so commonly the case, why testing is taking so long—how little time you’re spending on actually testing the product, and how much time you’re spending on bug investigation and reporting, setup, meetings, administrivia, and other interruptions to obtaing test coverage.
- Focus on making these reports accurate (say to the nearest five or ten per cent) rather than precise, because most problems that we have in software development can be seen and solved with first-order measures rather than six-decimal analyses derived from models that are invalid anyway.
- Show the managers that the majority of problems that you find aren’t exposed by mindless repetition of test cases, but by actions and observations that the test cases don’t cover—that is, by your sapient investigation of the product.
- Help managers and programmers alike to recognize that test automation is more, far more, than programming a machine to pound keys.
- Help everyone to understand that automation extends some kinds of testing and greatly limits others.
- Help to keep people aware of the difference between testing and checking. Help them to recognize the value of each, and that excellent checking requires a great deal of testing skill.
- Work to demonstrate that your business is skilled exploration of the product, and help managers to realize that that’s how we really find problems.
- Help the team to avoid the trap of thinking of software development as a linear process rather than an organic one.
- Help managers and programmers to avoid confusing the “testing phase” with what it really is: the fixing phase.
- When asked to “sign off” on the product, politely offer to report on the testing you’ve done, but leave approval to those whose approval really matters: the product owners.
Want to earn the respect of your team?
- Be a service to the project, not an obstacle. You’re a provider of information, not a process enforcer.
- Stop trying to “own” quality, and take as your default assumption that everyone else on the project is at least as concerned about quality as you are.
- Recognize that your role is to think critically—to help to prevent programmers and managers from being fooled—and that that starts with not being fooled yourself.
- Diversify your skills, your team, and your tactics. As Karl Weick says, “If you want to understand something complicated, you have to complicate yourself.”
- As James Bach says, invent testing for yourself. That is, don’t stop at accepting what other people say (including me); field-test it against your own experience, knowledge, and skills. Check in with your community, and see what they’re doing.
- If there’s something that you can learn that will help to sharpen your knowledge or your senses or your capacity to test, learn it.
- Study the skills of testing, particularly your critical thinking skills, but also work on systems thinking, scientific thinking, the social life of information, human-computer interaction, data representation, programming, math, measurement…
- Practice the skills that you need and that you’ve read about. Sharpen your skills by joining the Weekend Testing movement.
- Get a skilled mentor to help you. If you can’t find one locally, the Internet will provide. Ask for help!
- Don’t bend to pressure to become a commodity. Certification means that you’re spending money to become indistinguishable from a hundred thousand other people. Make your own mark.
- Be aware that process models are just that—models—and that all process models—particularly those involving human activities like software development—leave out volumes of detail on what’s really going on.
- Focus on developing your individual skill set and mindset, so that you can be adaptable to any process model that comes along.
- Share your copy of Lessons Learned in Software Testing and Perfect Software and Other Illusions About Testing.
