Manual and Automated

Software Testing
Techniques
Software Quality

Software Quality is a process of meeting customer expectations and customer requirements. The
features of Software Quality are described below:

 Meet customer requirements

 Meet customer expectation
 Time to Market
 Cost of product

Technical Factors:
 Meet customer requirement deals with the functionalities and the features of the
software that the customer uses.
 Meet customer expectation by checking the performance, user friendliness, privacy,
reliability of the software

Non-Technical Factors:
 Time to market deals with the delivery of the software to the customer within his
expected time.
 Lastly the price of the product should also meet customer expected price value.

Software Quality Assurance (SQA)

It is a mechanism to monitor and measure the strength of development process. Example of SQA is
Life Cycle Testing (LCT). Members of SQA team are often known as Test Engineers.

Software Development Life Cycle (SDLC)

The stages involved in Software Development Life Cycle are as follows:

Information gathering (Analysis)

Design (Architecture)
Coding (Development)
Testing (Single stage of Testing)
Maintenance (Support)

Information gathering specifies what and analysis specifies how. Once information is gathered from
the customer an analysis is performed on the collected information. Then using this information the
architecture is prepared which is commonly known as design. This design is passed onto
development team for coding purpose. Once the development team develops, it is passed through
single stage of testing. Finally after this testing it is delivered to the end user. Once the customer
starts using the software then maintenance of the software is concentrated by giving customer
support in case the customer faces any problems in using the software.

SDLC ( Software Development Life Cycle)

1. Initial Concept: They exactly are concluding with higher authorities and client.
2. Requirement Analysis: Here omitting the client. Requirement we need to develop the
application. Out put is SRS(Software Requirement Specification)
3. Functional Design: Overview of the design particular application. It is also known as High
Level Design.

SRS DESIGN VALID DESIGN DOCUMENT

4. Internal Design: Preparing of the flow charts and E- R diagrams. It is also know as Low
Level Design.

5. Documentation Plan: This done by a project Manager. Than give to every body who
are involving on a particular concept development and analysis.
6. Test Plan: Team leader will prepare a Test Plan.
7. Coding: The developer will develop the coding.

Validated design Implementation Source Code

Document

8. Integration: Combining all the modules.

Combining Integrating
Units------------------ modules------------ Application
9. Testing: Testing of the .exe files by the Test Engineer , Testers according to the Test Case

Test Inputs

Source Code Testing Test Output

Defect Analysis

10. Documentation Preparation: After completion of testing each and ever tester should want to
prepare the DP. And hand over to the Team Leader.
11. Maintenance: Authorized person can take of the data from server to client. That means
security.
12. Update: After completion of the maintenance adding the new Objects to that particular
application . This can also called as version IT.
13. Re – Test : Testing the application with new Test Case .
14. Phase – Out: Into the Market. This is of 2 types.

A. Alpha : Testing the application by the client in development center is known as

alpha testing or in - home testing
 B. Beta : Testing the application by the client in organization is known as beta
testing or Out – Home testing

Sdlc Models

1. Water fall model:

Stage o/p

RS SRS, Maintenance plan

SD and S/W Design system design document, H/w design document, interface design
document
Unit testing Program Code, Unit Test Plan.

Integration System test plan, Final user manual

Maintenance $

RS: During this phase the project team will work out in detail, the functional and likely limitation
of the s/w product to be developed. A document clearly indicating the
requirements. It is called the s/w RS document

S/W D and System D : This the requirements specification the system design is carried out.
System design implies hardware design and s/w design. The
functionality h/w and s/w are separated out and design of the s/w
modules is worked out in detail. A test plan is also prepared describing
the details of tests to be carried out on the system once development
is completed.

Implementation and Unit testing

Design -> Code -> Modules -> Units.

A unit can be defined as a logical separable part of the program. Each unit is tested
separately and ensured that it has no bugs.
Integration and system testing

UnitsSystem BuildFunctionalityPerformance.
A test report containing the test result is prepared.

Operation and maintenance:

This phase goes on till the s/w is retired. The s/w is delivered to the client and if any
enhancement are required they are carried out

The attractive feature of waterfall model is that at the end of each stage a visible o/p is available.

Advantages:

1.Because of availability of well defined out put at each stage, the progress of the project will be
evident to the management.
2. Monitoring, both by the internal management team and the client, is easy because of the visible
out put at each stage.
Disadvantages:

1. For long term projects.

2. If the client wants the developer to evolve specifications in a gradual manner this model is
not suitable

Prototyping Model

It is very difficult to obtain the exact user requirements (user is non it literate). In such cases, a
prototype is built and demonstrated the user. Based on the user’s feedback the SRS document
is prepared. prototyping is used to prove ur design concepts. In s/w prototyping is used to
obtain then user requirements. The cost will be done by the developer not in the cost of client.

Evolutionary Development Model:

The system is built in stages. Initial user requirements are obtained and the product is developed.
The user validates the system and gives the feedback for enhancements. The product is refined
based on the new requirements. This process is repeated till a user acceptable product is built.

Advantages:

1. This model is useful in exploratory programming.

2. In case major problems are foreseen the developer can stop the development after some
iteration.

Disadvantages:

1. Because the project is open-end, no time frame can be set.

2. Project monitoring is difficult.
3. Less visibility as compared to waterfall model.

Incremental building helps reduce risk for commercial projects.

SPRIAL MODEL

Useful for high – risk projects. Complicated model for projects with clear specifications.

Each loop split into 4 sections to carry out a specific task

1. To Determine the objectives ,alternatives and constraints.

2. Risk analysis and evaluation of alternatives .
3. Execution of that phase of development.
4. Planning the next phase.

For each round of the spiral, one form has to be filled containing the following information.

Objectives: What r the objectives of this phase in terms of technical activities?

Alternatives: What are the alternatives available to achieve the objectives?
Constraints: what are the risk items and the impact of the risk items?
Risk factors: what are the risk items and the impact of the risk items?
Risk Resolution: how the risks can be resolved?
Results: what results have been achieved vis – a - vis the objectives?
 Plans: what are the plans for the next phase?

Commitment: what are the commitments to the client and whether they can be fulfilled based on
the results of this phase of development?

So, at the end of each spiral(phase), the management can review the status based on this form,
and decide the future course of action.

Advantages of the spiral model:

 This is a flexible model, the phases can be determined by an organization depending on the
type and complexity for the project.
 This model is suitable for high – risk projects.
 Project monitoring is very effective as risk management is built into the model. Periodically, the
project can be assessed for its risks vis – a-vis the progress and a decision can be taken at the
end of each spiral regarding its continuation or otherwise.

Disadvantages of the spiral model:

 This model is not suitable for low risk projects or projects without any risk.
 It is a ‘complicated’ model for projects with clear SRS.
V Model Testing

Development Wing Testing Wing

Information Assessment of
gathering and development plan
analysis
Prepare Test plan

Requirement Phase
Testing

Design and Coding Design Phase

Testing

Program Phase
Testing (WBT)

Build Functionality and System

Testing (BBT)

UAT (User Acceptance

Test)

Test Document Maintenance

(versioning)

Maintenance Port Testing (Onsite client place testing),

Test Software Changes, Test Efficiency.

This model defines mapping between multiple stages of development process and multiple stages
of testing process.
 Refinement form of V Model
V Model is expensive process for small scale and medium scale organizations. Due to this reason
organizations are following refinement form of V Model with separate testing team for functional
and system-testing phase (Black Box Testing).

BRS/CRS/URS User Acceptance Test (UAT)

S/WRS Functional & System Testing (BB)

Review

HLD Integration Testing

White Box
Testing

LLD’S Unit Testing

Review

Coding

Stages involved in Life Cycle Testing

I) Review During Analysis
In general software development process starts with information gathering and analysis. In this
phase Business Analyst category people develop Business Requirement Specification (BRS) and
corresponding Software Requirement Specification (SRS). To estimate completeness and
correctness of the documents, Business Analysts are applying below factors:

BRS SRS

Are they Right Requirements?

Are they Complete?
Are they Achievable? (w.r.t. technology)
Are they reasonable? (w.r.t. time)
Are they testable? (might be expensive, eg. Satellite testing)

II) Review During Design

After completion of analysis and their reviews, technical support people concentrate on logical
design of the system in terms of external design and internal design. In this phase they develop
high level document (HLD) and corresponding low level documents (LLDs). They conduct reviews
on these documents for completeness and correctness. Below are the factors in this stage.

HLD LLDs

Are they understandable?

Have they met right requirement?
Are they complete?
Are they followable? (w.r.t. coding (cohesive and coupling))
Do they handle errors? (errors messages)
III) Unit Testing
After completion of design and their reviews, programmers concentrate on coding to
physically construct software. In this phase they can verify completeness and correctness of every
program through white box testing techniques. Module level testing or micro level testing are other
names for Unit Testing.

Programs

a) Execution Testing White box testing techniques

b) Operations Testing
c) Mutation Testing

a) Execution Testing:
Basis paths coverage (All statements are participating in execution
without runtime errors)
Loops coverage (Termination of loops without going to infinite)
Program technique coverage (Less number of memory cycles and
CPU cycles during execution.
b) Operations Testing
Whether our program is running on customer expected platform or not?
Platform means different operating systems, compilers, browsers etc. This
testing technique is optional because customers are not expecting multiple
platforms to run for all applications. This testing is done at program level.
C) Mutation Testing
After completion of a program testing, white box tester applies this technique to estimate
completeness and correctness of that program testing. Mutation means a complex change in that
program code.
Tests Tests Tests

-----------
----------- -----------
-
- -
No
Change in Change in
Change in
program program
program
----------- -----------
-----------
------- -------
-----------
--- --- --- ---
-----------
---- ----
---

Test Pass Test Pass Pass & Failed

(Incomplete testing) (Completeness)

IV) Integration Testing

During coding programmers are integrating dependent modules to form a system. During this
formation of system, programmers are conducting integrating testing to verify control transmission
and data transmission among the dependent module.

There are three approaches to conduct integration testing.

a) Top-down approach
Conduct testing on main module without coming to sum of sub modules is
called Top-down approach.

Eg:
 Login Main
Module

Stub

Mailing Sub1 Sub2 Chatting

From the above approach programmers are using temporary programs to send back controller to
main module instead of sub module. This temporary called program is called STUB.
b) Bottom-top approach
Conducts testing on sub modules without coming from main module is called Bottom-top
approach.

Eg:

Main
Module Main Module is under construction

Driver (temporary program)

Sub1

Sub2

From the above approach programmers are using a temporary program to call
corresponding sub module instead of main module. This type of calling program is called Driver.

C) Hybrid Approach
The combination of Top-down and Bottom-up approach is called Hybrid approach. It is also
known as sandwich approach.

Eg:

Main Module

Driver Upper Layer

Sub
1

UB
ST
Sub Sub
1 1
Bottom Layer