CH04. L01. Test development process

Summary

This video script delves into the intricacies of the software testing process, emphasizing the importance of test analysis, design, and implementation. It introduces key concepts such as test conditions, traceability, and the significance of the expected result in test cases. The script also highlights the IEEE STD 829-1998 standard for test documentation and discusses the transition from manual to automated test procedures, including the creation of test scripts and execution schedules. The goal is to ensure comprehensive coverage and understanding of the testing terminology and process.

Takeaways

• 📑 The script discusses the completion of a fundamental test process video, adding terms to test analysis, design, and implementation stages.
• 🔍 In test analysis, the basis documentation is reviewed, and testable items or events are identified as test conditions, described in test cases, and linked to their sources through a traceability matrix.
• 🔗 The traceability process is crucial for tracking changes in requirements and ensuring all requirements are covered, with test conditions and cases linked to each other in a bidirectional traceability matrix.
• 📝 Test case design includes a test case document with components such as input values, execution preconditions, postconditions, and expected results, with a focus on the expected result to avoid defects remaining hidden.
• 📘 The 'Software Test Documentation' standard (IEEE STD 829-1998) is highlighted, emphasizing that test design specifications should contain test conditions and test case specifications.
• 🛠️ Test implementation involves preparing test cases and, if using a tool, converting the test procedure into a test script written in a programming language for automated execution.
• 📋 The sequence of test case execution is outlined in a test procedure specification and managed through a testcase execution schedule, influenced by factors like prioritization and dependencies.
• 📚 The script distinguishes between different 'specification' terms, such as 'test case specification' with its components, 'test design specification' containing test conditions and cases, and 'test procedure specification' detailing the execution sequence.
• 📝 Understanding the sequence and automation of test procedures is important, especially when transitioning from written steps to an automated form for tool execution.
• 🎯 The script aims to ensure comprehension of the terms related to the test process, including the sources of test conditions, the linking process of traceability, and the execution sequence in test procedures.
• 📁 The terms and concepts discussed in the script can be reviewed in a file named 'Test development process' for further study and reference.

Q & A

What is the purpose of the Tractability matrix in the test analysis phase?

The Tractability matrix is used to link test conditions with their sources in the test basis documentation. It is crucial for ensuring that any changes in the requirements directly affect the test conditions and for verifying that all requirements are covered.

Why is it important to define the expected results in a test case specification?

Defining the expected results is essential because if they are not clearly stated, errors may be overlooked as correct, allowing defects to remain hidden in the software.

What does the term 'test case specification' include according to the script?

A test case specification includes a set of input values, execution preconditions, execution post conditions, and the expected results that describe the test condition.

What is the IEEE STD 829-1998 standard and why is it important to remember?

The IEEE STD 829-1998 is the 'Software Test Documentation' standard that confirms test design specifications should contain test conditions and test case specifications. It's important to remember as it provides a framework for test documentation and may be referenced in professional discussions or assessments.

How does the script differentiate between 'test basis' and 'test conditions'?

The test basis refers to the sources from which testable items or events are derived, while test conditions are the specific items or events from the test basis that are written into one or more test cases.

What is the role of a 'test procedure' in the test execution phase?

A test procedure outlines the steps to be followed during the execution of test cases. It helps in determining the order or sequence of test execution.

Why might a test procedure be written in an automated form?

A test procedure is written in an automated form when the software is executed using a tool. This allows the steps to be clear for the tool and ensures the program runs correctly with successful execution.

What is a 'test script' and how does it relate to a test procedure?

A test script is the automated form of a test procedure, written in a programming language so that the steps are clear for the tool and the program can be executed successfully.

What factors control the order of test cases in the 'test case execution schedule'?

Factors controlling the order in the test case execution schedule include prioritization, regression tests, technical, and logical dependencies.

What is the significance of the 'test procedure specification' document mentioned in the script?

The test procedure specification document outlines the sequence of test cases and the desired test script during execution, which helps in organizing and planning the test execution process.

How does the script suggest reviewing the terms related to the test process?

The script suggests reviewing the terms in a file named 'Test development process' for a comprehensive understanding of the test process and its related terms.

Outlines

00:00

📚 Test Analysis and Design Overview

This paragraph introduces the completion of the Fundamental test process video from chapter 1, focusing on the addition of terms in the stages of test analysis, design, and implementation. It explains the importance of reviewing and analyzing test basis documentation, identifying test conditions, and linking them to their sources through a tractability matrix. The paragraph also emphasizes the significance of traceability in ensuring all requirements are covered and test conditions are accurately located. It outlines the components of a test case, including input values, preconditions, postconditions, and expected results, highlighting the importance of defining expected results to avoid hidden defects in software. The paragraph concludes with a reference to the 'Software Test Documentation' standard (IEEE STD 829-1998), which confirms the inclusion of test conditions and test case specifications in test design specifications.

05:01

🔍 Reviewing the Test Development Process

The second paragraph serves as a reminder for viewers to review the discussed concepts in a file named 'Test development process'. It suggests that revisiting the material will aid in reinforcing the understanding of the test analysis, design, and implementation stages, as well as the key terms and processes involved in software testing.

Keywords

💡Test Analysis

Test Analysis refers to the initial phase of the software testing process where the test basis documentation is reviewed and analyzed to identify testable items or events, termed as 'test conditions'. It is crucial for ensuring that all requirements are covered and forms the foundation for the subsequent design and implementation stages. In the script, it is mentioned as the first step where the test basis documentation is reviewed.

💡Test Conditions

Test Conditions are the specific items or events within the software that can be tested. They are derived from the test basis documentation and are described in one or more test cases. The script emphasizes the importance of linking these conditions to their sources, a process known as 'Tractability', to ensure that any changes in the requirements directly affect the test conditions.

💡Tractability Matrix

The Tractability Matrix is a tool used to link test conditions with their sources in the test basis documentation. It is highlighted in the script as essential for tracking changes in requirements and ensuring that all test conditions are covered, thereby maintaining the integrity of the testing process.

💡Test Cases

Test Cases are detailed descriptions of test scenarios, including the steps to execute and the expected results. They are derived from test conditions and are a critical component of the test design. The script mentions that test cases should be linked to their test conditions through the Tractability Matrix.

💡Traceability

Traceability is the process of linking test conditions to their sources in the test basis, ensuring that any changes in the source directly affect the associated test conditions. The script explains that this is important for maintaining the relevance of test conditions and for ensuring that all requirements are tested.

💡Test Case Specification

A Test Case Specification is a document that outlines the components of a test case, including input values, execution preconditions, postconditions, and expected results. The script emphasizes the importance of the expected result component, stating that it includes outputs, changes to data and states, and other consequences of the test.

💡Expected Results

Expected Results are the outcomes anticipated from executing a test case. They are a key part of the Test Case Specification and are crucial for identifying defects if the actual results do not match the expected ones. The script warns that undefined expected results can lead to errors being overlooked during testing.

💡Test Design Specification

The Test Design Specification is a document that contains the test conditions and the test cases, as per the 'Software Test Documentation' standard (IEEE STD 829-1998). The script mentions this as a key document that should be memorized for its importance in the testing process.

💡Test Procedure

A Test Procedure is a set of steps written in words that describe how to execute test cases. The script explains that when software is tested using a tool, the test procedure is written in an automated form, known as a 'Test Script', to ensure clear execution by the tool.

💡Test Script

A Test Script is an automated form of a Test Procedure, written in a programming language that the testing tool can understand and execute. The script mentions that this is used when the software is tested using a tool, as opposed to manual testing by a tester.

💡Test Procedure Specification

The Test Procedure Specification is a document that outlines the sequence of test cases to be followed during the execution of software testing. It is mentioned in the script as a document that includes the order of test execution, which can be influenced by factors such as prioritization and dependencies.

💡TestCase Execution Schedule

The TestCase Execution Schedule is a schedule that includes the sequence of test procedures and the desired test scripts during the execution. The script explains that this schedule is influenced by factors such as prioritization, regression tests, technical, and logical dependencies.

Highlights

Introduction to completing the Fundamental test process video in chapter 1.

Adding terms in test analysis, design, and implementation stages.

Review and analysis of test basis documentation in test analysis.

Identification of testable items or events called test conditions.

Describing test conditions in test cases with links to test basis.

Importance of Tractability matrix for linking test conditions to sources.

Traceability to ensure all requirements are covered and test conditions are determined.

Bi-directional traceability matrix for writing traceability information.

Components of a test case in the design stage - input values, preconditions, postconditions, expected results.

Focus on expected results to avoid defects remaining hidden in software.

IEEE STD 829-1998 standard confirming test design specifications include test conditions and test case specifications.

Test implementation and execution for test cases, following test procedures.

Writing test procedures in automated form as test scripts when using tools.

Test procedure specification document for the sequence of test cases during execution.

Test case execution schedule with factors like prioritization, regression tests, and dependencies.

Differentiating between terms with 'specification' as documents - test case specification, test design specification, test procedure specification.

Understanding the role of test basis as sources for testable items and events.

Linking test conditions with test basis called 'traceability'.

Sequence of test procedures during execution, written in automated form as test scripts.

Completion of the test process with all related terms reviewed.

Transcripts

This video can be considered a completion

for the Fundamental test

process video in chapter 1.

We will add some terms

in the stages of test analysis and design,

as well as the test implementation stage.

In chapter 1, in the test analysis

we reviewed and analyzed

the test basis documentation.

We checked each item or event that

could testable.

We called them the test conditions.

We described the test conditions

in one or more test cases.

Of course we need to link

the test conditions with their sources

which are test basis.

This linking process is

the Tractability, which we do through

the tractability matrix.

It is very important because

in the requirements, which is one of

test basis sources, any change

happens to it will affect directly the test

conditions. The second reason

is to ensure that all the requirements

were covered, and to determine

exactly where are the test conditions and

test cases, since they are all

linked to each other. we write

the traceability information in

the Bi-directional traceability matrix.

As for the design stage,

we describe the test case and test data.

Here, we will add

the components of a test case

or the test case specification,

which is the test case document.

They are as follows:

The set of input values,

The execution preconditions,

The execution post conditions

and finally The expected results,

which we write to describe

the test condition.

We should focus more on the expected

result which is a part of the test case

specification. It includes

Outputs, changes to data and states

and any other consequences of the test.

If the expected result haven't been

defined, the error can pass

as it is correct, therefore

the defects keep hidden in the software

and no one will find them.

that's why writing the ER must be

defined before the test case execution.

The Standards of

"Software Test Documentation" (IEEE STD 829-1998)

confirms that test design specifications

contain the test conditions

and Test case specification.

We should memorize

the number of this standards very well, as

you may be asked about it.

Now, we will move to the test

implementation and execution.

As we've learned, implementation

and development are both for the test cases.

while the test execution is for the test cases,

through following test procedure.

From which we can figure out the order

or the sequence of the test execution

used in the Test Cases.

If we will execute the test case

for the software using a tool,

and not manually by the tester,

Then test procedure

which is written in words,

and it is usually a description for steps,

will be written

in an automated form. i.e. It will be

written in the form of programming language.

so that the steps will be clear for

the tool, and to have the program running correctly

and with a successful execution.

So,when we write the test procedure

in an automated form, the name

became test script instead of test procedure.

Here, we can add that the sequence of

the test case in execution

will be put in a document called

test procedure specification.

The sequence of the test procedures

and the desired test script

during the execution are both added in

a schedule called

"the testcase execution schedule".

There are some factors controlling

the order in the schedule like:

prioritization ,

regression tests,

technical and logical dependencies.

By the end of this video,

we can ensure together that

we've reached the required targets

in this part.

The first Target is that we can differentiate between

the terms with the word "specification",

which all of them can be

considered as documents.

for the " test case specification ",

we knew its components, which

includes the expected result.

The " test design specification"

contains the test conditions

and the test cases, and this is according to

Software Test Documentation (IEEE STD 829-1998)

As for the "test procedure specification",

it includes the sequence of

test cases, that we will follow

during execution of the software.

The second target required from us,

is to compare and understand these terms.

The test basis are the sources

from which you can take items

and events that can be tested

or testable and we call them

test condition.

The test condition can be written

in one or more test cases.

Linking the test condition with the test basis

is called "traceability".

In the test procedures,there is

the sequence we will follow

during execution.

We will write the test procedures in

an automated form when software

is executed by using a tool.

Now, we've finished

the test process with all

the terms related to it.

You can review them again in a file under the name of

"Test development process".