Unit 1

Fundamentals of Software
Testing

Prof. Charudatt Mane

 Points to be covered…
 Introduction
 Basics of Software Testing
 Approaches to Testing
 Testing During Development Life Cycle
 Essentials of Software Testing
 Features of Testing
 Misconceptions about Testing
 Principles of Software Testing
 Introduction

•Software Verification: comparing work product with processes,

standards & guidelines
• Software Validation: activities associated with checking the
outcome of developed product & processes used with respect to
standards and expectations of a customer
• Software testing involves verification as well as validation
activities.
• Testing involves finding the difference between actual
behaviors with respect to the expected behaviors of an
application.
• There are many stages of software testing as per software
development life cycle.
 Historical Perspective of Testing

 Debugging oriented testing

 Demonstration oriented testing
 Destruction oriented testing
 Evaluation oriented testing
 Prevention oriented testing
 Definition of Testing

Testing is defined as “execution of a work product with intent

to find a defect”
The primary role of software testing is not to demonstrate
the correctness of software product, but to expose hidden
defects so that they can be fixed
Testing is done to protect the common users from any failure
of system during usage
This approach is based on the assumption that any amount
of testing cannot show that software product is defect free
Testers are involved mainly to ensure that the system is not
doing what is not supposed to do
These assumptions & risk must be documented in the test
plan while deciding test strategy or test approach
 Why Testing is Necessary?

“If any level of testing cannot declare that there is no

defect in the product, then why is it required at all?”
Necessary reasons
Understanding of customer requirements may differ from
person to person
Development team assume that whatever they have
developed is as per customer requirements and will always
work
Different entities are involved in different phases of software
development.
Developers may have excellent skills of coding but
integration issues can be present when different units do not
work together, even though they work independently
There is a possibility of blindfold & somebody has to work as
the devil‟s representative
 Approaches of Testing
Big Bang approach of Testing
•Big bang approach involve testing software system after
development work is completed
•This is also termed “System testing” or final testing done before
releasing software to the customer for acceptance testing
•Testing done at the end of development cycle may show the
defects pertaining to any phase of development such as
requirements, design, & coding.
•In such type of testing find cascading effect and all defects
found may not be detected.
•It may discover the failures but cannot find the problems
effectively.
•Sometimes, defects found may not be fixed correctly as analysis
and defect fixing can be a problem.
Total Quality Management Approach

•There is a process definition for software testing, and these

processes are optimized and capable, no (less) defects are
produced and no (few) undetected defects are left in the
software when it is delivered to the customer.
•Defect removal costs are approx. 10 times more after coding
than before coding. This is a cost associated with fixing the
problems belonging to requirements, design, coding, etc.
•If defect is not detected earlier but found in acceptance testing
or further down the line during the warranty, it may be much
more costly.
•Defect removal cost would be 100 times more during production
(at user site) than before coding.
•This may involve deploying people at customer site, loss of
goodwill, etc, which is a part of failure cost.
TQM as against Big Bang Approach
•If organization has very good processes defined which are
optimized and capable, and can produce consistent results again
& again, then it gives advantage in productivity and effectiveness
in development .
•It can reduce cost of production significantly.
Stage 0 Cost = 0

Stage 1 Cost = 10

Stage 2 Cost = 100

Stage 3 Cost = 1000

TQM cost triangle

 TQM in Cost Perspective
•TQM defines the cost incurred in development and quality into
three parts as follows:
Cost of Prevention/ Green Money
•Investment by the organisation in doing quality work.
•It is a cost spent in definition of processes, training people, developing
foundation for quality.
•It improves profitability of an organisation.
Cost of Appraisal/ Blue Money
•Cost incurred by the organisation during the development, in the form of
first-time review/testing which gets returned in future. It does not earn
profit, but it is essential part of development process to ensure the
process capability.
•All appraisal techniques used during SDLC such as first time verification
or validation are considered as blue money.
Cost of Failure/ Red Money
•Red money is pure loss of organisation. It involves money lost in scrap,
rework, sorting etc.
•It also represents loss due to various wastes produced during
development life cycle and directly reduces the profit of the organisation
and the customer may not pay for it.
•All cost incurred in re-inspection, retesting and regression testing
represents cost of failure.
 Characteristics of Big Bang Approach
•Big bang approach talks about testing as the last phase of
development. Most of testing is concentrated in this phase only, as
there are no pervious verification and validation activities spread
during the development phases.
•It is characterised by huge rework, retesting, scrap, sorting of
software components and programs after the complete software is
built. All the defects are found in the last phase and cost of rework
can be huge.
•Big band works only on correction, and there are no corrective and
preventive actions and process improvements arising from these
defects.
•Regression testing reveals many issues, as correction may not be
correct and introduce some defects in the product. When some areas
in the software units are touched for correction or fixing of defect,
dependent components may get affected in a negative way. These
may be termed as “regression defects”.
•All requirements and designs cannot be covered in testing. As the
schedule of delivery is fixed. Testing done in a hurry, and many
iterations of defect fixing and testing are done in the shortest
possible time.
•Generally, positive testing is done to prove that software is correct.
 Definitions of Software Testing
•Testing is done to establish confidence that the program does what
it is supposed to do. It generally covers the functionality and
features expected in the software under testing. It covers only
positive testing.
•Testing is a process of demonstrating that errors are not present in
the product. This approach is used in the acceptance testing where
if the application meets acceptance criteria, then it must be
accepted by the customer.
•Testing gives number of defects present which indirectly gives a
measurement of software quality. More number of defects indicate
bad software and bad processes of development.
•Testing is done to evaluate the program or system used for making
software. As we consider that defects are introduced due to
incapable processes, testing may be used to measure process
capability to some extent.
•Testing used to confirm that a program performs its intended
functions correctly. Intended functionality may be defined from
requirement specifications.
•If testing is defined as process, then it is designed to,
•Prove that the program is error free or there is no defect present
•Establish that software performs its functions correctly and is fit
for use
•Establish that all expectations of functionalities are available

•Testing is completely guided by software requirement specifications

and design specifications, and supported by test strategy and test
approach depending on assumptions and risks of development,
testing and usage.

•Process of executing a program with the intention of finding defects.

It is expected that these defects may be fixed by the development
team during correction, and the root causes of the defects are also
found and closed during corrective actions. This can improve
development process.
 Objectives of Testing
•Find a scenario where the product does not do what it is supposed to
do. This is as deviation from the requirement specifications

•Find a scenario where the product does things it is not supposed to

do. This includes risk

•This first part refers to specifications which were not satisfied by

the product while the second part refers to unwanted side effects
while using the product.
 Testing during Development Life Cycle

•Life cycle phases and testing associated with it

•Requirement Testing
•It involves mock running of future application using the
requirement statements to ensure that requirements meet their
acceptance criteria.
•This type of testing is used to evaluate whether all requirements
are covered in requirement statement or not.
•This type of testing is similar to building use cases from the
requirement statement.
•Requirement testing differs from verification of requirements.
•Theoretically, each statement in requirement document must
give atleast one functional/ non-functional test scenario which
may result into test cases.
•Requirements must be prioritized as “must”, “should be” and
“could be” requirements.
•Requirement validation must define end-to-end scenario
completely so that there is no gap.
•Design Testing

•It involves testing of high-level design (system architecture) as

well as low-level design (detail design).
•High-level design testing covers mock running of future
application with other prerequisites, as if it is being executed by
the targeted user in production environment.
•This testing is similar to developing flow diagrams from designs,
where flow of information is tracked from start to finish. When
flow is complete, the design may be considered as good.
•For low-level design, system requirements and technical
requirements are mapped with the entities created in design to
ensure adequacy of detail design.
•Design verification talks about reviewing the design, by experts.
•It involves usage of standards, templates and guidelines defined
for creating these designs.
•Design verification ensures that designs meet their exit criteria.
•Code Testing
•Code files, tables and stored procedures are written by
developers as per guidelines and detail design specifications.
•Code testing (unit testing) is done by using drivers as required.
•Code review ensures that code file written are readable,
maintainable in future. Comments, testable in unit testing.
Traceable with requirements and designs. Reusability

•Test Scenario and Test Case Testing

•Test scenario are written by testers to address testing needs of a
software application.
•Test cases are derived from test scenarios which are related to
requirements and designs.
•Test scenario should be clear and complete, representing end to
end relationship of what is going to happen and also, possible
outcomes of such processing
•Test scenario should cover all requirements. Feasible, prioritised
•Test cases should cover all scenarios completely.
•Both must be prioritised so that in case of less time availability,
the major part of the system(where priority is higher) is tested.
 Essentials of Software Testing
Software testing is a disciplined approach.
It works on principle that no software is defect free, but less
risky software is better and more acceptable to users.
Completion of testing must yield number of defects which can
be analysed to find the weaker areas in the process of
software development.
Software testing is also viewed as an exercise of doing a
SWOT analysis of software product where we can build the
software on the basis of strengths of processes of development
and testing, and overcome weakness in the processes to the
maximum extent possible.

Strengths
Weakness
Opportunity
Threats
 Features of Software Testing
•Testing is a Destructive Process, But it is Constructive Destruction
•Testing needs a Sadistic Approach with a Consideration that there is
a Defect
•If the Test does not Detect a Defect present in the System, it is an
Unsuccessful Test.
•A Test that Detects a Defect is a Valuable Investment for
Development as well as Customer, it helps in Improving a Product
•It is a Risky to develop Software and Not to Test it Before Delivery
•With High Pressure to Deliver Software as Quickly as possible, Test
Process must provide maximum value in shortest Timeframe
•Highest Payback comes from Detecting Defect early in Software
Development Life Cycle and Preventing Defect Leakage/ Defect
Migration from one Phase to Another
•Organisation‟s Aim must be Defect Prevention rather than Finding
and Fixing a Defect
 Misconceptions about Testing

•Anyone can do testing, and no special skills are required for

testing
•Testers can test quality of product at the end of development
process
•Defects found in testing are blamed on developers
•Defects found by customer are blamed on tester
 Principles of Software Testing

•Programmers/team must avoid testing their own work

products
•Thoroughly inspect results of each test to find potential
improvements
•Initiate actions for correction, corrective action and preventive
actions
Test Policy
•Test policy is generally defined by the senior management covering
all aspects of testing.
•It decides the framework of testing and its status in overall mission
of achieving customer satisfaction.
•For project organisation, it may be defined by the client while for
product organisation, it is decided by the senior management.

Test Strategy or Test Approach

•Test strategy defines the action part of test policy.
•It defines the ways and means to achieve the test policy.
•Generally, there is a single test policy at organisation while test
strategy may differ from product to product, customer to customer
and time to time.
•Examples: definition of coverage like requirement coverage or
functional coverage or feature coverage defined for particular
product, project and customer.
•Level of testing, starting from requirements & going to acceptance
Phases of product
•How much testing would be done manually and what can be
automated?
•Number of developers to testers.
Test Planning

•It is first activity of test team

•Test plans are intended to plan for testing throughout SDLC.
•Test plans are defined in framework created by test strategy and
established by test policy
•Test plan should be realistic and talk about limitations and
constraints of testing. It should talk about risk and assumptions done
during testing.

•Plan testing efforts adequately with assumption that defects are

there
•If defects are not found, it is failure of testing activity
•Successful tester is not one who appreciates development but one
who finds defect in the product
•Testing is not a formality to be completed at the end of development
cycle
•Testing is not a certifying process.
•It is a life cycle activity and should not be the last part of a
development life cycle before giving the application to user/cust
Testing Process

•Testing is intended to find more number of defects.

•This is based on the principle that every application has defects and
every test team has some efficiency of finding defects.
•It is governed by the test team‟s defect finding ability
•Organizational Statistical analysis after considerable testing and use
of application by user, the number of defects found is three per KLOC
•Test planning must intend to find three defects per KLOC for the
program under testing.
•Number of defects found after considerable testing will always
indicate possibilities of existing number of defects.
Challenges in Testing
•Testing is challenging job
•On one front, It needs to tackle with problems associated with
development team.
•On second front, it has customers to tackle with management may
have problems with understanding testing approach and may consider
it as an obstacle to be crossed before delivering the product to the
customer.
•Challenges faced by test teams
•Requirements are not clear, complete, consistent, measurable and
testable. These may create problems in defining test scenario and test
cases.
•Requirements may be wrongly documented and interpreted by
business analyst and system analyst. But, Sometimes, they are
prejudiced based on their earlier experience.
•Code logic may be difficult to capture. Testers lack of technical
knowledge. Sometimes, testers don‟t have access to code files.
•Error handling may be difficult to capture. Various error messages and
controls are required: detective, corrective, preventive, suggestive
•Other challenges: bad code, bad architecture, testing as negative
activity and testers situation..more defects->delay & improper testing-
customer complaints are possible
Test Team Approach
•Type of the organisation and type of the product being developed
define a test team.
•There are four approaches of software testing team.

1. Location of Test Teams in an Organisation

• Generally test team is located in an organisation as per test
policy. It may vary from org to org, project to project
a) Independent test team: it may not be reporting to
development group at all, and are independent of development
activities. They may be reporting independently to senior
management or customer. Presence of test manager is
essential to lead the test team.
Advantages:
• no pressure of delivery.
• not under pressure of „not finding‟ a defect
• independent view about a product is obtained as thought
process of developers and testers may be completely
different.
• Expert guidance and mentoring required & available in the
form of a test manager.
Disadvantages:
• „us‟ vs „them‟ mentality between development team and test
team
• Testers are treated as outsiders. No good understanding of
development process
• Management inclined towards development or test team.

b) Test team reporting to Development Manager

• If test team reporting to development manager, then they can
be involved from the start of project till the project closed
Advantages:
• Better co-operation between both teams
• Test team can be involved in development and verification/
validation activities from the start of the project. Good
understanding of requirements
• Testers may get good understanding of development process
and can help in process improvement.
Disadvantages:
• Expert advice in the form test manager may not be available
• development manager are more inclined towards dev. Team
• Often, testers start perceiving the product from developers
angle and their defect finding ability reduces.
2. Developers becoming Testers
• Sometimes, those who work as developers in initial stages of
development life cycle take the role of testers when the latter
stages of life cycle are executed.
• This is common practice while working with simple software
which does not need very structured testing.
Advantages:
• Don‟t need another knowledge transfer while working as tester
• They have better understanding of detail design & coding and
can test the application easily
• For automation, some amount of development skill is required in
writing the automation scripts. They easily adapt in automation
testing
• It is less costly as there is no separate test team. Staff balancing
as initially dev. Team is large, at end testers team
• Acceptance of defects is not major issue as developers
themselves find defects
Disadvantages:
• Developers may not find value in performing testing
• Sometimes, not able to find more defects because of selection
approach and understanding requirements
• Primary responsibility developing and may neglect testing activity
• Testing needs destruction skill and development creation skill
3. Independent Testing Teams

• An organisation may create separate testing team with

independent responsibility of testing.
• Team would have people having sufficient knowledge & ability
to test software.
Advantages:
• Separate test team supposed to concentrate more on test
planning, test strategies and approach, creating test artifact
• There is independent view about the work products derived
from requirement statement.
• Special skills required for doing special tests may be available in
such independent test teams
• „Testers working for customer‟ can be seen in such environment
Disadvantages:
• Separate team means additional cost for an organisation
• Test team needs ramping up and knowledge transfer, similar to
a development team
• An organisation may have to check for rivalries between
development team and test team
4. Domain Experts doing Software Testing

• An organisation may employ domain expert for doing testing

• Generally, this approach is very successful in system testing and
acceptance testing where domain specific testing is required.
• Domain experts may use their experience on the subject matter
for performing such type of testing.
Advantages:
• „Fitness for use‟ can be tested in this approach where actual
user‟s perspective may be obtained. Domain experts will be
testing software from user‟s perspective.
• Domain experts may provide facilitation to developers about
defects and customer expectations and may be able to interpret
requirements in the correct context.
• Domain experts understand the scenario faced by actual users
and hence, their testing is realistic.
Disadvantages
• They may have prejudices about domain which may reflect in
testing. Sometimes they don‟t get what a particular customer
looking for though they have knowledge about a domain
• Difficult to get domain experts in diverse areas
• Huge cost for organisation as their cost is more than developers/
testers
Establishing Testing Policy
•Good testing is a deliberate planned effort by the organisation. It does
not happen on its own, but detailed planning is required.
•Testing efforts need to be driven by test policy, test strategy or
approach, test planning etc.
•Test Policy is an intent of test management about how an organisation
perceives testing and customer satisfaction. It should define test
objectives and test deliverables
•Test strategy or approach must define what steps are required for
performing an effective testing. How test environment will be created,
what tools will be used, defect capturing, defect reporting and number
of test cycles required will be a part of test strategy.
•Test objectives defines what testing will be targeting to achieve. It is
better to have test objectives expressed in numbers in place of
qualitative definitions. Some of test objectives may be about code
coverage, scenario coverage, requirement coverage, whereas others
may define the targeted number of defects.
•Testing must be planned & implemented as per plan. Test plan should
contain test objectives & methods applied for test scenario, test cases
and test data. It should also explain how the results will be declared
and how retesting will be done.
Methods:
•Generally, methods applied for testing efforts are defined at
organizational levels. They are generic, hence need customization.
•They are customized into a test plan, and any tailoring required to
suite a specific project may be done.
•Management directives establish methods applied for testing. Which
part will be tested/ not tested, tools used, defect tracking mechanism,
communication methods, automation-how to
•Management directives are defined in test strategy.
•Testing strategy must be discussed with users/ customer to get their
views/ buy-in about testing. It may be accomplished through meetings

•Methods of using data or inputs provided by a customer must be

analysed for sufficiency and correctness.
Defect, Error, or Mistake in Software
•The problems with software work product may be put under different
categories on the basis of who has found it and when it has been
found.
•Mistake:
•An issue identified while reviewing own documents, or peer review
may be termed as „mistake‟
•Very low cost of finding mistakes and can be fixed immediately
•Most of the time, problems and resolutions are not documented
properly
•Error:
•An issue identified internally or in unit testing may be termed as „error‟
•Slightly more cost of finding an error and needs some time for fixing
•Sometimes, problems and resolutions are documented, but may not be
used for process improvements.
•Defect:
•An issue identified by customer or in black box testing is termed as
„defect‟
•Most costly and needs longer time for fixing defects
•Problems and resolutions are officially documented and used for
process improvements.
Categories of Defects
•Categories must be defined in the Test Plan
•On the basis of Requirement/Design Specification
•Producer‟s gap: variance from product specification as documented in
requirement or design specifications represents specification related
defects
•Consumer‟s gap: variance from customer/user expectations as business
analyst/ system analyst is not able to identify customer need correctly.
These Variance may be in form of implied requirements
•Types of defects
•Wrongly implemented specifications are relate to the specifications as
understood by developers differently from what the customer wants.
These may be termed as „misinterpretation of specifications‟.
•Missing specifications are the specifications that are present in
requirement statements but not available in the final product. The
requirements are missed, as there is no requirement tracing through
product development.
•Features not supported by the specifications but present in the product
represent something extra. This is something added by developers
though these features are not supported by specifications.
Defect Classification
•Defects may be defined as anything which makes customer unhappy.
•It may be a result of wrong implementation of requirements,
something missing that is required by the customer, or putting
something more (extra) than required.

•Requirements defects
•These defects arise in a product when one fails to understand what is
required by the customer.
•These defects may be due to customer gap, where the customer is
unable to define his requirements, or producer gap, where developing
team is not able to make a product as per requirements.
•Requirement related defects further classified as
•Functional defects: related to functionalities present/absent in the
application which are expected/ not expected by the customer.
System testing concentrates on functionality as the first part of
testing
•Interface defects: talks about interfaces essential as per the
requirement statement. These defects may be due to UI problems,
problems with connectivity to other systems including hardware.
•Design defects
•It generally refers to the way of design creation or its usage while
creating a product.
•The customer may or may not be in a position be understand these
defects, if structures are not correct.
•Design related defects may be classified as follows
•Algorithmic defects: it may be introduced in a product if designs
of various decisions are not handled correctly. Various
permutations and combinations may cause defect introduction in
the product.
•Module-interface defects: about communication problems between
various modules. If one module gives some parameters which are
not recognized by another, it creates module-interface defects.
•System-interface defects: it may be generated when application
communication with environmental factors is hampered. System
may not be able to recognize inputs coming from the environment,
or may not be able to give outputs which can be used by the
environment.
•User-interface defects: it may be part of system-interface defects
where the other system working with the application is a human
being. UI defects may be a part of navigation, look & feel type of
defects which affect usability of an application
Coding Defects
•Coding defects may arise when designs are implemented wrongly. If
there is absence of development/ coding standards or if they are
wrong, it may lead to coding defects.
•Variable declaration/ initialization defect
•Database related defects
•Commenting/ documentation defects

•Testing Defects
•It is introduced due to wrong testing, or defects in the test artifacts
leading to wrong testing. Testing defects are very important in terms of
false call where there is no defect in reality.
•Defects which cannot be reproduced, or are not supported by
requirements or are duplicate may represent a false call.
•Test design defects: refers to defects in test artifacts. There can
defects in test plans, test scenarios, test cases, & test data definition
which may lead to defect introduction in software if it is not handled
correctly
•Test environment defects: it may be compromised of hardware, s/w,
simulators, & people doing testing. It may include operator training also
•Test tool defects: assumed that no defects in test tools. Any defect
introduced by a test tool may be very difficult to find and resolve, as
one may have to find using manual tests as against automated tools.
Defect Life Cycle
•A defect identified in verification/ validation
New must be first analysed to check whether it is a
defect or not, and if it is confirmed as a defect,
Yes then one must check if the same defect, has
Opened already been logged in system or not. If the
defect is already logged in the system, one
needs to check its status. If status is ‟open‟,
Assigned / one must not log the same defect again. If
reassigned defect is „closed‟, it must be changed to
NO
„reopen‟.
NO •If the defect found in new, the tester/
reviewer must give all the attributes of defects
Fixed (including steps to reproduce it) & assign it to
a person responsible for releasing a build/
project manager/ module leader as per org.
Verified process definition. Generally, the project
manager appoints somebody as a single point
of contact to receive all the defects found
closed during review/ testing.
•Once the defect is logged in the system, the concerned contact person
must reproduce the defect in development env to check if the defect is
there or not. If any additional info is required with reference to the
defect or defect discovery process, then he must contact the tester who
has found the defect. Once the presence of the defect is confirmed, it
must be acknowledged, and assigned to the respective developer with
„how to fix it‟ instructions. Status of defect may be changed to
„assigned‟.
•Once the defect is fixed, it undergoes review/ unit testing by the
developer. Status of the defect may become „fixed‟.
•If the defect passes through review/ unit testing, fixation of defect is
confirmed by the person responsible for receiving the defect in the
earlier stage. It is reassigned to the tester for retesting with the
information about the build number, where defect may be retested. The
status is changed to „verified‟. If fixing of defect is not confirmed, is
may be assigned back to the developer. Status of defect may become
„reassigned‟.
•Tester takes a new build in which the defect is expected to be fixed,
and conducts the test for reproducing the defect(retesting). If the
defect is found closed (cannot be reproduced), the status of the defect
is changed to „closed‟. If the defect is found open, the status is changed
to „reopen‟ and again assigned to respective pro. Manager/ module lead
Defect Management Process (fixing & root cause of defect)

•It must include the appraisal of a defect finding process, soft dev.
process and the actions initiated to close the defects and strengthen
the product/ processes associated with development, so that defects
are not repeated again & again.
•It attempts to remove weaker areas with potential defects. It typically
includes correction, corrective actions & preventive actions.

•Defect Naming: defect naming conventions are defined in a test plan.

•Defect Resolution: it includes defect fixing, retesting, resolving, and
taking actions on processes and methods which have produced defect.
It also includes regression testing to find whether defect fixing has had
any negative effect on the parts which have not been changed.
(defect correction, corrective action & defect prevention)
•Process Improvement: defect is an instance of a class problem. All
problems are due to failures in the process involved in creating s/w.
•Defect Fixing: defect prevention is a cycle of risk analysis and actions
based on its ranking. Defects found in verification/ validation must be
realistic, and represent the possible areas of improvement in the
development and testing processes.
•The frequency and effect of a defect on the user and impact on the
system usage must be driven defect prevention mechanism
•The process of risk analysis and defect prevention is shown in fig.

Defect fixing process

Developing Test Strategy

•Developing strategy about how the test team will perform testing.
•Some of key components of testing strategy are as follows
•Test factors required in particular phase of development
•Test phase corresponding to development phase
•Process of developing test strategy goes through following steps
•Select and Rank test factors for the given application
•Test team must identify critical success factors/quality factors/
test factors for the s/w product under testing. Trade-off decisions
may be taken after consulting with customer, if possible, when
relationship is inversed.
•Identify system development phases and related test factors
•The critical test factors may have varying importance as per
development life cycle phases.
•Identify associated risks with each selected test factor in case if it
not achieved
•Trade-off may lead to few risks of development and testing s/w
•Identify phase in which risk of not meeting a test factor need to be
addressed
•As the phase is over, one needs to access the actual impact of
the risks and effectiveness of devised countermeasures for same
Developing Testing Methodologies (test plan)

•Developing test tactics is the job of project level test manager/ test
lead.
•Designing and defining of test methodology may take the following
route
•Acquire & study test strategy as defined earlier
•Testing must address the critical success factors for the project
and risk involved in not achieving it.
•Determine the type of development project being executed
•Traditionally developed using Waterfall dev. life cycle
•Commercially off the shelf (COTS) purchased s/w which may
be integrated in the given s/w.
•Agile methodology, Iterative method, spiral development
•Determine the type of software system being made
•Type of s/w system defines how data processing will be
performed by the software. It may involve following
•Determine project scope(multivendor or multisite dev.)
•New development including scope of development & testing,
when products are enhanced from existing level.
•Changes to existing system such as bug fixing, enhancement,
reengineering, and porting
•Identify tactical risks related to development
•Risks may be introduced in a software due to its nature, type of
developing organisation, developing methodologies used, and
skills of teams. Risks may differ from project to project.
•Structural risks(refers to methods used to build a product)
•Technical risks(refers to technology used to build and operate
the system)
•Size risks(refers to size of all aspects of software)

•Determine when testing must occur during life cycle

•Testing phases starts from proposal, contract or req. testing till
acceptance testing.
•Previously collected information. It defines the cost of testing,
cost of customer dissatisfaction and any trade-offs.
•Build tactical test plan which is used by test team in execution
of testing related activities
•To describe software being tested, test objectives, risks,
business functions to be tested, and any specific tests to be
performed.
Testing Process

•Testing is a process made of many milestones. Testers needs to

achieve them, one by one, to achieve the final goal of testing.
•Each milestone forms a basis on which the next stage is built.
•Following are few milestones commonly used by many organizations
•Defining test policy
•Defining test strategy
•Preparing test plan
•Establishing test objectives to be achieved
•Designing test scenario & test cases
•Defining test data
•Creation of test bed
•Executing test cases
•Test result
•Test result analysis
•Performing retesting/ regression testing when defects are resolved by
development team
•Root cause analysis and corrective/ preventive actions.
Attitude towards Testing (common people issues)

•Attitude of development team and senior management or project

management towards a test team is very important aspect to build
morale of a test team
•It may be initiated from test policy and may be percolated down to
test strategy definition and test planning.

•Some of views about test team are as follows

•New members of development team are not accustomed to view

testing as a discovery process where defects are found in product.
•„We take pride on what we developed‟ or „it is not my fault‟
•Personal blames, personal egos affects root cause analysis of defects
•Conflict between developer & tester can create differences between
project team and test teams. In reality, the sole aim of development
and testing must be a customer satisfaction and defects may be
considered as something which prevents achievement of this objective.
Skills required by Tester

•One must try to build maximum possible skills, and training is one
of the effective methods to build a good testing team.
•General Skills:
•Written & verbal presentation skill
•Effective listening skill
•Facilitation skill
•Software development, Operations & Maintenance
•Continuous education
•Testing Skills
•Concepts of testing
•Levels of testing
•Techniques for validation and verification
•Selection & use of testing tools
•Knowledge of testing standards
•Risk assessment & management
•Developing test plan
•Defining acceptance criteria
•Checking of testing processes
•Execution of test plan
•Continuous improvement of testing process
Test Methodologies/ Approaches

•Major disciplines in testing are given below

•Black Box testing:

•It is an attesting methodology where product is tested as per
software specifications or requirement statement defined by
business analysts/ system analysts/ customer.
•Black box testing mainly talks about the requirement specification
given by customer, or intended requirements as perceived by
testers.
•It deals with testing of an executable and is independent of
platform, database etc.
•This testing is with the view as if a user is testing the system.

•
•White Box Testing:
•It is a testing methodology where software is tested for the
structures.
•It covers verification of work products as per structure,
architecture, coding standards and guidelines of software.
•It mainly deals with the structure and design of software product
•It requires that testers must have knowledge about development
processes and artifacts including various platforms, databases etc.
•Grey Box Testing
•It talks about a combination of both approaches, viz. black box
testing and white box testing at the same time.
•There may be various shades of black box testing as well as white
box testing in this type of testing, depending upon the
requirements of product.
•Though not a rule, grey box testing mainly concentrates on
integration testing part along with unit testing.