🤖Test Design
Test design is a process that describes “how” testing should be done. It includes processes for the identifying test cases by enumerating steps of the defined test conditions. The testing techniques defined in test -- http://tryqa.com/
In short it focuses on the creation and execution of the test. It can be as simple as exploratory testing or a coverage base with test cases.
Two distinct ways of preparing and performing tests
Test approach are divided into two:
A group of test approach where it do not follow strict rules, instead testers rely based on their skills, intuition and experience of the test.
Pursued value: Requirements and Specifications
A structured approach to testing that aims to demonstrate a specific type of coverage by applying one or more test design techniques.
A structured way of detailing information from one level to another.
Pursued value = Requirements and Specifications
Base from the requirements and specifics, the Quality risk is identified. And with those two, the Test situations are identified. Given with Test situations, test cases and test data can be created. Test cases then be combined into scenarios and be written into test scripts(automated). The actual outcome then be compared to the expected outcomes.
Outcome possibilities:
If the outcomes match, this means the test has passed, the quality risk is covered, the requirement implemented and the stakeholders can be informed through the reports that this part of the pursued value seems to be achievable.
If the expected and actual outcomes do not match, this means the test failed and a quality risk has materialized, and the requirement is not yet implemented. Therefore, the stakeholders must be informed through the reports that this part of the pursued value is not yet achievable.
Reporting based on test results
Detailed reporting for the members of the DevOps team and their direct contacts.
Overview reporting for people that look upon the test object from a business perspective such as the product owner and users.
High-level reporting for the stakeholders that are more distant to the team's activities such as high-level managers.
It is wise to combine Experience and Coverage base testing when performing and preparing test.
When the quality risks are relatively low, testers may decide to mainly apply experience-based testing. Still, if the tester for example encounters a boundary value during exploratory testing, it is very wise to apply boundary value analysis on the spot and make a test for each boundary value.
On the other hand, when the quality risk level (or any other good reason) is such that coverage-based testing is the main approach, then some experience-based testing is still a good thing to do. For example, investigating unexpected outcomes, or giving an important stakeholder a chance to see for themselves that the system actually works (because nothing adds so much to confidence as seeing it with their own eyes).
Last updated