Syllabus

• Review of Fundamentals of Software Testing,

• Testing during development life cycle,
• Requirement Traceability matrix, essentials,
• Work bench,
• Important Features of Testing Process,
• Misconceptions, Principles, salient and policy of Software testing,
• Test Strategy, Test Planning, Testing Process and number of defects
found,
• Test teem efficiency, Mutation testing, challenges, test team
approach, Process problem faced, Cost aspect,
• Establishing testing policy, methods, structured approach,
categories of defect, Defect/ error/ mistake in software, Developing
Test Strategy and Plan,
• Testing process, Attitude towards testing, approaches, challenges,
Raising management awareness for testing, skills required by tester
Software Testing Definition
 Testing
• It is the process of exercising or evaluating a system or
system component by manual or automated means to
verify that it satisfies specified requirements – [IEEE 83a]
 Process
• Sequence of steps performed for a given purpose [IEEE]

• Software Process
• A set of activities, methods, practices and transformations
that people use to develop and maintain software and
associated products [SEI-CMM]
Review-Software Testing
1. It is impossible to test a program completely.
2. Software testing is a risk-based exercise.
3. Testing cannot show the absence of bugs.
4. The more bugs you find, the more bugs there
are.
5. Not all bugs found will be fixed.
6. It is difficult to say when a bug is indeed a bug.
7. Specifications are never final.
8. Software testers are not the most popular
members of a project.
9. Software testing is a disciplined and technical
profession.
Testing during development life cycle
• All these phases go through the process of
software testing levels.
• There are mainly four testing levels
are:
1.Unit Testing
2.Integration Testing
3.System Testing
4.Acceptance Testing
Level of testing :- Each of these testing
levels has a specific purpose. These
testing level provide value to the
software development lifecycle.
1) Unit testing:
A Unit is a smallest testable portion of
system or application which can be
compiled, liked, loaded, and executed.
This kind of testing helps to test each
module separately.
The aim is to test each part of the
software by separating it. It checks that
component are fulfilling functionalities or
not. This kind of testing is performed by
developers.
2) Integration testing:
Integration means combining. For
Example, In this testing phase, different
software modules are combined and
tested as a group to make sure that
integrated system is ready for system
testing.
Integrating testing checks the data flow
from one module to other modules.
 This kind of testing is performed by
testers.
• 3) System testing:
System testing is performed on a complete,
integrated system. It allows checking
system's compliance as per the
requirements. It tests the overall interaction
of components.
It involves load, performance, reliability and
security testing.
System testing most often the final test to
verify that the system meets the
specification. It evaluates both functional
and non-functional need for the testing.
4) Acceptance testing:
• Acceptance testing is a test
conducted to find if the
requirements of a specification or
contract are met as per its delivery.
• Acceptance testing is basically
done by the user or customer.
• However, other stockholders can
be involved in this process.
• Following test cases can be included for acceptance
testing
1. -End-to-end functionality verification
2. -Domain tests
3. -User scenario tests
4. -Basic sanity tests
5. -New functionality
6. -A few non-functional tests
7. -Tests pertaining to legal obligations and -
service level agreements
8. -Acceptance test data
Other Types of Testing:
Regression Testing
Buddy Testing
Alpha Testing
Beta Testing
Requirement Traceability matrix
• What is Traceability Matrix? (TM)
A Traceability Matrix is a document
that co-relates any two-baseline
documents that require a many-to-
many relationship to check the
completeness of the relationship.
It is used to track the requirements
and to check the current project
requirements are met.
What is Requirement Traceability
Matrix?
Requirement Traceability Matrix (RTM) is a
document that maps and traces user
requirement with test cases. It captures all
requirements proposed by the client and
requirement traceability in a single document,
delivered at the conclusion of the Software
devlopement life cycle.
 The main purpose of Requirement Traceability
Matrix is to validate that all requirements are
checked via test cases such that no
functionality is unchecked during Software
testing.
Why RTM is Important?
 The main agenda of every tester should be to
understand the client’s requirement and make
sure that the output product should be defect-
free.
 To achieve this goal, every QA should understand
the requirement thoroughly and create positive
and negative test cases.
 The traceability matrix is typically a worksheet that
contains the requirements with its all possible test
scenarios and cases and their current state, i.e. if
they have been passed or failed. This would help
the testing team to understand the level of testing
activities done for the specific product.
Which Parameters to include in
Requirement Traceability Matrix?
1.Requirement ID
2.Requirement Type and Description
3.Test Cases with Status
 But in a typical software testing project, the
traceability matrix would have more than these
parameters.
• In illustrated above, a requirement traceability
matrix can:
Show the requirement coverage in the
number of test cases
Design status as well as execution status for
the specific test case
If there is any User Acceptance test to be
done by the users, then UAT status can also
be captured in the same matrix.
The related defects and the current state
can also be mentioned in the same matrix.
How to Create RTM
Functional Requirement
• Advantage of Requirement Traceability
Matrix
It confirms 100% test coverage
It highlights any requirements missing or
document inconsistencies
It shows the overall defects or execution
status with a focus on business
requirements
It helps in analyzing or estimating the
impact on the QA team's work with respect
to revisiting or re-working on the test cases
Workbench of Testing
A Workbench is a method of
documenting how a particular activity
must be fulfilled.
A workbench is referred to a stages,
steps, and assignments while
performing certain activities in testing.
A workbench gives you an opportunity
to execute any one task with
appropriate software testing.
Workbench Phases
1. Requirement phase:- The input data – the requirements of
clients; we perform a task – writing a document with the
customer’s requirements, we check the suitability of a
document to all needs of client, and receive the output –
requirement document.
2. Design phase:- The input data – the requirement document,
we execute the preparing a technical document; review/test
is performed to see if the design document is technically
right and transfers all the requirements in the requirement
document, and receive a technical document.
3. Execution phase:- It is the actual performance of the
project. The input data – the technical document; the
performance is nothing but realization/ coding according to
the technical document, and the output data – the source
code.
Workbench Phases
4. Testing phase workbench
It is the stage of software testing. The input data – the
source code which is required testing; the realization –
implementation of the test case and the output – the
results of software testing.
5. Distribution phase
There are two inputs for this step – the source code which
requires of customers and the source code with the
results of testing. The output of this project is the product
which is ready for use.
6. Maintenance phase
The input – the results of distribution, execution –
execution of the last customer requests, the running
regression software testing after every changed customer
request, and the output is a new release.
Important Features of Testing Process
1. Testing is destructive process, But its
constructive destruction
2. Testing needs positive approach with
consideration that there is defect
3. If test dose not detect defect present in system,
then its unsuccessful test
4. Root cause analysis and corrective/preventive
actions must be mentioned.
5. Performing regression testing when defect are
resolved by development team
6. Proper test helps to improve over all product.
Misconceptions about Testing and
Defects
1. Testers can test the quality of product at end of
development process.
2. Defect found in testing are blamed on developers .
3. Defect found by customers are blamed on testers.
4. Complete testing is done
5. Zero defect software (product) creation.
6. Tester can find all defects in limited period
7. Testing is manual process, Automation involve
optionally
8. Testing process is simple than development step.
9. Testing required less efforts
Generalized Principles of Software
testing,
1.Programmers/ team must avoid testing their
own works products
2.Thoroughly inspect results of each test case
has to found to identify weaker area in
software
3. Defects indicates process failure
4.Initiate actions for correction, corrective
action & preventive action.
Salient features of good Software
testing
1.Capture user requirements
2.Capturing user needs
3.Design objective must define properly
4.User interface simple and easy to understand
5.Internal Structure complex but simple to
understand
6.Execution of code reduce risk of failure
Test Policies
• Test policies are generally defined by senior
management try to cover all aspects of
testing.
• It decides framework of testing towards
customer satisfaction.
• Testing will performed against TQM
principles to find and fulfill customer centric
approach
Test Strategy or Approach
• Globally, there is unique test policy decided by
management but it can varies as per customer,
Deadline, Product, Project etc.
• Definition of coverage is defined for testing
(Functional, requirements and features for
different products, Customer and project)
• Level of testing must monitored and maintained
(unit to acceptance testing)
• How much testing manually and when to
automate has been planned and executed.
• Number of developer and testers are assigned in
proportion.
Test Planning
• Test planning is first activity of test team
• Test plan are defined throughout SDLC
• Test plan must be realistic and talk about
limitations and constraints in system
1. Plan testing efforts adequately with assumption
that defects are exists in software
2. Successful tester founds defect in systems not
appreciates developer
3. Testing dose not completed at end of development
cycle, (plan for maintenance)
4. Verification(do-right thing) and validation(right-
thing do) must done at each phase of testing.
Testing Process and number of
defects found in testing
In real time, As we find more defects, there
is probability of finding some more defects.
Governed by teams defect finding ability.
Figure :- defect trend
As tester assures one defect may leads
multiple defects and count of defect will
increasing
Defect trend
Test team efficiency
• It’s a defect finding rate of particular test team
• More the efficient team, Less the defects found
in system by customer, As these are resolved
by developer in iteration of product/service.
• Every test manager must aware of test team
efficiency which should tends towards 100%
• Ex. 90% means, 500 defects are reported by
team still there exists 50 more defects possible,
95% still 25 more. 100 no more
defects(practically not achievable).
• Efficiency can calculate using old success rates.
Mutation Testing
• This testing use to check capability of
test program and test cases to find
defects
• This also known as test case efficiency.
• If original program is changed(due to
any reason) and some defects are
added in system called mutant of
original program and process termed
as mutation.
Challenges in Testing
1.Challenges associated with developer
team, Customer needs, Management
perspective
2.Requirements are not clear, complete,
consistent, measurable and testable
3.Requirements are wrongly documented
& inspected by business & system analyst
4.Code logic may difficult to capture
5.Error handling may be difficult to capture
Test team & Approaches
• Type of organization & Type of product
developed to be tested define test team.
• There may or may not be separate testing
team for each product to be developed.
1. Developer become testers –Small size team
2. Independent testing team- Assigns test
manager
3. Domain experts doing software testing –
System and acceptance testing
4. Test team reporting development manager-
Most common test team approach
Process problem faced in Testing
• Defects are introduce in software due to incorrect
processes, The basic constituents (part) of
processes are :-
1. People :- user-specifying requirements, Business
analyst-document requirements, Test manager
define test plan, tester define test case etc.
2. Material:- Requirement docs, development
standards, guidelines must provide properly
3. Machines :-Simulators, real time objects defined
4. Methods:- Test planning, defining, test data may
not proper.
5. Economics of testing:-Customer dissatisfaction
inversely proportional to testing efforts
Cost aspect in Testing
• Cost of quality includes cost of appraisal,
prevention and failure cost of
product/service
• Testing is costly to organization, so it try to
keep as minimum as possible
• As per economics of testing cost has to
manage
• Cost include :-Capture requirements,
Conduct analysis, ask queries, Design test
cases high and low level, write code,
automation test tool, create final product
and maintain.
Structured approach for testing
Establish testing policies
Use standard methods
Four types of wastes are involved
in structured approch
Waste in wrong development
Waste in testing to detect defects
Wastage as wrong specification
 Categories of defect, Defect/ error/ mistake in
software,
What is a Defect?
 A software bug arises when the expected result don't
match with the actual results. It can also be error, flaw,
failure, or fault in a computer program. Most bugs arise
from mistakes and errors made by developers,
architects.
 Following are the methods for preventing programmers
from introducing bugs during development:
 Programming Techniques adopted
 Software Development methodologies
 Peer Review
• Code Analysis
Common Types of Defects
Following are the common types of defects
that occur during development:
1.Arithmetic Defects
2.Logical Defects
3.Syntax Defects
4.Multithreading Defects
5.Interface Defects
6.Performance Defects
Testing is the process of identifying
defects, where a defect is any variance
between actual and expected result .
“A mistake in code is called Error .”
Error found by tester is called
defect , Defect accepted by
development team is called Bug.
And build does not meet the
requirements then it is Failure.
Test Strategy Document (With Sample
Test Strategy Template)
Test strategy means “How you are going to
test the application?” You need to mention
the exact process/strategy that you are
going to follow when you will get the
application for testing.
Writing a Test Strategy effectively is a skill
every tester should achieve in their career. It
initiates your thought process which helps to
discover many missing requirements. Thinking
and test planning activities help a team to
define the Testing scope and Test coverage.
Test Strategy
It helps Test managers to get the clear state of
the project at any point. The chances of
missing any test activity are very low when
there is a proper test strategy in place.
 Whereas the test strategy defines guidelines for
test approach to be followed in order to achieve
the test objectives and execution of test types
defined in the testing plan.
 It deals with test objectives, approach, test
environment, automation strategy and tools, and
risk analysis with a contingency plan.
Test Startergy
What is a Test Plan?
A TEST PLAN is a detailed document that
describes the test strategy, objectives,
schedule, estimation and deliverables and
resources required for testing. Test Plan
helps us determine the effort needed to
validate the quality of the application under
test.
The test plan serves as a blueprint to
conduct software testing activities as a
defined process which is minutely
monitored and controlled by the test
manager.
How to write a Test Plan
• Follow the seven steps below to create a test plan
as per IEEE 829
1.Analyze the product
2.Design the Test Strategy
3.Define the Test Objectives
4.Define Test Criteria
5.Resource Planning
6.Plan Test Environment
7.Schedule & Estimation
8.Determine Test Deliverables
Skills required to become a Software
Tester
THANK YOU