Unit -1 Software Testing Intro

Software Testing Define:

Software testing is the process of evaluating and verifying that a software
application or system meets specified requirements and functions correctly. It
involves executing software/system components using manual or automated
tools to evaluate one or more properties of interest.

Role of Software Tester:

Software testers ensure software quality by identifying bugs, verifying

functionality, and assessing usability, ultimately delivering a polished and
error-free product to end-users
1. Test Manager: Oversees the testing process, manages the testing team,
and ensures that testing is aligned with project goals.
2. Test Lead: Coordinates testing activities, manages test schedules, and
communicates with stakeholders.
3. Test Engineer/Tester: Designs test cases, executes tests, and reports
defects.
4. Automation Engineer: Develops automated test scripts and frameworks
to improve testing efficiency.
5. Quality Assurance (QA) Analyst: Ensures that the software meets
quality standards and adheres to best practices.

Software Tester Role

A Software tester (software test engineer) should be capable of designing test
suites and should have the ability to understand usability issues. Such a tester is
expected to have sound knowledge of software test design and test execution
methodologies. It is very important for a software tester to have great
communication skills so that he can interact with the development team
efficiently. The roles and responsibilities for a usability software tester are as
follows:
1. A Software Tester is responsible for designing testing scenarios for
usability testing.
 2. He is responsible for conducting the testing, thereafter analyze the results
and then submit his observations to the development team.
3. He may have to interact with the clients to better understand the product
requirements or in case the design requires any kind of modifications.
4. Software Testers are often responsible for creating test-product
documentation and also has to participate in testing related walk through.

Goals of Testing
The main goal of software testing is to find bugs as early as possible and fix
bugs and make sure that the software is bug-free.
Important Goals of Software Testing:
 Detecting bugs as soon as feasible in any situation.
 Avoiding errors in a project’s and product’s final versions.
 Inspect to see whether the customer requirements criterion has been
satisfied.
 Last but not least, the primary purpose of testing is to gauge the project
and product level of quality.
 Verification: Ensure the software meets the specified requirements.
 Validation: Confirm that the software fulfills its intended purpose.
 Defect Identification: Find and report defects before the software is
released.
 Quality Assurance: Improve the overall quality of the software product.
 Risk Mitigation: Identify potential risks and issues early in the
development process.

The goals of software testing may be classified into three major categories
as follows:
1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals
  Immediate Goals:
 Bug Discovery: This is the immediate goal of software testing to find
errors at any stage of software development. The number of bugs is
discovered in the early stage of testing. The primary purpose of software
testing is to detect flaws at any step of the development process. The
higher the number of issues detected at an early stage, the higher the
software testing success rate.

 Bug Prevention: This is the immediate action of bug discovery, that

occurs as a result of bug discovery. Everyone in the software
development team learns how to code from the behavior and analysis of
issues detected, ensuring that bugs are not duplicated in subsequent
phases or future projects.
2. Long-Term Goals: These objectives have an impact on product quality in the
long run after one cycle of the SDLC is completed. Some of these are covered
in detail below:
 Quality: This goal enhances the quality of the software product. Because
software is also a product, the user’s priority is its quality. Superior
quality is ensured by thorough testing. Correctness, integrity, efficiency,
and reliability are all aspects that influence quality. To attain quality, you
must achieve all of the above-mentioned quality characteristics.
 Customer Satisfaction: This goal verifies the customer’s satisfaction
with a developed software product. The primary purpose of software
testing, from the user’s standpoint, is customer satisfaction. Testing
should be extensive and thorough if we want the client and customer to
be happy with the software product.
 Reliability: It is a matter of confidence that the software will not fail. In
short, reliability means gaining the confidence of the customers by
providing them with a quality product.
 Risk Management: Risk is the probability of occurrence of uncertain
events in the organization and the potential loss that could result in
negative consequences. Risk management must be done to reduce the
failure of the product and to manage risk in different situations.
3. Post-Implemented Goals: After the product is released, these objectives
become critical. Some of these are covered in detail below:
  Reduce Maintenance Cost: Post-released errors are costlier to fix and
difficult to identify. Because effective software does not wear out, the
maintenance cost of any software product is not the same as the physical
cost. The failure of a software product due to faults is the only expense of
maintenance. Because they are difficult to discover, post-release mistakes
always cost more to rectify. As a result, if testing is done thoroughly and
effectively, the risk of failure is lowered, and maintenance costs are
reduced as a result.
 Improved Software Testing Process: These goals improve the testing
process for future use or software projects. These goals are known as
post-implementation goals. A project’s testing procedure may not be
completely successful, and there may be room for improvement. As a
result, the bug history and post-implementation results can be evaluated
to identify stumbling blocks in the current testing process that can be
avoided in future projects.

Principles of Testing
1. Testing Shows the Presence of Defects: Testing can show that defects
are present, but cannot prove that there are no defects.
2. Exhaustive Testing is Impossible: It is not feasible to test all possible
inputs and scenarios.
3. Early Testing: Testing should start as early as possible in the software
development lifecycle.
4. Defect Clustering: A small number of modules usually contain most of
the defects.
5. Pesticide Paradox: Running the same set of tests will not find new
defects; tests must be regularly reviewed and revised.
6. Testing is Context-Dependent: The testing approach should be tailored
to the specific context of the project.

Phases of Software Testing (STLC))

The Software Testing Life Cycle (STLC) typically involves six key
phases: Requirement Analysis, Test Planning, Test Case Design, Test
Environment Setup, Test Execution, and Test Closure.
DEFINE:
The Software Testing Life Cycle (STLC) typically involves six key
phases: Requirement Analysis, Test Planning, Test Case Design, Test
Environment Setup, Test Execution, and Test Closure.
Phases of Software Testing
1. Requirement Analysis: Understanding and analyzing the requirements to
create a test plan.
2. Test Planning: Defining the scope, approach, resources, and schedule for
testing activities.
3. Test Design: Creating detailed test cases and test scripts based on
requirements.
4. Test Execution: Running the test cases and documenting the results.
5. Test Closure: Evaluating cycle completion criteria based on test
coverage, quality, cost, time, critical business objectives, etc.

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:

1.Reviewing the software requirements document (SRD) and other related

documents
2.Interviewing stakeholders to gather additional information
3.Identifying any ambiguities or inconsistencies in the requirements
4.Identifying any missing or incomplete requirements
5.Identifying any potential risks or issues that may impact the testing process

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

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

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.

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

Key Terms
 Failure: The inability of a system or component to perform its required
functions within specified performance requirements.
 Bug: A flaw or error in the software that causes it to produce incorrect or
unexpected results.
 Fault: A defect in the software that can cause a failure when executed.
 Defect: A deviation from the expected behavior or requirement; often
used interchangeably with "bug."
 Error: A human mistake that leads to a defect in the software.

V- Testing (V-Modelling) Verification and Validation Models

V Model
Also known as the verification and validation model, the V model guides where
testing needs to begin as early as possible in the SDLC life cycle. Testing is not
only an execution-based activity. It also involves various activities that must be
covered before the end of the coding phase. V Model corresponds to both
testing activities and development activities in parallel.
Verification Phases of the V Model
1. User Requirements / Requirement Analysis:
Remember the example given at the beginning about house construction; before
starting the construction work, an individual needs to gather specific details
such as financial options, appropriate location, right contractor for constructing
a house, construction and building materials, availability of water and
electricity, etc.
This document will capture both the product’s functional and non-functional
requirements and the requirement’s priority. The Requirements document is
signed-off formally by the stakeholders, which becomes the basis for all further
activity. Based on this, the user acceptance criteria test cases are developed. The
customers/stockholders, Business Analysts, and Project Managers are the key
members of the requirement analysis phase.
2. System Requirements:
Once we have collected the clear and detailed product requirements, the next
phase i.e., system requirements begins in earnest. Taking the Requirements
Specification inputs in this phase next Functional Requirements Specification
or System Requirement Specification begins.
Business Analysts and Developer Leads take the user requirements and turn
those into different features that the product should have at the end. During this
system requirement phase, teams will revisit and finalize the complete hardware
requirements, resources, and communication setup for the product under
development.
The system test plan is developed based on the system requirements phase.
These requirements are segregated into different features, and features are
grouped. Each feature is prioritized in this phase.
i. Global Design / High-Level Design:
The global design phase is also referred to as High-Level Design(HLD) phase.
Each feature is again broken down into different modules in this phase. The
Architects, Developers, Database designers, and other required members take
the elements segregated in the system requirements phase as input and develop
an overall high-level technical design.
This high-level design document has all the required technical details, such as
hardware, software, Programming language to be used, Database design,
applications touch points, etc., clearly defined. They built the HLD so that each
module is associated with a specific function. This information allows
integration tests to be designed and documented during this stage.
ii. Detailed Design / Low-Level Design:
In the next stage, the Technical Specification i.e. HLD, is taken as the input.
Individual developers or the team use it to develop a detailed design of their
modules and their interface with other modules. Details about what type of data
objects, how the data is to be collected, how the data can be integrated, business
rules to be applied, and data storage are all documented in the detailed design
Specification. This intricate design specification/document is also referred to as
Low-Level Design. In this phase, simultaneously, unit tests can be designed on
the internal low-level design of each module.
3. Implementation Phase / Coding Phase:
Programmers or Developers take the Low-Level Design Specification and start
the implementation process. The coding of each module designed in the detailed
design phase is taken up in the coding/implementation phase.
The coding is performed based on the coding guidelines and standards of the
specific language that is being used. The developed code goes through
numerous code reviews-feedbacks, and implementation and is optimized for its
best performance before the final build is checked into the source repository.

Validation Phases of the V Model

As discussed earlier, every development activity will have a corresponding
testing activity. And the test phase for a given level begins during the related
software development activity. Now let’s discuss different validation phases in
detail.
1. Component Test Execution/Unit Testing:
The component test execution phase is also referred to as component testing,
unit testing, or module and program testing executed during the detailed design
phases. This validation testing phase searches for defects in and verifies the
functioning of software’s different modules, programs, objects, classes, etc.,
separately testable.
Most often, component testing stubs and drivers are used to replace the missing
software and simulate the interface between the software components to achieve
the testing in isolation from the rest of the system. Component testing may
include different testing characteristics such as resource behavior, memory
leaks, code coverage, robustness testing, etc. The detected defects are typically
fixed as soon as they are found without formally recording the incidents.
2. Integration Test Execution/Integration Testing:
Primarily integration testing is carried out based on global or high-level design.
The development team comes up with the technical specification and a
corresponding integration for a test plan. The details are noted of how the
modules or programs will be integrated, data that will be passed through the
interfaces, and additional integration testing approaches such as Big Bang,
Top-Down, Bottom-up, or functional incremental, etc.
Integration testing is performed to expose the defects in the interfaces between
components, interactions of different parts or systems such as an Operating
System and File system, etc. Here the main focus is on how other modules or
components’ interaction works, not the functionality of the individual
component.
3. System Test Execution/ System Testing:
System testing tests an integrated system/whole system or product to verify that
it meets specified requirements. The main goal is to validate that the delivery
system meets the design specifications. The testing team performs complete or
thorough testing in this phase, including system, functional, and non-functional
test cases. Its purpose is to find as many defects as possible and report them.
System tests are generally executed in different development test
environments. However, the test environments should correspond to the
production environment as much as possible to minimize the risk of
environment-specific bugs.
4. Acceptance Test Execution/User Acceptance Testing:
Acceptance test execution is associated with the requirements analysis phase.
Testers review the Requirement specification and check whether the
requirement has enough details to be tested, there is no ambiguity if non-
functional requirements are mentioned as well, whether the requirements have
been prioritized, and if product risks have been captured. This Test plan is
designed focused on conducting tests concerning the user needs, requirements,
and business processes.
This determines whether or not the software product/system satisfies the
acceptance criteria and enables the users, customers, or other authorized entities
to determine whether or not to accept the system.
When to use the V Model in Software Testing?
It is advisable to use the V Model on small-to-medium-sized software projects
where the requirements are clear without any ambiguity. For projects where
acceptance criteria are proper, V Model is the preferable choice. The V Model is
useful when ample technical resources are available with technical expertise,
and tech stacks and tools are not dynamic.
Principles of V Model
The principles of the V model are based on Verification and Validation, which
you can find in the above sections. Here, we discuss the clear principles of the V
model in Software testing:
 From Large to Small: The first principle states that the testing needs to
be done in a sequential process. It must start with identifying the
requirements, creating a high-level, concise design, and detailing the
design phases of the project.
 Data and Process Integrity: This principle places emphasis on working
with data and processes together to implement a successful project
design.
 Scalability: The V model undertakes the ability to accommodate any IT
project despite the size, complexity, or duration.
 Cross Reference: This principle establishes a direct correlation between
requirements and corresponding testing activity.
 Clear Documentation: Like in every other project, this principle shows
how documentation is a requirement that needs to be done by both the
developers and the support team.
What are the Advantages of the V Model?
1. As we browse through different phases of the V Model of testing, we can
conclude that this is a highly-disciplined model, and phases go one-by-one.
2. Each phase has specific deliverables and a review process, so it is easier to
understand, use and manage.
3. Since the testing phases start from the beginning, ambiguities, defects, etc.,
are identified from the beginning; fixing those becomes more effortless and a
cost-effective model.
4. Works well with smaller or medium size software projects.
What are the Disadvantages of the V Model?
1. In Today’s dynamic world, requirements changes may happen very often,
whereas the V-model is a very disciplined and non-flexible model; hence, it is
not suitable for projects where requirements are at a moderate to high risk of
changing.
2. This model is not preferable when projects are larger or complex or have
uncertain requirements and high risk.
3. Working software is produced late in the life cycle.