Get ready for TX: Tester Experience

I recently had a discussion with my colleagues during which we discussed the evolution from user experience (UX) to developer experience (DX) – the latter being increasingly important when building software components and APIs that are to be consumed by developers.

A developer’s experience when adopting your APIs needs to be as positive as possible, which includes everything from a quick start up time, thorough documentation, and technical alignment with their expertise and expectations. It occurred to my colleagues and I that a complementary extension of these concepts would be TX – Tester Experience – the goal of providing testers and QA professionals the best possible experience when tasked with testing and debugging a target system.

We didn’t stop at coining a new nifty term though – we actually gave it some more thought.

TX defined

Let’s try to be a little more formal regarding the three terms we are playing with:

• User Experience (UX) – explores all aspects of a person’s interaction with an IT system; generally focuses on user-interface and related concepts; visual design, interaction design, etc.
• Developer Experience (DX) – can be seen as a subset of UX (developers are users too…). This focuses on lowering the barrier for developers to integrate with a given system: documentation, metadata, technical alignment, etc.
• Tester Experience (TX) – aims at providing testers with the best possible experience when testing/debugging a system – more on this below.

Not surprisingly, these three overlap to a certain extent.

UX and DX are both targeted at external consumers of an IT system or component, but with somewhat different needs and motivations. Unlike UX and DX, TX mainly targets internal resources, and although TX shares some components with both UX and DX – there are several aspects unique to TX:

• Testers often require behind-the-scenes insight into a system, which neither external users or developers need or should have.
• Testers are (hopefully) part of the underlying development process and have full insight into what they are testing from the beginning.
• Testers need to assess business and technical requirements, both from an end user’s perspective and from a testability perspective; i.e. they often not only assess the quality of a system’s UX and DX, they are dependent on it for their own work as well.

TX vs Testability

Testability – how easy it is to test a product – is a well-known aspect of system design, including things like:

• Modularity. A well-modularized system allows each module to be tested on its own – with possible mocking/stubbing of external dependencies.
• Transparency. Having insight into a system and its architecture is key to understanding how it works and where possible problems may lie.
• Observability. Getting continuous status information from a system while testing is key to being able to assess results and error conditions.
• Reproducibility. Being able to reliably reproduce behavior identified during testing is key to reporting and fixing issues.

(see this PDF for a more detailed overview).

Although testability definitely has a big part to play in TX, we felt there are some aspects of TX that it doesn’t cover.  For example:

Great TX requires the unconditional inclusion of testers and QA in the entire product lifecycle: requirements, architecture/development and operations.

Great TX empowers testers to give special attention to requirements:

• Gives them understanding and insight into the system to be built
• Allows them to pinpoint issues with requirements related to testability
• Perhaps most importantly, it allows them to identify quality issues with the requirements themselves

Great TX clearly defines the primary persona  (target user group) and expected usage of a system – allowing testers to understand for whom the application is intended and see if that target is met.

Great TX mandates that testers have full insight into a system under test (this is also covered by testability but deserves a special mention), achieved through

• Fearless Collaboration / Communication between the different people and roles involved in a project
• Technical and non-technical documentation; specifications, design models, requirements, business cases, etc.

Great TX gives testers full access to key people in the team;

•  Product Owners for clarifying/discussing requirements
• Architects and Developers for understanding technology and dependencies
• Operations for infrastructure for runtime assessment and

Great TX mandates the existence of dedicated testing environments that are

• Modeled after the necessary ambition to achieve a production-like environment
• Similar hardware and software stacks
• Virtualized external dependencies that allows the simulation of real user transactions involving external systems
• “Real” data and content allowing for realistic simulations of real user scenarios.
• Continuously updated with new features and fixes from development
• Easily restored if testing in any way puts them in an inconsistent state (for example during security or stress testing)

None of these should be seen as unreasonable or unobtainable, and many are in line with common development best practices.

James Bach created an insightful (and entertaining) overlay to “The Towering Inferno” that uses Steve McQueen’s character as a metaphor for the consulting software tester tasked with solving an acute crisis – it’s all about testability and tester experience – don’t hesitate to check it out and relate it to the TX concept – do they align in your mind?

Dude, it’s all about attitude.

Ultimately, what you need to provide great TX is a good attitude.  You must value testing and your testers, and meet them with openness and respect – just as you would do with your other team members and users.  And as an added bonus – great UX or DX is likely to follow.

Have you had that great tester experience? Does the term make sense for you? Please share your thoughts and experiences with us to see if TX is a term worth pursuing.

This post was originally published on Ole’s column

at Network World.

See Also:

• The Slow Web Movement and the Future of UX
• Robot Eyeballs: A New View on User Experience [INFOGRAPHIC]
• 7 Things Your Project Manager Wishes Developers Knew

[dfads params=’groups=931&limit=1&orderby=random’]

[dfads params=’groups=937&limit=1&orderby=random’]