ST Unit 1 Part 2
ST Unit 1 Part 2
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 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.
It consists of checking of
It consists of execution of program and is
documents/files and is performed by
performed by computer.
human.
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
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.
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.
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.
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.
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.
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.
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