Role of Testing and QA in Agile Software Development

Scott Ambler gave a talk entitled “The Role of Testing and QA in the Agile Software Development” at TASSQ. The talk however covered many topics and was not necessarily geared to testing and QA.

Scott starts by giving an overview of agile software development. Agile development involves open communication, enhanced collaboration, and embraces change. It results in the creation of working systems that meet the changing needs of stakeholders and produces high quality software with the highest value possible for the stakeholder’s investment.

Agile values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. There are 12 principles in Agile which Scott briefly goes over.

After that Scott dispels some misinformation about agile. These include:

1. 1. Many people confuse agility with code and fix (hacking). Many hackers claim to be agile. These are not agilest. Do they have a test bed? Do they know the stakeholders?
2. 2. Agilist don’t model. Agilist don’t document. Not true. Agile documentation and modeling is done just in time and avoids unnecessary documentations.
3. 3. ISO/CMM/6sigma therefore we cannot be agile. These presents some challenges’ but it is still possible to be agile even in these types of organizations.
4. 4. Agility does not scale. This has been proven to be false. Example is the Eclipse project.
5. 5. Agilist ignore Enterprise concerns. This area is still not well addressed by the agile community.

Next Scott moves on to cover Agile techniques. These include:

1. 1. Regular deployment of working software: The only measure of success is delivering working software.
2. 2. Pair programming: This is a hard sell to management, but the data shows that it increases productivity. People learn from each other quickly. Forces programmers to code. Reduces down time (facebook, email, browsing, etc…).
3. 3. Active stakeholder participation: They provide information and make decisions in a timely manner.
4. 4. Model with others – equivalent to pair programming. Collective ownership concept. More people understand what is going on. Leads to more collaboration and less documentation
5. 5. Refactoring – Small changes to code that improves design and retains the behavioral semantics of code. Enables evolving development assets in a controlled manner, enabling design to remain high quality.
6. 6. Database refactoring – simple change to database schema that preserves the behavioral semantics and the informational semantics.
7. 7. Test driven development. Write test 1st, write code to pass test.
8. 8. Continuous regression testing – Whenever someone checks code in.
9. 9. Test as primary artifacts – acceptance tests are considered to be primary requirements artifacts and unit tests are considered to be detailed design artifacts.
10. 10. Continuous Integration: Frequent builds
11. 11. Follow Guidance – Coding practices and Modeling practices

Finally Scott questions traditional dogma. He mentions that reviews and inspections compensate for poor teamwork and poor collaboration leading to people working alone, not sharing, and not following guidelines. Instead consider adopting pair programming, modeling with others, active stakeholder participation, open communications, collective ownership, promote collaboration, and have occasional spot reviews.

Scott gives statistics on the cost of big requirements up front. Results of a study showed the 45 % of the delivered requirements were never used and19% we rarely used. Almost 2/3 wastage when projects succeed. In agile, each iteration implements the highest priority requirements. Stake holders have complete control over what gets built, how long it takes, and how much it will cost.
Similarly, big design up front results in a detailed design model being built before coding begins. Then developers don’t follow the design and designers might make mistakes in the design and won’t get it right the 1st time. Instead, Scott suggest doing just enough modeling like initial scope and initial requirements modeling ad follow test driven development practices

Scott recommends avoiding unnecessary documentation. Developers don’t follow well defined requirements. Programmers don’t follow design documentation. Stakeholders are given fictional status reports and detailed project plans but no working software. Instead, consider how much documentation you really need. Valid reasons to document are stakeholders require it, to define a contract model, to support communication with an external group, or to think something through. Scott suggests providing a price tag to documentation. Let stakeholders prioritize and decide what they want to pay for. Also, adopt acceptance tests and unit tests as documentation. This keeps documents close to the code and ensures that they are updated regularly.

Finally Scott wraps things up by addressing some of the audience’s questions.
This presentation is available on InfoQ at http://www.infoq.com/presentations/role-of-testing-in-agile-scott-ambler