Some organisations initiate system implementation projects without documenting how existing business processes will be affected. In some cases, even the existing business processes lack documentation. Documentation in testing is something that we constantly need to think about.
More digitisation projects should shift its primary focus from just delivering working systems on time, to successfully adopting business processes to the new technology. To be successful, the project must also include training and motivation of all business users. System implementation projects missing “business process focus” will probably affect testing in a negative way, if the test manager does not pay attention.
This article will aim to give insights into these challenges of documentation in testing and provide some solutions, based on my experiences from a recent system implementation project, where I had the test manager role. I will focus on two problem areas which are also part of the start-up criteria for most test processes.
The Challenges
Recently I was hired as a test manager for a large system implementation project in a municipality in Norway, where old technology was being replaced by modern technology. The system has more than 4000 professional users from various professions within the health care sector.
My test strategy for the user acceptance testing just did not work. The main problem was that all the domain experts from the business were busy doing a variety of other project tasks instead of documenting the business processes, as this was going to be my main test basis for the acceptance testing. Another problem was that there had been low interest in learning the basic user interface of the new system.
When I was designing functional acceptance testcases based on the business processes, it soon became clear that the business processes were not really documented, and therefore it was not possible to plan and implement testing them.
Mainly because of the lack of testable requirements and not enough involvement from the business, the project did not manage to deliver as planned. The project was stopped.
Problem #1. Access to Qualified Domain Experts as Test Process Resources
Even though a digitalisation program normally consists of parallel projects for organizational changes, implementing new systems combined with end user training will still require access to the same qualified domain experts and end users as project resources.
On top of this, transformation must be done at a high pace and often within a limited timeframe.
The test process is often affected by this, because these experts must contribute in other parallel project tasks. Stakeholders and project managers usually fully agree that testing is important, but the resources allocated to the test process does not always reflect this.
Problem #2. Unclear Business Processes as Test Basis
Even if the business processes are documented, clarifying and simplifying them is important. Partly because all project participants and stakeholders must have a clear view of the functionality. This activity must involve domain experts from all business areas. In addition, end users, trainers, test resources, IT-operations and architects should also take some part in these activities.
What we did to Solve Problem #1 and #2 and Get The Project Back on Track
A new project plan, with documenting the business processes as the first milestone, was approved.
In addition to adjusting and transforming existing business processes to new technology and new user interfaces, the restarted project was also going to provide training of the end users. Even if all low-level testing was already approved during the first part of the project, we still planned for system testing and system integration testing as quality gates prior to starting acceptance testing.
The Test Strategy
The test strategy is based on 4 key principles which aims to give the domain experts the required support needed. Combining testing with training is important to deliver on time. Reporting to all stakeholders in a format understood at all levels are important for quick feedback.
4 key principles to successfully involving the business
By following these simple principles, and the new plan, the new project was soon on track. I could start designing a test framework based on this strategy. Most of the project team participated in the workshops whose aim was to deliver test basis for the system integration test. The documentation was done as BPMN. We did not spend time on writing test cases but just imported the documented process activities into the test tool. In parallel the technical team worked on the integrations and previously identified risk components.
The Domain experts then performed they’re own tests together as a team, to validate both the system and the processes. This test level also provided training to the domain experts in using the new interface.
Implementing and Executing Acceptance Testing
By now the business processes had to be made system specific. Each activity from the business processes were clearly documented step by step, ready for acceptance testing. The acceptance tests were then performed by representatives from all user groups and geographical locations.
The 5 primary activities from the re-started project plan.
- The green activities reside in the test plan and is the test managers responsibility.
- The orange activity belongs in the project plan and is managed by a process architect.
- The blue activities belong both in the test plan and in the training plan but are shared activities between the test manager and the training manager.
Documentation in Testing
The business processes must be visualised with reference to business roles, so that its clear who is going to use the system to do what. Allocating sufficient time and resources to this work is key to successfully clarifying the business processes and provide a baseline for the test process. The product of this activity is more than just documented and visualised business processes. In addition to making the business to agree on their own core business processes, it also provides basis for high level test cases for the test team to start planning and designing tests. Documentation in testing is not a popular topic but it is an important topic.
