Testability: What it is and how to increase it

As I got more into running and had these wishes to run desert trails, mountain passes and winding country trails. I kept seeing a particular word crop up time and time again, which was used to rank the possibility of being able to run on a course.

The gruelling Badwater 135, for example, would receive a low runability score. Not because the terrain alone is tough. But because the race starts in the depths of the Death Valley basin, 85 meters below sea level. The race sees runners tackle blistering desert heat, multiple mountain passes. And elevations that take them to Mt Whitney at 2530m.

In contrast, there are many races are quite runnable for many people and have a high runability rating, such as many road races including the London Marathon. Undoubtedly though, they can still be tough for many people. This just goes to show that just because something is easier and more accessible to a wider range of people. Doesn’t mean that it translates to an easy experience.

The concept of runability is an example of us being able to gauge the difficulty of performing a certain action on a particular object or thing. So taking this example, if we wanted to measure the difficulty of testing a piece of software. We could give someone the testability rating, and they could tell how easy it is to perform testing activities on it.

Having a set of requirements difficult to understand or not explicit. Or an application missing specific identifiers or page elements that a tester needs. Are examples of ways that we can make software harder to test. And contribute towards a low testability score.

Why a high testability rating is important

Every piece of software isn’t developed equally and depending on how it’s coded. Even if it works for the end-user. The internals of the software can be different in each iteration.

Software can be complex, and with many pathways, scenarios and use cases possible. Testing many of these requires the right hooks and identifiers to be present.

Essentially, if the testability of a piece of software is high. It contributes to a better experience for your end-users and a faster development cycle. Testers can locate bugs quicker. This will lead to faster debugging and more frequent iterations and releases.

An attribute of good software is being designed and developed with testability in mind. Like any other quality factors, like being maintainable and scalable. Building software that works or fulfils the client’s requirements, does not equal a quality product if we cannot test it.

How can we ensure software is testable?

During the software development stage. Following a set of guidelines or design principles. Will aid you in contributing to the testability level.

One of the design principles is the SOLID set of guidelines. These set out suggested principles that allow your code to be more modular and testable:

• Single Responsibility Principle – Each software module should only have one reason to change.
• Open/Closed Principle – Classes should be open for extension but closed to modifications.
• Liskov Substitution Principle – Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
• Interface Segregation Principle – No client should be forced to depend on methods it does not use
• Dependency Inversion Principle – High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions.

In addition, you could add certain features to detect the environment of the software. Expose internal APIs for easy manipulating of the data. And ensuring the UI is testable by including ID/class names.

One feature that usually gets overlooked not only in software development. But also in automation framework design. And that is logging. This feature alone makes a tester’s life so much easier for debugging an error, testing the internal state of an application. And investigating exposed errors.

Two things I haven’t included here are unit tests and code reviews. But I assume you are doing these already… right?

Conclusion

The testability of a software application can either be terrible. Or excellent. Not only because of the internal features of the application (like those above). But also because of the type of application that it is, and the tester’s ability to test it.

For example, they might find web apps easier to test than mobile applications. Not because we can’t test them. But because there aren’t the features available in the application to support our testing.

Software quality isn’t just about bugs found. But also a tester’s ability to find those potential bugs.

• Category: Software Testing