CHAPTER 5

Design and Testing

1
 System Use Case Modeling
• Composed of use case diagrams and documentation describing the use
cases, actors and associations
• Describes a sequence of actions that provide a measurable value to an actor
and is drawn as a horizontal ellipse
• An actor is a person, organization or external system that plays a role in one
or more interactions with your systems
– Drawn as stick figures
• Associations between actors and classes are indicated in use case diagrams, a
relationship exists whenever an actor is involved with an interaction
described by a use case
– Exist between use cases
– Depicted as a line (arrows are optional)
• System Boundary Box – Rectangle around the use cases

• Example of use case diagram

 Sequence Diagrams
• Used to model the logic of usage scenarios
• A description of a potential way your system is used
• One entire path through a use case
• Model the flow of logic within your system in a visual manner
• The boxes across the top of the diagram represent classifiers or
their instances, typically uses cases, objects, classes or actors
• Because you can send messages to both objects and classes,
objects respond to messages through the invocation of an
operation, and classes do so through the invocation of static
operations, it makes sense to include both on sequence
diagrams
• Because actors initiate and take an active part in usage
scenarios, they are also included in sequence diagrams
 How to draw sequence diagrams
• Identify the scope of the sequence diagram
• List the use case steps down the left hand side
• Introduce boxes for each actor
• Introduce controller classes
• Introduce a box for each major UI element
• Introduce a box for each included use case
• Identify appropriate messages for each use case step
• Add a method – invocation box for each invocation of a method
• Add destruction messages where appropriate
• Add your business classes and objects
• Update your class model
• Update your user interface model
• Update your use case model
 Component Modeling
• OO is a preferred foundation from which to build components
• UML includes a component diagrams that can be used to
analyze and design your component based software
• Components are modeled as rectangles with two smaller
rectangles jutting out from the left hand side
• Implement one or more interfaces, modeled using the same
“lollipop” notion that UML class diagrams use
• Components have dependencies on the interfaces of other
components, modeled using the standard UML dependency
notation
 Faciliities

Security
Seminar <<infrastructure>>
Management
<<application>> Student

Persistence
<<infrastructure>>
Seminar

Student
Administration
<<application>>
University DB
Schedule <<infrastructure>>
9
Definition

Software Testing is a process of analyzing a

software item to detect the differences
between existing and required conditions
(i.e., defects) and to evaluate the features of
the software item.

10
Software Testing Types
Manual Testing:
 Manual testing is the process of testing software by hand
to learn more about it, to find what is and isn’t working.
 This usually includes verifying all the features specified
in requirements documents.
Automation Testing:
 Automation testing is the process of testing the software
using an automation tool to find the defects.
 In this process, testers execute the test scripts and
generate the test results automatically by using
automation tools. 11
Testing Methods
1. Static Testing
2. Dynamic Testing
Static Testing:
 It is also known as Verification in Software Testing.
 Verification is a static method of checking documents
and files.
 Verification is the process, to ensure that whether we are
building the product right.

12
Cont’d
Dynamic Testing:
 It is also known as Validation in Software Testing.
 Validation is a dynamic process of testing the real
product.
 Validation is the process, whether we are building the
right product.

13
Testing Approaches
There are three types of software testing approaches.

I. White Box Testing

II. Black Box Testing
III. Grey Box Testing
I. White Box Testing:
 It is also called as Glass Box, Clear Box, Structural
Testing.
 White Box Testing is based on applications internal code
structure.
 In white-box testing, an internal perspective of the
system, as well as programming skills, are used to design
test cases.
 This testing is usually done at the unit level. 14
Cont’d
II. Black Box Testing:
 It is also called as Behavioural/Specification-Based/Input-
Output Testing.
 Black Box Testing is a software testing method in which
testers evaluate the functionality of the software under
test without looking at the internal code structure.

III. Grey Box Testing:

 Grey box is the combination of both White Box and
Black Box Testing.
 The tester who works on this type of testing needs to have
access to design documents.
 This helps to create better test cases in this process.
15
Testing Levels
 There are four levels of software testing
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
1. Unit Testing:
 Unit Testing is done to check whether the individual
modules of the source code are working properly.
 i.e. testing each and every unit of the application
separately by the developer in the developer’s
environment.

16
Cont’d

2. Integration Testing:
 Integration Testing is the process of testing the
connectivity or data transfer between a couple of unit
tested modules.
 It is subdivided into
 Top-Down Approach,
 Bottom-Up Approach and,
 Sandwich Approach (Combination of Top Down and
Bottom Up).

17
Cont’d
3. System Testing (end to end testing):
 It’s a black box testing.
 Testing the fully integrated application this is also called
as end to end scenario testing.
 To ensure that the software works in all intended target
systems.
 Verify thorough testing of every input in the application
to check for desired outputs.
Note:
o This level of testing uses also to test the users experiences
with the application.

18
Cont’d
4. Acceptance Testing:
 To obtain customer sign-off so that software can be
delivered and payments received.
 Types of Acceptance Testing are Alpha, Beta & Gamma
Testing.

19
Difference Between Alpha, Beta, and Gamma Testing
Alpha Beta Gama

Why? Validate all software in Get end user’s Check the software
all perspective, ensure feedback, ensure readiness to the
readiness for beta readiness for release specified requirements
testing
When? At the end of After alpha testing After beta testing
development process

Who? In-house development A group of real end Limited number of end

or QA team, customer users users

What Get? Blockers, missing Idea to improve Ideas for update in up

features and others. usability, compatibility, coming version
functionality
What Next? Beta testing Gama testing Final release

20
The End of Chapter 5

21