lOMoARcPSD|47263019

UNIT 1- Software Testing

Software Testing (Dr. A.P.J. Abdul Kalam Technical University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Rishav Raj (rrishav258@gmail.com)
 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

UNIT-I

SOFTWARE EVOLUTION

Software Evolution is a term which refers to the process of developing software initially,
then timely updating it for various reasons, i.e., to add new features or to remove obsolete
functionalities etc. The evolution process includes fundamental activities of change
analysis, release planning, system implementation and releasing a system to customers.
The cost and impact of these changes are accessed to see how much system is affected by
the change and how much it might cost to implement the change. If the proposed changes
are accepted, a new release of the software system is planned. During release planning, all
the proposed changes (fault repair, adaptation, and new functionality) are considered.
A design is then made on which changes to implement in the next version of the system.
The process of change implementation is an iteration of the development process where the
revisions to the system are designed, implemented and tested.

THE NECESSITY OF SOFTWARE EVOLUTION:

Software evaluation is necessary just because of the following reasons:

a) Change in requirement with time: With the passes of time, the organization’s needs
and modus Operandi of working could substantially be changed so in this frequently
changing time the tools (software) that they are using need to change for maximizing the
performance.

b) Environment change: As the working environment changes the things(tools) that

enable us to work in that environment also changes proportionally same happens in the
software world as the working environment changes then, the organizations need
reintroduction of old software with updated features and functionality to adapt the new
environment.

c) Errors and bugs: As the age of the deployed software within an organization increases
their preciseness or impeccability decrease and the efficiency to bear the increasing
complexity workload also continually degrades. So, in that case, it becomes necessary to

PREPARED BY: MS. SONAM SINGH Page 1

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

avoid use of obsolete and aged software. All such obsolete Software’s need to undergo the
evolution process in order to become robust as per the workload complexity of the current
environment.

d) Security risks: Using outdated software within an organization may lead you to at the
verge of various software-based cyber attacks and could expose your confidential data
illegally associated with the software that is in use. So, it becomes necessary to avoid such
security breaches through regular assessment of the security patches/modules are used
within the software. If the software isn’t robust enough to bear the current occurring Cyber-
attacks so it must be changed (updated).

e) For having new functionality and features: In order to increase the performance and
fast data processing and other functionalities, an organization need to continuously evolute
the software throughout its life cycle so that stakeholders & clients of the product could
work efficiently.

LAWS USED FOR SOFTWARE EVOLUTION:

1. Law of continuing change:

This law states that any software system that represents some real-world reality
undergoes continuous change or become progressively less useful in that environment.

2. Law of increasing complexity:

As an evolving program changes, its structure becomes more complex unless effective
efforts are made to avoid this phenomenon.

3. Law of conservation of organization stability:

Over the lifetime of a program, the rate of development of that program is
approximately constant and independent of the resource devoted to system
development.

4. Law of conservation of familiarity:

This law states that during the active lifetime of the program, changes made in the
successive release are almost constant.

SDLC
A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures the
structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the necessary
development activities to phases in different ways. Thus, no element which life cycle model
is followed, the essential activities are contained in all life cycle models though the action
may be carried out in distinct orders in different life cycle models. During any life cycle
stage, more than one activity may also be carried out.

PREPARED BY: MS. SONAM SINGH Page 2

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

NEED OF SDLC
The development team must determine a suitable life cycle model for a particular plan and
then observe to it.

Without using an exact life cycle model, the development of a software product would not be
in a systematic and disciplined manner. When a team is developing a software product, there
must be a clear understanding among team representative about when and what to do.
Otherwise, it would point to chaos and project failure. This problem can be defined by using
an example. Suppose a software development issue is divided into various parts and the parts
are assigned to the team members. From then on, suppose the team representative is allowed
the freedom to develop the roles assigned to them in whatever way they like. It is possible
that one representative might start writing the code for his part, another might choose to
prepare the test documents first, and some other engineer might begin with the design phase
of the roles assigned to him. This would be one of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each phase. A phase can
begin only if its stage-entry criteria have been fulfilled. So without a software life cycle
model, the entry and exit criteria for a stage cannot be recognized. Without software life
cycle models, it becomes tough for software project managers to monitor the progress of the
project.

SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes the
following steps:

The stages of SDLC are as follows:

STAGE1: PLANNING AND REQUIREMENT ANALYSIS

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.

PREPARED BY: MS. SONAM SINGH Page 3

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Planning for the quality assurance requirements and identifications of the risks associated
with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the data
like what the customer wants to build, who will be the end user, what is the objective of the
product. Before creating a product, a core understanding or knowledge of the product is very
necessary.

For Example, A client wants to have an application which concerns money transactions. In
this method, the requirement has to be precise like what kind of operations will be done, how
it will be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement Specification)

document is created. The developers should thoroughly follow this document and also should
be reviewed by the customer for future reference.

STAGE2: DEFINING REQUIREMENTS

Once the requirement analysis is done, the next stage is to certainly represent and document
the software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project life
cycle.

STAGE3: DESIGNING THE SOFTWARE

The next phase is about to bring down all the knowledge of requirements, analysis, and
design of the software project. This phase is the product of the last two, like inputs from the
customer and requirement gathering.

STAGE4: DEVELOPING THE PROJECT

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.

STAGE5: TESTING

After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

PREPARED BY: MS. SONAM SINGH Page 4

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

STAGE6: DEPLOYMENT

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.

After the software is deployed, then its maintenance begins.

STAGE7: MAINTENANCE

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.

This procedure where the care is taken for the developed product is known as maintenance.

SOFTWARE TESTING PROCESS

These are 11 steps software testing process is an experience based practical approach for
solution to test assignment.
These are explained as following below.
 Step-1: Assess Development Plan and Status –
This initiative may be prerequisite to putting together Verification, Validation, and
Testing Plan won’t to evaluate implemented software solution. During this step, testers
challenge completeness and correctness of event plan. Based on extensiveness and
completeness of Project Plan testers can estimate quantity of resources they’re going to
got to test implemented software solution.

 Step-2: Develop the Test Plan –

Forming plan for testing will follow an equivalent pattern as any software planning
process. The structure of all plans should be an equivalent, but content will vary
supported degree of risk testers perceive as related to software being developed.

 Step-3: Test Software Requirements –

Incomplete, inaccurate, or inconsistent requirements cause most software failures. The
inability to get requirement right during requirements gathering phase can also increase
cost of implementation significantly. Testers, through verification, must determine that
requirements are accurate, complete, and they do not conflict with another.

 Step-4: Test Software Design –

This step tests both external and internal design primarily through verification
techniques. The testers are concerned that planning will achieve objectives of wants,
also because design being effective and efficient on designated hardware.

 Step-5: Build Phase Testing –

The method chosen to build software from internal design document will determine

PREPARED BY: MS. SONAM SINGH Page 5

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

type and extensiveness of testers needed. As the construction becomes more automated,
less testing are going to be required during this phase. However, if software is made
using waterfall process, it’s subject to error and will be verified. Experience has shown
that it’s significantly cheaper to spot defects during development phase, than through
dynamic testing during test execution step.

 Step-6: Execute and Record Result –

This involves testing of code during dynamic state. The approach, methods, and tools
laid out in test plan are going to be wont to validate that executable code actually meets
stated software requirements, and therefore the structural specifications of design.

 Step-7: Acceptance Test –

Acceptance testing enables users to gauge applicability and usefulness of software in
performing their day-to-day job functions. This tests what user believes software should
perform, as against what documented requirements state software should perform.

 Step-8: Report Test Results –

Test reporting is continuous process. It may be both oral and written. It is important that
defects and concerns be reported to the appropriate parties as early as possible, so that
corrections can be made at the lowest possible cost.

 Step-9: The Software Installation –

Once test team has confirmed that software is prepared for production use, power to
execute that software during production environment should be tested. This tests
interface to operating software, related software, and operating procedures.

 Step-10: Test Software Changes –

While this is often shown as Step 10, within context of performing maintenance after
software is implemented, concept is additionally applicable to changes throughout
implementation process. Whenever requirements changes, test plan must change, and
impact of that change on software systems must be tested and evaluate.

 Step-11: Evaluate Test Effectiveness –

Testing improvement can best be achieved by evaluating effectiveness of testing at top
of every software test assignment. While this assessment is primarily performed by
testers, it should involve developers, users of software, and quality assurance
professionals if function exists within the IT organization.

ERROR

We are going to discuss the difference between the Bug, Defect, Error, and Fault &
Failure as we understood that all the terms are used whenever the system or an application act
abnormally.

Sometimes we call it an error and sometimes a bug or a defect and so on. In software testing,
many of the new test engineers have confusion in using these terminologies.

PREPARED BY: MS. SONAM SINGH Page 6

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Generally, we used these terms in the Software Development Life Cycle (SDLC) based on
the phases. But there is a conflict in the usage of these terms.

In other words, we can say that in the era of software testing, the terms bugs, defects, error,
fault, and failure come across every second of the day.

WHAT IS A BUG?

In software testing, a bug is the informal name of defects, which means that software or
application is not working as per the requirement. When we have some coding error, it leads
a program to its breakdown, which is known as a bug. The test engineers use the
terminology Bug.

If a QA (Quality Analyst) detect a bug, they can reproduce the bug and record it with the help
of the bug report template.

WHAT IS A DEFECT?

When the application is not working as per the requirement is knows as defects. It is specified
as the aberration from the actual and expected result of the application or software.

In other words, we can say that the bug announced by the programmer and inside the code is
called a Defect.

What is Error?

The Problem in code leads to errors, which means that a mistake can occur due to the
developer's coding error as the developer misunderstood the requirement or the requirement
was not defined correctly. The developers use the term error.

WHAT IS FAULT?

The fault may occur in software because it has not added the code for fault tolerance, making
an application act up.

A fault may happen in a program because of the following reasons:

PREPARED BY: MS. SONAM SINGH Page 7

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

o Lack of resources
o An invalid step
o Inappropriate data definition

WHAT IS FAILURE?

Many defects lead to the software's failure, which means that a loss specifies a fatal issue in
software/ application or in its module, which makes the system unresponsive or broken.

In other words, we can say that if an end-user detects an issue in the product, then that
particular issue is called a failure.

Possibilities are there one defect that might lead to one failure or several failures.

For example, in a bank application if the Amount Transfer module is not working for end-
users when the end-user tries to transfer money, submit button is not working. Hence, this is
a failure.

The flows of the above terminologies are shown in the following image:

Bug vs. Defect vs. Error vs. Fault vs. Failure

We have listed some of the vital differences between bug, defect, error, fault, and failure in
the below table.

Compa Bug Defect Error Fault Failure

rison
basis

Definitio It is an informal The Defect is the An Error is a mistake The Fault is a state If the software has
n name specified to difference between made in the code; that's that causes the lots of defects, it
the defect. the actual outcomes why we cannot execute software to fail to leads to failure or
and expected outputs. or compile code. accomplish its causes failure.
essential function.

Raised The Test The Testers identify The Developers and Human The failure finds by
by Engineers submit the defect. And it was automation test mistakes cause fault. the manual test
the bug. also solved by the engineers raise the engineer through
developer in the error. the development
development phase or

PREPARED BY: MS. SONAM SINGH Page 8

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

stage. cycle.

Different Different type of Different type of Different type of Error Different type of -----
types bugs are as follows: Defects are as is as below: Fault are as follows:
follows:
o Logic Based on priority: o Syntactic o Business
bugs Error Logic
o Algorith o High o User interface Faults
mic bugs o Medium error o Functional
o Resource o Low o Flow control and Logical
bugs error Faults
And based on the o Error o Faulty GUI
severity: handling o Performanc
error e Faults
o Critical
o Major o Calculation o Security
error Faults
o Minor
o Hardware o Software/
o Trivial error hardware
o Testing Error fault

Reasons Following are The below reason The reasons for having The reasons behind Following are some
behind reasons which may leads to the defects: an error are as follows: the fault are as of the most
cause the bugs: Giving incorrect and Errors in the code. follows: important reasons
Missing coding wrong inputs. The Mistake of some A Fault may occur by behind the failure:
Wrong coding Dilemmas and errors values. an improper step in Environmental
Extra coding in the outside If a developer is the initial stage, condition
behavior and inside unable to compile or process, or data System usage
structure and design. run a program definition. Users
An error in coding or successfully. Inconsistency or issue Human error
logic affects the Confusions and issues in the program.
software and causes it in programming. An irregularity or
to breakdown or the Invalid login, loop, and loophole in the
failure. syntax. software that leads
Inconsistency between the software to
actual and expected perform improperly.
outcomes.
Blunders in design or
requirement actions.
Misperception in
understanding the
requirements of the
application.

Way to Following are the With the help of the Below are ways to The fault can be The way to
prevent way to stop following, we can prevent the Errors: prevented with the prevent failure are
the the bugs: prevent the Defects: Enhance the software help of the following: as follows:
reasons Test-driven Implementing several quality with system Peer review. Confirm re-testing.
development. innovative review and Assess the functional Review the
Offer programming programming programming. necessities of the requirements and
language support. methods. Detect the issues and software. revisit the
Adjusting, Use of primary and prepare a suitable Execute the detailed specifications.
advanced, and correct software mitigation plan. code analysis. Implement current
operative development Validate the fixes and Verify the correctness protective
development techniques. verify their quality and of software design techniques.
procedures. Peer review precision. and programming. Categorize and
Evaluating the code It is executing evaluate errors and
systematically. consistent code issues.
reviews to evaluate
its quality and correct

PREPARED BY: MS. SONAM SINGH Page 9

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

CONCLUSION

After seeing all the significant differences between bug, defect, error, fault, and failure, we
can say that the several issues and inconsistencies found throughout software are linked and
dependent on each other.

All the above terminology affects and change different parts of the software and differs from
one another massively. However, all these differences between bug, defect, errors, faults, and
failures slow down the software's excellence and performance.

VERIFICATION AND VALIDATION

Verification is the process of checking that software achieves its goal without any bugs. It
is the process to ensure whether the product that is developed is right or not. It verifies
whether the developed product fulfils the requirements that we have. Verification is static
testing.

Verification means Are we building the product right?

Validation is the process of checking whether the software product is up to the mark or in
other words product has high level requirements. It is the process of checking the validation
of product i.e. it checks what we are developing is the right product. it is validation of
actual and expected product. Validation is the dynamic testing.

Validation means Are we building the right product?

THE DIFFERENCE BETWEEN VERIFICATION AND VALIDATION IS AS FOLLOW:

Verification Validation

It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the

code. It includes the execution of the code.

Methods used in verification are reviews, Methods used in validation are Black Box
walkthroughs, inspections and desk- Testing, White Box Testing and non-
checking. functional testing.

It checks whether the software meets the

It checks whether the software conforms to requirements and expectations of a customer
specifications or not. or not.

PREPARED BY: MS. SONAM SINGH Page 10

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Verification Validation

It can find the bugs in the early stage of the It can only find the bugs that could not be
development. found by the verification process.

The goal of verification is application and

software architecture and specification. The goal of validation is an actual product.

Validation is executed on software code with

Quality assurance team does verification. the help of testing team.

It comes before validation. It comes after verification.

It consists of checking of documents/files It consists of execution of program and is

and is performed by human. performed by computer.

VERIFICATION TESTING

Verification testing includes different activities such as business requirements, system

requirements, design review, and code walkthrough while developing a product.

It is also known as static testing, where we are ensuring that "we are developing the right
product or not". And it also checks that the developed application fulfilling all the
requirements given by the client.

PREPARED BY: MS. SONAM SINGH Page 11

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

VALIDATION TESTING

Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System
Testing (ST), and non-functional testing includes User acceptance testing (UAT).

Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business needs of
the client.

Note: Verification and Validation process are done under the V model of the software
development life cycle.
Difference between verification and validation testing

Verification Validation

We check whether we are developing the right We check whether the developed product is right.
product or not.

Verification is also known as static testing. Validation is also known as dynamic testing.

Verification includes different methods like Validation includes testing like functional testing,
Inspections, Reviews, and Walkthroughs. system testing, integration, and User acceptance
testing.

It is a process of checking the work-products It is a process of checking the software during or

(not the final product) of a development cycle at the end of the development cycle to decide
to decide whether the product meets the whether the software follow the specified business
specified requirements. requirements.

Quality assurance comes under verification Quality control comes under validation testing.
testing.

PREPARED BY: MS. SONAM SINGH Page 12

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

The execution of code does not happen in the In validation testing, the execution of code
verification testing. happens.

In verification testing, we can find the bugs In the validation testing, we can find those bugs,
early in the development phase of the product. which are not caught in the verification process.

Verification testing is executed by the Quality Validation testing is executed by the testing team
assurance team to make sure that the product is to test the application.
developed according to customers'
requirements.

Verification is done before the validation After verification testing, validation testing takes
testing. place.

In this type of testing, we can verify that the In this type of testing, we can validate that the
inputs follow the outputs or not. user accepts the product or not.

TEST CASE
The test case is defined as a group of conditions under which a tester determines whether a
software application is working as per the customer's requirements or not. Test case
designing includes preconditions, case name, input conditions, and expected result. A test
case is a first level action and derived from test scenarios.

It is an in-details document that contains all possible inputs (positive as well as negative) and
the navigation steps, which are used for the test execution process. Writing of test cases is a
one-time attempt that can be used in the future at the time of regression testing.

Test case gives detailed information about testing strategy, testing process, preconditions, and
expected output. These are executed during the testing process to check whether the software
application is performing the task for that it was developed or not.

PREPARED BY: MS. SONAM SINGH Page 13

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test
case documentation works as a full proof guard for the testing team because if developer
missed something, then it can be caught during execution of these full-proof test cases.

WHEN DO WE WRITE A TEST CASE?

We will write the test case when we get the following:

o When the customer gives the business needs then, the developer starts developing and
says that they need 3.5 months to build this product.
o And In the meantime, the testing team will start writing the test cases.
o Once it is done, it will send it to the Test Lead for the review process.
o And when the developers finish developing the product, it is handed over to the
testing team.
o The test engineers never look at the requirement while testing the product document
because testing is constant and does not depends on the mood of the person rather
than the quality of the test engineer.

WHY WE WRITE THE TEST CASES?

We will write the test for the following reasons:

o To require consistency in the test case execution

o To make sure a better test coverage
o It depends on the process rather than on a person
o To avoid training for every new test engineer on the product

To require consistency in the test case execution: we will see the test case and start testing the
application.

To make sure a better test coverage: for this, we should cover all possible scenarios and
document it, so that we need not remember all the scenarios again and again.

It depends on the process rather than on a person: A test engineer has tested an application
during the first release, second release, and left the company at the time of third release. As
the test engineer understood a module and tested the application thoroughly by deriving many
values. If the person is not there for the third release, it becomes difficult for the new person.
Hence all the derived values are documented so that it can be used in the future.

To avoid giving training for every new test engineer on the product: When the test engineer
leaves, he/she leaves with a lot of knowledge and scenarios. Those scenarios should be
documented so that the new test engineer can test with the given scenarios and also can write
the new scenarios.

PREPARED BY: MS. SONAM SINGH Page 14

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

TEST SUITE
WHAT IS A TEST SUITE?
Test suite is a container that has a set of tests which helps testers in executing and reporting
the test execution status. It can take any of the three states namely Active, Inprogress and
completed.
A Test case can be added to multiple test suites and test plans. After creating a test plan, test
suites are created which in turn can have any number of tests.
Test suites are created based on the cycle or based on the scope. It can contain any type of
tests, viz - functional or Non-Functional.

Test Suite - Diagram:

SOFTWARE VERIFICATION

WHAT IS SOFTWARE VERIFICATION?

Reviewing of any software for the purpose of finding faults is known as software
verification. Verification is the process of checking that software achieves its goal without
any bugs. It is the process to ensure whether the product that is developed is right or not.
The reviewing of a document can be done from the first phase of software development i.e.
software requirement and analysis phase where the end product is the SRS document. There
are many methods for practicing the verification of the software like peer reviews,
walkthroughs, inspections, etc that can help us in the prevention of potential faults
otherwise, it may lead to the failure of software.

PREPARED BY: MS. SONAM SINGH Page 15

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

METHODS OF VERIFICATION:

1. PEER REVIEWS –
The very easiest method and informal way of reviewing the documents or the
programs/software for the purpose of finding out the faults during the verification process
is the peer-review method. In this method, we give the document or software programs to
others and ask them to review those documents or software programs where we expect their
views about the quality of our product and also expect them to find the faults in the
program/document. The activities that are involved in this method may include SRS
document verification, SDD verification, and program verification. In this method, the
reviewers may also prepare a short report on their observations or findings, etc.

Advantages:

 You can expect some good results without spending any significant resources.
 It is very efficient and significant in its nature.

Disadvantages:

 Lead to bad results if the reviewer doesn’t have sufficient knowledge.

2. WALK-THROUGH –
Walk-through is the formal and very systematic type of verification method as compared to
peer-review. In a walkthrough, the author of the software document presents the document
to other persons which can range from 2 to 7. Participants are not expected to prepare
anything. The presenter is responsible for preparing the meeting. The document(s) is/are
distributed to all participants. At the time of the meeting of the walk-through, the author
introduces the content in order to make them familiar with it and all the participants are free
to ask their doubts.

Advantages:

 It may help us to find potential faults.

 It may also be used for sharing documents with others.

Disadvantages:

 The author may hide some critical areas and unnecessarily emphasize some specific
areas of his / her interest.

PREPARED BY: MS. SONAM SINGH Page 16

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

3. INSPECTIONS –

Inspections are the most structured and most formal type of verification method and are
commonly known as inspections. A team of three to six participants is constituted which is
led by an impartial moderator. Every person in the group participates openly, actively, and
follows the rules about how such a review is to be conducted. Everyone may get time to
express their views, potential faults, and critical areas. After the meeting, a final report is
prepared after incorporating necessary suggestions by the moderator.

Advantages:

 It can be very effective for finding potential faults or problems in the documents like
SRS, SDD, etc.
 The critical inspections may also help in finding faults and improve these documents
which can in preventing the propagation of a fault in the software development life
cycle process.

Disadvantages:

 They take time and require discipline.

 It requires more cost and also needs skilled testers.

APPLICATIONS OF VERIFICATION METHODS:

The above three verification methods are very popular and have their own strengths and
weaknesses. We can compare these methods on various specific issues as given below:
NO. OF PRE-
S.NO METHOD PRESENTER MEMBERS REQUISITES REPORT STRENGTH WEAKNESS

Output is
dependent
on the
ability of
No Not Less- the
1. Peer reviews 0 1 or 2 prerequisite Required Expensive reviewer

The report
The only is Find few
presenter is prepared faults and
2 to 7 required to by the Knowledge not very
2. Walkthrough Author members be prepared presenter sharing expensive

Expensive
All The report and
participants is requires
Author and are required prepared Effective very
other 3 to 6 to be by the but may skilled
3. Inspection members members prepared moderator get faults members

PREPARED BY: MS. SONAM SINGH Page 17

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Hence, Verification is likely more effective than validation but it may find some faults that
are somewhat impossible to find during the validation process. But at the same time, it
allows us to find faults at the earliest possible phase/time of software development.

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.

CONFIGURATION AUDITS AND REVIEWS:

Software Configuration audits verify that the entire software product satisfies the baseline
needs. It ensures that what is built is what is delivered.

Activities during this process:

 Configuration auditing is conducted by auditors by checking that defined processes

are being followed and ensuring that the SCM goals are satisfied.
 To verify compliance with configuration control standards. auditing and reporting the
changes made
 SCM audits also ensure that traceability is maintained during the process.
 Ensures that changes made to a baseline comply with the configuration status reports
 Validation of completeness and consistency

TESTING DOCUMENTATION

Testing documentation is the documentation of artifacts that are created during or before the
testing of a software application. Documentation reflects the importance of processes for the
customer, individual and organization.

Projects which contain all documents have a high level of maturity. Careful documentation
can save the time, efforts and wealth of the organization.

PREPARED BY: MS. SONAM SINGH Page 18

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

There is the necessary reference document, which is prepared by every test engineer before
stating the test execution process. Generally, we write the test document whenever the
developers are busy in writing the code.

Once the test document is ready, the entire test execution process depends on the test
document. The primary objective for writing a test document is to decrease or eliminate the
doubts related to the testing activities.

In software testing, we have various types of test document, which are as follows:

o Test scenarios
o Test case
o Test plan
o Requirement traceability matrix(RTM)
o Test strategy
o Test data
o Bug report
o Test execution report

Why documentation is needed

If the testing or development team gets software that is not working correctly and developed
by someone else, so to find the error, the team will first need a document. Now, if the
documents are available then the team will quickly find out the cause of the error by
examining documentation. But, if the documents are not available then the tester need to do
black box and white box testing again, which will waste the time and money of the
organization. More than that, Lack of documentation becomes a problem for acceptance.

Example

Let's take a real-time example of Microsoft, Microsoft launch every product with proper user
guidelines and documents, which are very explanatory, logically consistent and easy to
understand for any user. These are all the reasons behind their successful products.

Benefits of using Documentation

o Documentation clarifies the quality of methods and objectives.
o It ensures internal coordination when a customer uses software application.
o It ensures clarity about the stability of tasks and performance.
o It provides feedback on preventive tasks.
o It provides feedback for your planning cycle.
o It creates objective evidence for the performance of the quality management system.
o If we write the test document, we can't forget the values which we put in the first
phase.
o It is also a time-saving process because we can easily refer to the text document.
o It is also consistent because we will test on the same value.

PREPARED BY: MS. SONAM SINGH Page 19

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

The drawback of the test document

o It is a bit tedious because we have to maintain the modification provided by the

customer and parallel change in the document.
o If the test documentation is not proper, it will replicate the quality of the application.
o Sometimes it is written by that person who does not have the product knowledge.
o Sometimes the cost of the document will be exceeding its value.

SOFTWARE QUALITY ASSURANCE

Software quality assurance is a planned and systematic plan of all actions necessary to
provide adequate confidence that an item or product conforms to establish technical
requirements.

A set of activities designed to calculate the process by which the products are developed or
manufactured.

SQA Encompasses
o A quality management approach
o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o Measuring and reporting mechanisms.

SQA Activities

Software quality assurance is composed of a variety of functions associated with two

different constituencies? The software engineers who do technical work and an SQA group
that has responsibility for quality assurance planning, record keeping, analysis, and reporting

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during project
planning and is reviewed by all stakeholders. The plan governs quality assurance
activities performed by the software engineering team and the SQA group. The plan
identifies calculation to be performed, audits and reviews to be performed, standards
that apply to the project, techniques for error reporting and tracking, documents to be
produced by the SQA team, and amount of feedback provided to the software project
team.
2. Participates in the development of the project's software process description: The
software team selects a process for the work to be performed. The SQA group reviews
the process description for compliance with organizational policy, internal software
standards, externally imposed standards (e.g. ISO-9001), and other parts of the
software project plan.

PREPARED BY: MS. SONAM SINGH Page 20

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

3. Reviews software engineering activities to verify compliance with the defined

software process: The SQA group identifies, reports, and tracks deviations from the
process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with those defined as
a part of the software process: The SQA group reviews selected work products,
identifies, documents and tracks deviations, verify that corrections have been made,
and periodically reports the results of its work to the project manager.
5. Ensures that deviations in software work and work products are documented and
handled according to a documented procedure: Deviations may be encountered in the
project method, process description, applicable standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non- compliance
items are tracked until they are resolved.

Quality Assurance v/s Quality control

Quality Assurance Quality Control

Quality Assurance (QA) is the set of actions Quality Control (QC) is described as the
including facilitation, training, measurement, processes and methods used to compare
and analysis needed to provide adequate product quality to requirements and
confidence that processes are established applicable standards, and the actions are
and continuously improved to produce taken when a non-conformance is detected.
products or services that conform to
specifications and are fit for use.

QA is an activity that establishes and QC is an activity that demonstrates whether

calculates the processes that produce the or not the product produced met standards.
product. If there is no process, there is no
role for QA.

QA helps establish process QC relates to a particular product or service

QA sets up a measurement program to QC verified whether particular attributes

evaluate processes exist, or do not exist, in a explicit product or
service.

QA identifies weakness in processes and QC identifies defects for the primary goals
improves them of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

PREPARED BY: MS. SONAM SINGH Page 21

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Why do we need SQA in Test Management process?

As a Test Manager, you are the person who takes in charge these activities. However, you are
at the highest position in the project team. Who will review your tasks and check the project
management activities are executed to the highest standard?

Well, SQA auditor is the person who reviews and checks the project management activities
are executed to the highest possible standard. Only through the result of this review, the
Management Board can evaluate the quality of your project handling.

This is the reason why we do need Management Review or SQA in Test Management
process.

The SQA interviews you, the Test Manager, to benchmark the project against set standards.

BENEFITS OF SQA ARE –

PREPARED BY: MS. SONAM SINGH Page 22

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

HOW TO IMPLEMENT THE QUALITY ASSURANCE?

Step 1) Develop SQA Plan

Testing activity needs Test Plan likewise SQA activity also needs a plan which is called SQA
plan.

The goal of SQA plan is to craft planning processes and procedures to ensure products
manufactured, or the service delivered by the organization are of exceptional quality.

During project planning, Test Manager makes an SQA plan where SQA audit is scheduled
periodically.

In the SQA Plan, the Test Manager should do as following

Step 1.1) Identify the role and responsibilities of SQA team

In a project team, every member must have responsibility for the quality of his or her work.
Each person has to make sure their work meet the QA criteria.

The SQA team is the group of person who plays the major role in the project. Without QA,
no business will run successfully. Therefore, the Test Manager has to make clear
the responsibility of each SQA member in SQA plan as below:

 Review and evaluate the quality of project activities to meet the QA criteria
 Coordinate with management board and project teams to assess requirements and
engage in project review and status meetings.

PREPARED BY: MS. SONAM SINGH Page 23

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

 Design track and collect metrics to monitor project quality.

 Measure the quality of product; ensure the product meet the customer expectations.

For example, in the SQA Plan of the project Guru99 Bank, you can create the list members
of SQA team as below

No Member Roles Responsibility

Develop and document quality standard and process for all management
SQA
1 Peter process
Leader
Manage software quality assurance activities for the project
SQA
2 James Perform SQA tasks, report to SQA leader the result of SQA review.
auditor

SQA
3 Bean Perform SQA tasks, report to SQA leader the result of SQA review.
auditor

Step 1.2) List of the work products that the SQA auditor will review and audit
The Test Manager should

 List out all the work products of each Test Management Process
 Define which facilities or equipment the SQA auditor can access to perform SQA
tasks such as process evaluations and audits.

For example, for the project Guru99 Bank, you can list out the work products of each Test
Management Process and define permission for SQA members to access these work products
as per the following table

No Management Phases Work product Path Permission Grant to Person

1 Risk analysis Risk Management document [Server path] Read All SQA team members

2 Estimation Estimation and Metrics report … Read Peter

3 Planning Test Planning document … Read All SQA team members

4 Organization Human resource plan, training plan … Read All SQA team members

5 Monitoring and Control Collected metrics of project effort … Read Bean

6 Issue Management Issue management report … Read James

7 Test report Test Report document … Read All SQA team members

Step 1.3) Create the schedule to perform the SQA tasks

In this step, the Test Manager should describe the tasks to be performed by SQA auditor with
special emphasis on SQA activities as well as the work product for each task.

PREPARED BY: MS. SONAM SINGH Page 24

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Test Manager also creates the scheduling of those SQA tasks. Normally, the SQA schedule is
driven by the project development schedule. Therefore, an SQA task is performed in
relationship to what software development activities are taking place.

In the SQA plan, Test Manager makes the schedule for management review. For example

Personal in
Date SQA Tasks Description Output
charge

– Software Specification Review

30-Oct- Evaluate project planning, tracking SQA planning report,
James
2014 and oversight processes SQA review minute
– Estimation, Master Schedule
and Project Plan Review

15-Dec-
Review requirement analysis James – Review the software Process audit report
2014
requirement development

30-Mar- SQA report, SQA review

Review and Evaluate Test Design James – Review the Test Design
2015 minute
document

30-Mar-
Review release Bean SQA process audit report
2015 – Process Audit: Final Release

2-Apr-
Review Project closing Bean – External review after final SQA process audit report
2015
delivery to customer

Step 2) Define the standards/methodology

To review the Management activities against the standards process, you should do the
following steps

1. Define the policies and procedures intended to prevent defects from occurring in the
management process
2. Document the policies & procedures
3. Inform and train the staff to use it

PREPARED BY: MS. SONAM SINGH Page 25

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Step 3) Review the process

Review project activities to verify compliance with the defined management process. In the
management review, the SQA members have to perform 5 SQA reviews as following

Review time for SQA depends on the project’s development lifecycle model. In the review
schedule should be following

PREPARED BY: MS. SONAM SINGH Page 26

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

In each SQA phase, the SQA members provide consultation and review of the project plans,
work product, and procedures regarding compliance to defined organizational policy and
standard procedures.

During Audit, the SQA members should use SQA review checklist

After you walk through the 3 steps of software assurance implementation, you have the result
of Test Management Review & Audit. This is the evidence to show to your stakeholders
about your management quality.

Software quality assurance best practice

Here are some best practices for an effective SQA implementation

 Continuous improvement: All the standard process in SQA must be

improved frequently and made official so that the other can follow. This process
should be certified by popular organization such as ISO, CMMI… etc.
 Documentation: All the QA policies and methods, which are defined by QA team,
should be documented for training and reuse for future projects.
 Experience: Choosing the members who are seasoned SQA auditors is a good way to
ensure the quality of management review
 Tool Usage: Utilizing tool such as the tracking tool, management tool for SQA
process reduces SQA effort and project cost.
 Metrics: Developing and creating metrics to track the software quality in its current
state, as well as to compare the improvement with previous versions, will help
increase the value and maturity of the Testing process
 Responsibility: The SQA process is not the SQA member’s task, but everyone’s task.
Everybody in the team is responsible for quality of product, not just the test lead or
manager.

PREPARED BY: MS. SONAM SINGH Page 27

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

Difference between Inspection and Walkthrough

1. Walkthrough:

Walkthrough is a method of conducting informal group/individual review. In a

walkthrough, author describes and explain work product in a informal meeting to his peers
or supervisor to get feedback. Here, validity of the proposed solution for work product is
checked.

It is cheaper to make changes when design is on the paper rather than at time of conversion.
Walkthrough is a static method of quality assurance. Walkthrough are informal meetings
but with purpose.

2. Inspection:

An inspection is defined as formal, rigorous, in depth group review designed to identify

problems as close to their point of origin as possible. Inspections improve reliability,
availability, and maintainability of software product.
Anything readable that is produced during the software development can be inspected.
Inspections can be combined with structured, systematic testing to provide a powerful tool
for creating defect-free programs.
Inspection activity follows a specified process and participants play well-defined roles.
An inspection team consists of three to eight members who plays roles of moderator,
author, reader, recorder and inspector.
For example, designer can acts as inspector during code inspections while a quality
assurance representative can act as standard enforcer.
Stages in the inspections process:

 Planning: Inspection is planned by moderator.

 Overview meeting: Author describes background of work product.
 Preparation: Each inspector examines work product to identify possible defects.
 Inspection meeting: During this meeting, reader reads through work product, part by
part and inspectors points out the defects for every part.
 Rework: Author makes changes to work product according to action plans from the
inspection meeting.
 Follow-up : Changes made by author are checked to make sure that everything is
correct.

PREPARED BY: MS. SONAM SINGH Page 28

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

DIFFERENCE BETWEEN INSPECTION AND WALKTHROUGH:

S.NO. INSPECTION WALKTHROUGH

1. It is formal. It is informal.

2. Initiated by project team. Initiated by author.

A group of relevant persons Usually team members of the same project take
from different departments participation in the walkthrough. Author himself
3. participate in the inspection. acts walkthrough leader.

Checklist is used to find

4. faults. No checklist is used in the walkthrough.

Inspection processes includes Walkthrough process includes overview, little or

overview, preparation, no preparation, little or no preparation
inspection, and rework and examination (actual walkthrough meeting), and
5. follow up. rework and follow up.

Formalized procedure in each

6. step. No formalized procedure in the steps.

Inspection takes longer time

as list of items in checklist is Shorter time is spent on walkthrough as there is
7. tracked to completion. no formal checklist used to evaluate program.

Planned meeting with the

fixed roles assigned to all the
8. members involved. Unplanned

Reader reads product code.

Everyone inspects it and Author reads product code and his teammate
9. comes up with detects. comes up with the defects or suggestions.

10. Recorder records the defects. Author make a note of defects and suggestions

PREPARED BY: MS. SONAM SINGH Page 29

Downloaded by Rishav Raj (rrishav258@gmail.com)

 lOMoARcPSD|47263019

SHEAT-COLLEGE OF ENGINEERING AND MANAGEMENT, VARANASI

PREPARED BY: MS. SONAM SINGH Page 30

Downloaded by Rishav Raj (rrishav258@gmail.com)