Software testing is like telling two parallel stories: a story of a particular web product and the story of the testing process.

Test framing is a basic skill that allows building, changing, telling, and confirming the story of testing logically, consistently, and quickly. Main objective of test framing is to try to link completely all the testing types with a specific testing mission.

Basic Elements of Test Framing

It is worth remembering that in any case connected with testing, there are the following aspects:

1. A mission to search for information (but it can significantly change in due course).
2. Information on initial requirements: sometimes it can be obvious, and sometimes it is quite the opposite. And it can change in the future as well.
3. Risks originally inherent in the testing mission. Information about the risks and their main priorities can change (and it will).
4. Information on what can bring value to particular software and what threats can prevent this. These values will be improved during testing.
5. A certain context that you’re working on. It will also change in the future.
6. Oracles – special mechanisms, principles, and strategies which help to detect bugs. You can improve these oracles or find some new ones.
7. Particular product models that need to be covered. You will refine them during testing as well.
8. Specified procedures to be followed. From time to time, you can fully implement them.
9. Skills and heuristics that you may apply. Such heuristics will be developed during a test run.
10.  Situations connected with the balance of cost/value of the activity expended during software testing.
11. A test suite to be performed. These tests are usually fewer than those you would like to conduct. Anyway, you choose your tests from numerous valid checks.
12. Time to perform all the tests. The time allotted for tests, as usual, is extremely limited. Especially if we compare it with the required time for tests you would like to perform. Allotted time for tests asymptotically tends to zero in regards to the time needed to perform all possible tests.

A real test framing is a certain ability, under any circumstances and at any time, to follow only straight logic that allows connecting missions with tests and documenting this logic. Such a line of reasoning, as a rule, touches on all the elements from the list above.

Objectives of Test Framing

The primary purpose of test framing is to provide clear, reasonable, and accessible answers to questions like the following:

• Why run these particular tests?
• Why perform one or another test right now?
• For what do we test an X requirement but not a Y one?
• How to test the X requirement correctly?
• How is the configuration used in tests connected with the configuration of real software?
• In what way do test results relate to the initial content of the test design?
• What risks are connected with tests?
• How do tests differ from each other?
• Does QA have enough competence to perform certain tests?
• Where was the problem and did a tester know about it in the first place?

The Form of Test Framing

In the context of the form of test framing, we would like to notice that this is a logical line of conformations that allows connecting a test with a mission touching on all the test objects listed above.

A proposition is a simple statement that fully expresses the concept of a test. It can be both false and true. Usually, inside test framing, specialists use propositions in the form of affirmations or suggestions. Sometimes, propositions may be used as a basis for possible hypotheses that need to be thoroughly tested or completely falsified.

Connections are phrases and words that can link or relate some propositions generating new ones by indirections. Examples can include “and”, “not”, “if”, “unless” and so on. A language that is used in test framing shouldn’t always be strictly formal. The main requirements are maximum heuristic and fairly correct structure.

[highlight dark=”no”]If users have tests outside the test framing, it needs to be changed.[/highlight] You may not do it with some test right away, and that’s ok. Why is it so? That’s because as a user performs a test, he/she not only applies data but also finds it.

Therefore, it is a good idea to alternate between concentration and defocusing. After you thoroughly perform some well-formed tests, you have to implement those checks that you cannot frame right away.

In Conclusion

Experience has shown that many testers need help in some aspects of test framing – test development, evaluation of results, telling the story of testing, or establishing a link between test mission and performed test. If a QA specialist understands and correctly uses all this in practice, he/she can provide the proper quality of any software.