Compatibility Is Part of Done

A feature is not done until it works across the environments the product claims to support.

Commercial software normally has a technical specification or support matrix that describes the environments it supports. That may include browsers, operating systems, screen sizes, devices, or particular combinations of them. These are not simply testing preferences. They are part of the product’s promise to its customers.

Compatibility testing is usually described as non-functional testing. That classification is useful, but it can also make compatibility feel separate from feature development. Teams build the functionality first and validate it across supported environments later. By then, the story may already appear complete.

I was reminded of this while looking at a note I made in 2018. One of my teams used the acronym ICE for the browsers we needed to cover at the time: Internet Explorer, Chrome, and Edge. We also checked the application on iPad and Android tablets. The list now looks dated, as every compatibility list eventually will, but the practice behind it still matters.

We were making the supported environments visible while the work was still being developed. Compatibility was not an aftermath activity. It was part of understanding what the feature had to do.

When compatibility checks are left until the end, even a small issue creates disproportionate disruption. Work returns to development, people recover context they have already put down, parts of the test cycle are repeated, and confidence falls close to release. The defect may be minor; the timing makes it expensive.

Checking compatibility during development changes that dynamic. A developer can correct a layout, interaction, or environment-specific behaviour while the implementation is still fresh. The team gets a more honest view of progress because “done” means the feature works where the product says it works. Release delivery also becomes more predictable because compatibility does not arrive as a late source of unplanned work.

This does not mean testing every possible combination. The product’s technical specification should identify the environments the organisation has chosen to support. The development team can then treat those environments as part of the context for building and completing relevant stories.

Browsers and devices will change. The supported matrix will evolve. The lasting practice is to build and verify software with its real operating environments in view. Compatibility is not something to discover after development. It is part of developing the feature well.