The software testing basics of Test Implementation and Test Execution are key tools in the arsenal of a Test Manager and should be used each according to each test level. Proper Test Implementation and Test Execution will make the difference in quality for any product or project.
Software Test Implementation
Test Implementation Is the process of developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts. This is when tests are organized and prioritized and when test designs are implemented as test cases, test procedures and test data.
It is of great importance to pick the right tests and run them in the right order. The importance of this even grows exponentially in risk-based strategies when we prioritize based on the likelihood of risk and problems.
At this stage, the Test Manager should ensure:
- delivery of test environment
- delivery of test data
- constraints, risks and priorities are checked
- test team is ready for execution
- entry criteria is checked (explicit/implicit)
Some organizations may follow the IEEE829 standard to define inputs and their associated expected results during testing. Other only have rigorous rules when they need to provide evidence of compliance for regulatory projects or for adherence to standards.
In the most common cases, the test inputs are usually documented together with expected results, test steps and stored test data.
Just like test conditions and test cases, even during test implementation we will face the decision to go into an extensive (detailed) stage or to have a light (generic) approach. This decision should be taken by your understanding of the development life cycle and by the predictability of software features under test.
Please do not count off the extensive implementation preparation due to the above:
- Concrete test cases provide working examples of how the software behaves
- When tests are archived for long term and re-use in regression these details may become valuable
- Domain experts are likely to verify versus a concrete test rather than an abstract business rule
- Further weakness in software specification is identified
Some defects can be found only in production-like test environments. These are often expensive to procure and difficult to configure and manage. Similar challenges are also faced for the use of production data or production like data which can even lead to data privacy or other headaches.
Test implementation is not all about manual software testing, this is the stage where automated software testing scripting takes place, the stage where automation versus manual prioritization and execution order is established. And I am not talking only about software testing automation, even software testing tool acquisition is done here, especially for test data generation required to prepare for load, volume or performance testing.
Software Test Execution
Test execution is the software testing process of running a test on the component or system under test, producing actual result.
Should finish before execution starts
- Tests are designed or at least defined
- Tools are in place for test management and defect management and test automation (if applicable)
- Standards for test logging and defect reporting are published
Test execution begins once
- The test object is delivered
- The Entry criteria for test execution is met
During execution, a Test Managers role is to:
- Monitor progress according to the plan
- Initiate and carry out control actions to guide testing
- Ensure that test logs provide an adequate record of relevant details for tests and events
During execution it is important to keep a trace ability between test conditions, the test basis and the test objective and to have the appropriate level of test logging.
Time should be reserved for experienced-based and defect-based test sessions driven by tester’s findings.
In case you skipped Test analysis and Test design, just check it out as it builds the first step before test implementation and software testing execution.
This article is based on the ISTQB Advanced Syllabus version 2012 and it also references the ISTQB Foundation Syllabus version 2018. It uses terminology definitions from the ISTQB Glossary version 3.2.
