are. If you write bad code which nobody else in the team understands, people reading the code after you will bug you. If you are a team leader, and if new members keep complaining about not understanding what the code is doing, they are bugging you. If there is no documentation about the product or its design, they bug one another. Removing bugs according to this broader definition will help you remove those belonging to the narrower definition.
The agile movement amongst other things has emphasized three practices: continuous integration, test driven development and constant refactoring. I will describe these practices from the perspective of achieving quality, i.e. reducing bugs.
- Continuous Integration (CI) . Continuous Integration is not just about automating procedures to create a build. Today's CI environments can and usually incorporate automatic tests, static code analysis for code complexity, code duplication, and potential bugs, code execution coverage, presence of comments, and so on. These are helpful to detect problems early and give the team a chance to fix them early.
- Test Driven Development (TDD) . Perhaps writing test code before target code is not easy, but at the very least, but it should be something to strive for. At the very least, developers must deliver test code together with the target code and in the same code repository. A developer's job is not done until he has proven that his code works and there is nothing better than writing their own test code. If that is difficult, it means that the testability of the product is poor or the developers are just plain lazy.
- Constant Refactoring . There have been many debates between the merits of up-front design or emergent design, which I will discuss in a minute. But for now, I am talking about constant refactoring as a way of tidying, cleaning and sorting the code - to improve maintainability and extensibility and to have this as a habit as part of lean developments 5S (sorting, straightening, sweeping, standardizing, sustaining). So, all code must reside in its rightful place, and so should tests and documentation.
All the above practices, CI, TDD, Constant Refactoring, are their precisely to help you attain high quality while still being responsive through iterative development. Iterative development without CI, TDD, Constant Refactoring is not sustainable.
I have worked with a number of agile teams. They all practice iterative development in a SCRUM like manner, but they lack the will power and perhaps the competency to apply CI, TDD and constant refactoring effectively. Thus, whereas outwardly, they seem “agile” with sprints, stories and all, but peel off the outer layers and you still find the same old habits.
3. Mindset: Developers and Testers are One
Rightfully, there should not be a distinction between developers and testers. Developers should test their own code. They should not need other people to test what they do. Does it mean there should be no testers? Let me clarify myself. I distinguish two kinds of roles:
- Quality Advisors/Coaches . Of course, there needs to be some requirements persons to look at the product from a customer's or user's perspective. They give advice on what quality means in the context of the product, what are the key usage scenarios and the expected usage environment. They help fill the gaps in the requirements.
- Naive Testers . There is another group of people who have no better understanding of the product than the developers themselves. Their job is to test the system by following a set of test procedures. They are treated like robots. Some are more technically qualified, and they write