Elevate Code Quality by Integrating Testing and Development
Despite everything I read on the web about cutting-edge development styles, most software development happens right in the middle of average. Usually, this means two-week sprints, slightly siloed teams, and handoffs between specialties at each stage of development.
For the past few months I have had the pleasure of working with a team that is able to deliver a code change from start to finish without any handoffs. When the feature is done, we are ready to deploy it to production.
We did this by integrating our test and development teams.
Pair programming generally involves two programmers working on a single change from start to finish. We augmented this development pattern by adding a test specialist to that group. Here is what a normal day of this looks like.
During development of a feature, the three of us use either a screen-sharing program or a collaborative terminal program. This allows each of us to see the same piece of code even though we are at different computers.
We test-drive most feature changes, meaning we begin with an idea of something we need to do in the feature code—making an object accessible, for example—and write a test to check that before the object exists. At this point, the developers alternate driving, and the test specialist usually asks questions that guide test and code design. If a test needs to be built at the user interface level, the test specialist will usually create that.
We commit and push code regularly throughout this process, and I build new environments with the latest update of a feature branch. This facilitates either some light regression testing to see that the new change isn’t breaking related parts of the software, or testing of partially implemented code. We do this back and forth until we get a feeling that implementation is complete, based on either the acceptance criteria or conversations with a product person or designer.
What this process gets us is a code change with very good first-time quality. The typical code problems you see from implementation that is done by a single person, usually without test driving, don’t exist because we were so thoughtful about how the code was designed and implemented. In this process, it is rare to find surprises around entering incorrect data in a field or pages failing to submit all together. We still have to explore to find problems that might exist related to more complicated usage scenarios, so we explore as a group, and I usually discover a handful of problems that are fixed as I find them.
After this, the process becomes more familiar. We merge our branch with the main branch and run the entire test suite, then create a pull request that is available for anyone to review up to the point when those tests complete. If the merge build is green and there are no outstanding comments from the pull request, then we are ready to go to production.
Eliminating handoffs by working on a feature from start to finish is a benefit of testing with developers, but the real reward is built-in quality. Try adding a test specialist to your programming teams.
