JIMS Vasant KunjII is the Top institute for BCA. JIMS is one of the Best BCA Colleges in Delhi which offers best placements in Top IT Companies in Delhi NCR. It is amongst the top A+ Category highest ranked colleges in Delhi, provides 3 years Regular Degree from UGC Approved University. This unit of Software Testing is a part of BCA 5th sem syllabi.

1. SOFTWARE TESTING NOTES
BCA 5TH
SEM
UNIT 1
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.
Unit
Integration
System
According to ANSI/IEEE 1059 standard, Testing can be defined as “A process
of analyzing a software item to detect the differences between existing and
required conditions (that is defects/errors/bugs) and to evaluate the features of
the software item”.
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

2. 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.
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, 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.
Difference between Testing and Debugging
Testing: It involves the identification of bug/error/defect in the software
withoutcorrecting it. Normally professionals with a Quality Assurance
background are involved in the identification of bugs. Testing is performed in
the testing phase.

3. Debugging: It involves identifying, isolating and fixing the problems/bug.
Developerswho code the software conduct debugging upon encountering an
error in the code. Debugging is the part of White box or Unit Testing.
Debugging can be performed in the development phase while conducting Unit
Testing or in phases while fixing the reported bugs.
Testing Myths
Given below are some of the more popular and common myths about Software
testing.
Myth: Testing is too expensive.
Reality: There is a saying, pay less for testing during software development or
pay morefor maintenance or correction later. Early testing saves both time and
cost in many aspects however, reducing the cost without testing may result in
the improper design of a software application rendering the product useless.
Myth: Testing is time consuming.
Reality: During the SDLC phases testing is never a time consuming process.
However diagnosing and fixing the error which is identified during proper
testing is a time consuming but productive activity.
Myth: Testing cannot be started if the product is not fully developed.
Reality: No doubt, testing depends on the source code but reviewing
requirements and developing test cases is independent from the developed code.
However iterative or incremental approach as a development life cycle model
may reduce the dependency of testing on the fully developed software.
Myth: Complete Testing is Possible.
Reality: It becomes an issue when a client or tester thinks that complete testing
impossible. It is possible that all paths have been tested by the team but
occurrence of complete testing is never possible. There might be some
scenarios that are never executed by the test team or the client during the
software development life cycle and may be executed once the project has been
deployed.
Myth: If the software is tested then it must be bug free.
Reality: This is a very common myth which clients, Project Managers and the
management team believe in. No one can say with absolute certainty that a
software application is 100% bug free even if a tester with superb testing skills
has tested the application.
Myth: Missed defects are due to Testers.
Reality: It is not a correct approach to blame testers for bugs that remain in the
application even after testing has been performed. This myth relates to Time,

4. Cost, and Requirements changing Constraints. However the test strategy may
also result in bugs being missed by the testing team.
Myth: Testers should be responsible for the quality of a product.
Reality: It is a very common misinterpretation that only testers or the testing
team should be responsible for product quality. Tester’s responsibilities include
the identification of bugs to the stakeholders and then it is their decision
whether they will fix
the bug or release the software. Releasing the software at the time puts more
pressure on the testers as they will be blamed for any error.
Myth: Test Automation should be used wherever it is possible to use it and to
reduce time.
Reality: Yes it is true that Test Automation reduces the testing time but it is not
possible to start Test Automation at any time during Software development.
Test Automaton should be started when the software has been manually tested
and is stable to some extent. Moreover, Test Automation can never be used if
requirements keep changing.
Myth: Any one can test a Software application.
Reality: People outside the IT industry think and even believe that any one can
test the software and testing is not a creative job. However testers know very
well that this is myth. Thinking alternatives scenarios, try to crash the Software
with the intent to explore potential bugs is not possible for the person who
developed it.
Myth: A tester’s task is only to find bugs.
Reality: Finding bugs in the Software is the task of testers but at the same time
they are domain experts of the particular software. Developers are only
responsible for the specific component or area that is assigned to them but
testers understand the overall workings of the software, what the dependencies
are and what the impacts of one module on another module are.
Software Testing has different goals and objectives. The major objectives of
Software testing are as follows:
ÿ Finding defects which may get created by the programmer while
developing the software.
ÿ Gaining confidence in and providing information about the level of
quality.
ÿ To prevent defects.
ÿ To make sure that the end result meets the business and user
requirements.

5. ÿ To ensure that it satisfies the BRS that is Business Requirement
Specification and SRS that is System Requirement Specifications.
ÿ To gain the confidence of the customers by providing them a quality
product.
Software testing helps in finalizing the software application or product against
business and user requirements. It is very important to have good test coverage
in order to test the software application completely and make it sure that it’s
performing well and as per the specifications.
While determining the coverage the test cases should be designed well with
maximum possibilities of finding the errors or bugs. The test cases should be
very effective. This objective can be measured by the number of defects
reported per test cases. Higher the number of the defects reported the more
effective are the test cases.
Once the delivery is made to the end users or the customers they should be able
to operate it without any complaints. In order to make this happen the tester
should know as how the customers are going to use this product and
accordingly they should write down the test scenarios and design the test cases.
This will help a lot in fulfilling all the customer’s requirements.
Software testing makes sure that the testing is being done properly and hence
the system is ready for use. Good coverage means that the testing has been done
to cover the various areas like functionality of the application, compatibility of
the application with the OS, hardware and different types of browsers,
performance testing to test the performance of the application and load testing
to make sure that the system is reliable and should not crash or there should not
be any blocking issues. It also determines that the application can be deployed
easily to the machine and without any resistance. Hence the application is easy
to install, learn and use.
What is Defect or bugs or faults in software testing?
A defect is an error or a bug, in the application which is created. A programmer
while designing and building the software can make mistakes or error. These
mistakes or errors mean that there are flaws in the software. These are called
defects.
When actual result deviates from the expected result while testing a software
application or product then it results into a defect. Hence, any deviation from
the specification mentioned in the product functional specification document is
a defect. In different organizations it’s called differently like bug, issue,
incidents or problem.
When the result of the software application or product does not meet with the
end user expectations or the software requirements then it results into a Bug or
Defect. These defects or bugs occur because of an error in logic or in coding
which results into the failure or unpredicted or unanticipated results.

6. Additional Information about Defects / Bugs:
While testing a software application or product if large number of defects are
found then it’s called Buggy.
When a tester finds a bug or defect it’s required to convey the same to the
developers. Thus they report bugs with the detail steps and are called as Bug
Reports, issue report, problem report, etc.
This Defect report or Bug report consists of the following information:
Defect ID – Every bug or defect has it’s unique identification number.
Defect Description – This includes the abstract of the issue.
Product Version – This includes the product version of the application in
which the defect is found.
Detail Steps – This includes the detailed steps of the issue with the screenshots
attached so that developers can recreate it.
Date Raised – This includes the Date when the bug is reported
Reported By – This includes the details of the tester who reported the bug like
Name and ID
Status – This field includes the Status of the defect like New, Assigned, Open,
Retest, Verification, Closed, Failed, Deferred, etc.
Fixed by – This field includes the details of the developer who fixed it like
Name and ID
Date Closed – This includes the Date when the bug is closed
Severity – Based on the severity (Critical, Major or Minor) it tells us about
impact of the defect or bug in the software application
Priority – Based on the Priority set (High/Medium/Low) the order of fixing the
defect can be made.

7. Why is software testing necessary?
Software Testing is necessary because we all make mistakes. Some of those
mistakes are unimportant, but some of them are expensive or dangerous. We
need to check everything and anything we produce because things can always
go wrong – humans make mistakes all the time.
Since we assume that our work may have mistakes, hence we all need to check
our own work. However some mistakes come from bad assumptions and blind
spots, so we might make the same mistakes when we check our own work as we
made when we did it. So we may not notice the flaws in what we have done.
Ideally, we should get someone else to check our work because another person
is more likely to spot the flaws.
There are several reasons which clearly tells us as why Software Testing is
important and what are the major things that we should consider while testing
of any product or application.
Software testing is very important because of the following reasons:
l Software testing is really required to point out the defects and errors that
were made during the development phases.
l It’s essential since it makes sure of the Customer’s reliability and their
satisfaction in the application.
l It is very important to ensure the Quality of the product. Quality product
delivered to the customers helps in gaining their confidence.
l Testing is necessary in order to provide the facilities to the customers like
the delivery of high quality product or software application which requires
lower maintenance cost and hence results into more accurate, consistent
and reliable results.
l Testing is required for an effective performance of software application or
product.
l It’s important to ensure that the application should not result into any
failures because it can be very expensive in the future or in the later stages
of the development.
l It’s required to stay in the business.
Principles of Testing
There are seven principles of testing. They are as follows:
1) Testing shows presence of defects: Testing can show the defects are present,
but cannot prove that there are no defects. Even after testing the application or
product thoroughly we cannot say that the product is 100% defect free. Testing
always reduces the number of undiscovered defects remaining in the software
but even if no defects are found, it is not a proof of correctness.

8. 2) Exhaustive testing is impossible: Testing everything including all
combinations of inputs and preconditions is not possible. So, instead of doing
the exhaustive testing we can use risks and priorities to focus testing efforts. For
example: In an application in one screen there are 15 input fields, each having 5
possible values, then to test all the valid combinations you would need
30 517 578 125 (515
) tests. This is very unlikely that the project timescales
would allow for this number of tests. So, accessing and managing risk is one of
the most important activities and reason for testing in any project.
3) Early testing: In the software development life cycle testing activities
should start as early as possible and should be focused on defined objectives.
4) Defect clustering: A small number of modules contains most of the defects
discovered during pre-release testing or shows the most operational failures.
5) Pesticide paradox: If the same kinds of tests are repeated again and again,
eventually the same set of test cases will no longer be able to find any new bugs.
To overcome this “Pesticide Paradox”, it is really very important to review the
test cases regularly and new and different tests need to be written
toEXERCISE different parts of the software or system to potentially find more
defects.
6) Testing is context depending: Testing is basically context dependent.
Different kinds of sites are tested differently. For example, safety – critical
software is tested differently from an e-commerce site.
7) Absence – of – errors fallacy: If the system built is unusable and does not
fulfil the user’s needs and expectations then finding and fixing defects does not
help.
Software Testing Life Cycle STLC
Software Testing Life Cycle (STLC) is the testing process which is executed
in systematic and planned manner. In STLC process, different activities are
carried out to improve the quality of the product. Let’s quickly see what all
stages are involved in typical Software Testing Life Cycle (STLC).
Following steps are involved in Software Testing Life Cycle (STLC). Each step
is have its own Entry Criteria and deliverable.
∑ Requirement Analysis
∑ Test Planning
∑ Test Case Development
∑ Environment Setup
∑ Test Execution
∑ Test Cycle Closure

9. Ideally, the next step is based on previous step or we can say next step cannot
be started unless and until previous step is completed. It is possible in the ideal
situation, but practically it is not always true.
So Let’s discuss what all activities and deliverable are involved in the each step
in detailed.
Requirement Analysis:
Requirement Analysis is the very first step in Software Testing Life Cycle
(STLC). In this step Quality Assurance (QA) team understands the requirement
in terms of what we will testing & figure out the testable requirements. If any
conflict, missing or not understood any requirement, then QA team follow up
with the various stakeholders like Business Analyst, System Architecture,
Client, Technical Manager/Lead etc to better understand the detail knowledge
of requirement.
From very first step QA involved in the where STLC which helps to prevent the
introducing defects into Software under test. The requirements can be either
Functional or Non-Functional like Performance, Security testing. Also
requirement and Automation feasibility of the project can be done in this stage
(if applicable)

10. Entry Criteria Activities Deliverable
Following documents
should be available:
– Requirements
Specification.
– Application architectural
Along with above
documents Acceptance
criteria should be well
defined.
Prepare the list of questions
or queries and get resolved
from Business Analyst,
System Architecture,
Client, Technical
Manager/Lead etc.
Make out the list for what
all Types of Tests
performed like Functional,
Security, and Performance
etc.
Define the testing focus and
priorities.
List down the Test
environment details where
testing activities will be
carried out.
Checkout the Automation
feasibility if required &
prepare the Automation
feasibility report.
List of questions with all
answers to be resolved from
business i.e. testable
requirements
Automation feasibility
report (if applicable)
Test Planning:
Test Planning is most important phase of Software testing life cyclewhere all
testing strategy is defined. This phase also called as Test Strategy phase. In this
phase typically Test Manager (or Test Lead based on company to company)
involved to determine the effort and cost estimates for entire project. This phase
will be kicked off once the requirement gathering phase is completed & based
on the requirement analysis, start preparing the Test Plan. The Result of Test
Planning phase will be Test Plan or Test strategy & Testing Effort
estimation documents. Once test planning phase is completed the QA team can
start with test cases development activity.

11. Get the Sample Test Plan Template here.
Entry Criteria Activities Deliverable
Requirements Documents
(Updated version of unclear
or missing requirement).
Automation feasibility
report.
Define Objective & scope
of the project.List down the
testing types involved in the
STLC.Test effort estimation
and resource
planning.Selection of
Testing tool if required.
Define the testing process
overview.Define the test
environment required for
entire project.Prepare the
test schedules.Define the
control
procedures.Determining
roles and
responsibilities.List down
the testing
deliverable.Define the entry
criteria, suspension criteria,
resumption criteria and exit
criteria.Define the risk
involved if any.
Test Plan or Test strategy
document.
Testing Effort
estimationdocument.
Test Case Development:
The test case development activity is started once the test planning activity is
finished. This is the phase of STLC where testing team write down the detailed
test cases. Along with test cases testing team also prepare the test data if any
required for testing. Once the test cases are ready then these test cases are
reviewed by peer members or QA lead.
Also the Requirement Traceability Matrix (RTM) is prepared. The Requirement
Traceability Matrix is an industry-accepted format for tracking requirements
where each test case is mapped with the requirement. Using this RTM we can
track backward & forward traceability.

12. Entry Criteria Activities Deliverable
Requirements Documents
(Updated version of unclear
or missing requirement).
Automation feasibility
report.
Preparation of test cases
Preparation of test
automation scripts (if
required).
Re-requisite test data
preparation for executing
test cases.
Test cases.
Test data.
Test Automation Scripts (if
required).
Test Environment Setup:
Setting up the test environment is vital part of the STLC. Basically test
environment decides on which conditions software is tested. This is
independent activity and can be started parallel with Test Case Development. In
process of setting up testing environment test team is not involved in it. Based
on company to company may be developer or customer creates the testing
environment. Mean while testing team should prepare the smoke test cases to
check the readiness of the test environment setup.
Entry Criteria Activities Deliverable
Test Plan is available.
Smoke Test cases are
available.
Test data is available.
Analyze the requirements
and prepare the list of
Software & hardware
required to set up test
environment.
Setup the test environment.
Once the Test Environment
is setup execute the Smoke
test cases to check the
readiness of the test
environment.
Test Environment will be
ready with test data.
Result of Smoke Test cases.

13. Test Execution:
Once the preparation of Test Case Development and Test Environment setup is
completed then test execution phase can be kicked off. In this phase testing
team start executing test cases based on prepared test planning & prepared test
cases in the prior step.
Once the test case is passed then same can be marked as Passed. If any test case
is failed then corresponding defect can be reported to developer team via bug
tracking system & bug can be linked for corresponding test case for further
analysis. Ideally every failed test case should be associated with at least single
bug. Using this linking we can get the failed test case with bug associated with
it. Once the bug fixed by development team then same test case can be executed
based on your test planning.
If any of the test cases are blocked due to any defect then such test cases can be
marked as Blocked, so we can get the report based on how many test cases
passed, failed, blocked or not run etc. Once the defects are fixed, same Failed or
Blocked test cases can be executed again to retest the functionality.
Entry Criteria Activities Deliverable
Test Plan or Test strategy
document.
Test cases.
Test data.
Based on test planning
execute the test cases.
Mark status of test cases
like Passed, Failed,
Blocked, Not Run etc.
Assign Bug Id for all Failed
and Blocked test cases.
Do Retesting once the
defects are fixed.
Track the defects to closure.
Test case execution report.
Defect report.

14. Test Cycle Closure:
Call out the testing team member meeting & evaluate cycle completion criteria
based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and
Software. Discuss what all went good, which area needs to be improve & taking
the lessons from current STLC as input to upcoming test cycles, which will help
to improve bottleneck in the STLC process. Test case & bug report will analyze
to find out the defect distribution by type and severity. Once complete the test
cycle then test closure report & Test metrics will be prepared. Test result
analysis to find out the defect distribution by type and severity.
Entry Criteria Activities Deliverable
Test case execution is
completed
Test case Execution report
Defect report
Evaluate cycle completion
criteria based on Test
coverage, Quality, Cost,
Time, Critical Business
Objectives, and Software
Prepare test metrics based
on the above parameters.
Prepare Test closure report
Share best practices for any
similar projects in future
Test Closure report
Test metrics