Software Testing Aligned with Real User Needs: How to Achieve Quality Even with Limited Test Capacity

In the regulated environment of a large client, thousands of test cases for internal applications run daily. These test cases must be re‑executed for every maintenance release to ensure that regulatory requirements and business demands continue to be met. The first response was the introduction of a test‑automation solution, but it quickly became clear that the necessary code could only be maintained by a handful of developers. Whenever a breaking change occurred in an application or in the underlying platform (e.g., SharePoint), the automated tests had to be manually adjusted. The developers thus became the new bottleneck of quality assurance, where previously the testers were the constraint.

The real goal, however, is to design test automation so that non‑technical users can operate it themselves. The challenge lies not only in the technical implementation but especially in people‑ and process‑management. The client works on projects with short durations of less than six months; the stakeholders have little technical understanding and limited experience with iterative‑agile development methods; a situation that is common in highly regulated sectors.

The Core Problem

How can the quality of application releases be maintained when test capacity is severely limited? The answer is to stop treating testing solely as a technical activity and view it instead as a jointly delivered service defined by the user and supported by the developer. When responsibility for test maintenance returns to the business users, the developers’ load decreases, allowing them to focus again on platform evolution. At the same time, the risk that necessary tests are missed or become outdated due to a lack of resources is reduced.

A Holistic Solution Approach

1. Introduce a Single Transparent Information Board
   Create one board that serves as a “single point of truth” for all participants (project owners, developers, and users). It displays the current project prioritization, open test cases, planned changes, and automation status. Clean stakeholder‑management enables weighting of the various application landscapes and their regulatory requirements, aligning deliveries accordingly.
2. Prioritize Features Based on End‑User Input
   Feature prioritization is derived from conversations with the actual users. It is not a technical wishlist but a focus on the concrete value a test brings to daily work. Only functionalities that are directly needed by users are automated. Developers are not the target of ad‑hoc requests; instead, they receive clearly defined, well‑estimated work packages.
3. Controlled Collaboration Between Developers and Users
   Developers gain insight into the business department’s workflows, understand regulatory constraints, and can therefore write better, maintainable test scripts. Interaction is regulated so developers are not constantly interrupted by unplanned requests. Exchanges happen in short, scheduled review cycles where new or changed test cases are examined and approved together.
4. Iterative Implementation
   Each iteration delivers a usable feature: e.g., a new test recorder, a dashboard widget for result visualization, or a tool for easy adjustment of test parameters. Instead of rolling out large releases with many half‑finished features, a continuous stream of tangible value is provided that users can start using immediately. This lowers the entry barrier and builds trust in the system.

The Generated Value

Thanks to this structured approach, the developer effort per test case was reduced by roughly 95 %. Users can now record, configure, and run test cases with minimal assistance. The end‑to‑end integration from recording to execution eliminates the hand‑over losses that previously occurred with manual transfers. The outcome is a stable, traceable process where release quality no longer depends on individual persons but on a clearly defined, repeatable workflow.

In the long term, the concept can be expanded further: AI‑driven methods could automatically generate test descriptions from existing automated tests, raising the automation level even more. The current scope of three applications is planned to be gradually extended to more than twenty systems, without the need to create additional test capacity.

Conclusion

The central message is: even in highly regulated areas where test resources are scarce, the quality of application releases can be secured when testing is strategically managed. A shared information board, clear prioritization based on user needs, and a controlled exchange between developers and users create an environment where automated tests are no longer the exclusive domain of a few specialists but a service co‑created by everyone. With this clever governance, limited test capacity is used optimally while maintaining a high level of quality.

In our whitepaper on IT architecture we outline how to organize your IT landscape along business needs and avoid resource shortages early on.

Quelle Titelbild: Jakub Żerdzicki / Unsplash