Artifacts required for testing

Disclaimer This article is not a claim to objectivity, but reflects only my personal opinion. I also ask you to pay attention to the fact that my opinion is not static and may change. The article is written only in order not to answer many times the same questions, but simply to give a link.

So, I’ll try to answer the question: what artifacts are needed to support the testing process (meaning they are developed by the tester himself).

I highlight several artifacts:

1. Test plan
2. Test case (Test-case)
3. Test script or test suite
* Set of test scripts for Smoke-test
* Acceptance Test Plan (PSI)
4. Description of defects
5. Testing Report
')
Defects description and testing report are not considered in this article, since these are already results and therefore I will write about them separately.

Test plan

There are at least two common understandings of this document:

1. A document describing who, what, when and how will be tested
2. A document describing all the necessary tests to verify the application.

Speaking about the test plan , I mean exactly the first interpretation.
To see an example of a test plan, you can:

* Take the book Robert Culbertson, Chris Brown, Gary Cobb. Quick testing
* Take RUP
* Google
* Wait until I set an example in one of the following articles.

Test script (test)

A test script is a description of the initial conditions, input data, user actions and the expected result.
Good practice - writing test cases based on use cases (Use cases).

The test scenario is like an atom the smallest part of the documents described below (but, like the atom, it can be divided into conditions, input data, steps, results)

Name options:

* Atomic test
* Test version
* Testing option
* Test case

Test Case Sets

These are test scripts grouped by a certain attribute (for example, the tested functionality). They can be either dependent on the execution sequence (the result of the previous one is a prerequisite for the next (Test script)) or independent (the Test suite).
The most frequently allocated sets are: A set of test scenarios for Smoke-test and a Plan for acceptance tests.

Set of test scripts for Smoke-test

To be honest, I do not know an adequate translation into Russian of this term. Sometimes the “Smoky Testing” translation is used, but it makes me stubbornly disgusted.

A set of test scripts for Smoke-test is a document that includes a set of specific test scripts covering the core functionality of an object or system. The purpose of the Smoke-test is to make sure that the key functions of the program work without going into details.

Good practice is taking a build into testing based on passing a Smoke-test. Also often as such a test use a daily assembly with the obligatory passage of unit tests.

Comment: A daily build without unit tests cannot be counted as a Smoke test. This is called: “Wow compilation”

Acceptance Test Plan (PSI)

A document that includes a set of specific test scenarios, after a positive passage of which the customer signs an acceptance certificate (transfer and acceptance).

In the general case, the test subsets look like in the figure.

Above, I listed those artifacts that I consider important for testing. But this does not mean that for any testing it is necessary to use all of them. And the details of each of the artifacts in each case may vary.
Crosspost from a personal blog