Interview Preparation -Software Engineering
Testing Overview and Black-Box Testing Techniques
Software testing is an important technique for assessing the quality of a software product.
In this chapter, we will explain the following:
• the basics of software testing, a verification and validation practice, throughout
the entire software development lifecycle
• the two basic techniques of software testing, black-box testing and white-box
testing
• six types of testing that involve both black- and white-box techniques.
• strategies for writing fewer test cases and still finding as many faults as possible
• using a template for writing repeatable, defined test cases
1 Introduction to Testing
Software testing is the process of analyzing a software item to detect the differences
between existing and required conditions (that is, bugs) and to evaluate the features of
the software item [9, 12]. Software testing is an activity that should be done throughout
the whole development process [3].
Software testing is one of the “verification and validation,” or V&V, software practices.
Some other V&V practices, such as inspections and pair programming, will be discussed
throughout this book. Verification (the first V) is the process of evaluating a system or
component to determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase [11]. Verification activities include testing
and reviews. For example, in the software for the Monopoly game, we can verify that
two players cannot own the same house. Validation is the process of evaluating a system
or component during or at the end of the development process to determine whether it
satisfies specified requirements [11]. At the end of development validation (the second V)
activities are used to evaluate whether the features that have been built into the software
satisfy the customer requirements and are traceable to customer requirements. For
example, we validate that when a player lands on “Free Parking,” they get all the money
that was collected. Boehm [4] has informally defined verification and validation as
follows:
Verification: Are we building the product right?
Through verification, we make sure the product behaves the way we want it to. For
example, on the left in Figure 1, there was a problem because the specification said that
players should collect $200 if they land on or pass Go. Apparently a programmer
implemented this requirement as if the player had to pass Go to collect. A test case in
which the player landed on Go revealed this error.
Validation: Are we building the right product?
Through validation, we check to make sure that somewhere in the process a mistake
hasn’t been made such that the product build is not what the customer asked for;
validation always involves comparison against requirements. For example, on the right
in Figure 1, the customer specified requirements for the Monopoly game – but the
programmer delivered the game of Life. Maybe the programmer thought he or she“knew better” than the customer that the game of Life was more fun than Monopoly and
wanted to “delight” the customer with something more fun than the specifications stated.
This example may seem exaggerated – but as programmers we can miss the mark by that
much if we don’t listen well enough or don’t pay attention to details – or if we second
guess what the customer says and think we know better how to solve the customer’s
problems.
Testing Overview and Black-Box Testing Techniques
Software testing is an important technique for assessing the quality of a software product.
In this chapter, we will explain the following:
• the basics of software testing, a verification and validation practice, throughout
the entire software development lifecycle
• the two basic techniques of software testing, black-box testing and white-box
testing
• six types of testing that involve both black- and white-box techniques.
• strategies for writing fewer test cases and still finding as many faults as possible
• using a template for writing repeatable, defined test cases
1 Introduction to Testing
Software testing is the process of analyzing a software item to detect the differences
between existing and required conditions (that is, bugs) and to evaluate the features of
the software item [9, 12]. Software testing is an activity that should be done throughout
the whole development process [3].
Software testing is one of the “verification and validation,” or V&V, software practices.
Some other V&V practices, such as inspections and pair programming, will be discussed
throughout this book. Verification (the first V) is the process of evaluating a system or
component to determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase [11]. Verification activities include testing
and reviews. For example, in the software for the Monopoly game, we can verify that
two players cannot own the same house. Validation is the process of evaluating a system
or component during or at the end of the development process to determine whether it
satisfies specified requirements [11]. At the end of development validation (the second V)
activities are used to evaluate whether the features that have been built into the software
satisfy the customer requirements and are traceable to customer requirements. For
example, we validate that when a player lands on “Free Parking,” they get all the money
that was collected. Boehm [4] has informally defined verification and validation as
follows:
Verification: Are we building the product right?
Through verification, we make sure the product behaves the way we want it to. For
example, on the left in Figure 1, there was a problem because the specification said that
players should collect $200 if they land on or pass Go. Apparently a programmer
implemented this requirement as if the player had to pass Go to collect. A test case in
which the player landed on Go revealed this error.
Validation: Are we building the right product?
Through validation, we check to make sure that somewhere in the process a mistake
hasn’t been made such that the product build is not what the customer asked for;
validation always involves comparison against requirements. For example, on the right
in Figure 1, the customer specified requirements for the Monopoly game – but the
programmer delivered the game of Life. Maybe the programmer thought he or she“knew better” than the customer that the game of Life was more fun than Monopoly and
wanted to “delight” the customer with something more fun than the specifications stated.
This example may seem exaggerated – but as programmers we can miss the mark by that
much if we don’t listen well enough or don’t pay attention to details – or if we second
guess what the customer says and think we know better how to solve the customer’s
problems.
Posts
0 comments:
Post a Comment