As part of the ongoing efforts to see how potential customers would receive and use U-Qasar, we have met with several people who are devoted to agile methodologies. For them, Quality Assurance seems to be a process imposed by the management, used to the different stages of waterfall software development (requirements, development, QA, …). Thus, they see the potential of U-Qasar to solve their reporting issues. Managers like to check trends and act upon them. U-Qasar links to the tools they are already using and can automatically produce the charts that managers desire.
Still, agile practitioners feel unease with quality metrics, indicators and models. They are driven by the concept of Technical Excellence, and to be technically excellent you need to to deliver quality code that meets customer demands. For agile practitioners, then, there is no need for external people checking on their quality. When they implement a user story, themselves are responsible Mikko Pietola summarizes (and expands on) the concept of technical excellence in his Master’s Thesis at the University of Oulu:
Technical excellence in agile is achieved through Test-Driven Development (TDD), code reviews, Definition-of-Done (DoD), iterative development and refactoring together with a fully tested code. The software architecture is not defined up-front; instead it is allowed to emerge while developing a product. Daily builds, continuous integration and automated testing tools are in a supporting role when developing and delivering successfully high quality products.
The Definition of Done and Quality in Agile Development
Perhaps the most important quality aspect is the “Definition of Done” . The DoD can include quality thresholds, meaning that only when the product reaches them, it can be regarded as done. Mikko Pietola collects examples from the web and books. He refers to the book “Practices Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum”. DoD requires different things depending on the level or product stage that we are talking about. Agile has DoD for:
- single User Stories (or features) which not only covers what the customer wants, but it also reflects how the code is produced (e.g. peer review) and the quality measures that it has to pass (e.g. static code analysis, unit testing, …). Also documentation is produced and checked here.
- sprints, which collects user stories that are already Done. For sprints to be done, non-functional and integration test must pass. Mikko recommends concrete values for certain testing coverage:
- Branch coverage is measured to be over 70%
- Function coverage is measured to be 100%
- releases, which again collects the done user stories and runs the Release functional and non-functional testing. Also, user facing documentation is strengthened.
From what we see, agile development does not go well with strict processes, and over-reaching quality models. Still, agile teams can benefit from a single dashboard that collects the progress and quality state of different user stories. U-Qasar can provide that. Quality models in U-Qasar can reflect anything and be updated as the project advances.