A flashpoint that I don’t see much discussion about is the moment when developers realize they need more of a stake in the quality of an application.
I know quite a few developers who care about quality, and I’m sure they each have their own story about the moment they realized how important it can be. I’ve seen devs realize the difference a focus on testing can make when they’ve outpaced their testers and the testers had no hope of ever catching up.
In a meeting I attended awhile back, a dev said to me that he wanted to have more ownership of testing. Now, it’s not like he wants to wrestle it away from the testers, but he would like to feel like he is taking a more active role in the quality of his code and in the application.
These are just a few suggestions from me:
Don’t make it too cumbersome to write tests
I’ve worked with test infrastructure that was so old, there was a lot of new functionality lacking and old bugs made some testing a real pain. A frequently heard dialog was, “did you write tests for that?” “Uh, no, the framework doesn’t support it.”
Don’t be too strict about having perfect tests
Especially if you have developers who are just getting use to writing unit tests or functional tests, make it a positive experience. It should be ok to play around with what works well in the tests. It means that there will be refactoring later, but having tests to refactor and developers interested in refactoring them is better than having devs who are scared of ridicule when they write tests and no tests at all.
Use short developer checklists
– have an awareness of stuff that you tend to miss and make a short list to check for them
– are there certain types of problems your team is trying to avoid?
Make sure the interns are testing
We all know that testing education is hit or miss in CS programs. If you work around interns make sure they are writing tests. If they don’t know how to write tests, you’re looking at someone who will be a developer that doesn’t own tests or the quality of their code unless you intervene. This isn’t to say that I haven’t met interns who know how test, just that there are plenty who don’t.
But this is just me…the tester talking about owning quality. I went in search of some Mozilla web devs interested in sharing their perspective on this topic.
Kumar McMillan (@kumar303) a developer for addons.mozilla.org had these tips for developers:
test each component in isolation so that it works
- Integrate components early and often because there are usually surprises, especially when integration spans multiple teams (via APIs / services, etc)
- Test at different layers of integration. For example: write tests that combine lots of backend components but not no frontend components.
- Developers should deploy code directly or be present when deploying code and should know where to look to monitor the health of the deploy. Without this direct responsibility it’s easy for developers to lose track of quality.
- It’s also important for developers not to over-test components. It’s tempting to boost code coverage graphs or attempt a 3:1 test to code ratio but generally these practices are not helpful. It will slow you down. It’s more important to get code into the hands of users with crucial edge cases covered by tests. The “happy paths” are not so important to test because it is more likely for those to be explored.
- Whenever there’s a bug it’s important to write a test to prevent regressions before the bug is fixed.
- Always use continuous integration and make every developer own up to their mistakes when they break the test suite.
- All tests should be automated in CI otherwise that test is useless — someone will forget to run it.
Dave Dash (@davedash) who recently gave the workshop “Test Anything, Test Everything” at DjangoCon took a more philosophical approach. Dave’s perspective is that “Quality is more than finding bugs. It’s about having a high-quality product.” He mentioned it’s about having pride in your work and caring about the website you build. Dave’s attitude is one that I’ve consistently found in the best developers I’ve worked with. As a tester, I’ve noticed that it’s always 10 times easier to work with developers who care about quality and testing because they want their code and the applications they produce to be great. Quality is, indeed, about more than finding bugs.
Thanks to Dave and Kumar for sharing :)
If you have your own opinion about how developers can own quality, I invite you to share it in the comments.