Agile development is a new way of operating that may present some challenges to testers who struggle to identify their role. As developers take on more responsibility for functional testing, where does that leave the tester? How should senior managers organize their development teams? In this second of a two-piece interview with the four Net Objectives authors of Essential Skills for the Agile Developer: A Guide to Better Programming...
and Design, we look more into the role QA and test plays on the Agile development team.
SSQ: With the improvements to quality made from using techniques such as TDD and other forms of automation, do you think the tester’s role is changing? If so, how?
They should no longer need to focus on executing functional tests, pointing and clicking to follow a test script. With ATDD, testers are involved up-front in determining the acceptance tests that are needed for a system. This collaboration helps to create a common understanding of the requirements. Automating the acceptance tests removes most of the need for functional testing.
Testers have time for more exploratory testing. For example, they can examine workflows that are not part of the ATDD tests. They can inspect cross-requirement issues, rather than just individual requirements. Defects caused by interactions between features and components that are not specified or anticipated are often not found by unit tests. In many organizations, the testers can get so far behind development that they have no time for such tests; when the developers are writing tests, however, the testers are more able to apply their expertise and test in depth.
SSQ: Throughout the book, you talk about strong coding techniques, and summarize code qualities in Appendix B with tips on ensuring code quality in the areas of cohesion, coupling, redundancy and encapsulation. How are these areas best “tested”? Pair programming? Code reviews?
As noted in the appendix, the tests themselves can indicate the qualities of the code. Reviews of the tests, rather than the code itself, can indicate lower code quality. For example, they can expose whether a particular module is badly coupled to other modules due to the need for creating lots of components to check a particular operation. Similarly, testing excessively for cross-method interactions often indicates a lack of cohesion. You can review the tests contemporaneously with development by doing pair programming, or periodically by having code reviews.
SSQ: What do you think is the best way to measure the quality of code?
The testability of the code is the main trim tab for code quality. Testability is explicitly demonstrated by the existence of tests, not the promise in the future to create them. Tests improve maintainability of the code by providing a degree of safety for developers who need to alter the code to add new features.
One other useful measurement is the readability of the code. For business rules, a subject matter expert should be able to read the code and determine that it matches the required logic. We often see, for example, developers adding comments to explain every aspect of their code. This usually indicates that the code is not very readable which is, in turn, an indicator of poor quality.
SSQ: Do you believe in defect tracking throughout the development lifecycle? Do you start with measuring defects in requirements? Are poor coding techniques considered defects even if they don’t produce a bug that will be seen by the customer? Should these be tracked?
First, the most important defect tracking is the number of bugs that have escaped to production. Tracking and measuring other defects should be done only if there is a loop-back issue that slows down the flow of delivery. Many of these defects can be found by early detection, thus negating the need for loop-back. For example, creating acceptance tests for requirements before developing code (ATDD) can reveal ambiguous issues. Creating tests for modules in conjunction with coding (TDD) can expose poor coding techniques.
In TDD, a bug that makes it to production often indicates a missing test – namely the test that should have failed due to the bug, but was not there. So, in TDD, when a bug is reported from the field, job one is not to fix the bug, but to add the test. And, to watch it fail before addressing the bug.
SSQ: If developers continue to gain skills in creating high quality code and practice the disciplines outlined in your book, does the need for testers go away? Can development teams justify the cost of testers if they rarely find any defects?
The need for someone who focuses on testing will never go away. Good testers have a different perspective on a system than developers. They look for things that can go wrong, rather than things that go right. They look at cross-feature issues, rather than concentrating on a single feature. A development team does not necessarily have to have a dedicated tester, but they need to have members who can assume that mindset.
SSQ: What do you think is the biggest takeaway readers will get from your book?
The biggest is how to create an Agile development mentality on your team and develop the practices to support it. This also requires a high level of confidence in the team members. We hope that by providing this “list of things you should know how to do” we are giving them the guidance they need to feel this confidence, because they will feel a confirmation that they know what they should.
For more discussion from these authors, see the first part of this interview in Agile development: Essential skills for the Agile developer.