Introduction to Software Testing

Software Testing is the process of evaluating and verifying that a software application or system
meets the specified requirements and is free of defects.
Importance of Software Testing:
●​ Ensures the quality and reliability of software.

●​ Helps in finding bugs before release.

●​ Reduces maintenance costs and customer dissatisfaction.

●​ Increases confidence in software performance.

Goals of Software Testing

Software testing serves several primary and secondary goals:
Primary Goals:
1.​ Verification and Validation:
o​ Ensure the software does what it's supposed to (validation).
o​ Ensure the software was built correctly (verification).
2.​ Bug Detection:
o​ Find errors, gaps, or missing requirements.
3.​ Quality Assurance:
o​ Improve overall quality by identifying defects early.
4.​ Compliance:
o​ Ensure the software meets industry or regulatory standards.
Secondary Goals:
1.​ Risk Reduction:
o​ Minimize the risk of failure in production.
2.​ Performance Verification:
o​ Ensure software meets performance criteria.
3.​ Documentation Support:
o​ Provide a record of test cases, defects, and quality.

3. Software Testing Definitions

Here are some standard definitions:
Term Definition

Software A process used to identify the correctness, completeness, and quality of developed
Testing software.

A flaw in a software component that causes it to produce incorrect or unexpected

Bug/Defect
results.

A set of actions executed to verify a particular feature or functionality of the

Test Case
software.

A document describing the scope, approach, resources, and schedule of testing

Test Plan
activities.

Validation Ensures the software meets the business needs and requirements.

Verification Ensures the product is built according to the design and technical specifications.

Effective Software Testing vs Exhaustive Software Testing

Aspect Effective Software Testing Exhaustive Software Testing
Testing that focuses on key Testing all possible inputs,
Definition functionalities and high-risk areas paths, and combinations in the
to find defects efficiently. software.
Ensure 100% test coverage by
Maximize bug detection with
Goal checking every possible
minimal effort and time.
scenario.
Impractical and nearly
Practical and achievable in
Feasibility impossible, especially for
real-world projects.
complex systems.
Extremely costly and
Time & Optimized for time and cost.
time-consuming. Requires
Cost Prioritizes testing efforts.
massive resources.
Based on risk analysis, No prioritization; all test cases
Focus requirement priorities, and are considered equally
common usage patterns. important.
Test High coverage, but selective and Complete (100%) coverage of
Coverage strategic. all test cases and scenarios.
Aspect Effective Software Testing Exhaustive Software Testing
Testing login with valid/invalid Testing login with every
Example credentials, but not every possible possible combination of
character combo. characters, symbols, and inputs.
Only used for very small and
When to Used in almost all real-world
critical systems (e.g.,
Use software testing scenarios.
pacemakers).
Might miss some edge cases if Not scalable; increases test time
Drawback
risk analysis is incorrect. and costs exponentially.

Effective software testing and exhaustive software testing represent two

different approaches to verifying software quality. Effective software testing
focuses on strategically identifying and testing the most important and high-risk
parts of the software, using techniques like risk-based testing, equivalence
partitioning, and boundary value analysis. It aims to maximize defect detection
with limited time and resources, ensuring that the most critical functionalities
are thoroughly tested without attempting to cover every possible scenario. This
approach is practical, cost-effective, and widely used in real-world software
development.
On the other hand, exhaustive software testing refers to the theoretical idea of
testing every possible input, condition, and path in a software application. While
this might seem ideal in terms of completeness, it is practically impossible for
most real-world systems due to the vast number of possible combinations.
Exhaustive testing is extremely time-consuming, expensive, and only feasible
for very small or safety-critical systems, such as those used in medical devices
or aerospace applications.
In summary, while exhaustive testing guarantees 100% coverage, it is not
scalable. Therefore, effective testing is the preferred and realistic approach in
modern software engineering, ensuring a balance between quality, cost, and
efficiency.
Software Testing Life Cycle (STLC)
STLC is a systematic process followed during software testing to ensure
software quality and meet client requirements. It consists of a series of
well-defined phases, each with specific activities and deliverables.

Phases of STLC
1. Requirement Analysis
Goal: Understand what needs to be tested.
Activities:
●​ Analyze functional and non-functional requirements.
●​ Identify testable and non-testable requirements.
●​ Involve QA team in requirement walkthroughs.
●​ Identify types of testing required (functional, performance, etc.).
●​ Identify test environment needs.
Deliverables:
●​ Requirement Traceability Matrix (RTM)
●​ Automation feasibility report (if applicable)
●​ List of testable requirements

2. Test Planning
Goal: Define the strategy and scope of testing.
Activities:
●​ Create a test strategy or test plan document.
●​ Estimate effort, time, and resources.
●​ Assign roles and responsibilities.
●​ Define tools (test management, automation, etc.).
●​ Identify risks and mitigation plans.
Deliverables:
 ●​ Test Plan / Strategy Document
●​ Effort and cost estimation
●​ Resource planning document

3. Test Case Design / Development

Goal: Create test cases and prepare test data.
Activities:
●​ Write detailed test cases, including positive and negative scenarios.
●​ Create test scripts for automation (if applicable).
●​ Develop or identify test data.
●​ Review test cases for completeness and correctness.
●​ Map test cases to requirements in RTM.
Deliverables:
●​ Test Cases / Test Scripts
●​ Test Data
●​ Updated RTM

4. Test Environment Setup

Goal: Prepare the environment where testing will be executed.
Activities:
●​ Set up hardware and software as per requirements.
●​ Configure necessary tools and test environments.
●​ Validate that the environment is stable and ready.
●​ Coordinate with DevOps or infrastructure teams.
Deliverables:
●​ Test environment setup confirmation
●​ Smoke test results (to validate the environment)
5. Test Execution
Goal: Execute test cases and record results.
Activities:
●​ Execute manual or automated test cases.
●​ Log defects/bugs in the defect tracking tool.
●​ Retest and regression test after bug fixes.
●​ Track test progress and update test cases if needed.
Deliverables:
●​ Test execution reports
●​ Defect reports
●​ Updated test cases and status

6. Test Closure
Goal: Evaluate testing outcomes and formally close testing.
Activities:
●​ Assess test completion criteria (e.g., % passed, defect density).
●​ Ensure all test cases are executed or deferred logically.
●​ Conduct test summary report meeting with stakeholders.
●​ Archive test artifacts for future reference.
●​ Capture lessons learned and best practices.
Deliverables:
●​ Test Summary Report
●​ Defect Analysis Report
●​ Final RTM
●​ Lessons Learned Document
Points about STLC
●​ STLC is iterative: Defects found during execution may require going
back to earlier phases.
●​ STLC is not same as SDLC: STLC is specific to testing, whereas SDLC
covers the entire software development process.
●​ Each phase has entry and exit criteria.

Visual Summary of STLC

[ Requirement Analysis ]
↓
[ Test Planning ]
↓
[ Test Case Design ]
↓
[ Test Environment Setup ]
↓
[ Test Execution ]
↓
[ Test Closure ]

Verification of High-Level Design (HLD)

High-Level Design
●​ High-Level Design (HLD), also known as architectural design, defines
the overall system architecture.
●​ It outlines modules, components, their interactions, and data flow.
●​ It focuses on what the system does and how the main parts work together.
Verification of HLD
Verification of HLD ensures that the design:
 ●​ Satisfies the functional and non-functional requirements.
●​ Is logically correct and complete.
●​ Meets performance, security, and scalability standards.
●​ Aligns with architecture best practices.
Activities:
●​ Review architecture diagrams and design documents.
●​ Ensure all major components are defined (e.g., databases, APIs, services).
●​ Validate that data flow and communication between modules are properly
designed.
●​ Cross-check design against requirements in the Requirement Traceability
Matrix (RTM).
Deliverables:
●​ Design Review Checklist
●​ Reviewed and Approved HLD Document
●​ HLD Verification Report

Verification of Low-Level Design (LLD)

Low-Level Design
●​ Low-Level Design (LLD) focuses on the detailed design of each
component or module.
●​ It defines internal logic, algorithms, database schema, input/output
formats, and class diagrams.
●​ It answers the how of implementation at the module or function level.
Verification of LLD
Verification of LLD ensures that:
●​ The detailed design is accurate, consistent, and aligns with the HLD.
●​ It is feasible for development.
●​ It covers all logical flows, conditions, loops, and exception handling.
 ●​ The design adheres to coding standards and modularity principles.
Activities:
●​ Code-level walkthroughs of design.
●​ Review pseudocode, flowcharts, and class/method specifications.
●​ Ensure all edge cases and logic conditions are handled.
●​ Confirm that LLD maps correctly to HLD components.
Deliverables:
●​ Reviewed and Approved LLD Document
●​ Class/Function Design Specifications
●​ LLD Verification Report

Summary Table
Aspect High-Level Design (HLD) Low-Level Design (LLD)
Focus System architecture Module-level logic
Defines system structure and Defines internal logic of
Purpose
interactions components
Ensure system meets functional Ensure module-level
Verification
and non-functional correctness, completeness, and
Goal
requirements feasibility
Pseudocode, logic diagrams,
Output Architecture diagrams, data
database schema, class
Verified flow, component specs
diagrams
Performed
Architects, Senior Developers Developers, Technical Leads
By

Model for Software Testing

A Model for Software Testing is a structured framework that defines how
testing activities are carried out throughout the software development life cycle
(SDLC). It helps ensure that testing is organized, systematic, and efficient,
aligning closely with development phases.
Software Testing Models define when and how testing should be conducted.
They help in planning, executing, and managing testing activities efficiently.
commonly used models for software testing:

1. Waterfall Model
●​ Testing is a separate phase that comes after development.
●​ Follows a linear and sequential process:​
Requirement → Design → Development → Testing → Deployment
Pros: Simple, easy to manage​
Cons: Late bug detection, not suitable for changing requirements

2. V-Model (Verification and Validation Model)

●​ Extension of the waterfall model where testing activities are planned in
parallel with development.
●​ Every development stage has a corresponding testing stage.
Development Phase Testing Phase
Requirements Acceptance Testing
System Design System Testing
Architecture Design Integration Testing
Module Design Unit Testing
Pros: Early detection of defects​
Cons: Rigid, not flexible to changes

3. Agile Testing Model

●​ Testing is integrated into every iteration or sprint.
●​ Involves continuous testing, frequent feedback, and collaboration.
Pros: Fast feedback, adapts to changes​
Cons: Requires skilled team and frequent updates

4. Spiral Model (Risk-Based Testing)

●​ Combines development with risk analysis and testing in iterative loops.
●​ Testing is done at every cycle, focusing on high-risk areas first.
Pros: Suitable for large and high-risk projects​
Cons: Expensive, complex management

5. Incremental Model
●​ Development and testing are done in small modules.
●​ Each module is tested individually and then integrated and tested.
Pros: Early bug detection and integration testing​
Cons: Requires proper planning for module integration

Purpose of Using a Testing Model

●​ Ensures systematic testing
●​ Improves test planning and management
●​ Enhances test coverage and defect detection
●​ Aligns testing with the development process

Waterfall Model
Definition
One of the earliest software process models — proposed by Winston Royce in 1970 and
widely described by Pressman.
●​ Linear-sequential model: progress flows downwards through phases.
●​ Each phase must be completed before the next begins.

Phases
1.​ Requirements Analysis – Gather and document requirements.
 2.​ System Design – Create overall system architecture and detailed design.
3.​ Implementation (Coding) – Translate design into executable code.
4.​ Integration & Testing – Combine modules and verify correctness.
5.​ Deployment – Deliver product to users.
6.​ Maintenance – Correct defects, adapt to changes.

Advantages
●​ Simple and easy to understand.
●​ Well-suited for projects with clear, stable requirements.
●​ Good documentation at each phase.
Disadvantages
●​ Inflexible to changes.
●​ Late testing (errors found late).
●​ Not suitable for complex, evolving projects.

2. V-Model (Verification and Validation Model)

Definition
●​ An extension of the Waterfall model.
●​ Emphasizes testing activities alongside each development phase.
●​ Shaped like the letter “V” — left side is development, right side is testing.
The V-Model, also known as the Verification and Validation Model, is a software
development life cycle (SDLC) paradigm that emphasizes early and frequent testing
throughout the development process. As described by Pressman and other sources, it is an
extension of the Waterfall Model, addressing some of its limitations by integrating testing
activities with each corresponding development phase.
Key characteristics of the V-Model:
●​ V-Shape Structure:
The model forms a "V" shape, with the left side representing the "Verification" phases
(development activities) and the right side representing the "Validation" phases (testing
activities). The lowest point of the "V" signifies the coding phase.
●​ Verification (Left Side):
This side focuses on ensuring that the product is built correctly according to specifications. It
includes phases like:
●​ Requirements analysis
●​ System design
●​ Architectural design
●​ Module design
●​ Validation (Right Side):
This side focuses on ensuring that the correct product is built to meet user needs and
expectations. It includes corresponding testing phases for each development stage:
●​ Unit testing (for module design)
●​ Integration testing (for architectural design)
●​ System testing (for system design)
●​ Acceptance testing (for requirements analysis)
●​ Concurrent Testing and Development:
Unlike the sequential nature of the Waterfall Model, the V-Model emphasizes the planning
and execution of testing activities in parallel with the development phases. This allows for
early detection of defects, reducing the cost and effort of rework in later stages.
●​ Emphasis on Documentation:
The V-Model requires thorough documentation at each stage, which serves as a basis for both
development and testing activities.
Benefits of the V-Model:
●​ Improved quality due to early defect detection.
 ●​ Reduced risks by addressing issues proactively.
●​ Clearer understanding of requirements and design through structured documentation.
●​ Enhanced traceability between development and testing activities.
Limitations of the V-Model:
●​ Less flexible for projects with evolving or unclear requirements.
●​ Requires complete requirements definition upfront.
●​ May be resource-intensive due to extensive documentation and testing.

Phases
Left Side (Development)
1.​ Requirements Analysis → Acceptance Testing
2.​ System Design → System Testing
3.​ Architectural Design → Integration Testing
4.​ Module Design → Unit Testing
5.​ Coding
Right Side (Testing)
●​ Each test phase corresponds to a development phase.
●​ Early planning of tests ensures verification at each stage.

Advantages
●​ Strong focus on verification and validation.
●​ Detects defects early.
●​ Clear mapping between development and testing.
Disadvantages
●​ Similar to Waterfall — rigid and not ideal for changing requirements.

3. Incremental Process Model

Definition
●​ Combines linear and iterative approaches.
●​ Software is developed and delivered in increments (small functional releases).
●​ Each increment adds new functionality until the full system is complete.
Process
1.​ Initial Increment – Basic core functionality.
2.​ Subsequent Increments – Add new features.
3.​ Final Increment – Fully functional product.
An Incremental Process Model diagram, as described in texts by Roger S.
Pressman, illustrates the software development lifecycle as a series of iterations or
"increments". Each increment represents a small, complete cycle of software development
(requirements, design, implementation, testing) that adds new functionality to the previously
delivered version, resulting in a working system early on and evolving to a full system over
time.
Key Characteristics of the Incremental Model:
●​ Modular Development: The software is divided into separate modules, each
designed and implemented in an iterative fashion.
●​ Phased Approach: Each module or increment goes through the complete software
development lifecycle, including requirements, design, implementation, and testing.
●​ Early Working Software: A core feature of the model is delivering working software
early in the development cycle, which allows for customer feedback.
●​ Cumulative Functionality: Each subsequent increment adds functionality to the
system, gradually building up to the complete product.
●​ Flexibility and Adaptability: The model is flexible, allowing for changing
requirements and easier management of risks, as well as providing a more
cost-effective approach by spreading development budgets across stages.
How the Diagram Depicts the Process:
1.​ Initial Increment: The process starts with an initial increment that implements a few
basic features of the system.
2.​ Sequential Cycles: The subsequent increments are developed, each building upon the
previous one.
3.​ Core Cycle: Within each increment, there's a mini-waterfall or iterative cycle of
analysis, design, implementation, and testing.
4.​ Growing System: The "system" grows with each increment, with new features added
to the existing software.
5.​ Customer Feedback: The customer can provide feedback on each increment as it's
delivered, leading to adjustments in future increments.
6.​ Final System: This process continues until all planned features are implemented and
the final, complete system is achieved.

Advantages
●​ Delivers a working product early.
●​ Easier to manage risks.
●​ Users get value earlier.
●​ Supports partial deployment.
Disadvantages
●​ Requires good planning for integration.
●​ May need rework for earlier increments if changes occur.

Evolutionary Models
As per Roger Pressman, evolutionary software process models like the Prototyping
Model and the Spiral Model are characterized by their iterative nature, allowing for the
delivery of increasingly complete software versions. The Prototyping Model focuses on
developing user-visible prototypes to clarify requirements, while the Spiral Model combines
iteration with systematic risk analysis and controlled development phases.
Here's a breakdown of these models as described by Pressman:
Evolutionary Models in General
●​ Iterative and Incremental: These models deliver software in smaller, manageable
increments over time, allowing for continuous feedback and refinement.
 ●​ Increased Completeness: Each iteration results in a more complete version of the
software.
●​ Flexibility and Adaptability: They are well-suited for projects where requirements
may not be fully understood upfront or are expected to change during development.

Evolutionary Model
Prototyping Model
●​ User Feedback: The primary mechanism for this model is the creation of a
"mock-up" or prototype that serves to identify and refine user requirements.
●​ User Involvement: Users get to experience the system early, which helps to align
expectations and gather feedback.
●​ Potential Issues: Prototypes can sometimes lead to users having unrealistic
expectations for early delivery or may neglect important quality and maintenance
issues.
Spiral Model
●​ Combines Strengths: This model merges the iterative nature of prototyping with the
systematic approach and control of the Waterfall Model.
●​ Risk Analysis: A key aspect of the Spiral Model is the systematic analysis of project
risks in each iteration.
●​ Phased Approach: It proceeds through several loops, with each loop encompassing
planning, risk analysis, engineering (development), and evaluation.
Concurrent Model
the Concurrent Model (or Concurrent Development Model) is a software development
approach where development activities are performed in parallel, rather than sequentially**,
to accelerate delivery and improve outcomes. Unlike the linear Waterfall Model, this model
allows for simultaneous progress on different phases, incorporating events that trigger state
transitions (e.g., an issue in analysis causing a transition to awaiting changes). It's particularly
effective for large, complex projects or those with a client/server architecture.
Key Characteristics
●​ Parallel Execution: Multiple activities from different development phases occur at
the same time.
●​ Event-Driven States: The model uses state transitions triggered by specific events to
manage progress, such as an error in the analysis phase causing a state change.
●​ Flexibility: It offers greater adaptability and can integrate other development models
like Waterfall or Spiral to manage specific tasks within the overall concurrent
framework.
How it Works
 1.​ Initial Planning: The software development process is broken down into activities,
and often a more established model like Spiral or Waterfall might be used for initial
planning or specific sub-projects.
2.​ Concurrent Execution: Activities in different phases (e.g., design and component
realization) run simultaneously.
3.​ Event-Driven Management: As development progresses, events occur (e.g., design
inconsistencies, new requirements) that trigger changes in the state of activities. For
instance, a "design inconsistency" event might move the design activity into an
"awaiting changes" state.
4.​ Iteration and Refinement: The model allows for early feedback and adjustments,
leading to faster iteration cycles and improved product quality.
Benefits
●​ Faster Delivery: By overlapping activities, the overall development time is reduced.
●​ Improved Quality: Early identification and resolution of issues become more
feasible.
●​ Enhanced Flexibility: The model is more adaptable to changing requirements
compared to purely sequential models.
Applications
●​ Client/Server Architectures: It's well-suited for client/server systems, where
components can be designed and realized concurrently.
●​ Large-Scale Projects: Its ability to manage parallel activities makes it effective for
complex and large projects.

1. Agility Principles
Pressman outlines 12 core principles aligned with the Agile Customer satisfaction via early
and continuous delivery
1.​ Welcoming changing requirements, even late in development
2.​ Deliver working software frequently (weeks or months, ideally weeks)
3.​ Business–developer collaboration daily
4.​ Motivated individuals: empower and trust them
5.​ Face-to-face communication as the most effective means
6.​ Working software as the primary measure of progress
7.​ Sustainable pace for sponsors, users, and developers
 8.​ Continuous attention to technical excellence and design
9.​ Simplicity: maximize the work not done
10.​Emergent solutions from self-organizing teams
11.​Regular reflection (retrospectives) and adaptation

2. Extreme Programming (XP) –

🔄 Framework Activities
XP consists of four key activities: Planning, Design, Coding, and Testing
Planning
●​ Development begins with user stories captured on cards.
●​ Team estimates and assigns cost/value; groups potential releases.
●​ After first increment, project velocity guides future planning Design
●​ Follows KIS (Keep It Simple) principle.
●​ Uses CRC cards, spike prototypes, and refactoring to improve design iteratively

Coding
●​ Test-first development via automated unit tests.
●​ Pair programming ensures real-time QA and collaboration
●​ Continuous integration of work multiple times per day
Testing
●​ Daily runs of unit tests; acceptance tests defined and executed by customer based on
user stories
Values & Principles
XP is grounded in five values: Communication, Simplicity, Feedback, Courage, and
Respect ​
These support rapid feedback, collective ownership, and incremental design.
3. Scrum – Organizational Agile Framework
Structure
●​ Roles: Product Owner, Scrum Master, Development Team
●​ Artifacts: Product Backlog, Sprint Backlog, Product Increment
●​ Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
Workflow
●​ Iterative sprints of 1–4 weeks
●​ Daily stand-ups (max 15 min) for status sync
●​ Review (stakeholder demo) + Retrospective for improving process
●​ Delivers potentially shippable software each sprint

4. Kanban Model – Pressman-Inspired

Drawing from the six core practices Pressman describes and from authoritative sources
Core Practices
 1.​ Visualize workflow via a Kanban board (To Do → Doing → Done)
2.​ Limit Work-In-Progress (WIP) to improve focus and throughput
3.​ Manage flow: detect and reduce bottlenecks
4.​ Explicit policies: define “done” criteria and decision rules
5.​ Continuous improvement: implement data-driven feedback loops
6.​ Collaborative change: involve the team in process updates
Meetings
●​ Daily stand-up: walk-the-board, identify missing cards, and unblock work
●​ Weekly retrospective: review metrics, propose and implement process improvements
The diagram (image 8) shows swimlanes and WIP limits in each column—this depicts how
Kanban visualizes flow from backlog to delivery in a pull-based system

▶️ Diagram Gallery
●​ Image 1 (top-left): XP lifecycle showing Planning → Design → Coding → Testing
→ Release
●​ Image 2: High-level Agile principles model (ToolsQA)
●​ Image 3: Scrum/XP hybrid model – overlapping structures of both methods
●​ Image 4: A detailed Kanban board structure with WIP limits and swimlanes

📋 Comparison Table
Aspect XP Scrum Kanban

Iteration Very short, story-based Fixed-length sprints (1–4 Continuous flow, pull
Style increments weeks) system

Primary Technical rigor (TDD, Organizational structure Flow optimization & WIP
Focus refactoring, pairing) and roles control

Roles Flat team, includes Product Owner, Scrum Flexible roles based on
Defined on-site customer Master, Dev Team existing org

Informal boards, CRC Kanban board with

Board Usage Backlogs + Sprint board
cards, stories explicit policies

Feedback Unit and acceptance Review + retrospective Daily board walkthrough

Cycles tests, rapid loops each sprint + retrospectives
Agile Model

The meaning of Agile is swift or versatile. "Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in
advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller parts
helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software development
life cycle including planning, requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1.​ Requirements gathering

 2.​ Design the requirements
3.​ Construction/ iteration
4.​ Testing/ Quality assurance
5.​ Deployment
6.​ Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders
to define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance
and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

Agile Testing Methods:

Every Agile technique aims to produce functional software as quickly as feasible while
embracing and adapting to change. Each approach differs, though, in how it outlines the
stages involved in software development. The following are some of the most popular Agile
techniques:

o​ Scrum
o​ eXtreme Programming(XP)

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in

team-based development conditions.

There are three roles in it, and their responsibilities are:

o​ Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
 o​ Product owner: The product owner makes the product backlog, prioritizes the delay
and is responsible for the distribution of functionality on each repetition.
o​ Scrum Team: The team manages its work and organizes the work to complete the
sprint or cycle.

eXtreme Programming(XP)
Extreme programming (XP) is a methodical technique that emphasizes continuous Delivery
and speed. It encourages close cooperation, constant planning and testing, quick feedback
loops, and greater customer participation. Frequent software delivery occurs, often every one
to three weeks. The aim is to enhance software responsiveness and quality in response to
evolving client needs.

The principles of boldness, simplicity, communication, and feedback form the foundation of
the XP technique.

Crystal:
There are three concepts of this method-

1.​ Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.
2.​ Cyclic delivery: under this, two more cycles consist, these are:
o​ Team updates the release plan.
o​ Integrated product delivers to the users.
3.​ Wrap up: According to the user environment, this phase performs deployment,
post-deployment.