Department of Computer Science and Applications (MCA)

PCA20D06J – Software Testing

Unit 1

What is testing?
Testing is the process of exercising or evaluating a system or system components by manual or
automated means to verify that it satisfies specified requirements.
The Purpose of Testing

Testing consumes at least half of the time and work required to produce a functional program.
o MYTH: Good programmers write code without bugs. (It’s wrong!!!)
o History says that even well written programs still have 1-3 bugs per hundred statements.
Tests
Tests are formal procedures, Inputs must be prepared, Outcomes should predict, tests should be
documented, commands need to be executed, and results are to be observed. All these errors are
subjected to error
Phases in a tester's mental life:(Psychology of testing)

Phases in a tester's mental life can be categorized into the following 5 phases:

1. Phase 0: (Until 1956: Debugging Oriented) There is no difference between testing and
debugging. Phase 0 thinking was the norm in early days of software development till testing
emerged as a discipline.
2. Phase 1: (1957-1978: Demonstration Oriented) the purpose of testing here is to show that
software works. Highlighted during the late 1970s. This failed because the probability of
showing that software works 'decreases' as testing increases. I.e. the more you test, the more
likely you will find a bug.
3. Phase 2: (1979-1982: Destruction Oriented) the purpose of testing is to show that software
doesn’t work. This also failed because the software will never get released as you will find
one bug or the other. Also, a bug corrected may also lead to another bug.
4. Phase 3: (1983-1987: Evaluation Oriented) the purpose of testing is not to prove anything but
to reduce the perceived risk of not working to an acceptable value (Statistical Quality
Control). Notion is that testing does improve the product to the extent that testing catches
bugs and to the extent that those bugs are fixed. The product is released when the confidence
on that product is high enough. (Note: This is applied to large software products with
millions of code and years of use.)
5. Phase 4: (1988-2000: Prevention Oriented) Testability is the factor considered here. One
reason is to reduce the labor of testing. Other reason is to check the testable and non-
testable code. Testable code has fewer bugs than the code that's hard to test. Identifying the
testing techniques to test the code is the main key here.
Software Testing Principles
Software testing is a procedure of implementing software or the application to identify the defects or bugs. For
testing an application or software, we need to follow some principles to make our product defects free, and that
also helps the test engineers to test the software with their effort and time. Here, in this section, we are going to
learn about the seven essential principles of software testing.

o Testing shows the presence of defects

o Exhaustive Testing is not possible
o Early Testing
o Defect Clustering
o Pesticide Paradox
o Testing is context-dependent
o Absence of errors fallacy

Testing Versus Debugging:

Many people consider both as same. Purpose of testing is to show that a program has
bugs. The purpose of testing is to find the error or misconception that led to the program's
failure and to design and implement the program changes that correct the error.
Debugging usually follows testing, but they differ as to goals, methods and most
important psychology. The below tab le shows few important differences between testing
and debugging.

Testing Debugging
Testing starts with known conditions, Debugging starts from possibly unknown
uses predefined procedures and has initial conditions and the end cannot be
predictable outcomes. predicted except statistically.
Testing can and should be planned, Procedure and duration of debugging cannot
designed and scheduled. be so constrained.
Testing is a demonstration of error or
Debugging is a deductive process.
apparent correctness.
Debugging is the programmer's vindication
Testing proves a programmer's failure.
(Justification).
Testing, as executes, should strive to be
Debugging demands intuitive leaps,
predictable, dull, constrained, rigid and
experimentation and freedom.
inhuman.
Much testing can be done without Debugging is impossible without detailed
design knowledge. design knowledge.
Testing can often be done by an
Debugging must be done by an insider.
outsider.
Much of test execution and design can
Automated debugging is still a dream.
be automated.
Software Development Life Cycle (SDLC)

SDLC is a process that creates a structure of development of software. There are different phases within SDLC,
and each phase has its various activities. It makes the development team able to design, create, and deliver a
high-quality product.

SDLC describes various phases of software development and the order of execution of phases. Each phase
requires deliverable from the previous phase in a life cycle of software development. Requirements are
translated into design, design into development and development into testing; after testing, it is given to the
client.

Let's see all the phases in detail:

Different phases of the software development cycle

o Requirement Phase
o Design Phase
o Build /Development Phase
o Testing Phase
 o Deployment/ Deliver Phase
o Maintenance

Software Development Life Cycle (SDLC) Models

The software development models are those several process or approaches which are being selected for the
development of project based on the project's objectives. To accomplish various purposes, we have many
development life cycle models. And these models identify the multiple phases of the process. Picking up the
correct model for developing the software application is very important because it will explain the what, where,
and when of our planned testing.

Here, are various software development models or methodologies:

o Waterfall model
o Spiral model
o Verification and validation model
o Prototype model
o Hybrid model

Waterfall Model

It is the first sequential-linear model because the output of the one stage is the input of the next stage. It is simple
and easy to understand, which is used for a small project. The various phases of the waterfall model are as
follows:

o Requirement analysis
 o Feasibility study
o Design
o Coding
o Testing
o Installation
o Maintenance

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of the software requirements and iteratively
enhances the evolving versions until the full system is implemented. At each iteration, design modifications are
made and new functional capabilities are added. The basic idea behind this method is to develop a system
through repeated cycles (iterative) and in smaller portions at a time (incremental).

The following illustration is a representation of the Iterative and Incremental model −

Spiral Model

It is the best suites model for a medium level project. It is also called the Cyclic and Iteration model. Whenever
the modules are dependent on each other, we go for this model. And here, we develop application model wise
and then handed over to the customer. The different stages of the spiral model are as follows:

o Requirement collection
o Design
o Coding
o Testing

Prototype Model

From the time when customer rejection was more in the earlier model, we go for this model as customer
rejection is less. And also, it allows us to prepare a sample (prototype) in the early stage of the process, which
we can show to the client and get their approval and start working on the original project. This model refers to
the action of creating the prototype of the application.

Verification & Validation Model

It is an extended version of the waterfall model. It will implement in two phases wherein the first phase, we will
perform the verification process, and when the application is ready, we will perform the validation process. In
this model, the implementation happens in the V shape, which means that the verification process done under
downward flow and the validation process complete in the upward flow.
Hybrid Model

The hybrid model is used when we need to acquire the properties of two models in the single model. This model
is suitable for small, medium, and large projects because it is easy to apply, understand.

The combination of the two models could be as follows:

o V and prototype
o Spiral and Prototype

Agile Model
Software Testing Life Cycle (STLC)

The procedure of software testing is also known as STLC (Software Testing Life Cycle) which includes phases
of the testing process.The testing process is executed in a well-planned and systematic manner. All activities are
done to improve the quality of the software product.

Let's see, the different steps of STLC.

Software testing life cycle contains the following steps:

1. Requirement Analysis
2. Test Plan Creation
3. Environment setup
4. Test case Execution
5. Defect Logging
6. Test Cycle Closure
Requirement Analysis:

The first step of the manual testing procedure is requirement analysis. In this phase, tester analyses requirement
document of SDLC (Software Development Life Cycle) to examine requirements stated by the client. After
examining the requirements, the tester makes a test plan to check whether the software is meeting the
requirements or not.

Entry Criteria Activities Deliverable

For the planning of test plan Prepare the list of all requirements List of all the
requirement specification, and queries, and get resolved from necessary tests for
application architecture Technical Manager/Lead, System the testable
document and well-defined Architecture, Business Analyst and requirements
acceptance criteria should be Client. andTest environment
available. Make a list of all types of tests details
(Performance, Functional and
security) to be performed.
Make a list of test environment
details, which should contain all the
necessary tools to execute test cases.

Test Plan Creation:

Test plan creation is the crucial phase of STLC where all the testing strategies are defined. Tester determines the
estimated effort and cost of the entire project. This phase takes place after the successful completion of
the Requirement Analysis Phase. Testing strategy and effort estimation documents provided by this phase.
Test case execution can be started after the successful completion of Test Plan Creation.

Entry Criteria Activities Deliverable

Requirement Define Objective as well as the scope Test strategy document.

Document of the software. Testing Effort estimation
List down methods involved in documents are the deliverables of
testing. this phase.
Overview of the testing process.
Settlement of testing environment.
Preparation of the test schedules and
control procedures.
Determination of roles and
responsibilities.
List down testing deliverables, define
risk if any.

Environment setup:

Setup of the test environment is an independent activity and can be started along with Test Case Development.
This is an essential part of the manual testing procedure as without environment testing is not possible.
Environment setup requires a group of essential software and hardware to create a test environment. The testing
team is not involved in setting up the testing environment, its senior developers who create it.

Entry Criteria Activities Deliverable

Test strategy and test Prepare the list of software and hardware by Execution
plan document. analyzing requirement specification. report.
Test case document. After the setup of the test environment, execute Defect report.
Testing data. the smoke test cases to check the readiness of the
test environment.

Test case Execution:

Test case Execution takes place after the successful completion of test planning. In this phase, the testing team
starts case development and execution activity. The testing team writes down the detailed test cases, also
prepares the test data if required. The prepared test cases are reviewed by peer members of the team or Quality
Assurance leader.
RTM (Requirement Traceability Matrix) is also prepared in this phase. Requirement Traceability Matrix is
industry level format, used for tracking requirements. Each test case is mapped with the requirement
specification. Backward & forward traceability can be done via RTM.

Entry Criteria Activities Deliverable

Requirement Creation of test cases. Test execution result.

Document Execution of test cases. List of functions with the detailed
Mapping of test cases according to explanation of defects.
requirements.

Defect Logging:

Testers and developers evaluate the completion criteria of the software based on test coverage, quality, time
consumption, cost, and critical business objectives. This phase determines the characteristics and drawbacks of
the software. Test cases and bug reports are analyzed in depth to detect the type of defect and its severity.

Defect logging analysis mainly works to find out defect distribution depending upon severity and types.If any
defect is detected, then the software is returned to the development team to fix the defect, then the software is re-
tested on all aspects of the testing.

Once the test cycle is fully completed then test closure report, and test metrics are prepared.

Entry Criteria Activities Deliverable

Test case It evaluates the completion criteria of the software based Closure
execution report. on test coverage, quality, time consumption, cost, and report
Defect report critical business objectives. Test metrics
Defect logging analysis finds out defect distribution by
categorizing in types and severity.

Test Cycle Closure:

The test cycle closure report includes all the documentation related to software design, development, testing
results, and defect reports.

This phase evaluates the strategy of development, testing procedure, possible defects in order to use these
practices in the future if there is a software with the same specification.

Entry Criteria Activities Deliverable

 All document and Evaluates the strategy of development, testing Test closure
reports related to procedure, possible defects to use these practices report
software. in the future if there is a software with the same
specification

CODE INSPECTION

What is code Inspection?

Code Inspection is the most formal type of review, which is a kind of static testing to avoid the defect
multiplication at a later stage.

 The main purpose of code inspection is to find defects and it can also spot any process improvement if
any.
 An inspection report lists the findings, which include metrics that can be used to aid improvements to the
process as well as correcting defects in the document under review.
 Preparation before the meeting is essential, which includes reading of any source documents to ensure
consistency.
 Inspections are often led by a trained moderator, who is not the author of the code.
 The inspection process is the most formal type of review based on rules and checklists and makes use of
entry and exit criteria.
 It usually involves peer examination of the code and each one has a defined set of roles.
 After the meeting, a formal follow-up process is used to ensure that corrective action is completed in a
timely manner.

Where Code Inspection fits in ?

What is Code Review?

Code Review is a systematic examination, which can find and remove the vulnerabilities in the code such as
memory leaks and buffer overflows.

 Technical reviews are well documented and use a well-defined defect detection process that includes
peers and technical experts.
 It is ideally led by a trained moderator, who is NOT the author.
 This kind of review is usually performed as a peer review without management participation.
 Reviewers prepare for the review meeting and prepare a review report with a list of findings.
 Technical reviews may be quite informal or very formal and can have a number of purposes but not
limited to discussion, decision making, evaluation of alternatives, finding defects and solving technical
problems.

Where Code Review fits in ?

What is Code Walkthrough?

Code Walkthrough is a form of peer review in which a programmer leads the review process and the other team
members ask questions and spot possible errors against development standards and other issues.

 The meeting is usually led by the author of the document under review and attended by other members of
the team.
 Review sessions may be formal or informal.
 Before the walkthrough meeting, the preparation by reviewers and then a review report with a list of
findings.
 The scribe, who is not the author, marks the minutes of meeting and note down all the defects/issues so
that it can be tracked to closure.
 The main purpose of walkthrough is to enable learning about the content of the document under review
to help team members gain an understanding of the content of the document and also to find defects.

Where Code Walkthrough fits in ?

What is Code-Based Testing?

Code-based testing corresponds to the testing that is carried out on code development, code inspection, unit
testing in software development process.

The Code-based testing consists of following testing:

 Dynamic Testing - Statement coverage, Branch coverage, Path coverage

 Checking for Complexity of Code using techniques like Cyclomatic Complexit
 Static Testing - Code Inspection, Code Walkthrough, Code Review, Code Audit

Code Based Testing Techniques:

Desk Checking

A desk check focuses on the logic and value of the variables. This is quite different from a test plan, which does
not focus on the internal workings and logic, and rather mostly focuses on inputs and outputs required by the
application. A desk check is performed with the help of a table with columns for pseudo-code line number
column, condition column, input/output column and a column for variables. The pseudo-code line number
column helps in specifying the line or lines being executed. The condition column helps in the showing the
working when evaluating the conditions. The input/output column helps in showing the inputs and outputs, and
helps in evaluating the input received by the user and the output displayed by the logic. The column for variables
helps in evaluating the calculations using variables. The programmer/designer/tester starts with some possible
inputs and walks through the algorithm line by line. The lines are assigned line numbers and proceed with each
one taking into account the change in values for variables. All information is captured in table columns. The
evaluation is usually done with the help of pen/pencil and paper, and is similar to proofreading.

There are many benefits associated with desk checking. It can find and expose issues and errors with the
algorithm. It also helps in verifying that the algorithm performs as intended to the designer or programmer. It is
a fast and inexpensive technique. It can help in identifying errors in logic at early stages of evaluation.
A desk check is not foolproof. It is the duty of the designer/programmer to make sure to have traversed through
all possible paths of the logic and make use of every data set that is required. Desk checking is subject to human
error, as the evaluator needs to understand requirements before evaluating the logic.

What is a bug in software testing?

The Bug is the informal name of defects, which means that software or application is not working as per the
requirement.

In software testing, a software bug can also be issue, error, fault, or failure. The bug occurred when developers
made any mistake or error while developing the product.

While testing the application or executing the test cases, the test engineer may not get the expected result as per
the requirement. And the bug had various names in different companies such as error, issues, problem, fault, and
mistake, etc.

Basic terminology of defect

Let see the different terminology of defect:

o Defect
o Bug
o Error
o Issue
o Mistakev
o Failurev

Terms Description Raised by

Defect When the application is not working Test Engineer

as per the requirement.

Bug Informal name of defect Test Engineer

Error Problem in code leads to the errors. Developer, Automation Test

Engineer

Issue When the application is not meeting Customer

the business requirement.

Mistake Problem in the document is known as --

a mistake.
 Failure Lots of defect leads to failure of the --
software.

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:

o Wrong coding
o Missing coding
o Extra coding

CONSEQUENCES OF BUGS:

 Importance of bugs: The importance of bugs depends on frequency, correction cost,

installation cost, and consequences.
1. Frequency: How often does that kind of bug occur? Pay more attention to the
more frequent bug types.
2. Correction Cost: What does it cost to correct the bug after it is found? The cost is
the sum of 2 factors: (1) the cost of discovery (2) the cost of correction. These
costs go up dramatically later in the development cycle when the bug is
discovered. Correction cost also depends on system size.
3. Installation Cost: Installation cost depends on the number of installations: small
for a single user program but more for distributed systems. Fixing one bug and
distributing the fix could exceed the entire system's development cost.
4. Consequences: What are the consequences of the bug? Bug consequences can
range from mild to catastrophic.

A reasonable metric for bug importance is

Importance= ($) = Frequency * (Correction cost + Installation cost + Consequential cost)

 Consequences of bugs: The consequences of a bug can be measure in terms of human

rather than machine. Some consequences of a bug on a scale of one to ten are:
1 Mild: The symptoms of the bug offend us aesthetically (gently); a misspelled
output or a misaligned printout.
2 Moderate: Outputs are misleading or redundant. The bug impacts the system's
performance.
3 Annoying: The system's behavior because of the bug is dehumanizing. E.g.
Names are truncated or arbitrarily modified.
4 Disturbing: It refuses to handle legitimate (authorized / legal) transactions. The
ATM won’t give you money. My credit card is declared invalid.
5 Serious: It loses track of its transactions. Not just the transaction itself but the fact
that the transaction occurred. Accountability is lost.
6 Very Serious: The bug causes the system to do the wrong transactions. Instead of
 losing your paycheck, the system credits it to another account or converts deposits
to withdrawals.
7 Extreme: The problems aren't limited to a few users or to few transaction types.
They are frequent and arbitrary instead of sporadic infrequent) or for unusual
cases.
8 Intolerable: Long term unrecoverable corruption of the database occurs and the
corruption is not easily discovered. Serious consideration is given to shutting the
system down.
9 Catastrophic: The decision to shut down is taken out of our hands because the
system fails.
10 Infectious: What can be worse than a failed system? One that corrupt other
systems even though it does not fall in itself ; that erodes the social physical
environment; that melts nuclear reactors and starts war.

Software Tester Role

A Software tester (software test engineer) should be capable of designing test suites and should have the
ability to understand usability issues. Such a tester is expected to have sound knowledge of software test
design and test execution methodologies. It is very important for a software tester to have great
communication skills so that he can interact with the development team efficiently. The roles and
responsibilities for a usability software tester are as follows:

1. A Software Tester is responsible for designing testing scenarios for usability testing.
2. He is responsible for conducting the testing, thereafter analyze the results and then submit his
observations to the development team.
3. He may have to interact with the clients to better understand the product requirements or in case
the design requires any kind of modifications.
4. Software Testers are often responsible for creating test-product documentation and also has to
participate in testing related walk through.

A software tester has different sets of roles and responsibilities. He should have in depth knowledge
about software testing. He should have a good understanding about the system which means technical
(GUI or non-GUI human interactions) as well as functional product aspects. In order to create test cases
it is important that the software tester is aware of various testing techniques and which approach is best
for a particular system. He should know what are various phases of software testing and how testing
should be carried out in each phase. The responsibilities of the software tester include:

1. Creation of test designs, test processes, test cases and test data.
2. Carry out testing as per the defined procedures.
3. Participate in walkthroughs of testing procedures.
4. Prepare all reports related to software testing carried out.
5. Ensure that all tested related work is carried out as per the defined standards and procedures.
There are some testing Axioms they are:

1. It is Impossible to Test a Program Completely

Reasons:

 There may be a large number of possible inputs.

 There may be a large number of possible outputs.

 There may be different paths to design a software based on users

requirements.

 It is completely based on specifications of the software.

2. Software Testing is One of the Risk Based Exercise

Reasons:

 If you test the software completely it increases the cost for testing

 If you leave some aspects in the testing there may be chances of

occurring of errors

 If your skipped part has errors it may cause a risk these risks includes:

 Financial loss,security loss,money loss or loss of a life! We can't predict

the type of risk.

 If you test too little of the software,the probability of software failure

may increase.
  Software testing takes so much time.

3. Testing cannot show the absence of bugs

Reasons:

 We can't guarantee that a software has not bugs

 In every software there may be minute bugs that may be visible or

invisible.

 Can you guarantee that there are no bugs?

4. The more bugs you find ,the more bugs there are

Reasons:

 May be programmers sometimes have bad days

 If you try to fix one bug,there may be chances of gettings some other
bugs

 Usually programmers make some mistakes in overflow that may lead to

new bugs.

 We will take care of these things when you are testing a software.

5. Not all bugs found will be fixed

Reasons:

 There is not enough time

 -too few people to code and test
 -not enough room to left them
 -must have software in time
 It is really not a bug
 It is common that we misunderstood that even if there is no error
 If we change the user requirements it may results in test errors
 It is too risk to fix
 As we discussed earlier it's a risk based exercise we can't fix those
problems
 It's just not worth it
 We usually don't consider the bugs that occur infrequently
 Bugs that are appeared in infrequently used features
 A user can avoid or prevent those bugs.

6. we can't say that when a bug is indeed a bug

 If there is some problem in the software,but we can't find the bug in the
entire software we can't say that its a bug.

7. The specifications mentioned by the user should never fail

 Reasons:

 One of the advantage in software field is that software can be easily

changed we change the code if required
 But in other domains it may be impossible
 Construct a software that is fair and not copied from any of the other
previous systems or softwares.
 Competition is high in the software industry
 There are so many new technologies that are released everyday in the
market.
 So that our software should be unique to others to succeed.

8. Software Testers are Not the Most Popular Members in a Project

Reasons:

 Do’s of a tester:
 Finding bugs in the software
 Finding the bugs correctly and in the less time
 Make sure that all bugs can be fixed as early as possible.
 Don’ts of a tester:
 Don't post the bad news to the developing team earlier
 Make sure to double check even though you can't find if you can inform
them.
 Act like a professional to other team members
 Control your enthusiasm if you are a tester

9. Software Testing is Somewhat Disciplined and Technical Profession

Reasons:

 We can say that it is a disciplined activity because it goes through step by

step procedure
 If we miss one step we may get the test errors
 We can say it is a technical profession because we are using

I. sophisticated tools
II. advanced technologies
III. rewarding career growth

 if software is simple and more manageable software testers are

untrained,we can't find bugs in the software
 If we put millions of money on the team we couldn't get a single test error
in it.

Software Testing Terminology

Software Testing Terminology, Software Development Life Cycle, Software Test Levels,
Test Types, Test Design Techniques, Software Testing Life Cycle, and Informal Testing.

1. Phases of SDLC (Requirements Gathering, Analysis & Planning, Design, Coding, Testing,
Release & Maintenance)
2. SDLC Models (Waterfall Model, V Model, Spiral Model, Agile Model, etc,)

3. Test Levels (Unit Testing, Integration Testing, System Testing, and Acceptance Testing)

4. Test Types (Functional Testing, Non-functional Testing, Re & Regression Testing, and
Structural Testing)

5. Test Design Techniques (White box, Black box, and Experience-based)

6. Phases of STLC (Requirements Analysis, Test Planning, Test Design, Test Environment
Setup, Test Execution, and Test Cycle Closure)

7. Test Documents (Test Policy, Test Strategy, Test Plan, Test Scenario, Test Case, Defect
Report, Test Metrics Report, and Test Summary Report)

Software Testing Important Terminology

1. SDLC (Software Design Life Cycle)

Software Development Life Cycle is a systematic approach for developing software. It is a

Process followed by Software Developers, and Software Testing is an integral part of
Software Development.

Phases of SDLC are Requirement Gathering, Analysis, Design, Coding, Testing, Deployment
& Maintenance.

2. Test Level

Test Level: A specific instantiation of a test process.

Software testing can be performed at different levels of the software development process.
Performing testing activities at multiple levels help in early identification of bugs and better
quality of software product.

There are mainly four Levels of Testing in software testing, Unit Testing, Integration Testing,
System Testing, and Acceptance Testing.

3. Test Type

A Test type is a group of test activities aimed at testing specific characteristics of a software
system or a part of a system.

Test Type: A Test type is a group of test activities aimed at testing specific characteristics of
a software system or a part of a system.
We have four types of Testing, Functional testing, Non-functional testing, Structural testing,
and Change-related testing.

4. Test Design Technique

A test design technique is used to select a good set of tests from all possible tests for a given
system.

We have static and dynamic test design techniques in Software Testing. White box, black
box, and experienced-based techniques are there in dynamic testing, and Equivalence
partition, boundary value analysis, decision table testing, state transition testing, and use case
testing are important for dynamic testing.

5. STLC (Software Test Life Cycle)

Software Testing Life Cycle (STLC) is a sequence of different activities performed during
the software testing process.

Software testing life cycle contains various phases, which are Requirement Analysis, Test
Planning, Test Case development, Test Environment Setup, Test Execution, and Test Cycle
Closure.

6. Informal Testing

Informal Testing: Ad hoc testing performed without a documented set of objectives or plans.
Informal testing relies on the intuition and skills of the individual performing the testing.
Experienced engineers can be productive in this mode by mentally performing test cases for
the scenarios being exercised.

7. Test Planning

Test planning is a phase in STLC, the main objective of this phase is to prepare a Test Plan
document. It includes three major aspects – Scope of Deliverables, Effort estimation, and
Resource Plan.

8. Test Documentation

Test documentation is documentation of artifacts created before, during, and after the testing
of software.

Test Policy, Test Strategy, RTM, Test Plan, Test Case, Defect Report, Test Metrics Report,
and Test Summary Reports are the important Test Documents.

9. Test Execution Level

We have some levels of Test Execution, Smoke Testing, Sanity Testing, Comprehensive
Testing, and Regression Testing.

10. Test Deliverables

Test Deliverables refer to a list of documents, tools, and other equipment that must be
created, provided, and maintained to support testing activities in a project.

11. Test Closure

Test closure is a set of activities that are performed at the end of the testing process. These
are usually performed after the product is delivered, like generating a test report, etc.

12. Maintenance Testing

Once a system is deployed it is in service for years and decades. During this time the system
and its operational environment is often corrected, changed or extended. Testing that is
provided during this phase is called Maintenance Testing.

What is Verification in Software Testing?

Verification in Software Testing is a process of checking documents, design, code, and

program in order to check if the software has been built according to the requirements or not.
The main goal of verification process is to ensure quality of software application, design,
architecture etc. The verification process involves activities like reviews, walk-throughs and
inspection.

What is Validation in Software Testing?

Validation in Software Engineering is a dynamic mechanism of testing and validating if the
software product actually meets the exact needs of the customer or not. The process helps to
ensure that the software fulfills the desired use in an appropriate environment. The validation
process involves activities like unit testing, integration testing, system testing and user
acceptance testing.

Difference Between Verification and Validation in Software Testing

Here is the main difference between Verification and Validation in Software Testing:

Verification Validation

The verifying process includes checking It is a dynamic mechanism of testing

documents, design, code, and program and validating the actual product

It does not involve executing the code It always involves executing the code

Verification uses methods like reviews,

It uses methods like Black Box Testing, White
walkthroughs, inspections, and desk- checking
Box Testing, and non-functional testing
etc.
 Whether the software conforms to specification It checks whether the software meets the
is checked requirements and expectations of a customer

It can find bugs that the verification process

It finds bugs early in the development cycle
can not catch

Target is application and software architecture,

specification, complete design, high level, and Target is an actual product
database design etc.

QA team does verification and make sure that the

With the involvement of testing team
software is as per the requirement in the SRS
validation is executed on software code.
document.

It comes before validation It comes after verification