Unit 1: Software Testing Background

BCA SEMESTER-V
TITLE: SOFTWARE TESTING AND QUALITY ASSURANCE

UNIT 1: SOFTWARE TESTING BACKGROUND

Testing:
Testing is the process of evaluating a system or its component(s) with the intent to
find that whether it satisfies the specified requirements or not.
This activity results in the actual, expected and difference between their results.
In simple words testing is executing a system in order to identify any gaps, errors or
missing requirements in contrary to the actual desire or requirements.

Software Testing:
Software testing is an integral part of the software development life cycle which
identifies the defects, flaws or the errors in the application. It is incremental and
iterative in nature.
Objectives of software testing
 It ensures if the solutions meet the business requirements, thereby enhancing customer
confidence.
 It catches the bugs, errors and defects.
 It ensures if the system is stable and ready for use.
 It identifies the areas of weakness in an application or product.
 It establishes the degree of quality. 6. It determines user acceptability
The scope of testing can be comprehensive and could examine components like
 Business requirements
 Design requirements
 Programmer’s code
 Hardware configuration and
 Systems administration standards and constraints.
The ambit of testing could also involve testing with respect to industry standards and
professional best practices. Testing thus provides an opportunity to validate and verify all
aspects of software engineering.
Thus, software testing brings many benefits to an organization. It saves time and money,
since defects are identified early. Testing ensures that the product is stable with less
downtime, thereby gaining customer satisfaction.
Verification - typically involves reviews and meeting to evaluate documents, plans, code,
requirements, and specifications. This can be done with checklists, issues lists, walkthroughs,
and inspection meeting.
Validation - typically involves actual testing and takes place after verifications are
completed.
Validation and Verification process continue in a cycle till the software becomes defects free.

Dept. of Computer Science Page 1 of 34

 Unit 1: Software Testing Background

Verification Validation
Are you building it right? Are you building the right thing?
Ensure that the software system meets all Ensure that functionalities meet the
the functionality. intended behavior.
Verification takes place first and includes Validation occurs after verification and
the checking for documentation, code etc. mainly involves the checking of the overall
product.
Done by developers. Done by Testers
Have static activities as it includes the reviews, Have dynamic activities as it includes
walkthroughs, and inspections to verify that executing the software against the
software is correct or not. requirements.
It is an objective process and no subjective It is a subjective process and involves
decision should be needed to verify the subjective decisions on how well the
Software. Software works.

Who does testing?

It depends on the process and the associated stakeholders of the project(s). In the IT industry,
large companies have a team with responsibilities to evaluate the developed software in the
context of the given requirements. Moreover, developers also conduct testing which is called
Unit Testing. In most cases, following professionals are involved in testing of a system within
their respective capacities:
 Software Tester
 Software Developer
 Project Lead/Manager
 End User
Different companies have difference designations for people who test the software on the
basis of their experience and knowledge such as Software Tester, Software Quality
Assurance Engineer, and QA Analyst etc.
It is not possible to test the software at any time during its cycle. The next two sections state
when testing should be started and when to end it during the SDLC.
i. When to Start Testing
An early start to testing reduces the cost, time to rework and error free software that is
delivered to the client. However in Software Development Life Cycle (SDLC) testing
can be started from the Requirements Gathering phase and lasts till the deployment of
the software. However it also depends on the development model that is being used.
For example in Water fall model formal testing is conducted in the Testing phase, but
in incremental model, testing is performed at the end of every increment/iteration and
at the end the whole application is tested.
Testing is done in different forms at every phase of SDLC like during Requirement
gathering phase, the analysis and verifications of requirements are also considered
testing. Reviewing the design in the design phase with intent to improve the design is
also considered as testing. Testing performed by a developer on completion of the
code is also categorized as Unit type of testing.
ii. When to Stop Testing
Unlike when to start testing it is difficult to determine when to stop testing,

Dept. of Computer Science Page 2 of 34

 Unit 1: Software Testing Background

as testing is a never ending process and no one can say that any software is 100%
tested. Following are the aspects which should be considered to stop the testing:
 Testing Deadlines.
 Completion of test case execution.
 Completion of Functional and code coverage to a certain point.
 Bug rate falls below a certain level and no high priority bugs are identified.
 Management decision.

Terms for software failures:

Error, Fault and Failure
Humans make errors in their thoughts, actions, and in the products that might result from
their actions. Errors occur in the process of writing a program.
A programmer makes an error (mistake), which results in a defect (fault, bug) in the software
source code. If this defect is executed, in certain situations the system will produce wrong
results, causing a failure.
Not all defects will necessarily result in failures. For example, defects in dead code will never
result in failures. A defect can turn into a failure when the environment is changed.
Examples of these changes in environment include the software being run on a new hardware
platform, alterations in source data or interacting with different software. A single defect may
result in a wide range of failure symptoms.
Not all software defects are caused by coding errors. One common source of expensive
defects is caused by requirement gaps, e.g., unrecognized requirements that result in errors of
omission by the program designer. A common source of requirements gaps is non-functional
requirements such as testability, scalability, maintainability, usability, performance, and
security.
Errors – Examples
 Incorrect usage of software by users
 Bad architecture and design by architects and designers
 Bad programming by developers
 Inadequate testing by testers
 Wrong build using incorrect configuration items by Build Team Member
Fault - Examples
 A fault is the manifestation of one or more errors
 An incorrect statement
 Wrong data type
 Wrong mathematical formula in design document
 Missing functionality in the system
Failure
A failure occurs when a faulty piece of code is executed leading to incorrect state that
propagates to the program’s output.

Dept. of Computer Science Page 3 of 34

 Unit 1: Software Testing Background

The following figure tells us how Error made by human will result in failure of the software.

Software Bug:
A bug, also known as a software bug, is an error in a software program that may produce
incorrect, undesired result or prevent the program from working correctly.
In software testing, a bug not only means an error, but anything that affects the quality of the
software program.
Software bugs take different names such as – defect, fault, problem, error, incident, anomaly,
failure, variance and inconsistency and so on.
The following are certain conditions that result in a bug in a software:
 If the software does not respond or act in the way as stipulated in the product
specification.
 If the software behaves in a way that is stipulated in an opposite way in the product
specification.
 If the software responds or reacts in a way that is not mentioned in the product
specification.
 If the software does not behave in the mandatory way as expected --perhaps, this
might not be mentioned in the product specification.

Dept. of Computer Science Page 4 of 34

 Unit 1: Software Testing Background

 If the software is difficult to understand or has cumbersome steps to follow, or if it is

slow in its reaction.
Types of Bugs:
Software bugs, which occur irrespective of the size of the program, are generally encountered
when different groups of developers work to develop a single program. We will now list the
common types of bugs and their causes.
Some of the common types of software bugs include the following:
1. Bugs due to conceptual error
Incorrect usage of syntax in the program, misspelled keywords, using wrong or
improper design or concept.
2. Math bugs
Divide by zero error, overflow or underflow, lack of precision in arithmetic values
due to incorrect rounding or truncation of decimal values.
3. Logical bugs
Infinite loops, infinite recursion, applying wrong logic, incorrect usage of jump or
break conditions.
4. Resource bugs
Stack or buffer overflow, access violations, using variables that are not initialized.
5. Co-programming bugs: Concurrency errors, deadlock, race condition.
6. Team working bugs:
Out of date comments, non-matching of documentation or files, linking the program
to incorrect files.
Reasons for Occurrence of a Bug:
Bugs can occur in a program due to many reasons. Some of the common reasons that may
cause bugs in software are:
1. Human Factor:
The developer who develops the software is human and there is always a chance that
some error, incorrect usage of logic or syntax or improper linking of files might occur.
Since the entire software development process involves humans, it is prone to errors.
2. Communication Failure:
The lack of communication or communicating incorrect information during the
various phases of software development will also lead to bugs. Lack of
communication can happen during various stages of Software Development Life
Cycle (Requirements, Design, Development, Testing, and Modification). Many bugs
occur due to lack of communication when a developer tries to modify software
developed by another developer.
Ex: The requirements defined in the initial phase of the Software Development Life
Cycle may not be properly communicated to the team that handles the design of the
software. The design specifications that reach the development team may be incorrect,
which could lead to occurrence of bugs in the software.

Dept. of Computer Science Page 5 of 34

 Unit 1: Software Testing Background

3. Unrealistic Development Timeframe:

Sometimes developers work under tight schedules, with limited or insufficient
resources, and unrealistic project deadlines. Compromises are made in the
requirements or design of the software in order to meet the delivery requirements.
Most of the time, it leads to wrong understanding of the requirements, inefficient
design, improper development, and inadequate testing.
4. Poor Design Logic:
During complex software development, some amount of R&D and brainstorming has
to be done to develop a reliable design. It is also important to choose the right
components, products and techniques for software development and testing during the
design phase. If there is any lack of proper understanding in the technical feasibility
of the components, products, or techniques in the development process, it may cause
bugs in the software that is being developed.
5. Poor Coding Practices:
Poor coding practices such as inefficient use of codes, misspelled keywords, or
incorrect validation of variables will lead to bugs. Sometimes, faulty tools such as
editors, compilers, and debuggers generate wrong codes, which cause errors in the
software and it is difficult to debug such errors.
6. Lack of Skilled Testing:
If there are any drawbacks in the testing process of the software, bugs go unnoticed.
7. Change Requests:
If there are last minute changes on requirements, tools, or platform, it could cause
errors and can lead to serious problems in the application.
Cost of Bugs:
Any bug that exists in the software delivered to the customer can lead to huge financial
losses. It will bring down the reputation of the organization developing the software. In case
the bug causes any damage to life or property of the customer, it can also lead to huge penalty
on the organization that developed the software.
Bugs that are detected during the testing stage will take some time to get fixed, affecting the
timeline and increasing the project cost. If the bugs are detected and fixed at the earliest in
the software development life cycle, it can result in higher return on investment for the
organization with respect to time and cost. The cost of fixing a bug differs depending on the
development stage at which it is detected.
Let us analyze the impact when bugs are detected at different stages of project life cycle.
1. Requirement Stage:
It would cost the organization some time to rewrite the requirements and can be easily
detected and fixed.
2. Coding Stage:
It would make the developer spend some time to debug. However, the time required
to fix the bug will vary depending on the complexity of the bug. A bug detected by
the developer at this stage can be resolved easily, since the developer understands the
problem and will be able to fix it.

Dept. of Computer Science Page 6 of 34

 Unit 1: Software Testing Background

3. Integration Stage:
It will require more time to be resolved. Since the problem occurs at a higher level, it
requires time to check the part of the code or configuration which is wrong and
additional time to fix the bug. The developer and other system engineers will be
involved in detecting and resolving the bug.
4. Testing Stage:
It will involve the developer, system engineer, and project manager for detecting and
resolving the bug. It is an iterative process, which takes a lot of time and effort with
respect to man hours and cost in order to detect and fix the bug. Since the bugs have
to be tracked and prioritized for debugging, it will increase the project cost in terms of
man power and tools required and causes delay in the delivery times as well.
5. Production Stage:
It will take huge time and investment for the organization, as it involves developers,
system engineers, project managers, and customers for detecting and resolving the
bug. It demands prioritizing and detailed planning when compared to a bug detected
in testing stage. Such bugs not only cause a huge loss, but also bring down the
reputation of the organization.

Dept. of Computer Science Page 7 of 34

 Unit 1: Software Testing Background

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
The Software Development Lifecycle is a systematic process for building software that
ensures the quality and correctness of the software built.
SDLC process aims to produce high-quality software which meets customer expectations.
The software development should be complete in the pre-defined time frame and cost.
SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software. Every phase of the SDLC lifecycle has its own process and deliverables.

Why SDLC?
Here, are prime reasons why SDLC is important for developing a software system.
 It offers a basis for project planning, scheduling, and estimating.
 Provides a framework for a standard set of activities and deliverables.
 It is a mechanism for project tracking and control.
 Increases visibility of project planning to all involved stakeholders of the development
process.
 Increased and enhance development speed.
 Improved client relations.
 Helps you to decrease project risk and project management plan overhead.

SDLC Phases
 Requirements gathering and analysis
 Planning
 Design
 Development & Coding
 Testing
 Deployment & Maintenance
Requirements gathering and analysis
During requirement gathering the specific requirements of the software to be built are
gathered and documented.
If the software is bespoke software, then there is a single customer who can give these
requirements.
If the product is general-purpose software, then a product marketing team within the software
product organisation specifies the requirements by aggregating the requirements of multiple
potential customers.
In either case, it is important to ensure that right requirements are captured at every stage.
The requirements get documented in the form of System Requirement Specification (SRS)
document. This document acts as a bridge between the customer and the designer chartered to
build the product.
Planning
The purpose of the Planning phase is to come up with a schedule, the scope and resource
requirements for a release. A plan explains how the requirements will be met and by which
team. It needs to take into account the requirements - what will be met and what will be not

Dept. of Computer Science Page 8 of 34

 Unit 1: Software Testing Background

met for the current release to decide on the scope of for the project, look at resource
availability, and to come out with set of milestones and release date for the project.
The planning phase is applicable for both development and testing activities. At the end of
this phase, both project plan and test plan documents are delivered.
Design
The purpose of the design phase is to figure out how to satisfy the requirements enumerated
in the System Requirement Specification documents.
The design phase product produces representation that will be used by the following phase,
the development phase. This representation should serve two purposes.
First, from this representation, it should be possible to verify that all the required
requirements are satisfied.
Second, this representation should give sufficient information for the development Phase to
proceed with the coding and implementation of the system.
Design is usually split into two levels - high level design and low level design or detailed
design. The design step produces the system design description (SDD) document that will be
used by development teams to produce the programs that realise the design.
Development or Coding
Design acts as a blueprint for the actual coding to proceed. This development are coding
phase comprises coding the programs in the chosen programming language. It produces the
software that meets the requirements the design was meant to satisfy. In addition to
programming, this phase also involves the creation of product documentation.
Testing
As the programs are coded (in the chosen programming language), they are also tested. In
addition, after the coding is (deemed) complete, the product is subjected to testing.
Testing is the process of exercising the software product in pre-defined ways to check if the
behaviour is the same as expected behaviour.
By testing the product, an organisation identifies and removes as many defects as possible
before shipping it out.
Deployment and maintenance
Once a product is tested, it is given to the customers who deploy it in their environments. As
the user start using the product in their environments, they may observed discrepancies
between the actual behaviour of the product and what they were given to expect (either by
marketing people or through the product documentation). Such discrepancies could end up as
product defects, which need to be corrected.
The product now enters the maintenance phase, wherein the product is maintained or changed
to satisfy the changes that arise from the customer expectations, environmental changes, etc.
Maintenance is made up of corrective maintenance (for example, fixing customer-reported
problems), adaptive maintenance (for example, making the software run on a new version of
an operating system or database), and preventive maintenance (for example, changing the
application program code to avoid the potential security hole in an Operating System code).

Dept. of Computer Science Page 9 of 34

 Unit 1: Software Testing Background

QUALITY, QUALITY ASSURANCE AND QUALITY CONTROL

Requirements get translated into software features, each feature being designed to meet one
or more of the requirements. For each such feature, the expected behaviour is characterized
by set of test cases. Each test cases is further characterized by
 The environment under which the test case is to be executed
 Inputs that should be provided for that test cases
 How these inputs should get processed
 What changes should be produced in the internal state or environment; and
 What outputs should be produced.
The actual behaviour of a given software for a given test case, under given set of inputs, in a
given environment, and in a given internal state is characterised by
 How these inputs actually get processed;
 What changes are actually produced in the internal state and environment; and
 What outputs are actually produced.
How do we increase the chances of a product meeting the requirements expected of it,
consistently and predictably? There are two types of methods - quality control and quality
assurance.
Quality control attempts to build a product, test for expected behaviour after it is built, and if
the expected behaviour is not the same as the actual behaviour of the product, fixes the
product as is necessary and rebuilds the product.
This iteration is repeated till the expected behaviour of the product matches the actual
behaviour of the scenarios tested. Thus quality control is defect-detection and defect-
correction oriented, and works on a product rather than on the process.
Quality assurance, on the other hand attempts defect prevention by concentrating on the
process of producing the product rather than working on defect detection/correction after the
product is built.
Quality Control Quality Assurance
Concentrates on specific products Concentrates on process of producing the products
defect-detection & correction oriented defect prevention oriented
Usually done after the product is built Usually done through the life cycle
This is usually a Line Function This is usually a staff function
Ex: Software testing at various level Ex: Reviews and audits

Dept. of Computer Science Page 10 of 34

 Unit 1: Software Testing Background

SOFTWARE DEVELOPMENT LIFE CYCLE MODEL

 Big Bang Model
 Code and Fixed Model
 Waterfall Model
 Spiral Model
Big Bang Model
Big-Bang is the SDLC (Software Development Life cycle) model in which no particular
process is followed.
Generally this model is used for small projects in which the development teams are small.
The development just starts with the required money and efforts as the input, and the output
is the software developed which may or may not be as per customer requirement.
This Big Bang Model does not follow a process/procedure and there is a very little planning
required. Even the customer is not sure about what exactly he wants and the requirements are
implemented on the fly without much analysis. Usually this model is followed for small
projects where the development teams are very small.
The Big Bang Model comprises of focusing all the possible resources in the software
development and coding, with very little or no planning. The requirements are understood
and implemented as they come. Any changes required may or may not need to revamp the
complete software.

This model is ideal for small projects with one or two developers working together and is
also useful for academic or practice projects. It is an ideal model for the product where
requirements are not well understood and the final release date is not given.
Big Bang Model - Pros and Cons
The advantage of this Big Bang Model is that it is very simple and requires very little or no
planning. Easy to manage and no formal procedure are required.
However, the Big Bang Model is a very high risk model and changes in the requirements or
misunderstood requirements may even lead to complete reversal or scraping of the project. It
is ideal for repetitive or small projects with minimum risks.

Dept. of Computer Science Page 11 of 34

 Unit 1: Software Testing Background

The advantages of the Big Bang Model are as follows −

 This is a very simple model
 Little or no planning required
 Easy to manage
 Very few resources required
 Gives flexibility to developers
 It is a good learning aid for new comers or students.
The disadvantages of the Big Bang Model are as follows −
 Very High risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Can turn out to be very expensive if requirements are misunderstood.

Code-and-fix Model
The first model of software development is not really a model but, the model is used in small
projects. That model is the code and fix model.
It is a simple two phase mode, in first phase code is developed and in second phase fixes the
code until the client not satisfied then deliver the product to client.

In code and fix model there are no required documentation, no quality assurance, no formal
requirements or formal testing and delivery is haphazard at best.

Dept. of Computer Science Page 12 of 34

 Unit 1: Software Testing Background

Do not even think about schedules and effort estimates when this model used. It tells take a
minimal amount of time to understand the problem then start code. Run or compile your
code and try it out. If it is not working, fix that first problem and try it again.
Continue this process of type compile – run – fix until program work what you want with no
errors and then ship it.
Every programmer knows and understands this model. This model is work for quick,
disposable tasks. For example, this model works better for proof – of – concept programs.
No maintenance includes. The model works good for small and single – person programs.
Advantage
 Requires less experience to execute or manage other than the ability to program.
 Suitable for smaller software.
 Requires less project planning.
Disadvantage
 No real means is available of assessing the progress, quality, and risks.
 It is difficult to accommodate changes.
 Cost of using this process model is high as it requires rework until user's
requirements are accomplished.
 Informal design of the software as it involves unplanned procedure.
 Maintenance of these models is problematic.

WATERFALL MODEL
The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model.

Dept. of Computer Science Page 13 of 34

 Unit 1: Software Testing Background

In a waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
In "The Waterfall" approach, the whole process of software development is divided into
separate phases. Typically, the outcome of one phase acts as the input for the next phase
sequentially.
The sequential phases in Waterfall model are:
 Requirement Gathering and analysis − All possible requirements of the system to
be developed are captured in this phase and documented in a requirement
specification document.
 System Design − the requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
 Implementation − with inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model".
Waterfall Model – Advantages
 Simple and easy to understand and use.
 For smaller projects, waterfall model works well and yield the appropriate results.
 Since the phases are rigid and precise, one phase is done one at a time, it is easy to
maintain.
 The entry and exit criteria are well defined, so it easy and systematic to proceed with
quality.
 Results are well documented.
The advantages of waterfall development are that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one. Development moves
from concept, through design, implementation, testing, installation, troubleshooting, and
ends up at operation and maintenance. Each phase of development proceeds in strict order.

Dept. of Computer Science Page 14 of 34

 Unit 1: Software Testing Background

Waterfall Model - Disadvantages

 Cannot adopt the changes in requirements
 It becomes very difficult to move back to the phase. For example, if the application
has now moved to the testing stage and there is a change in requirement, It becomes
difficult to go back and change it.
 Delivery of the final product is late as there is no prototype which is demonstrated
intermediately.
 For bigger and complex projects, this model is not good as a risk factor is higher.
 Not suitable for the projects where requirements are changed frequently.
 Does not work for long and ongoing projects.
 Since the testing is done at a later stage, it does not allow identifying the challenges
and risks in the earlier phase so the risk mitigation strategy is difficult to prepare.
The disadvantage of waterfall development is that it does not allow much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.

SPIRAL MODEL
Spiral Model is a combination of a waterfall model and iterative model. The model consists
of four phases - planning, risk analysis, design engineering and customer evaluation. The
four phases are iteratively followed till the problems are rectified. Two to three prototypes
are developed before the final product is delivered. Each prototype follows the entire cycle to
solve problems. This method of software development enables to understand the problems
associated with a particular phase and deals with those problems when the same phase is
repeated again.
The various phases involved in each cycle are,
1. Plan:
In this phase, the specifications, objectives, constraints, and alternatives of the project are
listed in logical order as per the project requirements. The objectives and specifications are
defined in order to decide the strategies to be followed during the project life cycle.
2. Risk Analysis:
This is a very crucial phase of spiral model. During this phase, all the alternatives that are
helpful in developing a cost effective project are analyzed and all possible risks involved in
the project development are identified.
3. Design Engineering:
This is the phase where the actual development of the software takes place. The software
product is developed iteratively and passed on to the next phase.
4. Testing:
In this phase, the customer receives the product and gives comments and suggestions which
can help in identifying and resolving potential problems in the developed software. During
this cycle all the phases concentrate on the feedback received from the customer and the
testing team to resolve the drawbacks and bugs found in each prototype of the product.

Dept. of Computer Science Page 15 of 34

 Unit 1: Software Testing Background

The main drawback of the model is the amount of time taken to complete the iterations
which can increase costs. Testing at the customer’s end and fixing of bugs might require
higher cost and time.
The figure 1.2 is the pictorial representation of spiral model.

 One of the oldest types of SDLC, where the development process is carried out,
incrementally and iteratively, in a systematic and speedy way.
 It is a risk-driven approach, which focuses on continuous risk-evaluation and
improvement of the software product, through one or more than one iteration.
 An effective approach to meet the constantly changing and continuous requirements.
 Good methodology for the software that continuously requires risk evaluation.
 Effective for the larger projects and is considered not suitable for the small projects.
 However, it demands more cost and involves complex requirements.
 It may undergo infinite iterations.

Dept. of Computer Science Page 16 of 34

 Unit 1: Software Testing Background

WHITE BOX TESTING:

White box testing is a way of testing the external functionality of the code by examining and
testing the program code that realizes the external functionality this is also known as clear
box or glass box or open box testing.
White box testing takes into account the program code, code structure and internal design
flow. In contrast black box testing does not look at the program code but looks at the product
from an external perspective.
A number of defects come about because of incorrect translation of requirements and design
into program code. Some other defect created by programming errors and programming
language idiosyncrasies.
White box testing is classified into Static and Structural testing.
Static testing:
Static testing is a type of testing which requires only source code of the product not the
binaries are executables.
Static testing does not involve executing programs on computers but involves select people
going through the code to find out whether
 the code works according to the functional requirement
 the code has been written in accordance with the design developed earlier in the
project life cycle
 the code for any functionalities has been missed out
 the code handles errors properly static testing can be done by humans are with the
help of specialised tools
Static testing by humans
These methods relay on principle of humans reading the program code to detect error rather
than computers executing the code to find errors.
There are multiple methods to achieve static testing by humans.
1. Desk checking of the code
2. Code Walkthrough
3. Code review
4. Code inspection
Since static testing by humans is done before the code is compiled and executed, some of
these methods can be viewed as process oriented or defect-prevention oriented or quality
assurance oriented activities rather than pure testing activities.
Desk checking:
Normally done manually by author of the code, desk checking is a method to verify the
portions of the code for correctness. such verification is done by comparing the code with the
design or specification to make sure the code does what it is supposed to do and effectively.
This is Desk checking that most programmers do before compiling and executing the code.
Whenever errors are found the author applies the corrections for errors on the spot. this
method of catching and correcting Errors is characterized by
1. No structured method for Formalism to ensure completeness and
2. No maintaining of a log or checklist.

Dept. of Computer Science Page 17 of 34

 Unit 1: Software Testing Background

The main advantage offered by this method is that the programmer knows the code and the
programming language very well is well equipped to read and understand his or her own
code.
Some of the disadvantages of this method of testing are as follows
1. A developer is not the best person to detect problems in his or her own code. He or
She maybe tunnel visioned and have blind spots to certain types of problems
2. Developers generally preferred to write new code rather than do any forms of testing
3. This method is essentially person dependent and informal and does not work
consistently across all developers
Owing to this disadvantages the next to two types of proactive methods are introduced. The
basic principle of walkthroughs and formal inspections is to involve multiple people in the
review process.
Code walkthrough:
This method and formal inspection are group oriented methods. Walkthroughs are less
formal than inspections. The line drawn in Formalism between walkthroughs and inspections
is very thin and varies from organisation to organisation.
The advantage that Walkthrough has over desk checking is that it brings multiple
perspectives. In walkthroughs, a set of people look at the program code and raise questions
for the author. The author explains the logic of the code, and answers the questions. if the
author is unable to answer some questions, he or she then takes those questions and finds
their answers. Completeness is limited to the area where questions are raised by the team.
Formal inspection:
Code inspection also called Fagon inspection (named after the original formulator) is a
method, normally with the high degree of Formalism. The focus of this method is to detect all
faults, violations and other side effects.
This method increases the number of defects detected by
 demanding through preparations before and inspection/review
 enlisting multiple diverse views;
 assigning specific roles to multiple participants; and
 going sequentially through the code in the structured manner.
A formal inspection should take place only when the author has made sure the code is ready
for inspection by performing some basic desk checking and walkthroughs
When the code is in such a reasonable state of readiness, an inspection meeting is arranged.
There are four rules in inspection.
 First is the author of the code.
 Second is a moderator who is expected to formally run the inspection according to the
process.
 Third are the inspectors.
These are the people who actually provide reviews comments for the code. There are
typically multiple inspectors. Finally there is a Scribe who takes detailed notes during the
inspection meeting and circulates them to the inspection team after the meeting.
The author or the moderator selects the review team. The chosen members have the skill sets
to cover as many defects as possible. In introductory meeting the Inspector get copies of the

Dept. of Computer Science Page 18 of 34

 Unit 1: Software Testing Background

court to be inspected along with the other supporting document such as design document,
requirements documents and any documentation of applicable standards. The author also
presents his or her perspective of what program is intended to do along with any specific
issues that that he or she may I want the inspection team to put extra focus on.
The moderator inform the team about the date time and venue of the inspection meeting the
inspectors get adequate time to go through the documents and programs and ascertain their
compliance to the requirements, design and Standards.
Structural testing:
Structural testing takes into account the code, code structure, internal design and how they are
coded. The fundamental difference between Structural testing and static testing is that in
Structural testing test are actually run by computer on the built product whereas in static
testing the product is tested by humans using just the source course and not the executable or
binaries.
Structural testing entails running the actual product against some pre-designed test cases to
exercise as much of the code as possible or necessary.
A given portion of the code is exercised if a test case causes the program to execute that
portion of the code when running the test.
Structural testing can be further classified into
1. Unit/Code functional testing
2. Code coverage
3. Code complexity testing
Unit/Code functional testing:
The initial part of Structural testing corresponds to some quick checks that a developer
performs before subjecting the code to more extensive code coverage testing for code
complexity testing.
This can happen by several methods
 Initially the developers can perform certain obvious tests, knowing the input variables
and the corresponding expected output variables.
 For models with Complex logic or conditions, the developer can build a “debug
version” of the product by putting intermediate print statement and make sure the
program is passing through the right loops and iterations the right number of times.
It is important to remove the intermediate print statements after the defects are fixed.
 Another approach to do the initial tests to run the product under a debugger or an
integrated development environment (IDE) this tools Allows single stepping of
instructions (allowing the developer to stop at the end of each instruction, view or
modify the contents of a variables and so on), setting breakpoints at any function or
instructions and weaving the various system parameters are program variable values.
Code coverage testing
Since a product is released in terms of program code, if we can run test cases to exercise the
different parts of the code, then the part of the product released by the code gets tested.
Code coverage testing involves designing and executing test cases and finding out the
percentage of code that is covered by testing. The percentage of code covered by a test is
found by adopting a technique called instrumentation of code.

Dept. of Computer Science Page 19 of 34

 Unit 1: Software Testing Background

Code coverage testing is made up of the following types of coverage

1. Statement coverage
2. Path coverage
3. Condition coverage
4. Function coverage
Statement coverage:
Program constructs in most conventional programming language can be classified as
 Sequential control flow
 Two way decision statements like if then else
 Multi-way decision statements like switch
 Loop like while doing repeat until and for
For a section of code that consists of statements that are sequentially executed (that is, with
no conditional branches) test cases can be designed to run through from top to bottom. A test
case that starts at the top would generally have to go through the full section till the bottom of
the section. However, this may not always be true.
When we consider two-way decision construct like the if statement then to cover all the
statements, we should also cover the then and else parts of the if statement this means we
should have for each if then else, (at least) one test case to test the then path and (at least) one
test case to test the else part.
The multi-way decision construct 50 which statement can be reduced to multiple two-way if
statements. Thus to cover all possible switch cases there would be multiple test cases.
Loop constructs present more variations to take care of. A loop in various forms such as for,
while, repeat and so on is characterized by executing a set of statements repeatedly until or
while certain conditions are met.
Path coverage
In path coverage we split a program into number of distinct paths. A program (or a part of a
program) can start from the beginning and take any of the paths to its completion.
Let us take an example of a date validation routine. Date is accepted as three fields mm, dd
and yyyy. We have assumed that Prior to entering this runtime, the values are checked to be
numeric. To simplify the discussion we have assume that existence of a function called
leapyear which will return true if the given year is a leap year. There is an array called
dayofmonth which contains the number of days in each month. A simplified flowchart for
this given below as can be seen from the figure there are different paths that can taken
through the programme.
Some of the paths are:
• A

• A-B

• A-C-D

• A-C-E-F

• A-C-E-G

Dept. of Computer Science Page 20 of 34

 Unit 1: Software Testing Background

Regardless of number of statements in each of these paths we can execute these paths, then
we would have covered most of the typical scenarios.
Condition coverage:
It is necessary to have test cases that exercise each Boolean expression and have a test cases
test produces the true as well as false paths.
Obviously this will mean more test cases and number of test cases will rise exponentially
with number of conditions and Boolean expressions however in reality the situation may not
be very bad as these conditions usually have some dependencies on one another.
The condition coverage as defined by the formula alongside in the margin gives an indication
of the percentage of conditions covered by a set of test cases.
Condition coverage is stronger criteria then path coverage which in turn is a much stronger
than statement coverage.
Function coverage:
This is a new addition to Structural testing to identify how many program functions are
covered by test cases.
The requirements of the product are mapped into functions during the design phase and each
of the functions form a logical unit. For example in a database software, “inserting a row into
the database” could be a function or, in a payroll application, “calculate tax” could be a
function. Each function could in turn be implemented using the other functions. While
providing the function coverage, test cases can be written so as to exercise each of the
different functions in the code.

Dept. of Computer Science Page 21 of 34

 Unit 1: Software Testing Background

Black box testing

Black box testing involves looking at the specification and does not require examining the
code of a program. Black box testing is done without the knowledge of the internals of the
system under test. Black box testing is done from the customer's view. The test engineer
engaged in black box testing only knows the set of inputs and expected outputs and is
unaware of how those inputs are transferred into outputs by the software.
Black box tests are convenient to administer because they use the complete finished product
and do not require any knowledge of its construction.
Black box testing thus 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.
Why black box testing
Black box testing helps in the overall functionality verification of the system under test.
Black box testing is done based on requirements:
It helps in identifying any incomplete, inconsistent requirements 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 and compasses the end user perspective
Since we want to test the behaviour of the product from an external perspective, end-
user perspectives are an integral part of black box testing.
Black box testing and as 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 and invalid inputs. testing from the end user
perspective includes testing for this errors are invalid conditions This ensures that the
product behave as expected in a varied situation and does not hang are crash when
provided with an invalid input these are called positive and negative test cases
When to do black box testing
Black box testing activities requires involvement of the testing team from the beginning of
the software project life cycle, regardless of the software development life cycle model
chosen for the project.
Tester can get involved right from the requirements gathering and analysis phase for the
system under test. Test scenarios and test data are prepared during the test construction phase
of the test life cycle, when the software is in the design phase
Once the code is ready and delivered for testing, test execution can be done. All the test
scenarios developed during the construction phases are executed. Usually, a subset of these
test scenarios is selected for regression testing.

Dept. of Computer Science Page 22 of 34

 Unit 1: Software Testing Background

How to do black box testing

Black box testing exploits specification to generate test cases in a methodical way to avoid
redundancy and to provide better coverage.
Various techniques to be used to generate test scenarios for effective black box testing:
 Requirements based testing
 Positive and negative testing
 Boundary value analysis
 Decision tables
 Equivalence partitioning
 State based testing
 Compatibility testing
 User documentation testing
 Domain testing
Requirements based testing
Requirements testing deals with validating the requirements given in the software
Requirements Specification (SRS) of the software system.
Not all requirements are explicitly stated; some of the requirements are implicit or implied.
Explicit requirements are stated and documented as a part of requirement specification.
Implied or implicit requirements are those that are not documented but assumed to be
incorporated in the system.
The precondition for requirements testing is a detailed review of the requirement
specification. Requirements review ensures that they are consistent, correct, complete and
testable.
This process ensures that some of the implied requirements are converted and documented as
explicit requirements, thereby bringing better clarity to requirements and making
requirements based testing more effective.
All explicit requirements (from the systems requirements specifications) and implied
requirements (inferred by the test team) are collected and documented as “Test Requirement
Specification” (TRS). Requirement based testing can also be conducted based on such a
TRS, as it captures the testers perspective as well. However, for simplicity we will consider
SRS and TRS to be one and the same.
Requirements are tracked by Requirements Traceability Matrix (RTM). An RTM traces all
the requirements from their genesis through design, development and testing. This Matrix
evolves through the life cycle of the project. Each requirement is given a unique ID along
with the brief description. The requirement identifier and description can be taken from the
requirement specification or any other available documents that list the requirements to be
tested for the product.
Each requirement is assigned a requirement priority, classified as high, medium or low. This
not only enables prioritising the resources for development of features but it also used to
sequence and run tests.
Tests for higher priority requirements will get precedence over test for lower priority
requirements. This ensures that the functionality that has the highest risk is tested earlier in
the cycle. Defects reported by such testing can be fixed as early as possible.

Dept. of Computer Science Page 23 of 34

 Unit 1: Software Testing Background

The “test conditions” column list the different ways of testing the requirement. Identification
of all the test conditions gives a comfort feeling that we have not miss any scenario that
would produce a defect in the end user environment. These conditions can be grouped
together to form a single test case. Alternatively, each test conditions can be mapped to one
test case.
The “test case IDs” column can be used to complete the mapping between the test cases and
the requirements. Test case ID should follow naming conventions so as to enhance their
usability. Test cases are serially numbered and prefixed with the name of the product. In a
more Complex product made up of multiple models, a test case Id may be identified by a
module code and serial number.
Once the test case creation is completed the RTM helps in identifying the relationship
between the requirements and test cases.
The following combinations are possible
 One to one - for each requirements there is one test case
 One to many - for each requirement there are many test cases
 Many to one - a set of requirements can be tested by one test case
 Many to many - mini requirements can be tested by many test cases
 One to none - the set of requirements can have no test cases. The test team can take a
decision not to test the Requirements due to non implementation are the requirements
being low priority.
Requirement is subjected to multiple faces of testing - unit, component, integration and
system testing. This reference to the faces of testing can be provided in a column in the
requirement traceability matrix. This column indicates when a requirement will be tested and
at what phase of testing it needs to be considered for testing.
Requirement Traceability Matrix table format:
Req Description Priority Test Test Case Phase of
ID (H,M,L) Conditions Ids testing

BOUNDARY VALUE ANALYSIS:

Conditions and boundaries are two major sources of defects in software product. Most of the
defects in software products hover around conditions and boundaries. By conditions, we
mean situations wherein, based on the values of various variables, certain actions would have
to be taken. By boundaries, we mean “limits” of values of the various variables.
Boundary value analysis, a method useful for arriving at tests that are effective in catching
defects that happen at boundaries. Boundary value analysis believes and extends the concept
that the Destiny of defect is more towards the boundaries.
To illustrate the concept of errors that happened at boundaries, let us consider a building
system that offer volume discounts to customers.
Most of us would be familiar with the concept of volume discounts when we buy goods- buy
one packet of chips for 1.59 rupees but three for Rupees 4. It becomes economical for the
buyer to buy in bulk.

Dept. of Computer Science Page 24 of 34

 Unit 1: Software Testing Background

From the sellers point of view also, so it is economical to sell in bulk because the seller incurs
less of storage and inventory costs and has a better cash flow.
Let us consider a hypothetical store that sells certain commodities and offer different pricing
for people buying in different quantities that is surprised in different slabs.

Number of units bought price per unit

First 10 units( that is from 1 to 10 units) 5 rupees

Next 10 units( that is from units 11 to 20 units ) 4.75 rupees

Next 10 units (that is from units 21 to 30 units) 4.50 rupees

More than 30 units 4 rupees

From the above table it is clear that if we buy 5 units we pay 5*5=25. If we buy 11 units we
pay 5*10=50 for the first 10 units and rupees 4.75 for the eleventh item. Similarly if we buy
15 units we will pay 10*5+5*4.75 = 73.75 rupees.
The question from a testing perspective for the above problem is what test data is likely to
reveal the most number of defects in the program? Generally it has been found that most
effects in the situation such as this happen around the boundaries for example when buying 9,
10, 11, 19, 20, 21, 29, 30, 31, and similar number of items.
While the reason for this phenomenon is not entirely clear, some possible reasons are as
follows.
Programmers tentativeness in using the right comparison operator for example weather to use
<= operator or < operator when trying to make comparisons.
Confusion caused by availability of multiple ways to implement loops and condition
checking. For example, in a programming language like C, we have for loop, while loop and
repeat loops. Each of these have different terminating conditions for the loop and this could
cause some confusion in deciding which operator to use, thus skewing the defects around the
boundary conditions.
The requirements themselves may not be clearly understood, especially around the
boundaries, thus causing even the correctly coded program to not perform the correct way.
In the above case, the tests that should be performed and expected values of the output
variable (the cost of the units ordered) are given in table below. This table only includes the
positive test cases. Negative test cases like a non-numeric are not included here. The circled
rows are boundary values which are more likely to uncover the defects then the rows that are
not circled.

Dept. of Computer Science Page 25 of 34

 Unit 1: Software Testing Background

Value expected
to be why this value should be tested value of the
tested output
1 the beginning of the first slab 5.00 rupees
5 a value in the first slab, removed from the boundaries 25.00 rupees
9 just below the second slab are just at the end of the first slab 45.00 rupees
10 the limit for the second slab 50.00 rupees
11 just above the first lab, just into the second slab 54.75 rupees
16 a value in the second slab, removed from the boundaries 28.50 rupees
19 just below the third slab are just at the end of second slab 92.75 rupees
20 the limit for the third slab 97.50 rupees
21 just above the third slab, just into the third slab 102.00 rupees
27 a value in the third slab, removed from the boundaries 129.00 rupees
29 just below the fourth slab or just at the end of third slab 138.00 rupees
30 the limit for the fourth slab 142.50 rupees
31 Just above the fourth slab 146.50 rupees
50 Well above the lower limit for the fourth slab 182.50 rupees

To summarise boundary value testing

 Look for any kind of graduation or discontinuity in data values which affect
computation- the discount unities are the boundary values, which require thorough
testing.
 Look for any internal limits such as limits on resources. The behaviour of the product
at these limits should also be the subject of boundary value testing.
 Also included in the list of boundary values, documented limits on hardware
resources. For example, if it is documented that a product will run with minimum 4
Mb of RAM, make sure you include test cases for the minimum RAM (4mb in this
case).
 The examples given above discuss boundary conditions for input data- the same
analysis needs to be done for output variables also.
Boundary values and decisions tables help identify the test cases that are most likely to
uncover defects. Generalisation of both these concepts is the concept of equivalent classes.
DECISION TABLE TESTING:
Decision table testing is a software testing technique used to test system behavior for
different input combinations. This is a systematic approach where the different input
combinations and their corresponding system behavior (Output) are captured in a tabular
form. That is why it is also called as a Cause-Effect table where Cause and effects are
captured for better test coverage.
A Decision Table is useful when input and the output data can be expressed as Boolean
conditions (TRUE, FALSE, and DON’T CARE).
Advantages of Decision Table Testing
 When the system behavior is different for different input and not same for a range of
inputs, both equivalent partitioning, and boundary value analysis won't help, but
decision table can be used.

Dept. of Computer Science Page 26 of 34

 Unit 1: Software Testing Background

 The representation is simple so that it can be easily interpreted and is used for
development and business as well.
 This table will help to make effective combinations and can ensure a better coverage
for testing
 Any complex business conditions can be easily turned into decision tables
 In a case we are going for 100% coverage typically when the input combinations are
low, this technique can ensure the coverage.
Disadvantages of Decision Table Testing
The main disadvantage is that when the number of input increases the table will become more
complex.
A Decision Table is a tabular representation of inputs versus rules/cases/test conditions.
Let's learn with an example:
How to make Decision Base Table for Login Screen
Let's create a decision table for a login screen.

The condition is simple if the user provides correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.

Rule Rule Rule Rule

Conditions
1 2 3 4
Username (T/F) F T F T
Password (T/F) F F T T
Output (E/H) E E E H
Legend:
 T – Correct username/password
 F – Wrong username/password
 E – Error message is displayed
 H – Home screen is displayed

Dept. of Computer Science Page 27 of 34

 Unit 1: Software Testing Background

Interpretation:
 Case 1 – Username and password both were wrong. The user is shown an error
message.
 Case 2 – Username was correct, but the password was wrong. The user is shown an
error message.
 Case 3 – Username was wrong, but the password was correct. The user is shown an
error message.
 Case 4 – Username and password both were correct, and the user navigated to
homepage
While converting this to test case, we can create 2 scenarios,
 Enter correct username and correct password and click on login, and the expected
result will be the user should be navigated to homepage
And one from the below scenario
 Enter wrong username and wrong password and click on login, and the expected
result will be the user should get an error message
 Enter correct username and wrong password and click on login, and the expected
result will be the user should get an error message
 Enter wrong username and correct password and click on login, and the expected
result will be the user should get an error message
EQUIVALENCE PARTITIONING:
Equivalence Partitioning is also known as Equivalence Class Partitioning. In equivalence
partitioning, inputs to the software or system are divided into groups that are expected to
exhibit similar behavior, so they are likely to be proposed in the same way. Hence selecting
one input from each group to design the test cases.
Each and every condition of particular partition (group) works as same as other. If a condition
in a partition is valid, other conditions are valid too. If a condition in a partition is invalid,
other conditions are invalid too.
It helps to reduce the total number of test cases from infinite to finite. The selected test cases
from these groups ensure coverage of all possible scenarios.
Equivalence partitioning is applicable at all levels of testing.
Example on Equivalence Partitioning Test Case Design Technique:
Example 1:
Assume, we have to test a field which accepts Age 18 – 56

Dept. of Computer Science Page 28 of 34

 Unit 1: Software Testing Background

Valid Input: 18 – 56
Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57 (>=57)
Valid Class: 18 – 56 = Pick any one input test data from 18 – 56
Invalid Class 1: <=17 = Pick any one input test data less than or equal to 17
Invalid Class 2: >=57 = Pick any one input test data greater than or equal to 57
We have one valid and two invalid conditions here.
Example 2:
Assume, we have to test a filed which accepts a Mobile Number of ten digits.

Valid input: 10 digits

Invalid Input: 9 digits, 11 digits
Valid Class: Enter 10 digit mobile number = 9876543210
Invalid Class Enter mobile number which has less than 10 digits = 987654321
Invalid Class Enter mobile number which has more than 11 digits = 98765432109

STATE OR GRAPH BASED TESTING

Change of sate from one state to another. State based Testing is useful to generate the test
cases for state machines as it has a dynamic behavior (multiple states) in its system.
Can explain this using state transition diagram. It is a graphic representation of a state
machine.
State Transition testing is defined as the software testing technique in which changes in input
conditions cause's state changes in the Application under Test (AUT).
It is a black box testing technique in which the tester analyzes the behavior of an application
under test for different input conditions in a sequence. In this technique, tester provides both
positive and negative input test values and record the system behavior.
It is the model on which the system and the tests are based. Any system where you get a
different output for the same input, depending on what has happened before, is a finite state
system.
State Transition Testing Technique is helpful where you need to test different system
transitions.

Dept. of Computer Science Page 29 of 34

 Unit 1: Software Testing Background

When to Use State Transition?

 This can be used when a tester is testing the application for a finite set of input values.
 When the tester is trying to test sequence of events that occur in the application under
test. I.e., this will allow the tester to test the application behavior for a sequence of
input values.
 When the system under test has a dependency on the events/values in the past.
When to Not Rely On State Transition?
 When the testing is not done for sequential input combinations.
 If the testing is to be done for different functionalities like exploratory testing
Four Parts of State Transition Diagram
There are 4 main components of the State Transition Model as below
1) States that the software might get
2) Transition from one state to another
3) Events that origin a transition like closing a file or withdrawing money
4) Actions that result from a transition (an error message or being given the cash.)
State Transition Diagram and State Transition Table
There are two main ways to represent or design state transition, State transition diagram, and
state transition table.
In state transition diagram the states are shown in boxed texts, and the transition is
represented by arrows. It is also called State Chart or Graph. It is useful in identifying valid
transitions.
In state transition table all the states are listed on the left side, and the events are described on
the top. Each cell in the table represents the state of the system after the event has occurred. It
is also called State Table. It is useful in identifying invalid transitions.
How to Make a State Transition
Example 1:
Let's consider an ATM system function where if the user enters the invalid password three
times the account will be locked.
In this system, if the user enters a valid password in any of the first three attempts the user
will be logged in successfully. If the user enters the invalid password in the first or second
try, the user will be asked to re-enter the password. And finally, if the user enters incorrect
password 3rd time, the account will be blocked.
State transition diagram
In the diagram whenever the user enters the correct PIN he is moved to Access granted state,
and if he enters the wrong password he is moved to next try and if he does the same for the
3rd time the account blocked state is reached.

Dept. of Computer Science Page 30 of 34

 Unit 1: Software Testing Background

State Transition Table

Correct PIN Incorrect PIN
S1) Start S5 S2
S2) 1st attempt S5 S3
S3) 2nd attempt S5 S4
S4) 3rd attempt S5 S6
S5) Access Granted - -
S6) Account blocked - -
In the table when the user enters the correct PIN, state is transitioned to S5 which is Access
granted. And if the user enters a wrong password he is moved to next state. If he does the
same 3rd time, he will reach the account blocked state.

COMPATIBILITY TESTING
Compatibility Testing is a type of Software testing to check whether your software is capable
of running on different hardware, operating systems, applications, network environments
or Mobile devices. Compatibility Testing is a type of Non-functional testing.
Types of Compatibility Tests
 Hardware
 Operating systems
 Software
 Air network
 Browser
 Devices
 Mobile
 Versions

Dept. of Computer Science Page 31 of 34

 Unit 1: Software Testing Background

Compatibility testing types:

Hardware: It checks software to be compatible with different hardware configurations.
Operating Systems: It checks your software to be compatible with different Operating
Systems like Windows, Unix, Mac OS etc.
Software: It checks your developed software to be compatible with other software. For
example, MS Word application should be compatible with other software like MS Outlook,
MS Excel, VBA etc.
Network: Evaluation of performance of a system in a network with varying parameters such
as Bandwidth, Operating speed, Capacity. It also checks application in different networks
with all parameters mentioned earlier.
Browser: It checks the compatibility of your website with different browsers like Firefox,
Google Chrome, Internet Explorer etc.
Devices: It checks compatibility of your software with different devices like USB port
Devices, Printers and Scanners, Other media devices and Blue tooth.
Mobile: Checking your software is compatible with mobile platforms like Android, iOS etc.
Versions of the software: It is verifying your software application to be compatible with
different versions of the software. For instance checking your Microsoft Word to be
compatible with Windows 7, Windows 7 SP1, Windows 7 SP2, Windows 7 SP3.
There are two types of version checking

Backward compatibility Testing is to verify the 32ehaviour of the developed

hardware/software with the older versions of the hardware/software.
Forward compatibility Testing is to verify the 32ehaviour of the developed
hardware/software with the newer versions of the hardware/software.
Tools for Compatibility Testing:

BrowserStack - Browser Compatibility Testing: This tool helps a Software engineer to check
application in different browsers.

Dept. of Computer Science Page 32 of 34

 Unit 1: Software Testing Background

Virtual Desktops - Operating System Compatibility: This is used to run the applications in
multiple operating systems as virtual machines. n Number of systems can be connected and
compare the results.
How to do Compatibility Testing
 The initial phase of compatibility testing is to define the set of environments or
platforms the application is expected to work on.
 The tester should have enough knowledge of the platforms/software/hardware to
understand the expected application behavior under different configurations.
 The environment needs to be set-up for testing with different platforms, devices,
networks to check whether your application runs well under different configurations.
 Report the bugs. Fix the defects. Re-test to confirm Defect fixing.
Conclusion:
The most important use of compatibility testing is to ensure whether developed software
works under different configurations (as stated in requirements documentation). This testing
is necessary to check whether the application is compatible with the client's environment.

USER DOCUMENTATION TESTING

User Documentation covers all the Manuals, User guides, Installation guides, Setup guides,
Read me files, Software release notes, and Online help that are provided along with the
software to help the end user to understand the software system.
User Documentation Testing should have two objectives:-
 To check, if what is stated in the document is available in the software.
 To check, if what is there in the product is explained correctly in the document.
User Documentation is done to ensure the documentation matches the product and vice-versa.

DOMAIN TESTING
Domain testing is a software testing technique in which selecting a small number of test cases
from a nearly infinite group of test cases. For testing few applications, Domain specific
knowledge plays a very crucial role.
Domain testing is a type of functional testing and tests the application by feeding interesting
inputs and evaluating its outputs.
Is domain knowledge needed for domain testing?
Some may say this is not necessary. But it is quite difficult for anyone to perform effectively
or efficiently in a terrain he/she is not conversant with. If one is to do well, therefore, as a
domain tester, there is the need to have basic domain knowledge. Now, let’s look at a few
reasons why this is important.
Online banking: Some of the basic things that a tester needs to test as far as online banking
is concerned are login, bill payment, transfers, and lots more. A tester might require essential
testing knowledge in order to login. However, doing bill payments and transfers require that
the tester has to be an expert in the subject matter. He has to be conversant with the business
logic on money flow.

Dept. of Computer Science Page 33 of 34

 Unit 1: Software Testing Background

Retail: Examples of retail domains are Enterprise management, In-store solutions, and
Warehouse management. In order to successfully run a domain test, the tester has to have an
understanding of how things flow at each level. For instance, you need to know some things
regarding a POS before you can successfully run a test on it.
Healthcare system: how would someone who has no knowledge of the system handle it? He
will certainly be a big risk to someone’s life.
Where is domain knowledge needed?
Domain knowledge for effective domain testing is needed in the following key areas:
 Mobile application testing
 Protocol testing
 Network testing
 VoIP applications
 Wireless application testing
 Banking applications
Skills needed for domain testing
If your dream is to be a good domain tester, you need to acquire some important skills. These
skills include
 Testing skill
 Domain knowledge
 Automation skill
 Ability to work under pressure
 Bug hunting skill
 Programming skill
 Communication skill
 Technical skill
 Quick grasping
Conclusion
Domain testing requires that testers should have basic knowledge in the domain they are to
test in order to be able to perform effectively.

Dept. of Computer Science Page 34 of 34