Abstract: This blog post describes in detail how to perform remote integration testing in a home office team using the Accelerated Testing Package and MS Teams as a collaboration tool. It provides a field-tested guide on how to set up the process.
In the past project, in the middle of the testing phase, we as a team were forced by the lockdown into the necessity of continuing the tests from the home offices in remote collaboration. We made a virtue out of necessity and, using the Accelerated Testing package and MS Teams (which can certainly be used in place of other collaboration environments), set up an effective working environment for the team in which the tests could be continued with undiminished intensity in remote collaboration. With this approach, everyone was aware of what they needed to do at all times, and as the test manager, I had an overview of the status of the tests at each site at all times. We have successfully run through several test cycles with this approach.
Below you will find a description of how the whole thing can be set up simply and pragmatically. The following components play a central role:
- The Accelerated Testing Package (a detailed description of how to set this up can be found in the BLOG post 19 as well as in the corresponding video explanations on Loom and others)
- All relevant test scripts for a test cycle/site are stored in a central folder that can be accessed by all (i.e. Sharepoint).
- In addition, the testing status file is created once for each site, in which the test cycle at the respective site is monitored.
- The entire testing team including those involved in the defect resolution (i.e. Migration, Development, Basis etc.) is defined as one team in MS-Teams
- The following channels in the MS Teams team are important for the execution of the test:
- One channel per test cycle (and site, if applicable, if testing is site specific.
- A. the test control board (generated from the task list, a detailed description follows below) and B. a description of all essential procedures, master data to be used in the individual test cases and the like (detailed description follows below)
- One channel per defect solution team (i.e. Migration, Development, Basis etc.). Here it is sufficient to create a task list in the channel, in which the person responsible for the work area can create the buckets as it is best for him to manage.
- One channel per test cycle (and site, if applicable, if testing is site specific.
Finally, all testing and defect resolution tasks are managed centrally in MS Teams. And the testers and those involved in solving the defects can jump to the relevant test script at the click of a mouse, complete their test tasks, update the status and keep the workflow running by moving the test task or assigning a new person responsible. Test and project management thus have complete transparency over the status of the work at all times.
Setting up the test control board for a test cycle:
In the test cycle channel, a register is set up based on a task list:
For the operational handling of the test there is the TEST CONTROLBOARD :
Each test case has a task in the bucket of the responsible end-to-end process workstream (see examples RTO & PLG (instead of PTS) & OTC) – assigned bucket owners manage the test tasks; they are responsible for:
- Assigning start and due dates and ensuring that due dates are met by others within their workstreams
- Assigning the correct members of their workflow to perform testing for new tasks in their area
- Ensuring the quality of test documentation by randomly reviewing competing test scripts
The definition of e2e workstreams should be clearly defined – for example, the following system can be used (as also found in the Definitions tab in the BPML):
The following information is stored in the individual test item:
Fields to be maintained in the test tasks
Each e2e test case is managed in its own test item. Mandatory fields must always be filled in completely and correctly:
Assigned (next tester)- Bucket (current test workflow)
- Progress (not started, in progress, Completed)
- Start date
- Due date
- Annotations (link to xlsx test script)
- Label (indicating the current status)
Bucket owners are always responsible for the correctness
and completeness of the test scripts in their bucket – the
schedule is under the responsibility of the WS to whom the
e2e test case is assigned (as specified in the name)
Instructions and rules for the test procedure How-To:
Alternatively, the authorization problems can be managed in a separate channel in a task list in the same way as the migration.
A regular update in the test status.xlsx of the Accelrated Testing Package can be used to track in detail the test progress in the individual workstreams:
A regular update in the test status.xlsx of the Accelerated Testing Package can be used to track in detail the test progress in the individual workstreams:
From here, a mouse click on the affected cell can display and evaluate all rows cumulated in it of the test scripts involved and thus, for example, easily detect error accumulations and control prioritizations in the solution of bottlenecks.
TAB Test Preparation and Management
In another tab in the channel of the respective test, the basic information for the test is stored on the basis of a wiki, such as:
- The link to an Excel in which the master data to be used in the individual test cases are defined.
- A link to the test status monitoring file (this should be password protected by the test manager).
- A link to the path where the Testscripts are stored (you don’t really need this, because the Testscripts are linked in the Testtasks).
- The How-To instructions (see above)
If you want to set up your test environment according to the above description and have problems doing so, I can gladly support you (the effort on my part for this is max. 1 to 2 man-days) and also participate remotely in a corresponding kickoff meeting for testing to answer any questions the testers may have directly – if you wish to do so, feel free to contact me at .