Artifacts of Testing

  1. Bug report

A defect (also known as a bug) is a discrepancy between the actual result of the program execution and the expected result. Defects are discovered at the stage of software (software) testing, when the tester compares the results of the program (component or design) with the expected result described in the requirements specification. So, as soon as we discover a bug, we need to document it in order to continue the life cycle of the defect (which we considered earlier). A document that describes a bug is called a bug report.

A bug report is a technical document that contains a complete description of a bug, including information about both the bug itself (short description, severity, priority, etc.) and the conditions under which the bug occurred. The bug report should contain correct, unified terminology that describes the user interface elements and the events of these elements that lead to the bug. In general, a bug report consists of:

Hat.

  • Short description (short description of the problem). 
  • Project (name of the current project). 
  • Application component (in which the defect occurred). 
  • Version (version of the build in which the bug was found). 
  • Severity (gradation of the degree of impact on the application of the bug). 
  • Priority (bug fix queue). 
  • Status (displays the status of the bug in its lifecycle). 
  • Author (author of the bug report). 
  • Assignment (who should fix the defect).

Environment

  • Operating system, bit depth, Service Pack, browser, version, etc. 

Description

  • Reproduction steps (description of the path that leads to the occurrence of the defect). 
  • The actual result (the result we arrive at after completing all the playback steps). 
  • Expected result (the result that be in accordance with the requirements).

Additions

  • Attached file (logs, screenshots, and other documents that may help reproduce the problem or solve it). 

Despite such a large number of bug report items, there are several main fields that must be present: 

  • Short description. The field in which you need to put the whole meaning of the entire bug report. Most often, in a short description, they briefly answer 3 questions: “Where?”, “What?”, “When?”.
  • Priority. The defect either completely stops the application from working, or only part of the functionality, or otherwise. 
  • Reproduction Steps. An accurate and understandable description of all the steps that lead to the appearance of a defect, taking into account all the necessary input data, etc. 
  • Actual result. 
  • Expected Result.
  1. Test Case

Test Case is a test artifact, the essence of which is to perform a certain number of actions and/or conditions necessary to test a certain functionality of the developed software system. 

The structure of this artifact is in the “trinity”: Action performed – Expected result – Actual result.

The test case consists of 3 parts:

  1. PreConditions – either a list of steps that bring the system under test into a state suitable for testing, or a list of checks for conditions that the system is already in the required state. 
  2. Test Case Description – a list of actions by which the main test of the functionality is carried out (after which the actual result is compared with the expected one). 
  3. PostConditions  – a list of actions that return the system to its original state.

The way of describing test cases and their structure can be different in each company or team: they have different depths of the description of the necessary actions and results, have different structural components. But, good structure and high usability of test case templates can greatly reduce the time of routine form filling and increase the efficiency of the team as a whole.

3. Checklist

Checklist – a set of ideas for testing, development, planning, and management. And also, this is a list of formalized test cases in a form convenient for conducting checks. Test cases in a checklist should not be dependent on each other. 

Must contain the following information:

  • idea of ​​checks; 
  • a set of input data; 
  • expected results; 
  • boolean mark about passing/failing the test case; 
  • boolean mark about the match/non-match of the actual and expected result for each test.

It may also contain the steps for conducting the check, data about the features of the environment, and other information necessary for carrying out the checks. The goal is to ensure that requirements are consistently covered by checks that are necessary and sufficient to conclude that the product conforms to them. The peculiarity is that checklists are composed of those test cases that are indicative of a specific requirement.

There are two types of checklists: special and universal. 

Special checklists are created and used for specific projects, so the items in such a checklist correspond to the specifics of the project. The tester, using a special checklist, checks the ability to perform a unique action provided for by the requirements. 

Universal checklists are suitable for testing projects of the same type. Verification according to the universal checklist is not tied to graphic elements or a specific implementation, but the very ability of the user to perform an action is checked. An abstract list of checks is compiled for the universal checklist. Universal checklists can be reused on projects of the same type.

4. Test Plan

Test Plan is a document that describes the entire scope of testing work, starting with a description of the objects being tested, a strategy, schedule, criteria for starting and ending testing, the equipment required in the process, special knowledge, and risk assessment with options for resolving them.

 A test plan is an important part of any well-organized testing process, as it contains all the necessary information that describes this process. But in most cases that we will have to deal with, the test plan will play a more formal role, but still, its presence has many advantages. For example:

  • Ability to prioritize testing tasks. 
  • Building a testing strategy agreed with the entire team. 
  • Ability to keep records of all required resources, both technical and human. 
  • Planning the use of resources for testing. 
  • Calculation of risks possible during testing. 

Depending on the specification of the described tasks, a test plan can have two levels of detail: a master test plan and a detailed test plan.

Detailed Test Plan contains test tasks for each team, for each release or iteration of the project. A detailed test plan is created either for the decomposed part of the project or for small projects. It may consist of: 

  • List of testing areas with priorities. 
  • Testing strategy. 
  • List of possible risks. 
  • List of required resources. 
  • Project implementation plan.

Master Test Plan is created either to organize the testing process between several teams that test one project, but have different tasks, or for a project that consists of many iterations that are connected by some common information, the repetition of which in each release takes too long. The master test plan includes: 

  • General information about the project (links to documentation, bug trackers, etc.) 
  • Provisions describing the testing process, the introduction of defects, etc. 
  • Criteria for product readiness for release.