In the next white paper of the series, I want to share our experience of introduction of the templates for the test request and test response as well as some improvements in the project communication process.
Senior Tester of Network Testing Team
For testers: get the product version for testing as soon as the build is ready; get all necessary information for testing together with the build.
For managers/developers: get all information concerning tested features state as soon as testing is finished.
How it was:
Developer built a version and sent an email to tester: the new version can be found by this file path. Or he just came and told tester: “I’ve built the new version, please check it”. Sometimes developers just forgot to inform testing team about the new version, or did not include any information concerning changes to the test request, thus making it much more difficult to plan testing properly.
Tester could not always get to know about the new version in time, so testing could start late.
Tester did not know what parts to test and how detailed this check should be, as he was not informed about the performed changes.
When developers did not include the list of the fixed bug reports to the test request, two problems appeared. The first was that developers could forget to change bug report status from “New” to “Please check”, false “New” bug reports were accumulated, and it caused some chaos. The second was that developers changed the bug report status to “Please check” right after they had added their fixes to the version control system. Usually, time period between start of the build and start of the testing is from 3 hours to a couple of days, so if testers did not have the list of bug reports to be checked in this build, some irrelevant “Please check” bug reports appeared: they were not included in the current build but were still considered as the testing targets.
Some additional time could be spent to find relevant product version if the link was not provided in time.
With such lack of the general information stream, managers and development leaders also were not able to get the complete picture of the project quality status, testing results, process and plans.
We formalized testing requests and responses.
All developers must send test request to the common project email list. In one of our projects, we use such template:
Subject: TESTING REQUEST - [Product name] – [Short description of performed changes] Body: Hi Team, The new build of the [Product name] is here: [Link to the built version location] Comments: [Developer comments – any information he wants to share with the tester] Testing type: [What testing scope should be (more detailed or less detailed)] Please, check such bug-reports: - [Bug-report #XXXXX] Title1 - [Bug-report #YYYYY] Title2 Impact analysis is attached/ Impact analysis is not required.
In other project, test request sending is a part of the automated build process. Request includes the link to the built version folder, bug reports list for this version, and Impact Analysis table. This test request is generated automatically without any developers’ activity required.
Test response also has a formalized template, which includes:
- Version number
- Tables with test execution statistics
- Checked bug reports lists
- Testing metrics
- QA specialist summary concerning product quality status.
All project team members get all necessary information in time.
Information processing speed increases.
Email templates are widely used, so we spend minimal time and efforts to write and read project emails.