Testing compatibility with TMAP

What is compatibility, really?

Compatibility, also known as installability is sometimes confused with the technical act of installation (whether a package lands correctly on a server). However, within the TMAP framework, we look much further.

Compatibility is the degree to which automated software aligns with the manual procedures of the organization. It’s about the interface between human and machine. You can write the best code in the world, but if that code doesn’t "fit" the user's daily routine, the software is practically worthless. Compatibility forces you to look beyond the buttons on the screen and examine the entire process chain: from the first human action to the final processing in the system.

User adoption is key

Why should you, as a tester, product owner, or developer, care about compatibility? The answer is simple: User Adoption.

If software lacks compatibility, three things happen that can ruin your project:

Workarounds

Users are creative. If the system works against them, they will find ways around it. They’ll keep shadow lists in Excel or stick post-its on their monitors with data to be entered later. The result? Your data integrity is gone.

Compliance risks

When manual control points don’t logically align with the system output, errors slip through. Before you know it, you’re no longer compliant with the laws and regulations the system was meant to uphold.

Higher costs

A process that looks faster on paper but creates friction in practice increases workload and error rates. The business case you calculated beforehand evaporates instantly.

Recognizing failing infrastructure in practice

Let’s make it concrete. Where does installability usually go wrong?

• The order of information: A call center agent is forced by the system to enter a Social Security Number on the first screen. In practice, however, customers only look up that number halfway through the conversation. The software enforces a process that doesn’t match the natural flow of a phone call.
• Physical constraints: A system for mechanics requires them to type an extensive report after every repair. But because they are standing outside in the rain with dirty hands, they wait until the end of the day. The 'real-time' reporting management relies on is never up to date.
• The 'Gap' factor: The software handles step A and step C perfectly, but there is no logical place in the workflow for step B (for example, a manual signature from a manager). The process literally falls into a gap.

How to make this testable with TMAP?

Testing for installability isn't done from behind a desk with a test script in hand. It requires a Shift Left approach. You start 'testing' before a single line of code is even written.

(1) Review User Stories with a 'process lens'

For every new feature, ask: "What does the user do immediately before this action, and what do they do immediately after?" If those steps aren't in the system, who performs them? And does it connect logically?

(2) Use the Process Cycle Test (PCT)

This is a powerful TMAP test design technique. With PCT, you map out the various paths through a process. By drawing not just the 'happy flow' in the system, but also the manual steps surrounding it, you immediately see where friction arises.

(3) Test 'physical' installability

Go to the workplace. If you’re developing software for a factory, go to the floor. Testing a mobile app for travelers? Get on a train. Only there will you discover if the installability holds up under pressure, ambient noise, or fluctuating connectivity.

Installability as a team effort: The 'Whole Team Approach'

In an Agile or DevOps environment, quality is no longer just the tester's responsibility. This is especially true for installability. Because this test quality attribute sits right on the edge of technology and business, you need the whole team to get it right.

• The Developer: Builds with context in mind. If a developer knows the software will be used in a noisy factory, they might choose visual signals over subtle audio alerts.
• The Product Owner (PO): Is the guardian of the 'process fit.' The PO must be brave enough to say: "This feature is technically brilliant, but it doesn't align with how our customer service works. We need to simplify it."
• The Scrum Master: Facilitates communication with end users. They ensure that feedback from 'field tests' actually makes it onto the sprint backlog.

How do you measure Installability?

You can’t capture installability with a simple 'pass/fail' percentage. It is often qualitative, but you can make it concrete with the right indicators:

• Time-to-complete (Manual vs. Auto): How long does the total process (including manual steps) take with the new software compared to the old situation?
• Support tickets regarding 'Process Questions': Is the helpdesk flooded with questions like "How do I handle X in the system?" If so, the software doesn't align with real-world exceptions.
• Observation score: Shadow five users. How often do they have to leave the system (to look something up, call someone, or consult a colleague) to complete a single transaction?

From 'checklist' to intuition

The beauty of the TMAP philosophy is that quality attributes like installability eventually become part of your team's DNA. You stop building mere functions and start building solutions that actually work in the hands of the people they are intended for. That is the difference between an IT project that is 'done' and an IT solution that adds value.

Want to structurally improve your software quality?

Installability is just one piece of the puzzle within the TMAP framework. In a world where software is becoming increasingly complex, a shared language regarding quality is indispensable.

Do you and your team want to learn how to integrate quality attributes like installability, performance, and usability into your development process from day one? Follow the e-learning TMAP: Quality for Cross-Functional Teams. You will learn how to translate quality into concrete, testable scenarios and take responsibility for the end user as a team.