UNIT V TESTING

Object Oriented Methodologies – Software Quality Assurance – Impact of object orientation on Testing –
Develop Test Cases and Test Plans

1:OBJECT ORIENTED METHODOLOGY

OMT (Object Modelling Technique) was one of the first OO methodologies and was introduced by
Rumbaugh in 1991

 It is a new system development approach, encouraging and facilitating re-use of software

components.
 It employs international standard Unified Modeling Language (UML) from the Object Management
Group (OMG).
 Using this methodology, a system can be developed on a component basis, which enables the
effective re-use of existing components, it facilitates the sharing of its other system components.
 Object Oriented Methodology asks the analyst to determine what the objects of the system are?, What
responsibilities and relationships an object has to do with the other objects? and How they behave
over time?
OMT – An Overview

The basic steps of system designing using OOM may be listed as:
 System Analysis
 System Design
 Object Design
 Implementation

popular object oriented methodologies are:

 Booch Methodology [1994]: He developed the Object Oriented Analysis and Object
Oriented Design (OOA/OOD) concepts.
 RDD Methodology [1990]: Wirfs-Brock, Wilkerson, and Wiener developed Responsibility
Driven Design (RDD) methodology.
 OMT methodology [1991]: James Rumbaugh led a team at research labs of General Electric
to develop the Object Modeling Technique (OMT).
 OOSE [1994]: Ivar Jacobson developed the Object Oriented Software Engineering (OOSE)

1
Rumbaugh’s Object Modeling Technique (OMT)

 A method for analysis, design and implementation by an object oriented technique.

 fast and intuitive approach for identifying and modeling all objects making up a system.
 Class attributes, methods, inheritance and association can be expressed easily.
 Dynamic behavior of objects can be described using the OMT dynamic model.
 Detailed specification of state transitions and their-descriptions within a system

Four phases of OMT (can be performed iteratively) :

1. Analysis: objects,dynamic and functional models
2. System Design: Basic architecture of the system.
3. Object Design: static, dynamic and functional models of objects.
4. Implementation: reusable, extendible and robust code.

There are three types of Object Oriented Methodologies

1. Object Modeling Techniques (OMT)
2. Object Process Methodology (OPM)
3. Rational Unified Process (RUP)

Three parts of OMT – Modeling:

1.The Object Model (OM):–object model & data dictionary.

It depicts the object classes and their relationships (together with their associated attributes and operations) as
a Class Diagram, which represents the static structure of the system.

OMT object model for bank system

2.The Dynamic Model (DM):–state diagrams & event flow diagrams.

It captures the behaviour of the system over time and the flow of control and events in Event-Trace
Diagramsand State Transition Diagrams (State Charts)

2
 state transition diagram for Bank application user interface.

3.The Functional Model (FM): – data flow & constraints.

A hierarchical set of Data Flow Diagrams (DFD) that describe internal processes independently from how
these processes are performed.

3
Object Modeling Techniques (OMT)
 It was one of the first object oriented methodologies and was introduced by Rumbaugh in 1991.
 OMT uses three different models that are combined in a way that is analogous to the older structured
methodologies.
OMT - Object Design:
 Object design specifies all of the details needed to describe how the system will be
implemented
 All of the classes, associations, attributes and operations are fully defined, together with the
operations and data structures and any internal objects needed for implementation.
OMT - System Design:
The system design phase deals with the high-level structure of the system
e.g:–
 Identify global resources
 Organize the system into subsystems
 Identify boundary conditions
 Identify concurrency
 Allocate subsystems and tasks
 Establish trade-off priorities
 Choose a strategy for implementing data stores
 Choose a strategy for implementing software controls

a. Analysis
 The main goal of the analysis is to build models of the world.
 The requirements of the users, developers and managers provide the information needed to develop
the initial problem statement.

2. Object Process Methodology (OPM)

 It is also called as second generation methodology.
 It was first introduced in 1995.
 It has only one diagram that is the Object Process Diagram (OPD) which is used for modeling the
structure, function and behavior of the system.
 It has a strong emphasis on modeling but has a weaker emphasis on process.
 OPM has only one diagram the Object Process Diagram (OPD) for modelling the structure, function
and behaviour of the system.
 Every OPD can be described in text form using the Object Process Language (OPL) a constrained
natural language.

 It consists of three main processes:
I. Initiating: It determines high level requirements, the scope of the system and the resources that will be
required.

II. Developing: It involves the detailed analysis, design and implementation of the system.

III. Deploying: It introduces the system to the user and subsequent maintenance of the system.

3. Rational Unified Process (RUP)

 It was developed in Rational Corporation in 1998.

4
 It consists of four phases which can be broken down into iterations.
1.Inception
2.Elaboration
3.Construction
4.Transition
 Each iteration consists of nine work areas called disciplines.
 A discipline depends on the phase in which the iteration is taking place.
 For each discipline, RUP defines a set of artefacts (work products), activities (work undertaken on the
artefacts) and roles (the responsibilities of the members of the development team).

Objectives of Object Oriented Methodologies

 To encourage greater re-use.
 To produce a more detailed specification of system constraints.
 To have fewer problems with validation (Are we building the right product?).

Benefits of Object Oriented Methodologies

1. It represents the problem domain, because it is easier to produce and understand designs.

2. It allows changes more easily.

3. It provides nice structures for thinking, abstracting and leads to modular design.

4. Simplicity:
The software object's model complexity is reduced and the program structure is very clear.

5. Reusability:
 It is a desired goal of all development process.
 It contains both data and functions which act on data.
 It makes easy to reuse the code in a new system.
 Messages provide a predefined interface to an object's data and functionality.

6. Increased Quality:
 This feature increases in quality is largely a by-product of this program reuse.
7. Maintainable:
 The OOP method makes code more maintainable.
 The objects can be maintained separately, making locating and fixing problems easier.
8. Scalable:
 The object oriented applications are more scalable than structured approach.
 It makes easy to replace the old and aging code with faster algorithms and newer technology.
9. Modularity:
 The OOD systems are easier to modify.
 It can be altered in fundamental ways without ever breaking up since changes are neatly encapsulated.

10. Modifiability:
 It is easy to make minor changes in the data representation or the procedures in an object oriented
program.

11. Client/Server Architecture:

 It involves the transmission of messages back and forth over a network.

5
The Booch Methodology
 Widely used OO method
 Uses the object
 paradigm Covers the design and analysis phase of an OO system
 Criticized for his large set of symbols
Diagrams of Booch method
 Class diagrams- describe roles and responsibilities of objects
 Object diagrams- describe the desired behavior of the system in terms of scenarios
 State transition diagrams -state of a class based on a stimulus
 Module diagrams -to map out where each class & object should be declared
 Process diagrams -to determine to which processor to allocate a process
 Interaction diagrams -describes behavior of the system in terms of scenarios
Booch method prescribes:
 Macro Development Process
 Micro Development Process

Macro Development Process

 Controlling framework for the micro process.

 Primary concern-technical management of the system.

Steps for macro developmentprocess:

1. Conceptualization
2. Analysis & Development of the model
3. Design or create the system architecture
4. Evolution or implementation
5. Maintenance

Object modeling using Booch notation. The arrowsrepresent specialization;

for example, class Taurus is subclass of the class Ford.

6
An alarm class state transition diagram with Boochnotation. This diagram can capture the state of a
classbased on a stimulus. For example, a stimulus causes theclass to perform some processing, followed by
atransition to another state. In this case, the alarmsilenced state can be changed to alarm sounding stateand
vice versa.

Micro Development Process

Each macro process has its own micro development process
Steps:-
1. Identify classes & objects
2. Identify class & objects semantics
3. Identify class & object relationship
4. Identify class & objects interface and implementation

JACOBSON METHODOLOGIES
 Use Cases.
 Object Oriented Software Engineering.
 Object Oriented Business Engineering.

Use Cases
 Understanding system requirements
 Interaction between Users and Systems

The use case description must contain

 How and when the use case begins and ends.
 The Interaction between the use case and its actors, including when the interaction occurs and what is
exchanged.
 How and when the use case will need data stored in the system.
 Exception to the flow of events
 How and when concepts of the problem domain are handled.

7
Some uses of a library. As you can see, these are externalviews of the library system from the actor such as
amember. The simpler the use case, the more effective itwill be. It is unwise to capture all of the details right
atthe start;

OOSE
Object Oriented Software Engineering.
Objectory is built around several different models:
1. Use case model- The use-case model defines the outside (actors) and inside (use case) of the
systems behavior.
2. Domain object model- The objects of the “real” world are mapped into the domain object model.
3. Analysis object model- The analysis object model presents how the source code (implementation)
should be carried out and written.
4. Implementation model- The implementation model represents the implementation of the system.
5. Test model -The test model constitutes the test plans, specifications, and reports.

The use case model is considered for every model and phase.

OOBE
Object Oriented Business Engineering .OOBE is object modeling at the enterprise level.
 Analysis phase
 Design and Implementation phase
 Testing phase
E.g. Unit testing, integration and system testing.
Why modeling
 Blue print
 Clarity
 Familiarity
 Maintenance
 Simplification
Advantages of modeling
 Easy to express complex ideas
 Reduce complexity
 Enhance & reinforce learning and training
 Low cost
 Easy to change the model
8
2:SOFTWARE QUALITY ASSURANCE:
 Software quality assurance (SQA) is a process which assures that all software engineering processes,
methods, activities and work items are monitored and comply against the defined standards. SQA
incorporates all software development processes starting from defining requirements to coding until
release.
 It is a set of activities for ensuring quality in software engineering processes. It ensures that developed
software meets and complies with the defined or standardized quality specifications. SQA is an
ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the
developed software to ensure it meets the desired quality measures.
 SQA practices are implemented in most types of software development, regardless of the underlying
software development model being used. SQA incorporates and implements software testing
methodologies to test the software. Rather than checking for quality after completion, SQA processes
test for quality in each phase of development, until the software is complete. With SQA, the software
development process moves into the next phase only once the current/previous phase complies with
the required quality standards.
 SQA generally works on one or more industry standards that help in building software quality
guidelines and implementation strategies.
 It is simply a way to assure quality in the software. It is the set of activities which ensure processes,
procedures as well as standards suitable for the project and implemented correctly.
 Software Quality Assurance is a process which works parallel to development of a software. It
focuses on improving the process of development of software so that problems can be prevented
before they become a major issue. Software Quality Assurance is a kind of an Umbrella activity that
is applied throughout the software process.

software Quality Assurance is the set of activities which ensure that the standards, processes and
procedures are suitable for the project and implemented correctly. It defines the fitness for use of the
total software product”. A good quality software does exactly what it is supposed to do and is interpreted
in terms of satisfaction of the requirement specification laid down by the user .

Quality - Quality of the software is checked to see if it meets the requirements, expectations and
demands of the customer and free from defects.

Assurance - It means ensuring the correctness of the results and security of the product, as it works
without any bug and according to the expectations.

Software quality assurance is a methodology that determines the extent to which a software product is fit for
use.
The activities that are included for determining software quality are

 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system

Software Quality Assurance have:

1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
9
 4. Effective software engineering technology
5. Measurement and reporting mechanism
SQA Activities
SQA includes the following activities:

 Process definition
 Process training
 Process implementation
 Process audit
SQA Processes
SQA includes the following processes:
 Project Management
 Project Estimation
 Configuration Management
 Requirements Management
 Software Design
 Software Development [Refer to SDLC]
 Software Testing [Refer to STLC]
 Software Deployment
 Software Maintenance etc.

Quality Factors

 Correctness − Correctness determines whether the software requirements are appropriately met.
 Usability − Usability determines whether the software can be used by different categories of users
(beginners, non-technical, and experts).
 Portability − Portability determines whether the software can operate in different platforms with
different hardware devices.
 Maintainability − Maintainability determines the ease at which errors can be corrected and modules
can be updated.
 Reusability − Reusability determines whether the modules and classes can be reused for developing
other software products.

Major Software Quality Assurance Activities:

1. SQA Management Plan:
Make a plan how you will carry out the sqathrough out the project. Think which set of software
engineering activities are the best for project.check level of sqa team skills.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the basis of collected
data on different check points.
3. Multi testing Strategy:
Do not depend on single testing approach. When you have lot of testing approaches available use
them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more errors keep the
measure of impact of change on project. Reset the new change to change check the compatibility of
this fix with whole project.

10
 5. Manage Good Relations:
In the working environment managing the good relation with other teams involved in the project
development is mandatory. Bad relation of sqa team with programmers team will impact directly and
badly on project. Don’t play politics.

Difference between Quality Assurance and Quality Control

Quality Assurance Quality Control
Quality assurance provides assurance that the quality The quality of request required In QA is achieved in
request has been met. QC
The goal of quality control is to recognize and fix
The goal of quality assurance is to prevent the defects.
defects.
Quality assurance manages the quality Verification. Quality control checks the quality-Validation.
It does not include the execution of program. It requires execution of program.
Quality assurance is a proactive technique. Quality control is a reactive technique.
It is a proactive measure. It is a reactive measure.
It is a procedure to produce the deliverables i.e a
It is a procedure to check those deliverables.
product of development process.
Quality assurance is included in complete software Quality testing is included in complete software testing
development life cycle. life cycle.
It defines the standards and methodologies to meet It ensures that the standards are followed while
customer requirements. working on the product.
It is executed only after quality assurance activity is
It is executed before quality control.
completed.
Quality assurance is a less time consuming activity. Quality control is a more time consuming activity.
Statistical technique applied on QA is known as Statistical technique applied on QC is known as
Statistical Process Control (SPC). Statistical Quality Control (SQC).
Software Quality Attributes
The common definition of Software Quality Attribute (SQA) is FURPS model which was developed by
Robert Grady. Under this model following characteristics are recognized.
1.Functionality - It evaluates the feature set and capabilities of the program.
2.Usability - It is accessed by considering the factors such as human factor, consistency and documentation.
3.Reliability - It is evaluated by measuring parameters like frequency and security of failure, output result
accuracy, the mean-time-to-failure(MTTF), recovery from failure and the the program predictability.
4.Performance - It is measured by considering processing speed, response time, resource consumption,
throughput and efficiency.
5.Supportability

 It combines the ability to extend the program, adaptability, serviceability. These three term define
maintainability.
 Testability, compatibility and configurability are the terms using which a system can be easily
installed and the problems can be found easily.
 Supportability also consists of more attributes such as compatibility, extensibility, fault tolerance,
modularity, reusability, robustness, security, portability, scalability.

11
Capability Maturity Model (CMM)
 Capability Maturity Model (CMM) is an industry standard model. This model is used to develop and
refine processes of an organization.
 This model is organized into the five levels of maturity.
 Each level ranks the organization as per standardization of process assessed in the subject area.
 The subject area can be software engineering, system engineering, project management, risk
management, system acquisition, information technology services etc.
 A maturity model is a structured collection of element and explains the characteristics of effective
processes.
 It is used as benchmark for accessing various organizations for equivalent comparison.

Following are the five levels of maturity:

i) Initial
ii) Repeatable
iii) Defined
iv) Managed
v) Optimizing

i) Initial

 The software processes at this level are ad hoc and do not give a stable environment.
 The success of project depends on the capability and braveness of the people in the organization.
 There are no actual applications required to adopt planning, monitoring or controlling the process.
 It is not possible to estimate the time and cost to develop the software.

ii) Repeatable

 The software development processes are repeatable. They are not repeated for all the projects in the
organization.
 An organization may use basic and constant project management processes to track cost, schedule and
functionality.
 The minimum process discipline is used to repeat earlier success of project with same applications.

iii) Defined

 In defined level of maturity model, common engineering and management activities are standardized
and documented.
 These standards are adapted and accepted for use on various projects.
 Test documents and plans are reviewed and accepted before testing starts.
 The groups of testers are independent from the developers.
 The test outputs are used to determine when the software is ready.

12
iv) Managed

 In managed level of maturity, detailed measure of the software process and product quality is
gathered.
 The software process and product are quantitatively understood and controlled.

v) Optimizing

 This level show continuous improvement from previous levels and hence it is called as
Optimizing.
 The processes and new technologies are attempted, the outputs are measured and the evolutionary
and incremental changes are achieved for better quality levels.

ISO 9000 standard

 ISO 9000 is a family of standard for quality management and quality assurance.
 This standard is maintained by ISO i.e International Standards Organization.
 A family of standard defines the basic set of practices which helps a company consistently deliver
the product, meeting customer's quality requirements.
 ISO 9000 deals with the ISO 9001 and ISO 9000-3.

Requirements of ISO 9001:

 ISO 9001 covers all the key processes in business i.e design, develop, create, install, service and
product.
 Processes are observed to verify that they are effective.
 The records which are satisfactory are kept for further use.
 The results are checked for defects. Proper and corrective action is taken, as necessary.
 Separate process are reviewed regularly and quality process for the effectiveness. It makes continual
improvement easier.

ISO 9000-3

ISO 9000-3 covers key points in business i.e develop, supply, install and maintain computer software.

The requirements of ISO 9000-3 include:

 Develop detailed quality plans and procedures to control verification and validation, configuration
management, bugs and fixes.
 Construct and receive approval for software development plan. Iit consists of definition of project, a
list of project objectives, schedule, specification and organization of a project and discussion about
risks, assumptions and strategies.
 The software design review procedures are planned, developed, documented and performed.
 Software test plans are developed and documented.
 A method is developed to ensure tha it meets customer requirement.
 The output records of test are maintained.
 The procedures are developed to control the software's release process.
 Define and recognize what type of quality information is necessary to collect.
 The statistical techniques are used to analyze the software development process. These techniques are
also used to analyze the product quality.

13
Benefits of Software Quality Assurance (SQA):

1. SQA produce high quality software.

2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for long time.
5. High quality commercial software increase market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.

Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include adding more resources,
employing more workers to help maintain quality and so much more.

3:IMPACT OF OBJECT ORIENTATION ON TESTING

Testing Issues
To identify the testing issues raised by OO software
Testing issues related to OO software
1. Question of levels of testing
It requires clarification of OO units

2. Implications of composition strategy of OO

• OO s/w is characterized by inheritance, encapsulation, and polymorphism
• Hence, lets see how traditional testing can be extended to address the implications of these issues
Units for OO Testing
• Two Definition of Unit
A unit is the smallest program component that can be compiled and executed
A unit is a s/w component that would be developed by one person

• In certain applications, classes are huge

These violate the one-designer, one-class definition

• On such applications, define an OO unit as the work of one person

This ends up as a subset of the class operations.
• For such units, OO testing reduces to traditional testing
But it shift much of the OO testing burden onto integration testing
Also throws out the gains made by encapsulation

Advantage of class-as-unit
1. Helpful in test case identification
2. OO integration testing can have clear goals
Namely – To check the cooperation of separately tested classes

Implications of Composition and Encapsulation

• A unit (class) may be composed with other unknown units (classes) – So, notation of coupling and cohesion
are applicable
• Composition with the goal of reuse – Creates the need for very strong unit testing
• Even Presuming very good unit-level testing, – Real burden is at the integration testing level
14
Implications of Composition and Encapsulation

15
16
17
Levels of testing – 1
Individual methods are units
Four levels Method
 Unit testing- Class Intraclass
 integration testing- Integration Interclass
 integration testing-System At port level
 traditional testing

Levels of testing – 2
Classes are units
Three levels Class
 Unit testing
 Integration
 Interclass testing

Dataflow testing
Need analogue to dataflow testing of units in traditionalprograms Use a revised Petri net definition to
handle method calls between classes.

The main advantages of OO paradigm include :

 increased reusability
 reliability
 interoperability
 extendibility.

18
 As classes form the main unit of object-oriented program, testing of classes is the main concern while
testing an OO program. At the class level, every class should be tested as an individual entity.

OO based on hope that objects could be reused without

 Modification
 Additional testing ( Based on notion that objects encapsulate functions and data that belong together
)
Consensus now is that such optimism is unwarranted
OO programs has more severe testing problems than traditional programs
Looking to other models that can be combined with OO to ameliorate the problems
Aspect-oriented programs
Aspect-orientation can be combined with any programming language
Implications of composition strategy of OO
Compare to functional decomposition
OO programs
 Inheritance, encapsulation and polymorphism
 How can traditional testing be extended?
Traditional testing methods are not directly applicable to OO programs as they involve OO concepts
including encapsulation, inheritance, and polymorphism. These concepts lead to issues, which are yet to be
resolved. Some of these issues are listed below.
1.)Basic unit of unit testing.
 The class is natural unit for unit test case design.
 The methods are meaningless apart from their class.
 Testing a class instance (an object) can validate a class in isolation.
 When individually validated classes are used to create more complex classes in an application system,
the entire subsystem must be tested as whole before it can be considered to be validated(integration
testing).
19
 2.)Implication of Encapsulation.
 Encapsulation of attributes and methods in class may create obstacles while testing. As methods are
invoked through the object of corresponding class, testing cannot be accomplished without object.
 In addition, the state of object at the time of invocation of method affects its behavior. Hence, testing
depends not only on the object but on the state of object also, which is very difficult to acquire.
3.) Implication of Inheritance.
 Inheritance introduce problems that are not found in traditional software.
 Test cases designed for base class are not applicable to derived class always (especially, when derived
class is used in different context). Thus, most testing methods require some kind of adaptation in
order to function properly in an OO environment.
4.)Implication of Genericity.
 Genericity is basically change in underlying structure.
 We need to apply white box testing techniques that exercise this change.
i.)Parameterization may or may not affect the functionality of access methods.
ii.)In Tableclass, elemType may have little impact on implementations of the access methods of the Table.
Example: generic (parameterized class) class Tableclass(elemType) int numberelements; create();
insert(elemType entry); delete(elemType entry); isEmpty() returns boolean; isentered(elemType entry)
returns boolean; endclass;

 But UniqueTable class would need to evaluate the equivalence of elements and this could vary
depending on the representation of elemType. Example: class UniqueTable extends Table
insert(elemType entry); endclass;

4.)Implications of Polymorphism
 Each possible binding of polymorphic component requires a seperate set of test cases.
 Many server classes may need to be integrated before a client class can be tested.
 It is difficult to determine such bindings.
 It complicates the integration planning and testing.
5.)Implications for testing processes

Here we need to re-examine all testing techniques and processes.

Challenges in Testing Object-oriented Programs
Traditional testing methods are not directly applicable to OO programs as they involve OO concepts
including encapsulation, inheritance, and polymorphism. These concepts lead to issues, which are yet to be
resolved. Some of these issues are listed below.
1. Encapsulation of attributes and methods in class may create obstacles while testing. As methods are invoked
through the object of corresponding class, testing cannot be accomplished without object. In addition, the
state of object at the time of invocation of method affects its behavior. Hence, testing depends not only on the
object but on the state of object also, which is very difficult to acquire.
2. Inheritance and polymorphism also introduce problems that are not found in traditional software. Test cases
designed for base class are not applicable to derived class always (especially, when derived class is used in
20
different context). Thus, most testing methods require some kind of adaptation in order to function properly
in an OO environment.

4: DEVELOP TEST CASES AND TEST PLANS

Software Testing Life Cycle (STLC) defines the sequential testing approach having definite number of steps

to pursue and accomplish quality goals. Each phase provides a better way of implementation. The STLC life

cycle may vary from organizations to organizations, but the perspective to meet goal remains the same.

Software Testing Life Cycle(STLC) Phases

STLC follows a fixed hierarchy and

comprises following stages: Software Testing Life Cycle
1. Requirements Phase.
2. Planning Phase.
3. Analysis Phase.
4. Design Phase.
5. Implementation Phase.
6. Execution Phase.
7. Conclusion Phase.
8. Closure Phase.

21
Test Case:
A test case is a document, which has a set of test data, preconditions, expected results and postconditions,
developed for a particular test scenario in order to verify compliance against a specific requirement.
Test Case acts as the starting point for the test execution, and after applying a set of input values, the
application has a definitive outcome and leaves the system at some end point or also known as execution
postcondition.

Typical Test Case Parameters:

 Test Case ID
 Test Scenario
 Test Case Description
 Test Steps
 Prerequisite
 Test Data
 Expected Result
 Test Parameters
 Actual Result
 Environment Information
 Comments

Example:
Let us say that we need to check an input field that can accept maximum of 10 characters.
While developing the test cases for the above scenario, the test cases are documented the following way. In
the below example, the first case is a pass scenario while the second case is a FAIL.

Scenario Test Step Expected Actual Outcome

Result

Verify that the input field that Login to application and Application Application accepts all 10
can accept maximum of 10 key in 10 characters should be able characters.
characters to accept all 10
characters.

Verify that the input field that Login to application and Application Application accepts all 10
can accept maximum of 11 key in 11 characters should NOT characters.
characters accept all 11
characters.

22
If the expected result doesn't match with the actual result, then we log a defect. The defect goes through the
defect life cycle and the testers address the same after fix.

Test case Design Technique

Following are the typical design techniques in software engineering:
1. Deriving test cases directly from a requirement specification or black box test design technique. The
Techniques include:
 Boundary Value Analysis (BVA)
 Equivalence Partitioning (EP)
 Decision Table Testing
 State Transition Diagrams
 Use Case Testing
2. Deriving test cases directly from the structure of a component or system:
 Statement Coverage
 Branch Coverage
 Path Coverage
 LCSAJ Testing
3. Deriving test cases based on tester's experience on similar systems or testers intuition:
 Error Guessing
 Exploratory Testing

During the process of software testing, test case defines the preconditions for test execution and offers an
insight into the various specification and requirements that are stated before the commencement of the
testing. An integral part of the process, this document is used to define various important components of the
software testing such as, testing inputs, execution conditions, testing procedures, and the expected results.
The main purpose of this document is to help testers meet the objective of testing as well as the
requirements stated before the commencement of the process.

Types of Test Case:

1. Formal Test Case: For designing formal test cases, the team follows a standard format, which
allows them to create a test case that offers ease of understanding to other members of the team and that
cover all the possible tests completely. Formal test cases are further divided into two types of test cases-
positive and negative, which are mainly designed to ensure that all the requirements of the application are
tested properly by the team. Formal test case also offers various details about the software such as
preconditions, input & output data, among other things.

2. Informal Test Case: These test cases are mainly designed for applications and software without any
formal requirement or specification. Informal test cases can be written in a manner that is considered fit by
the team or by the individual responsible for creating test case. Moreover, in this type of test case the input
and output are now known to the team.

23
Importance of Test Case:

In software testing the relevance and importance of test case is monumental. It is a vital document prepared
during the early stages of software testing that specifies the inputs, execution conditions, testing procedures,
etc, of a testing process. With the assistance of this document, the team can offer an insight into the testing
process to other members of the team as well as the client and the concerned stakeholders. Test case allows
them to establish transparency among members and improves communication within the team.

Other reasons that make test case an integral part of software testing are:

 With the assistance of test cases testers can find defects and issues in the test design, which is
not
 covered by requirements.
 Helps identify usability issues, as the whole process is monitored.
 Enables the team to record the testing procedure and activities, which can be helpful in
future.
 It organizes the complete testing process.
 Helps validate if all requirements are fulfilled or not.
 It ensures accurate test coverage.

Details Covered by a Test Case:

A test case document offers miscellaneous information about the software testing process. From the basic
requirements to the testing procedure, everything is covered in this document, which offers the team an
opportunity to communicate major details about the process with other members of the team as well as the
stakeholders

Other details included in this document are:

 Test title.
 Test scenarios.
 Test descriptions.
 Steps & procedure.
 Prerequisites.
 Actual & expected results.
 Test environment.

Things to Consider while Writing Test Cases:

As one of the most significant document prepared during the software testing life cycle (STLC), the
document for test case needs to be designed with great care and accuracy. The details or information
included in it should be described in a manner that is understandable and precise. Hence, following are some
factors that need consideration while preparing the test case document.

 The customer requirements should be stated and defined clearly.

 It should be compact, simple and understandable, yet informative.
 Should offer details about the roles and responsibilities of the team members.
 The document should be traceable, economical, and reusable.
 Any critical or important information related to the expected results should be included.
 Should assure full test coverage.
24
TEST PLAN

A test plan is a detailed document that describes the test strategy, objectives, schedule, estimation and
deliverables and resources required for testing. Test Plan helps us determine the effort needed to validate the
quality of the application under test. The test plan serves as a blueprint to conduct software testing activities
as a defined process which is minutely monitored and controlled by the test manager.

A test plan is a document describing software testing scope and activities. It is the basis for formally testing
any software/product in a project.
Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a
baseline plan to track the progress of the project. It also defines the size of the test effort.
It is the main document often called as master test plan or a project test plan and usually developed during
the early phase of the project.
Definition

 In Software Testing there are numerous components and documents that help testers in executing the

process of testing. From creating a particular plan to resolving issues and retesting the software, the

importance of these documents is immense and without them the team can encounter various issues

and challenges which can impact the performance and functionality of the software under

development. Test case and test plan are two important documents that play a significant role in

defining as well as managing the procedure of testing and offering the team vital information

regarding the testing of the software.

 Preparing a detailed plan is always helpful and advised by people all around the world. It simplifies

the process and helps keep a track of the activities that are performed based on it. Similarly, test plan

is a document prepared during the early stages of software testing life cycle (STLC), based on which

the process of testing is executed. This document describes the scope and objective of testing along

with the steps taken to achieve it. In short, test plan can be termed as the blueprint for software

testing, wherein the numerous testing techniques, methodologies, tools, approaches, testing activities,

etc. are defined.

 Derived from the Software Requirements Specification document which is prepared by the team lead

or manager, the test plan includes a detailed description of all the steps taken to meet the stated

requirements of the client.

25
Types of Test Plan:

Test plan document is the most important and the first document published by the team before the process of

testing is initiated. It defines the strategy and philosophy behind testing and is mainly created to simplify

communication among team members and to monitor various activities performed during the process. Test

plan document can be categorized into three types, which consist different levels of information and details

and cater to different types of testing performed by the software testers. These types of test plans are:

 Master Test Plan: This is a high level test plan that is created to plan and manage projects with

multiple level of tests. This includes a summary of required resources, responsibilities, and tools &

techniques, along with the required testing efforts.

 Level Specific Test Plan: Second type of test plan is the level specific test plan, wherein the plans
are prepared for each level of software testing, such as performance testing, unit testing, system

testing, etc.

 Type Specific Test Plan: Here, the plans are prepared for major types of testing which require

constant observation and improvement like performance testing.

Importance of Test Plan:

Whether you are preparing for your exam or shifting to a new city, plans are always there to help us out in

difficult situations and processes. Likewise, in software testing also test plan help testers in numerous ways,

which make it a vital part of the whole process. Therefore, following are some reasons that increase the

importance of test plans.

Making Test Plan has multiple benefits

 Help people outside the test team such as developers, business managers, customers understand the
details of testing.
 Test Plan guides our thinking. Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by Management Team and re-used for
other projects.

 With the assistance of test plan testers can determine the efforts required to validate the effectiveness

and quality of the software.

 Testers use test plan document to communicate important features, components, and details about the

software testing process with various members of the team, client, and other stakeholders of the

project.

26
  It guides the team and the testing process.

 Helps the team monitor the process of testing as well as identify any deviances.

 Allows the team to document and report various important details about the process, such as the

testing activities, techniques, strategies, approaches, resources, etc.

Parameters Covered by Test Plan:

Test plan document covers a vast section of the testing process and offers great insight into it. From defining

the main scope & objective of testing to offering a comparison between the expected and actual output, the

test plan ensure proper coverage of the whole process.

S.No. Parameter Description

1. Test plan identifier Unique identifying reference.

2. Introduction A brief introduction about the project and to the document.

3. Test items A test item is a software item that is the application under test.

4. Features to be tested A feature that needs to tested on the testware.

5. Features not to be tested Identify the features and the reasons for not including as part of testing.

6. Approach Details about the overall approach to testing.

7. Item pass/fail criteria Documented whether a software item has passed or failed its test.

8. Test deliverables The deliverables that are delivered as part of the testing process,such as test
plans, test specifications and test summary reports.

9. Testing tasks All tasks for planning and executing the testing.

10. Environmental needs Defining the environmental requirements such as hardware, software, OS,
network configurations, tools required.

11. Responsibilities Lists the roles and responsibilities of the team members.

12. Staffing and training Captures the actual staffing requirements and any specific skills and training
needs requirements.

13. Schedule States the important project delivery dates and key milestones.

14. Risks and Mitigation High-level project risks and assumptions and a mitigating plan for each
identified risk.

15. Approvals Captures all approvers of the document, their titles and the sign off date.

27
Test Planning Activities:
 To determine the scope and the risks that need to be tested and that are NOT to be tested.
 Documenting Test Strategy.
 Making sure that the testing activities have been included.
 Deciding Entry and Exit criteria.
 Evaluating the test estimate.
 Planning when and how to test and deciding how the test results will be evaluated, and defining test
exit criterion.
 The Test artefacts delivered as part of test execution.
 Defining the management information, including the metrics required and defect resolution and risk
issues.
 Ensuring that the test documentation generates repeatable test assets.
Sample of a Test Case
Here is an example of a test case:

Title: Login Page – Authenticate Successfully on gmail.com

Description: A registered user should be able to successfully login at gmail.com.

Precondition: the user must already be registered with an email address and password.

Assumption: a supported browser is being used.

Test Steps:

1. Navigate to gmail.com
2. In the ’email’ field, enter the email address of the registered user.
3. Click the ‘Next’ button.
4. Enter the password of the registered user
5. Click ‘Sign In’
Expected Result: A page displaying the gmail user’s inbox should load, showing any new message at the
top of the page.

Here’s what this test case would look like in TestLodge:

28
Types of testingTools:
S.No. Tool Type Used for Used by

1. Test Management Tool Test Managing, scheduling, defect testers

logging, tracking and analysis.

2. Configuration management tool For Implementation, execution, All Team members

tracking changes

3. Static Analysis Tools Static Testing Developers

4. Test data Preparation Tools Analysis and Design, Test data Testers
generation

5. Test Execution Tools Implementation, Execution Testers

6. Test Comparators Comparing expected and actual All Team members

results

7. Coverage measurement tools Provides structural coverage Developers

8. Performance Testing tools Monitoring the performance, Testers

response time

9. Project planning and Tracking For Planning Project Managers

Tools

10. Incident Management Tools For managing the tests Testers

How to write a Test Plan

You already know that making a Test Plan is the most important task of Test Management Process. Follow
the seven steps below to create a test plan as per IEEE 829

1. Analyze the product

2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables

29
Step 1) Analyze the product

How can you test a product without any information about it? The answer is Impossible. You must learn a
product thoroughly before testing it.

The product under test is Guru99 banking website. You should research clients and the end users to know
their needs and expectations from the application

 Who will use the website?

 What is it used for?
 How will it work?
 What are software/ hardware the product uses?

Step 2) Develop Test Strategy

Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is a high-level document,
which is usually developed by Test Manager. This document defines:

 The project’s testing objectives and the means to achieve them

 Determines testing effort and costs

Back to your project, you need to develop Test Strategy for testing that banking website. You should follow
steps below

Step 2.1) Define Scope of Testing

Before the start of any test activity, scope of the testing should be known
30
  The components of the system to be tested (hardware, software, middleware, etc.) are defined as "in
scope"
 The components of the system that will not be tested also need to be clearly defined as being "out of
scope."

Defining the scope of your testing project is very important for all stakeholders. A precise scope helps you

 Give everyone a confidence & accurate information of the testing you are doing
 All project members will have a clear understanding about what is tested and what is not

How do you determine scope your project?

To determine scope, you must –

 Precise customer requirement

 Project Budget
 Product Specification
 Skills & talent of your test team

Now should clearly define the "in scope" and "out of scope" of the testing.

 As the software requirement specs, the project Guru99 Bank only focus on testing all
the functions and external interface of website Guru99 Bank (in scope testing)
 Nonfunctional testing such as stress, performance or logical database currently will not be tested.
(out of scope)

Problem Scenario

The customer wants you to test his API. But the project budget does not permit to do so. In such a case what
will you do?

Well, in such case you need to convince the customer that Api Testing is extra work and will consume
significant resources. Give him data supporting your facts. Tell him if Api Testing is included in-scope the
budget will increase by XYZ amount.

The customer agrees and accordingly the new scopes, out of scope items are

 In-scope items: Functional Testing, Api Testing

 Out of scope items: Database Testing, hardware & any other external interfaces

Step 2.2) Identify Testing Type

A Testing Type is a standard test procedure that gives an expected test outcome.

Each testing type is formulated to identify a specific type of product bugs. But, all Testing Types are aimed at
achieving one common goal “Early detection of all the defects before releasing the product to the customer”

The commonly used testing types are described as following figure

31
Step 2.3) Document Risk & Issues

Risk is future’s uncertain event with a probability of occurrence and a potential for loss. When the risk
actually happens, it becomes the ‘issue’.

In the article Risk Analysis and Solution, you have already learned about the ‘Risk’ analysis in detail and
identified potential risks in the project.

In the QA Test Plan, you will document those risks

Risk Mitigation

Team member lack the required skills for website Plan training course to skill up your members
testing.

The project schedule is too tight; it's hard to complete Set Test Priority for each of the test activity.
this project on time

Test Manager has poor management skill Plan leadership training for manager

A lack of cooperation negatively affects your Encourage each team member in his task, and
employees' productivity inspire them to greater efforts.

Wrong budget estimate and cost overruns Establish the scope before beginning work, pay a lot
of attention to project planning and constantly track
and measure the progress

32
Step 2.4) Create Test Logistics

In Test Logistics, the Test Manager should answer the following questions:

 Who will test?

 When will the test occur?

Who will test?

You may not know exact names of the tester who will test, but the type of tester can be defined.

To select the right member for specified task, you have to consider if his skill is qualified for the task or not,
also estimate the project budget. Selecting wrong member for the task may cause the project to fail or delay.

Person having the following skills is most ideal for performing software testing:

 Ability to understand customers point of view

 Strong desire for quality
 Attention to detail
 Good cooperation

In your project, the member who will take in charge for the test execution is the tester. Base on the project
budget, you can choose in-source or outsource member as the tester.

When will the test occur?

Test activities must be matched with associated development activities.

You will start to test when you have all required items shown in following figure

Step 3) Define Test Objective

Test Objective is the overall goal and achievement of the test execution. The objective of the testing is
finding as many software defects as possible; ensure that the software under test is bug free before release.

To define the test objectives, you should do 2 following steps

1. List all the software features (functionality, performance, GUI…) which may need to test.
2. Define the target or the goal of the test based on above features

Let’s apply these steps to find the test objective of your Guru99 Bank testing project
33
You can choose the ‘TOP-DOWN’ method to find the website’s features which may need to test. In this
method, you break down the application under test to component and sub-component.

In the previous topic, you have already analyzed the requirement specs and walk through the website, so you
can create a Mind-Map to find the website features as following

This figure shows all the features which the Guru99 website may have.

Based on above features, you can define the Test Objective of the project Guru99 as following

 Check that whether website Guru99 functionality(Account, Deposit…) is working as expected

without any error or bugs in real business environment
 Check that the external interface of the website such as UI is working as expected and & meet the
customer need
 Verify the usability of the website. Are those functionalities convenient for user or not?

34
Step 4) Define Test Criteria

Test Criteria is a standard or rule on which a test procedure or test judgment can be based. There’re 2 types
of test criteria as following

Suspension Criteria

Specify the critical suspension criteria for a test. If the suspension criteria are met during testing, the active
test cycle will be suspended until the criteria are resolved.

Example: If your team members report that there are 40% of test cases failed, you should suspend testing
until the development team fixes all the failed cases.

Exit Criteria

It specifies the criteria that denote a successful completion of a test phase. The exit criteria are the targeted
results of the test and are necessary before proceeding to the next phase of development. Example: 95% of
all critical test cases must pass.

Some methods of defining exit criteria are by specifying a targeted run rate and pass rate.

 Run rate is ratio between number test cases executed/total test cases of test specification. For
example, the test specification has total 120 TCs, but the tester only executed 100 TCs, So the run rate
is 100/120 = 0.83 (83%)
 Pass rate is ratio between numbers test cases passed / test cases executed. For example, in above
100 TCs executed, there’re 80 TCs that passed, so the pass rate is 80/100 = 0.8 (80%)

35
This data can be retrieved in Test Metric documents.

 Run rate is mandatory to be 100% unless a clear reason is given.

 Pass rate is dependent on project scope, but achieving high pass rate is a goal.

Example:Your Team has already done the test executions. They report the test result to you, and they want
you to confirm the Exit Criteria.

Step 5) Resource Planning

Resource plan is a detailed summary of all types of resources required to complete project task. Resource
could be human, equipment and materials needed to complete a project

The resource planning is important factor of the test planning because helps in determining the number of
resources (employee, equipment…) to be used for the project. Therefore, the Test Manager can make the
correct schedule & estimation for the project.

This section represents the recommended resources for your project.

Human Resource

The following table represents various members in your project team

No. Member Tasks

1. Test Manager Manage the whole project
Define project directions
Acquire appropriate resources
2. Tester Identifying and describing appropriate test techniques/tools/automation
architecture
Verify and assess the Test Approach
Execute the tests, Log results, Report the defects.
Tester could be in-sourced or out-sourced members, base on the project
budget
For the task which required low skill, I recommend you
choose outsourced members to save project cost.
3. Developer in Test Implement the test cases, test program, test suite etc.
4. Test Builds up and ensures Test Environment and assets
Administrator are managed and maintained
SupportTester to use the test environment for test execution
5. SQA members Take in charge of quality assurance
Check to confirm whether the testing process is meeting specified
requirements

36
System Resource

For testing, a web application, you should plan the resources as following tables:

No. Resources Descriptions

1. Server Install the web application under test

This includes a separate web server, database server, and application server if
applicable
2. Test tool The testing tool is to automate the testing, simulate the user operation,
generate the test results

There are tons of test tools you can use for this project such as Selenium,
QTP…etc.
3. Network You need a Network include LAN and Internet to simulate the real business
and user environment
4. Computer The PC which users often use to connect the web server

Step 6) Plan Test Environment

What is the Test Environment

A testing environment is a setup of software and hardware on which the testing team is going to execute test
cases. The test environment consists of real business and user environment, as well as physical
environments, such as server, front end running environment.

How to setup the Test Environment

Back to your project, how do you set up test environment for this banking website?

To finish this task, you need a strong cooperation between Test Team and Development Team

ask the developer some questions to understand the web application

 what is the maximum user connection which this website can handle at the same time?
 What are hardware/software requirements to install this website?
 Does the user's computer need any particular setting to browse the website?

37
Step 7) Schedule & Estimation

In the article Test estimation, you already used some techniques to estimate the effort to complete the project.
Now you should include that estimation as well as the schedule to the Test Planning

In the Test Estimation phase, suppose you break out the whole project into small tasks and add the estimation
for each task as below

Task Members Estimate effort

Create the test specification Test Designer 170 man-hour
Perform Test Execution Tester, Test Administrator 80 man-hour
Test Report Tester 10 man-hour
Test Delivery 20 man-hour
Total 280 man-hour

Then you create the schedule to complete these tasks.

Making schedule is a common term in project management. By creating a solid schedule in the Test
Planning, the Test Manager can use it as tool for monitoring the project progress, control the cost overruns.

To create the project schedule, the Test Manager needs several types of input as below:

 Employee and project deadline: The working days, the project deadline, resource availability are
the factors which affected to the schedule
 Project estimation: Base on the estimation, the Test Manager knows how long it takes to complete
the project. So he can make the appropriate project schedule
 Project Risk : Understanding the risk helps Test Manager add enough extra time to the project
schedule to deal with the risks

create the schedule as below


38
Step 8) Test Deliverables

Test Deliverables is a list of all the documents, tools and other components that has to be developed and
maintained in support of the testing effort.

There are different test deliverables at every phase of the software development lifecycle.

Test deliverables are provided before testing phase.

 Test plans document.

 Test cases documents
 Test Design specifications.

Test deliverables are provided during the testing

 Test Scripts
 Simulators.
 Test Data
 Test Traceability Matrix
 Error logs and execution logs.

Test deliverables are provided after the testing cycles is over.

 Test Results/reports
 Defect Report
 Installation/ Test procedures guidelines
 Release notes

Benefits
 You’ll find gaps in the design early
 You’ll find usability issues
 New hires can pick up and test the application without much, or any training
 It builds empathy for the users of your product
 It helps you and others learn the product

39