Documentation in The Testing Process
Uploaded by
ScribdTranslationsDocumentation in The Testing Process
Uploaded by
ScribdTranslationsDOCUMENTATION IN THE TESTING PROCESS
In a software development project, there is a set of documents associated with each of the phases.
of the life cycle: planning, analysis, design, construction,... We can consider the testing process as
a project that is executed in parallel with the development and in which three major stages can be distinguished:
• Preparation of the tests.
• Execution of tests.
• Completion of the tests.
In each of these phases, it is necessary to generate the appropriate documentation, which can be complicated if not
it has a proper reference. To provide a standard basis for the documentation of the process of
testing created the IEEE 829 standard.
IEEE 829 proposes a series of documents that fit into the testing stages as follows:
• Preparation of the tests.
o Test plan.
o Test design specification.
o Test case specification.
o Specification of testing procedures.
o Test Item Transfer Report.
• Execution of the tests.
o Test log.
o Incident report.
• Completion of the tests.
o Summary test report.
Although the standard refers to different documents, in practice they do not have to be documents.
separated physicists. Even on many occasions, a large part of the information will not reside in documents, but in
tools aimed at supporting the testing process.
On the other hand, not all projects require the same level of formality in the documentation of the process.
Testing: surely a medical software project will not have the same documentary rigor as one about
the construction of a simple website. Other factors such as the company's culture and politics can influence
the formality of the documentation.
PREPARATION OF TESTS
The preparation phase of the tests is the one that requires the most documentation as it involves defining aspects
like the test schedule, what is to be tested, how it will be tested, on what test environment, etc.
The first step in documenting the testing process is the creation of the test plan.
Test plan
The test plan is the master plan that will guide the testing efforts of a project.
determined. A test plan must consider the following aspects:
Error: Reference source not found 1
• What elements and functionalities of the software product are going to be tested (and which ones are not), that is,
reaches the tests.
• Who will conduct the tests (assign responsibilities) and what resources are needed in terms of
people, software, hardware and training.
• The planning of testing tasks, with their dependencies, schedule, duration, ...
• The types of tests to be performed (component tests, integration tests, etc.) and the chosen techniques for
design the tests, as well as the level of coverage and the exit criteria. That is, the aspects
related to the locality of the tests.
• The main risks to consider, especially the circumstances under which it will stop or will
will restart the testing process.
Test Design Specification Document
The test design specification is the first step in the actual development of tests. This document
specify the characteristics and functionalities that you want to test of the software product (test conditions)
the test requirements) and their prioritization, as well as the success/failure criteria of the tests.
For example, in a user management module, the following could be test conditions: 'A user
a user can register in the system
The test design specification document helps to determine early on where to
they want to focus testing efforts in such a way that later energies are not wasted in creating cases of
test for elements that are not worth it.
Test Case Specification Document
Test conditions or requirements are often specified very vaguely. A test case performs a
more detailed specification indicating:
• The specific input data to be used (for example, 'run registration process with name
user 'juan' and password '123').
• What is the expected result after the execution of the test.
Other relevant elements that must be indicated in the test case document are:
• The preconditions that must be met before executing the test case. For example, 'The
User with the name 'juan' should not exist in the system.
• Interdependencies between test cases. For example, if there is a test case that successfully creates a
User with the name 'Juan' should be executed after the previous case so that the
preconditions of the first can be met.
Specification document of the testing procedures
This document specifies aspects such as:
• The detailed steps on how to execute each test and the order of execution.
• The exact configuration of the testing environment.
For example, a testing procedure could contain instructions such as the following:
• Step 1: Recreate the database by running the script "bbdd.sql".
• Step 2: Load users into the database using the script 'usuarios.sql'.
Error: Reference source not found 2
• Step 3: Access the URL http://pruebas/login
• Etc.
Report on the transmission of test elements
Behind this complicated name lies a document whose purpose is to describe the elements that
they are going to enter a testing phase. In this way, the testers can have the assurance that the
elements that are going to be tested are prepared and know where to locate them.
DOCUMENTATION DURING THE EXECUTION OF TESTS
During the execution of the tests, it is essential to know the status of the testing process, to know which tests
executed and which remain pending, what defects have been found, ... For this, the ...
test records and incident reports.
Test registration
A fundamental objective of the testing process is to provide information about the system being tested.
testing. The test log documents the aspects related to the execution of the tests: what tests have been
executed, who and when executed them, in what order, in what environment, whether the test has passed or failed. In
this document is also important, to associate the execution information of each test with versions
specific to the software under test to ensure traceability.
The information collected in the test registry allows us to understand the progress of the execution phase of
tests and make decisions about whether the software is ready to move on to the next phase.
Incident report
It is important to highlight the reference to the term "incident"; an incident does not necessarily have to be due to a
System defect. An incident represents a discrepancy between expected results and actual results.
obtained. This discrepancy may be due to several reasons, such as a defect, an error in the specification of
test cases, a misinterpretation of the requirements, etc.
The incident report must contain all the necessary information for the identification and resolution of the
used entries, expected results, obtained results, procedural step in which it
it has produced the incident, environment configuration, impact assessment,…
DOCUMENTATION FOR THE COMPLETION OF THE TESTS
Once the testing process is completed, enough information must be provided so that the
those involved in the project can know the results and make decisions.
Summary report of tests
The final test report is created at determined milestones of the project or upon completing a testing level.
determined. It allows communication of the obtained results to all stakeholders in order to decide whether the software
is ready to move on to the next phase.
This report provides information on the tests performed and the time taken, as well as
assessments regarding the quality of the testing process conducted, of the level of quality achieved in the product.
This final report can serve as a basis for planning future improvements in the testing process.
Reference source not found 3
CONCLUSION
The documentation of the testing process allows for capturing all key aspects of the tests. This
Documentation allows the testing group to perform their work better by knowing at all times the times,
the elements that need to be tested, how to conduct the tests, etc.
But the documentation is not only valid for the team responsible for building the software. When we perform
a software for a client, a fundamental objective is for the client to gain confidence in the system. The
Documentation generated as part of the testing process is a fundamental tool to win this.
trust.
The test plan and the design specifications and test cases can provide the client with a good
vision of what approach is used and the quality of the proposed tests.
The progress information obtained during the execution of the tests provides the client with visibility about
the degree of progress in the testing process and, more importantly, about the quality level of the product, at
to know information about the number of tests conducted, number of defects found, ...
In medium/large projects, the management of information related to the testing process through
simple documents can become very complicated. In these cases, using a tool is
fundamental. Aspects such as traceability or interdependencies between test cases can be
impossible to manage without the support of a tool.
NOTE: The currently valid version of the IEEE 829 standard is IEEE 829-2008 published in July 2008.