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 aprevious blog. The outside view also relates to the business tests.
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.
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.
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.
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.