for testing. So, how can rapid iterations lead to catching defects sooner and reducing defect incidence overall?
There is a whole lot to tell about agile testing. Entire agile practices are centered on testing (TDD, for example), but many incorporate testing into the iteration—a task just like a bug fix, code review, or new feature.
In a short development cycle, there isn’t a whole lot of time to run a full coverage suite of tests. Some companies even have regression tests that take days to complete. Regression tests of that sort are great in a sense, but they can only discover defects later in the development process. Remember, the longer you wait to catch a bug, the more it costs to fix it.
If it takes five days for a regression test to complete and catch a bug, how many more changes have been introduced to the code since then, how easy will it be to fix now without disrupting something else, and what happens after you wait another five days to confirm the fix? It’s not a very agile approach, but automation is important to agile testing with some manual testing aspects thrown in for good measure.
Popular examples of agile testing techniques include:
- Continuous Integration —Builds occur right after a developer commits a change to catch errors right away and ensure new changes play nicely with the rest of the system, including recent changes from other developers.
- Unit Testing —This is an example of testing that can be automated at the code level (“white box”) and checks for logic errors. For example, if X is set to 7, do we get the expected result for Y?
- Functional and Smoke Testing —This is a manual or automated way to test features—usually newly created elements—to ensure they are working. In a rapid iteration, there will be minimal manual testing coverage, but it can be greatly expanded with automation.
- Regression Testing —Verify that old features and functionality still work and have not been broken by new changes, can be automated, and can include functional and unit tests.
As Martin and Schwaber write, “The short cycles of Scrum require continuous testing, continuous integration, and continuous improvement of the code.” We’ve already looked at good design, and continuous improvement of the code is part of that, so lets look at continuous testing and integration.
Continuous I ntegration
Continuous integration is one of the best testing practices that every development team—not just agile practitioners—can benefit from. The main principle is that as every change is introduced into the code repository, a new build is kicked off, usually automatically. If the build passes, it means introducing new changes doesn’t immediately break old changes. If the build fails, someone is notified immediately by the system (usually through email).
It is far easier to fix a broken build that you coded five minutes ago than one you coded five days ago, because you may have forgotten why you made a certain change. Or, you may have added more changes that work but depend on the broken section, so five days of work must be rewritten or tossed.Continuous integration also identifies who originally introduced the error, allowing the same person who made the change to fix it, rather than having someone else do it.
Continuous integration is ideal for agile teams because it occurs so quickly. With agile methodolgoies, your goal is to have functioning software to demo to your customers and stakeholders without much time in the rapid iteration cycle. So, knowing of build errors right away is a huge benefit, because you can reduce