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.
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.
A kata is a small programming task you build a solution to. The point is to develop programming skill through familiarity with programming patterns, which is a useful practice for testers today. You’ll learn about software development, testing, continuous integration, exploration—and even how to be a better person.
Many companies have some notion of an ideal tester-to-developer ratio, or the number of testers they need for every certain number of developers. It may seem like a superficial standard, but it's rooted in a very real need to understand staffing requirements and budgets. Let's dig deeper into the team balance.
People using behavior-driven development (BDD) say conversation is the most important part of the process. They use a “given-when-then” format to describe the current state, an action that is supposed to occur, and what results to expect. But if that structure isn't working for your team, don't restrain discussion.
Building a test automation strategy involves all members of the technical team, layering tests throughout the technology stack, and using this approach to design better software and catch simple problems earlier in the development cycle. But working like that requires a shift in mindset across the organization.