How can you improve the testability of your product?

Teams whose focus includes testability are more likely to be high performing.[1] Good testability will “minimize testing costs”[2]. Testability can also be seen as one of the factors that determine quality.

When the testability of a feature is discussed people often ask what is meant by testability.

The clearest definition of testability I have found was in Juran’s Quality Handbook 5th Edition[3]. The definition was taken from a report by GEC for the USAF which defined testability as the “effort required to test a program to ensure it performs its intended function.” [4] 

There are a number of ways to improve testability. 

Several writers point out that considering testability during planning and design enables us to design testability into the feature we are developing. The report by GEC shows that is important to consider testability during design[5]. Others also see testability as relating to design: Kowalski describes testability as “a design characteristic”[6] and Beizer wrote that “we test software: to “achieve a testable design; a design that can be easily validated, falsified and maintained’ [7].

GEC’s report suggests instrumentation, simplicity, and self-descriptiveness as ways to improve testability[5].

Janet Gregory and Lisa Crispin wrote that “business-facing tests built with appropriate design patterns and ahead of any coding help the team achieve a testable design pattern”[8].

Improving visibility and control are ways to improve testability, and a way of doing this is to give all the team access to the source code [9]. 

Making commands easier to execute, such as via an API, is a way to improve control and so is a way to improve testability.[10].

How can you improve the testability of the feature that your team is developing? Here are some suggestions:

• It is really helpful for development teams to discuss how they will test new features because they can identify the issues with testability for the feature. The team can then work out how to address these issues. 
• Testability is a feature of design therefore a tester should be included in planning so that they can raise issues that will make testing easier and help the team create business-facing tests.
• Difficulties in testing a feature can be raised in team retros to enable discussion and learning about them, and the finding of a solution.
• Making architectural decisions that enable the development team to do most of its testing without requiring an integrated environment.[1] This could include creating the infrastructure required to test feature branches in production
• The development team should ensure that it is easy to identify elements in the DOM in order to facilitate test automation via the UI.
• If the team is working on an API the team needs to ensure that it facilitates automated API testing. An example of something that will help testability of an API is that if you can create an object via the API you should also be able to delete it via the API. 
• The design of new features needs to include useful log messages, for example, through logging in Dev Tools.

The book Team Guide to Software Testability also has many suggestions, including exercises that you can do with your team to better understand how testability applies to your project. 

I am sure that there are other examples of ways that teams can improve testability, and it would be great to hear how your team is improving testability. 

References:

[1] Accelerate by Nicole Forsgren, PhD, Jez Humble and Gene Kim (2018, p89)

[2] FACTORS IN SOFTWARE QUALITY Concept and Definitions of Software Quality

 By Jim A. McCall, Paul K. Richards CD Cene, F. Walters (1977, p155)

[3]  Juran’s Quality Handbook 5th Edition –  Computer Applications to Quality Systems by Fredric I. Orkin and Daniel Oliver (1998, Section 10)

[4] FACTORS IN SOFTWARE QUALITY Concept and Definitions of Software Quality

 By Jim A. McCall, Paul K. Richards CD Cene, F. Walters (1977, p32)

[5] FACTORS IN SOFTWARE QUALITY Concept and Definitions of Software Quality

 By Jim A. McCall, Paul K. Richards CD Cene, F. Walters (1977, p42)

[6] Juran’s Quality Handbook 5th Edition – Quality in Research and Development by Al C. Endres (1998, Section 19.29)

[7] Black-Box Testing by Boris Beizer (1995, p7)

[8] Agile Testing by Lisa Crispin and Janet Gregory (2009, p183)

[9] Lessons Learned in Software Testing by Cem Kaner, James Bach and Bret Pettichord (2002, p149)

[10] AUTOMATED TESTS: TESTABILITY by Kamil Grzybek (2023)