I have been a professional software tester in various capacities since 2005. In my current role, I am a consulting software tester and writer working with Excelon Development. Outside of work, I am currently serving on the Association For Software Testing Board of Directors as VP of Education helping to facilitate and develop projects like BBST and WHOSE. I am also a student in the Miagi-Do school of software testing, and facilitate sessions for Weekend Testing Americas.
I am deeply interested in software testing and delivery, and also helping organizations fix problems in measurement and metrics programs.
Tools are a normal part of testing jobs because they can amplify our ability to learn about product quality. It's a good idea to review new tools for automation, performance, or monitoring to see if some solution will help you test better. Before you even look at tools, though, there are two questions you should ask.
Testers fill in their assumptions about the project, domain, and technology with things they learn while testing and while talking with people. Sometimes the information they learn is good, but sometimes they miss something important. Here are two quick wins for filling in those assumptions with good information.
Of course a developer's primary job is to produce good code, but there's also a lot they can do to contribute to quality and test their code before it gets to a tester. Code quality techniques help developers write better code, more thoroughly understand their changes, and avoid builds with many easy-to-find problems.
No single person on the team knows much about test coverage at a high level. Developers might understand it for parts of the code base they worked on. Testers might understand it for the last handful of features they tested. But neither is able to talk about test coverage in a meaningful way. We need a holistic view.
If testing is taking awhile and a lot of bugs are getting into production, it's a good idea to review your entire test strategy. Spend some time understanding the current process and what testing is happening through the dev process—not what is outlined in a process wiki, but the work that actually happens.
Testers often look at automation work as the next career step after manual testing. Automation work has more visibility at the project level, and people who do this work usually also tend to have a little more social status. But Justin Rohrman makes a case for why testers shouldn't be the ones doing automation work.
Most testing work is invisible—something that happens inside your head and leaves no artifacts behind. This generally leaves testers feeling like no one understands what they do all day. Here are some ideas for collaborating with your coworkers so they can see—and start to understand—your testing work.