0% found this document useful (0 votes)
15 views12 pages

ST Unit 1 Part 2

Notes

Uploaded by

kumarshuklawhy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views12 pages

ST Unit 1 Part 2

Notes

Uploaded by

kumarshuklawhy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Verification Validation

It includes checking documents, It includes testing and validating the


design, codes and programs. actual product.

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

It does not include the execution of


It includes the execution of the code.
the code.

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

It checks whether the software meets the


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

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

The goal of verification is application


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

Quality assurance team does Validation is executed on software code


verification. with the help of testing team.

It comes before validation. It comes after verification.

It consists of checking of
It consists of execution of program and is
documents/files and is performed by
performed by computer.
human.

Verification refers to the set of Validation refers to the set of activities


activities that ensure software that ensure that the software that has
correctly implements the specific been built is traceable to customer
function. requirements.

After a valid and complete Validation begins as soon as project


Verification Validation

specification the verification starts. starts.

Verification is for prevention of errors. Validation is for detection of errors.

Verification is also termed as white Validation can be termed as black box


box testing or static testing as work testing or dynamic testing as work
product goes through reviews. product is executed.

Verification finds about 50 to 60% of Validation finds about 20 to 30% of the


the defects. defects.

Verification is based on the opinion of


Validation is based on the fact and is
reviewer and may change from
often stable.
person to person.

Verification is about process,


Validation is about the product.
standard and guideline.

Software Testing Life Cycle (STLC)

The Software Testing Life Cycle (STLC) is a systematic approach to testing a software
application to ensure that it meets the requirements and is free of defects. It is a process that
follows a series of steps or phases, and each phase has specific objectives and deliverables.
The STLC is used to ensure that the software is of high quality, reliable, and meets the needs
of the end-users.

Characteristics of STLC
 STLC is a fundamental part of the Software Development Life Cycle (SDLC) but STLC
consists of only the testing phases.
 STLC starts as soon as requirements are defined or software requirement document is
shared by stakeholders.
 STLC yields a step-by-step process to ensure quality software.
Phases of STLC
1. Requirement Analysis: Requirement Analysis is the first step of the Software Testing Life
Cycle (STLC). In this phase quality assurance team understands the requirements like what is
to be tested. If anything is missing or not understandable then the quality assurance team
meets with the stakeholders to better understand the detailed knowledge of requirements.

The activities that take place during the Requirement Analysis stage include:
 Reviewing the software requirements document (SRD) and other related documents
 Interviewing stakeholders to gather additional information
 Identifying any ambiguities or inconsistencies in the requirements
 Identifying any missing or incomplete requirements
 Identifying any potential risks or issues that may impact the testing process
Creating a requirement traceability matrix (RTM) to map requirements to test cases
At the end of this stage, the testing team should have a clear understanding of the software
requirements and should have identified any potential issues that may impact the testing
process. This will help to ensure that the testing process is focused on the most important
areas of the software and that the testing team is able to deliver high-quality results.
2. Test Planning: Test Planning is the most efficient phase of the software testing life cycle
where all testing plans are defined. In this phase manager of the testing, team calculates the
estimated effort and cost for the testing work. This phase gets started once the requirement-
gathering phase is completed.
The activities that take place during the Test Planning stage include:
 Identifying the testing objectives and scope
 Developing a test strategy: selecting the testing methods and techniques that will be used
 Identifying the testing environment and resources needed
 Identifying the test cases that will be executed and the test data that will be used
 Estimating the time and cost required for testing
 Identifying the test deliverables and milestones
 Assigning roles and responsibilities to the testing team
 Reviewing and approving the test plan
At the end of this stage, the testing team should have a detailed plan for the testing activities
that will be performed, and a clear understanding of the testing objectives, scope, and
deliverables. This will help to ensure that the testing process is well-organized and that the
testing team is able to deliver high-quality results.
3. Test Case Development: The test case development phase gets started once the test
planning phase is completed. In this phase testing team notes down the detailed test cases.
The testing team also prepares the required test data for the testing. When the test cases are
prepared then they are reviewed by the quality assurance team.
The activities that take place during the Test Case Development stage include:
 Identifying the test cases that will be developed
 Writing test cases that are clear, concise, and easy to understand
 Creating test data and test scenarios that will be used in the test cases
 Identifying the expected results for each test case
 Reviewing and validating the test cases
 Updating the requirement traceability matrix (RTM) to map requirements to test cases
At the end of this stage, the testing team should have a set of comprehensive and accurate
test cases that provide adequate coverage of the software or application. This will help to
ensure that the testing process is thorough and that any potential issues are identified and
addressed before the software is released.
4. Test Environment Setup: Test environment setup is a vital part of the STLC. Basically, the
test environment decides the conditions on which software is tested. This is independent
activity and can be started along with test case development. In this process, the testing team
is not involved. either the developer or the customer creates the testing environment.
5. Test Execution: After the test case development and test environment setup test execution
phase gets started. In this phase testing team starts executing test cases based on prepared
test cases in the earlier step.
The activities that take place during the test execution stage of the Software Testing
Life Cycle (STLC) include:
 Test execution: The test cases and scripts created in the test design stage are run
against the software application to identify any defects or issues.
 Defect logging: Any defects or issues that are found during test execution are logged in a
defect tracking system, along with details such as the severity, priority, and description of
the issue.
 Test data preparation: Test data is prepared and loaded into the system for test
execution
 Test environment setup: The necessary hardware, software, and network configurations
are set up for test execution
 Test execution: The test cases and scripts are run, and the results are collected and
analyzed.
 Test result analysis: The results of the test execution are analyzed to determine the
software’s performance and identify any defects or issues.
 Defect retesting: Any defects that are identified during test execution are retested to
ensure that they have been fixed correctly.
 Test Reporting: Test results are documented and reported to the relevant stakeholders.
It is important to note that test execution is an iterative process and may need to be repeated
multiple times until all identified defects are fixed and the software is deemed fit for release.
6. Test Closure: Test closure is the final stage of the Software Testing Life Cycle (STLC)
where all testing-related activities are completed and documented. The main objective of the
test closure stage is to ensure that all testing-related activities have been completed and that
the software is ready for release.
At the end of the test closure stage, the testing team should have a clear understanding of the
software’s quality and reliability, and any defects or issues that were identified during testing
should have been resolved. The test closure stage also includes documenting the testing
process and any lessons learned so that they can be used to improve future testing processes
Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-
related activities are completed and documented. The main activities that take place during
the test closure stage include:
 Test summary report: A report is created that summarizes the overall testing process,
including the number of test cases executed, the number of defects found, and the overall
pass/fail rate.
 Defect tracking: All defects that were identified during testing are tracked and managed
until they are resolved.
 Test environment clean-up: The test environment is cleaned up, and all test data and
test artifacts are archived.
 Test closure report: A report is created that documents all the testing-related activities
that took place, including the testing objectives, scope, schedule, and resources used.
 Knowledge transfer: Knowledge about the software and testing process is shared with
the rest of the team and any stakeholders who may need to maintain or support the
software in the future.
 Feedback and improvements: Feedback from the testing process is collected and used
to improve future testing processes
It is important to note that test closure is not just about documenting the testing process, but
also about ensuring that all relevant information is shared and any lessons learned are
captured for future reference. The goal of test closure is to ensure that the software is ready
for release and that the testing process has been conducted in an organized and efficient
manner.
Reviewing 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 the
software.
Methods of Verification
Here are some of the common methods that are required for Verification are listed below.
 Peer Reviews
 Walk Through
 Inspections
Peer Reviews
The very easiest method and most 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 of Peer Reviews:
Here are some of the advantages of Peer Reviews that are listed below.
 You can expect some good results without spending any significant resources.
 It is very efficient and significant in its nature.
Disadvantages of Peer Reviews:
Here are some of the disadvantages of Peer Reviews that are discussed below.
 Lead to bad results if the reviewer doesn’t have sufficient knowledge.
Walk-Through
Walk-Throughs are a 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 of Walk-Through
Here are the advantages of Walk-Through that are listed below.
 It may help us to find potential faults.
 It may also be used for sharing documents with others.
Disadvantages of Walk-Through
Here are the disadvantages of Walk-Through that are discussed below.
 The author may hide some critical areas and unnecessarily emphasize some specific
areas of his / her interest.
Inspections
Inspections are the most structured and 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, and 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 from the moderator.
Advantages of Inspections:
Here are the advantages of Inspections that are discussed below.
 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 of Inspections:
Here are the disadvantages of Inspections that are discussed below.
 They take time and require discipline.
 It requires more cost and also needs skilled testers.

Output is
depende
No Not Less-
nt on the
prerequisi Require Expensiv
1 or 2 ability of
te d e
the
reviewer

The only The Find few


presenter report is faults
2 to 7 Knowled
Walkthrou is prepared and not
Author member ge
gh required by the very
s sharing
to be presente expensiv
prepared r e

Expensiv
All The
e and
participan report is
Author 3 to 6 Effective requires
ts are prepared
Inspection and other member but may very
required by the
members s get faults skilled
to be moderat
member
prepared or
s
 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 a software audit?


A software audit is an internal or external review of a software program to check its quality, progress
or adherence to plans, standards and regulations. The process is conducted by either internal teams or
by one or more independent auditors.
Software audits may be conducted for many reasons, including the following:
 to track and report software use, including frequency and who is using the software;
 to verify licensing compliance;
 to monitor for quality assurance (QA);

 to comply with industry standards; and

 to meet legal requirements.

Software development companies usually contract with third-party reviewers and teams to provide
independent verification of a software program's compliance with development plans, industry
standards, best practices and legal practices. Compliance audits may focus on adherence
to IEEE standards or legal regulatory compliance. This kind of audit focus is especially important in
the case of software used in critical infrastructure and key resources.

Instead of focusing on a software's technical quality, a software audit focuses on compliance of


products or processes. They are an important part in evaluating if a software product or process
adheres to regulations, standards and procedures.

Software audits serve a vital purpose to an organization. But they can also disrupt a company's
development and may place a financial strain on a project because of unbudgeted costs. Teams and
management may be required to consult with auditors to ensure the process is complete and accurate.
The involved consultation can take away from time spent on work. Organizations should refrain from
overdoing audits, and executives should understand how, why and when audits are conducted so they
can best prepare for them.

Why are software audits necessary?


Internal audits can help an organization improve its efficiency by reducing the number of inactive or
expired licenses and finding problems before they can become licensing or regulatory issues in a
third-party review. An external, or third-party, review generally focuses on software that is being
used beyond licensed rights and can help identify compliance gaps. These different priorities mean it
is prudent for an organization to conduct an internal review before an external audit.

If an internal audit is done, the auditor the organization selects must be independent and unbiased.
The auditors then determine if there are any violations, such as piracy. For example, the organization
may have bought one software license but installed copies of the software on several devices.
Internally, software audits help organizations gain a reality check on their current state of affairs
surrounding the use of software. The audits can help ensure the software an organization uses is up to
date and is working as intended.

This image shows two types of audits.

Software audits are conducted when an organization believes that it may be in violation of its user
agreements. The organization can start a software audit when licensing compliance needs to be
verified, to monitor QA, to ensure licenses are all current and up to date, and to ensure industry
standards are still being complied with. Software audits also help uncover any unused tools with
current licenses. Removing unused licensed software can help save an organization money. If an
organization experiences a lack of visibility or software process bottlenecks, then a software audit
acts as a health check for the software being audited.

How to conduct a software audit


Software audits take roughly 60 working days to complete, and an IT department could be asked to
undergo up to three audits a year.

A software vendor or software publisher may communicate its intent to begin an audit through a
formal mailed letter. The initiator of the audit may be anyone. This includes a manager, an
organization representative, a customer or a third party. At an early stage, the audit personnel are
chosen, and they decide on follow-up actions.
Software auditor participants include the audited organization, auditor and recorder. The audited
organization works with the auditors to provide all the information the auditors may need to complete
their tasks. The auditor is someone who examines the software products outlined in an audit plan,
documents observations and provides recommended corrective measures. The recorder is a party that
takes note of action items, anomalies and corrective actions. Recorders also document the audit
team's recommendations.
Software audits follow an audit plan created by an audit team. The plan should outline the audit's
objective and include further goals or obligations. Software audits include an audit of
hardware, virtualization and software development inventory, as well as user data. Audited hardware
is any device that is used in the organization or the software being audited. This includes every
important detail surrounding the organization's hardware equipment.

Virtualization inventory under audit should have documented information about virtual environments
and virtual servers that run on physical machines. Virtual machines that can migrate from one
physical host to another should also be examined.

Software deployment inventory is a list of software that runs a device. The software vendor's name,
product name, its edition and version should all be recorded.

User data collected is generally accessed by Active Directory, since it contains information about
remote users and devices.

What the audit focuses on depends on the scope of the audit plan and the reason the audit was
initiated.
What can you expect before, during and after software audits?
Before the audit

Before a software audit begins, the software vendor sends the organization a notice for audit. This
letter should explain the audit and how the organization can help the process move smoothly. For
example, the letter should include details such as what software is being requested for the audit,
along with a time frame for the organization to respond to the audit request.
The organization should build a team of relevant employees to map out a strategy for the audit
process, including roles, responsibilities and timelines. Employees from IT, legal and software
procurement roles should be included in the team.

Team members from legal should review any possibly relevant information, such as the use of any
end-user license agreement.

A role should also be established specifically for corresponding with the auditors. To keep third-party
auditors from disclosing information to a software vendor, a nondisclosure agreement should be
made among the third-party auditor, the organization under audit and the software vendor. The scope
of the audit should be clearly defined, including the areas that are in the audit and the products used.

Software Quality Assurance




Software Quality Assurance (SQA) is simply a way to assure quality in the


software. It is the set of activities which ensure processes, procedures as well as
standards are suitable for the project and implemented correctly.
Software Quality Assurance is a process which works parallel to development of
software. It focuses on improving the process of development of software so that
problems can be prevented before they become a major issue. Software Quality
Assurance is a kind of Umbrella activity that is applied throughout the software
process.
Generally the quality of the software is verified by the third party organization
like international standard organizations .
Software quality assurance focuses on:
 software’s portability
 software’s usability
 software’s reusability
 software’s correctness
 software’s maintainability
 software’s error control
Software Quality Assurance has:
1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism
Major Software Quality Assurance Activities:

1. SQA Management Plan:


Make a plan for how you will carry out the sqa through out the project. Think
about which set of software engineering activities are the best for project. check
level of sqa team skills.

2. Set The Check Points:


SQA team should set checkpoints. Evaluate the performance of the project on the
basis of collected data on different check points.

3. Multi testing Strategy:


Do not depend on a single testing approach. When you have a lot of testing
approaches available use them.

4. Measure Change Impact:


The changes for making the correction of an error sometimes re introduces more
errors keep the measure of impact of change on project. Reset the new change
to change check the compatibility of this fix with whole project.

5. Manage Good Relations:


In the working environment managing good relations with other teams involved
in the project development is mandatory. Bad relation of sqa team with
programmers team will impact directly and badly on project. Don’t play politics.

Benefits of Software Quality Assurance (SQA):

1. SQA produces high quality software.


2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for a long time.
5. High quality commercial software increase market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.
8. It cuts maintenance costs. Get the release right the first time, and your company
can forget about it and move on to the next big thing. Release a product with
chronic issues, and your business bogs down in a costly, time-consuming, never-
ending cycle of repairs.

Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include
adding more resources, employing more workers to help maintain quality and so
much more.
v

You might also like