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.
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.
All Stories by Justin Rohrman
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.
There's a recent trend in having generalists on the software team—there are no developers or testers, only "team members." The idea of the two roles learning from each other is a good one, but it's usually a one-way street: Testers learn to write production code or test tooling, but no one focuses on deep testing.
We use test design techniques to answer the questions “What do I need to test?” and “What tests should I perform?” We try to ensure test coverage during test automation too, except that choosing poorly creates slower builds and unreliable information about product quality. Here are some guidelines for test selection.
Pair programming generally involves two programmers working on a single change from start to finish. You can augment this pattern by adding a test specialist, so you can test-drive feature changes first and the tester can ask questions and guide test and code design. What you get is quality built in from the start.
The idea of working as a test specialist on a team using DevOps can be intimidating. There are at least two technology stacks, containerization and continuous integration, that you need to be familiar with. But few people need to be able to start from scratch. Here's what a normal day of testing in DevOps looks like.
If a development team does pair programming, where does testing fit in? You don't have to wait until the programming is done—testers can be part of the whole process, from code design to reviewing changes to production. Pair programming plus a good automation strategy mean quality is built in throughout development.