OOAD Techniques - Testing

1. UNIT V
SOFTWARE QUALITY

2. Introduction
• To develop and deliver robust system, we need a
high level of confidence that
– Each component will behave correctly
– Collective behavior is correct
– No incorrect collective behavior will be produced
• Debugging and testing
• Quality assurance test, testing strategies, OO on
Software quality, test plan and test cases.

3. Quality Assurance Tests
• Reason why quality assurance is needed,
– Computers are infamous for doing what we tell
them to do, not necessarily what we want them to
do.
– To close this gap, code must be free of errors or
bugs that cause unexpected results

4. Debugging
• Software debugging system can provide tools
for finding errors in programs and correcting
them
• Different kinds of errors are
– Syntax errors
– Run‐Time errors
– Logic errors

5. Quality Assurance Tests
• Quality assurance testing can be divided into two
major categories
– Error based testing (testing the boundary condition)
– Scenario based testing (Usage‐based testing)
• Error based Testing
Search a given class’s method for particular clues
of interests, then describe how these clues should be
tested
• Scenario based Testing
Concentrates on what the user does, not what
the product does

6. Testing Strategies
• Extend of testing a system is controlled by
many factors, such as the risks involved,
limitations on resources and deadlines
• There are many test strategies, but most
testing uses a combination of them
– Black box testing
– White box testing
– Top‐Down testing
– Bottom‐Up testing

7. Testing Strategies
• Black Box Testing
– Used to represent a system whose inside
workings are not available for inspection.
– Test items are tested as “Black”, since its logic is
unknown, all that is known is what goes in and
what comes out, i.e. input and output
– Works nicely in testing objects in OO
environment

8. Testing Strategies
• Black Box Testing
Input Output

9. Testing Strategies
• White Box Testing
– Assumes that the specific logic is important and must be
tested to guarantee the system’s proper functioning.
– Main use is in error‐based testing, when we already have
tested all objects of an application and all external or
public methods of an object that are of greater importance
– One form of white box testing, called path testing, makes
certain that each path in a object’s method is executed at
least once during testing.

10. Testing Strategies
• Two types of path testing are
– Statement based testing
– Branch based testing

11. Testing Strategies
• Top‐Down Testing
– It assumes that the main logic or object
interactions and systems message of the
application need more testing than an individual
object’s method or supporting logic
– It can detect the design flows early in the
implementation
– It supports testing the user interface and event‐
driven systems

12. Testing Strategies
• Top‐Down Testing
– It can test the navigation through screens and
verify that it matches the requirement, users can
see, at an early stage, how the final application
will look and feel.
– Useful for Scenario‐based testing.
– Useful to test subsystem and system integration.

13. Testing Strategies
• Bottom‐Up testing
– Starts with the details of the system and proceeds to
higher levels by a progressive aggregation of details until
they collectively for the requirements for the system.
– This approach is more appropriate for testing the
individual object in a system.
– Test each object, combine them and test their interaction
and the message passed among object by utilizing the top‐
down approach.

14. Testing Strategies
• Bottom‐Up testing
– In bottom‐up, start with methods and classes
that call or rely on no others, then progress to
next level up. Those methods and classes that use
only the bottom level ones already tested
– It leads to integration testing which leads to
system testing

15. Test Cases
• To have a comprehensive testing scheme, the
test must cover all methods or a good
majority of them.
• All services of the system should be checked
atleast once.
• To test a system, given input and received
output checked with expected output

16. Test Cases
• The main objectives of testing are:
– Testing is the process of executing a program
with the intent of finding errors.
– A good test case is the one that has a high
probability of detecting an as‐yet undiscovered
error.

17. Guidelines for Developing
Quality Assurance Test
Cases
• A test case is a set of what‐if questions
• Thomas has developed guidelines that have been
adapted for the UA
– Describe which feature or service your test attempts to
cover
– If the test case is based on a use‐case, it is good idea to
refer to the use‐case name. Use‐cases are the source of
test cases.
– Specify what you are testing and which particular feature
– Test the normal use of the object’s methods.

18. Guidelines for Developing
Quality Assurance Test
Cases
– Test the abnormal but reasonable use of object’s
method.
– Test the boundary condition
– Test object’s interactions and message sent among
them
– The internal quality of the software, such as
reusability and extendibility should be assessed as
well.

19. Test Plan
• Test plan is developed to detect and identify
potential problems before delivering the
software to its users
• It provides the roadmap for testing activities,
whether usability, user satisfaction or quality
assurance tests.

20. Test Plan
• Steps needed to create a test plan:
– Objectives of the test
– Development of a test case
– Test analysis
• All passed tests should be reported with the
revised program called regression testing,
which can discover errors introduced during
the debugging process

21. Who should do testing?
• For a small application, the designer or the design team
usually will develop the test plan and test cases and in some
situations, actually will perform the tests.
• Many organizations have a separate team, such as a quality
assurance group, that works closely with the design team and
is responsible for these activities

22. Who should do testing?
• Most software companies also use beta testing a
popular inexpensive and effective way to test
software on a select group of the actual users of the
system
• In contrast, alpha testing is done by in‐house testers,
such as programmers, software engineering and
internal users.

23. Guidelines for
Developing Test Plans
• You may have requirements that dictate a
specific appearance or format for your test
plan.
• Test plan should contain a schedule and a list
of required resources
• After you have determined what types of
testing are necessary, you need to document
specifically what you are going to do

24. Guidelines for
Developing Test Plans
• A configuration control system provides a way
of tracking the changes to the code.
• A well thought out design tends to produce
better code and result in more complete
testing, so it is a good idea to buy to keep the
plan up to date.
• At the end of each month, take time to
complete routine updates.

25. Continuous Testing
• Software is tested to determine whether it conforms
to the specifications of requirements.
• Software is maintained when errors are found and
corrected and software is extended when new
functionality is added to an already existing program.
• There are different reasons for testing such as to test
for potential problems in a proposed design or to
compare two or more designs to determine which is
better, given a specific task or set of tasks

26. Continuous Testing
• Testing the whole system and detecting bugs
is more difficult than testing smaller pieces of
the application as it is being developed.
• Testing must take place on a continuous basis
and this refining cycle must continue through
out the development process until we are
satisfied with the results.

27. Continuous Testing
• The steps to successful testing:
– Understand and communicate the business case for
improved testing
– Develop an internal infrastructure to support continuous
testing.
– Look for leaders who will commit to and own the process
– Measures and document your findings in a defect
recording system
– Publicize improvements as they are made and let people
know what they are doing better

28. Debugging Principles
• Bug Locating Principle:
– Think
– If you reach an impasse, sleep on it.
– If the impasse remains, describe the problem to
someone else
– Use debugging tools
– Experimentation should be done as a last

29. Debugging Principles
• Debugging Principle:
– Where there is a one bug, there is likely to be
another
– Fix the error, not just the symptom of it
– The probability of the solution being correct
drops as the size of the program increases
– Because of the possibility that an error
correction will create a new error

30. Review Questions
• What is testing ? List out the different testing strategies.
• What is black box testing?
• When would you use white box testing?
• If you don’t know what is inside the box, how would you test it?
• What is the importance of developing a test case?
• What is white box testing?
• What is path testing?
• What is statement testing coverage?
• What is branch testing coverage?
• What is regression testing?
• What is a test plan? What steps are followed in developing a test plan?
• What is top‐down testing?
• What is bottom ‐up testing?
• What are guidelines for developing test plans?
• What do you mean by continuous testing?
• What are the Myer’s debugging principles?
• What is debugging?
• What is error based testing? Give an example.
• What is scenario ‐based testing?
• What are two types of path testing?
• Differentiate beta testing and alpha testing?
• What are the steps involved in successful testing?
• Define Unit Testing?

31. Bibiliography
• Object oriented system development by Ali
Brahami
• Object oriented methodology by Booch
• A text book on UML by Srimathi