Our company started an initiative to implement agile quality assurance best practices in all software development projects. Our teams have extensive experience with traditional quality assurance approaches based on the idea "test the deliverables". They have also experience in integrated quality assurance tools such as Test Driven Development, Defect Driven Development, Pair Programming, Coding Dojos, and agile Scrum development methods. This approach is based on the idea "deliver quality products".
Below the definition of quality insurance taken from wikipedia. The major element in the definition is the statement "in advance".
"Quality Assurance is a part and consistent pair of quality management proving fact-based external confidence to customers and other stakeholders that a product meets needs, expectations, and other requirements. QA assures the existence and effectiveness of procedures that attempt to make sure - in advance - that the expected levels of quality will be reached" Wikipedia
The vision of our initiative is stated on the bbv Software service company internal wiki.
The agile quality insurance group is the knowledge group for agile quality insurance and testing. One major goal is to increase our knowledge and "best practices" for agile quality assurance. Through continuous improvement we will ameliorate the internal and external quality of our internal projects and customer projects. Themes are for example clean code, ATDD, TDD, CI, continuous deployment, static metrics, dynamic metrics, coding guidelines, reviews, walkthroughs, pair check-in, architecture guidelines such as SOLID, etc.-
We want to find an ideal approach to integrate agile quality assurance and agile testing skills in our Scrum teams. Once the approaches are identified they should be part of the standard approach how bbv teams realize projects. All gathered information and activities of this group should be published on the company wiki.
Test Driven Development - TDD -
Test Driven Development (TDD)
is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[Wikipedia]
Please read the benefits chapters to understand that TDD is cheaper than traditional testing and delivers a product with higher quality
Acceptance Test Driven Development - ATDD -
The goals of acceptance tests is to drive the development and verify the correct realization of stories.
The practices of ATDD include:
- Establishing the goals of different stakeholders required for a vision to be implemented
- Drawing out features which will achieve those goals using feature injection
- Involving stakeholders in the implementation process through outside–in software development
- Using examples to describe the behavior of the application, or of units of code
- Automating those examples to provide quick feedback and regression testing
- Using 'should' when describing the behavior of software to help clarify responsibility and allow the software's functionality to be questioned
- Using 'ensure' when describing responsibilities of software to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.
- Using mocks to stand-in for collaborating modules of code which have not yet been written [Wikipedia]
Automated Acceptance Testing (ATDD) is a key agile development practice that can also be very beneficial for more traditional projects. Developers write automated functional tests that are specified collaboratively with the business. Key benefits include [Wakaleo]:
- Reduced risk due to a better understanding of the requirements
- Better team communication and an unambiguous definition of what needs to be done
- Issues are detected and fixed faster
- Faster releases due to comprehensive automated regression tests
- Objective, real-time measures of progress
- DevOps: is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals.
End of year 2011 we published a company internal questionary how agile quality assurance and agile testing principles are used on a daily basis in software development projects. The findings are used to define an improvement program for all software projects developed internally and at customer sites. The responses are compiled from the ten projects which provided information. We had five projects developed under .NET/C##, three projects developed under Java, and two projects developed in C++. As a remark currently we do not distinguish industrial applications from commercial finance oriented solutions.
The majority of the projects are green field projects, only two projects stated that they are brown field projects.
Wide opportunities and threats are identified over all the sent responses describing software projects.
- Our company is a geographical leader for agile Scrum development and Extreme Programming approaches
- All collaborators are trained in agile techniques
- Almost all collaborators are certified Scrum master or product owners and have access to advanced training and coaching
- In 2011 the company could not fulfill requests for Scrum development - Scrum coaches and experienced Scrum masters -
- In 2011 the company lost leads in the area of agile quality assurance and agile testing
- Major competitors are trying to establish themselves as the Swiss agile Scrum specialists
The strengths and weaknesses were defined below on a more detailed level.
| Theme|| Dimension
|| .NET / C#
|| Java/ JEE
| Static Tools|| Programming environment and development tools
- Visual Studio + Resharper
||Strength: Our organization is mature. Training should be provided to all juniors for effective use of modern IDE and standard extensions.
| || Coding guidelines
||Strength: Our organization is mature. Approaches should be defined how brown field projects are transformed to respect coding guidelines where adequate.
| || Static syntax quality metrics
- Sonar (history)
||Improvement: Tools are known but not all projets use them. Not all projects use the results as quality gate.
| || Static semantic quality metrics
- Sonar (history)
||Improvement: Tools are known but not all projects use them. Not all projects use the results as quality gate.
- Agile architecture and refactoring
- Agile principles such as SOLID
- Clean Code
| ||Improvement: Our organization is professional. Clean code is insured through pair programming, pair checkin, coding dojo. Agile architecture principles are not lived in all projects.|
| Dynamic Tools|| Test driven development and mocking
- TFS test
||Strength: Our organization is professional. Training should be provided to seniors to increase efficiency and to juniors to push awareness of these approaches.
| || Acceptance test driven development
||Weakness: major weakness in the area of performing the tests, adapting the RE process and missing KPI.
| || Code coverage measurement
| Environment|| Continuous integration
||Strength: Our organization is mature
| || Continuous deployment||
||Improvement: No clear approach and best practices could be identified in the company. Some projects have already reached professional level.
| || Quality gate
- through Teamcity
- through TFS
||Improvement: Not all projects have systematic pair checkin, defined process for done stories, or defined release process.
| Development Approach|| Scrum approach (management aspects)|
- sprint duration is 2 weeks
- stories and RE are written ad hoc
|Strength: Our organization is professional. All developers know about Scrum. But not all projects are practicing Scrum. The majority of the teams also have working knowledge of Kanban approach.|
Subtle aspects such a team organization, team responsibility, scrum master responsibilities, team code ownership are not well understood in all projects.
| || Extreme programming approach (technical aspects)|| || || ||Strength: Our organization is professional. All developers know about clean code, TDD, pair programming, pair checkin, and coding dojo.|
| || Stories or requirements with testable acceptance criteria|| || || ||Improvement: Projects are learning how to write such stories and requirements. The dependencies between backlog, requirements and acceptance tests should be better understood. Improvements are necessary.|
| || Tracking of defects and cycle time for defects||Weakness: Issue management tools provide support. Not all projects have a clear tracking of issues to releases.|
| || Key performance indicators to track quality||none||none ||none ||Weakness: Projects do not have a culture for KPI - Key Performance Indicator -. The focus on ROI as required in Scrum is also weak.|
| || Risk Management||none||none ||none ||Weakness: Risk management for project should be standard.|
| || Project and release planning|
- analog roadmap
- analog current release plan
|none ||none ||Weakness: Agile project and release planning should be standard.|
| || Quality assurance role in team|| none||none ||none || The TechDay 2011 keynote clearly showed the weaknesses in our development approach.|
Based on the above findings the agile quality assurance group will define measures and prioritize them.
Under definition by the agile quality assurance group members. The identified area are
- KPI and Quality Gate
- Scrum project management with release planning, risk management with mitigation measures, continuous improvement
- Agile architecture and refactoring
- ATDD, documentation, and Quality Gate
- Quality assurance roles in the Scrum team
- Continuous Deployment and DevOps aspects
The weaknesses and improvements identified in the area of requirements engineering should be corrected in the requirement engineering task force. Tracking of progress will still be done in our group due to the quality assurance component.
The weaknesses and improvements identified in the area of Agile Scrum and Kanban development process should be corrected in the Scrum master and product owner task force. Tracking of progress will still be done in our group due to the quality assurance component.
Themes for Kick-Off Meeting Quality Assurance Improvements
The data collected from the questionary and the feedback from the experts members of the agile quality assurance and testing group give hints for the following themes
- Clean Code and writing of source code
- Coding guidelines
- Static syntax metrics
- Static semantic metrics
- Continuous integration
- TDD and eXtreme Programming
- Test Driven Development - TDD, mock, impact on the architecture -
- Coding dojos, definition of done for internal quality
- ATDD, BDD and acceptance quality
- ATDD and BDD tools
- Writing conventions for stories to insure implementable, testable and complete acceptance criteria
- Agile software architecture
- Software architecture for TDD/ATDD/Clean Code projects
- Architecture refactoring
- Technical project documentation: architecture, installation, user manual, issue-TDD-release
- Impact on TDD, ATDD, BDD
- Requirement Engineering and Product Owners (RE/PO Interest Group - Stefan Widmer / Raphael Auf der Mauer)
- Agile quality assurance influence on stories, requirements and the role of product owner
- Quality assurance for stories and requirements
- Agile portfolio management and agile architecture - Enterprise Architecture -
- Refactoring aspects
- Change management and traceability in a regulatory environment
- Process improvements (Process/Scrum Interest Group - Alan Ettlin / Heads)
- Scrum usage
- Quality assurance roles in a Scrum team
- Project Management Office PMO with releases planning, project planning and risk management, and Scrum of Scrums
- KPI and quality gates - process, ROI, tools -
- Bridge between issue management and development process - Scrum, Kanban, traceability -
Here a set of books discussing various aspects of agile quality assurance and testing. For more details see books I recommend often
- Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory, Addison-Wesley 2009
- Refactoring Improving the Design of Existing code, Martin Fowler, Addison-Wesley 1999
- Working Effectively with Legacy Code, Michael C. Feathers, Prentice-Hall 2005
- Test Driven Development by Example, Ken Beck, Addison-Wesley 2003
- Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall 2009
- The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin, Prentice Hall 2011
And one reference to help us introduce improvements in organization
- Fearless Change: Patterns for Introducing New Ideas, Mary Lynn Manns & Linda Rising, Addison-Wesley 2005
Blogs discussion agile quality insurance and agile testing are