Implement Quality with Doneness Focused Processes

December 16, 2016 — Posted by Ken Pugh

A software application’s quality can be viewed from at least two perspectives – the outside (customer/user) and the inside (technical).  These two views correspond with the customer/user tests and the technical tests described in a previous blog.  The outside view also relates to the business tests.    

Outside Quality

 The customer/user quality revolves around whether the system performs the functionality he or she requires, whether it meets the non-functional requirements (performance, security, usability etc.), and whether there are any defects that occur during its operation.  

During the Acceptance Test-Driven Development (ATDD) process, customer/user tests are created that define the desired functionality as well as many of the non-functional requirements.  Passing these tests demonstrate that the application meets these quality values.   The tests also serve as documentation as to the current operation of the system. 

It is necessary to pass the customer/user tests, but just passing these is usually not sufficient as a check for defects.  Additional exploratory tests should be run to discover additional issues.  

Usability is one aspect of quality that is relative.  Different users can have different expectations in the exact way that a function is performed.  For example, some corporate standards conflict with patterns of behavior established by an operating system; certain users will prefer the operating system standard and others will prefer the corporate standard.   Still others may prefer something consistent with another program that they have used. 

Business tests can include whether a change has provided an expected business value.  For example, after a new feature is deployed does it create additional customer promoters or remove some customer detractors.   Passing these tests usually indicates a higher quality application.  

Inside Quality

The technical quality revolves around the maintainability of the code which includes its structure and its appearance.   A key indicator of maintainability is the testability of the code.   Code that is straightforward to test, preferably with automated tests, is more effortless to change.   Employing Test-Driven Development (TDD) can ensure that code is testable, since the tests are created prior to the code being written. 

There are many aspects to maintainability.   Some can be measured with tools, others require subjective opinions.   Although the numbers returned by tools are objective, their interpretation can be somewhat subjective as well.  

Aspects that can be measured include size of methods and classes, cyclometric complexity, type of coupling, spell-checked names, duplicated code, and adherence to a coding standard.    More subjective aspects include whether the cohesion, coupling, encapsulation, abstraction, and overall application architecture are appropriate for the application.   The technical tests for a module or component can help indicate how the code measures relatively against these aspects.  For example, a test of a module that requires instantiating many other modules shows a high amount of coupling.   

Cross-over

There is a cross-over effect between ATDD and inside quality.  Acceptance tests are written in business domain terms.   Technical tests can be derived from acceptance tests and thus should employ the same terms.  Since the terms are in the technical tests, they can appear in the code itself.   Code which uses business domain terms is simpler to understand since there is little impedance in terminology between the external tests and the code. 

An application can pass all the customer/user tests and still be written with lower quality code that is not easy to maintain.  Sometimes a decision is made to implement a change as quickly as possible to meet a deadline.  However, the maintainability issue causes problems in implementing future changes, so it should be eliminated as soon as possible.   Ward Cunningham uses the term technical debt for these maintainability issues.  

Summary

Instituting ATDD and TDD into your development processes helps to improve quality both from the outside and the inside.  Improved quality makes for more satisfied customers and users.  

.     

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban