process through continuous integration (CI) and automated unit testing is another key feature.
Testing is more than just the rubber stamp at the end of the lifecycle
Agility does a nice job of showing how testing must be built in from the beginning of the lifecycle. Continuous integration (CI) servers immediately take newly committed code and compile them, executing automated tests and of course identifying who broke the build (make sure you get his $2 penalty fine for the office cupcake fund).
Agile has long criticized requirements documents that simply sit unused on the shelf. The implicit (and well-founded) notion is that most requirements documents are outdated before the ink dries. Keeping the requirements documents updated is a huge chore and rarely completed in a satisfactory manner. Of course, there are some systems which must have documented requirements that have been reviewed and validated. It has also long been a service management practice to consider all reported incidents, once triaged and investigated, potential candidates for becoming test cases. Test Driven Requirements refers to using well-written (and current) test documentation as requirements specifications.
The day that I managed to get the development effort to stop
Many years ago, I was involved with a trading system that had little or no written test case documentation. I was responsible for the release management and I always gathered information for the testers regarding exactly which modules had changed in the release and any interesting anomalies that I had observed during the build, deploy and initial smoke testing. The testers had an exhaustive home-grown regression test process that suffered from little or no direct input from the customers (or even the customer liaisons). As luck would have it, I found myself in a meeting with some of these subject matter experts. I remember taking a political risk and challenging them by asking for one hour of their time to write test cases. I promised that they would see the value in exactly one hour if they gave me the chance. I admit that I was pretty scared when I showed up at this internationally recognized trading exchange armed only with my trusty laptop computer.
The Golden Hour
In emergency medical services we talk about the “golden hour”. This is the first hour of care after a traumatic incident. EMS professionals, including this writer, know that the care given during the golden hour is often the decisive factor in whether or not the patient will recover. My own golden hour came when I started interviewing the SMEs and coaching them in how to write effective test cases. Within the first hour, one of the men picked up the phone and called the development manager in charge of the project. The SME told the development manager to stop their work on a particular feature explaining that, “what we have asked for is not what we want.” Getting the subject matter experts to think about testing the application caused them to realize that they had originally requested the wrong functionality. Cognitively, these very smart professionals had gone from passive to active mode and realized how the system should really behave. Writing active and live test cases, and using them as requirements, is a strong best practice that should be used on both agile and non-agile projects to improve quality.
Quality through better process
Improving our processes through Agility is all about making the right choices to implement the right practices. More than that it is about becoming Agile in the way that we approach technology efforts. Frameworks such as SCRUM, XP, paired programming and many