Black Box Testing Techniques © Sheridan College SYST30009-Engineering Quality Software 4.

Lesson04Black Box Testing Techniques

© Sheridan CollegeSYST30009-Engineering Quality

Software

4

AgendaToday

o Software Testing perspectiveso Focus primarily on black box testing

• Black box test design techniques• Use case testing• Equivalence partitioning• Boundary Value Analysis• Decision table testing• State table testing

o Note Reference Materials • SLATE• Required reading

o Quiz No 1 - Today


Software2

SYST30009-Engineering Quality Software

3

Software errors, software faults and software failures.

© Sheridan College


4

Software errors, software faults and software failures.

Consider the following statements:o “We’ve used the Simplex HR software in our Human Resources

Dept. for about three years and we have never had a software failure.”

o “I started to use Simplex HR two months ago; we had so many failures that we are considering replacing the package.”

o “We have been using the same software package for almost four years. We were very satisfied throughout the period until the last few months, when we suddenly faced several severe failures. The Support Center of the software vendor from which we bought the package claims that they have never encountered failures of the type we experienced even though they serve about 700 customers who utilize Simplex HR.”

Why is it possible for such a variation in users’ experience with failure to appear with the same software package?

How can a software package that successfully served an organization for a long period “suddenly” change its nature (quality) and become “bugged”?

© Sheridan College


5

What’s the relationship between a software fault and a software failure?

Do all software faults end with software failures?o Example: The “Meteoro-X” meteorological

equipment firmware.• The software requirements for “Meteoro-X”

meteorological equipment firmware (software embedded in the product) were meant to block the equipment’s operation when it’s internal temperature rose above 60 degrees Celcius. A programmer error resulted in a software fault when the temperature limit was coded as 160 degrees. This fault could cause damage when the equipment was subjected to temperatures higher than 60 degrees. Because the equipment was used only in coastal areas where the temperature never exceeded 60 degrees, the software fault never turned into a software failure.

© Sheridan College


6

Causes of Software Errors(1)

Faulty definition of Requirements• Absence of vital requirements• Incomplete definition of requirements• Inclusion of unnecessary requirements

Client-Developer communication failures• Misunderstanding of the client’s instructions as stated in

the requirement document.• Misunderstanding of the client’s requirements changes

presented to the developer in written form during the development period.

• Misunderstanding of the client’s requirements changes presented to the developer orally during the development period.

• Misunderstanding of the client’s responses to the design problems presented by the developer.

• Lack of attention to client messages referring to requirements changes and to client responses to questions raised by the developer on the part of the developer.

© Sheridan College


7


Deliberate deviations from software requirements.o Developer re-uses software modules from another

project without sufficient analysis of the changes and adaptations needed to correctly fulfill all of the requirements.

o Due to time or budget pressures, the developer decides to omit part of the required functions to cope with these pressures.

o Developer-initiated, unapproved improvements to the software, introduced without the client’s approval, frequently disregard requirements that seem minor to the developer. Such minor changes may, eventually cause software errors.© Sheridan College


8


Logical Design Errorso Process definitions that contain sequencing errors.o Erroneous definitions of boundary conditions.

Coding Errors Non-compliance with documentation and coding

instructions.o Some team members not following standards

© Sheridan College


9


Shortcomings of the testing processo Incomplete test plans leave untreated portions of the

software.o Failure to document and report detected errors and

faults.o Failure to properly correct detected software faults as a

result of inappropriate indications of the reasons or the fault.

o Incomplete correction of detected errors due to negligence or time pressure.

© Sheridan College


10


User Interface and procedure errorso User procedures direct the user with respect to the

sequence of required activities of data collection and processing.

o Main reasons for these types of errors• Misunderstanding of the implementation process• Failure to communicate the detail of the solution steps

required to perform the application

Documentation errors

© Sheridan College

Software Testing

o Black Boxo White(Glass) Boxo Exploratory

• Experienced based


Software11

What is Black Box Testing

Consider this every day example…o A lock & key


Software12


Software13

Functionality of the lock

Functionality What you need to know to use

Features of a lock It is made of metal, has a hole provision to lock, has a facility to insert the key, and the keyhole ability to turn clockwise or anticlockwise.

Features of a key It is made of metal and created to fit into a particular lock’s keyhole.

Actions performed Key inserted and turned clockwise to lock.Key inserted and turned anticlockwise to unlock.

States Locked/Unlocked

Inputs Key turned clockwise or anticlockwise

Expected outcome Locking Unlocking

Black Box Testing

Black box testing requires a functional knowledge of the product to be tested.

• It does not mandate the knowledge of the internal logic of the system nor does it mandate the knowledge of the programming language used to build the product.

Tests are focused towards testing the features of the product (example: lock and key), the different states.

You may check if the lock works with some other key (other than its own).


Software14

Why Black Box Testing?

Black box testing is done based on requirements • It helps in identifying any incomplete, inconsistent requirement as well as any

issues involved when the system is tested as a complete entity.

Black box testing addresses the stated requirements as well as implied requirements

• Not all the requirements are stated explicitly, but are deemed implicit. For example, inclusion of dates, page header, and footer may not be explicitly stated in the report generation requirements specification. However, these would need to be included while providing the product to the customer to enable better readability and usability.

Black box testing encompasses the end user perspectives • Since we want to test the behaviour of a product from an external perspective, end-

user perspectives are an integral part of black box testing.

Black box testing handles valid and invalid inputs • It is natural for users to make errors while using a product. Hence, it is not sufficient

for black box testing to simply handle valid inputs. Testing from the end-user perspective includes testing for these error or invalid conditions. This ensures that the product behaves as expected in a valid situation and does not hang or crash when provided with an invalid input. These are called positive and negative test cases.

• The tester may or may not know the technology or the internal logic of the product. However, knowing the technology and the system internals helps in constructing test cases specific to the error-prone areas.

• Test scenarios can be generated as soon as the specifications are ready. Since requirements specifications are the major inputs for black box testing, test design can be started early in the cycle.


Software15

How to do Black Box Testing


Software16

There are several Black Box Test Design Techniques.

Typical black box test design techniques include:o Use case testing o Equivalence partitioning o Boundary value analysis o Decision table testing o State transition tables


Software17

Equivalence Partitioning & Boundary Value Analysis

Fancy terms for a simple idea For a given input value determine the set of valid

values and set of invalid ones. Pick a value from the valid set and the invalid set

to test. “bugs lurk in corners and congregate on

boundaries”-programmers often make mistakes on the boundaries of the valid and invalid sets and hence we have to focus testing at these boundaries.

This type of testing is called Boundary Value Analysis.


Software18

A simple example Consider how interest is calculated on a savings

account at the banko A balance in the range of $0 to $100 earns 3%o A balance over $100 and up to $1000 earns 5%o Balances over $1000 earn 7%

How would you test to verify that the right interest rate has been paid?


Software19

Summary

Boundary Value Analysis is based on testing at the boundaries between partitions-in other words range checking.

When we say invalid, it doesn’t mean that it represents a value that cannot be entered by a user or a value the user isn’t supposed to enter. It means that it is not one of the expected inputs for this particular field. The software should correctly handle values from this invalid partition (or set) by replying with an appropriate message.

Equivalence partitioning and boundary value analysis is a sampling strategy to cope with the problem of too many possible tests (the economics of testing).

Traditional domain analysis considers numeric input and output fields. Boundary analysis is optimized to expose a few types of errors such as

miscoding of boundaries or ambiguity in definition of the valid/invalid sets.


Software20

I-C-E-09-PART D & C


Software21

Black Box Testing Techniques © Sheridan College SYST30009-Engineering Quality Software 4.

Documents

Transcript of Black Box Testing Techniques © Sheridan College SYST30009-Engineering Quality Software 4.