MODULE-3

TRANSITIONING TYPICAL PROCESSES

Transitioning a typical process is the process of gradually replacing an

existing workflow or methodology with a new one to improve efficiency,
quality, and collaboration.

Steps in Transitioning to Agile

1. Assess the current process

o Understand how the team currently works.

o Identify problems such as delays, poor communication, or high

defect rates.

2. Train the team

o Provide training on Agile principles, Scrum, Kanban, and Agile

testing.

3. Define new roles

o Assign roles such as Product Owner, Scrum Master, and

Development Team.

4. Create a Product Backlog

o List and prioritize all project requirements.

5. Plan Sprints

o Break the project into short iterations (usually 2–4 weeks).

6. Adopt Continuous Testing

o Perform testing throughout development instead of waiting

until the end.

7. Conduct Sprint Reviews and Retrospectives

o Review completed work, gather feedback, and identify

improvements.

8. Continuously Improve

o Refine processes based on lessons learned after each sprint.

In traditional software development models (such as the Waterfall

model), the project is divided into separate phases like:
 1. Requirements Gathering

2. Design

3. Development

4. Testing

5. Deployment

At the end of each phase, the team prepares heavy documentation and
obtains formal approvals (sign-offs) before moving to the next phase.

For example:

 After completing the requirements document, the customer signs it.

 After finishing the design document, the project manager approves

it.

 Only then can the developers begin coding.

This process is called a phased and gated process, where each phase
acts as a gate that must be completed before proceeding.

Why doesn't this work well in Agile?

Agile follows a different approach:

 Requirements can change frequently.

 Development and testing happen continuously.

 Customers provide feedback throughout the project.

 Working software is valued more than extensive documentation.

Therefore, creating hundreds of pages of documents and waiting for

approvals after every phase slows down the project.

Heavyweight Documentation

Heavyweight documentation means producing large, detailed documents

before moving forward.

Examples include:

 Software Requirement Specification (SRS)

 Detailed Design Documents

 Test Plans
  Test Summary Reports

 Approval Documents

Problem

 Takes a lot of time.

 Difficult to update when requirements change.

 Many documents become outdated quickly.

Agile Alternative

Instead of heavy documents, Agile prefers lightweight documentation

such as:

 User Stories

 Product Backlog

 Sprint Backlog

 Acceptance Criteria

 Task Boards

 Automated Test Cases

 Sprint Reviews

These are easier to update and keep the team focused on delivering
working software.

Sign-offs in Traditional Projects

A sign-off is formal approval that confirms a phase has been completed.

Example:

Customer:

"I approve these requirements."

Project Manager:

"Design phase is complete."

Only after these approvals does the next phase begin.

Agile Project
Sprint 1

 Write user stories

 Develop feature

 Test feature

 Customer reviews feature

Sprint 2

 Modify requirements if needed

 Develop next feature

 Test continuously

 Customer gives feedback again

This cycle repeats until the product is complete.

Many traditional project processes are not suitable for Agile because they
depend on:

 Extensive documentation,

 Strict phase-by-phase progression, and

 Formal approvals before moving ahead.

Agile replaces these with:

 Lightweight documentation,

 Continuous collaboration,

 Frequent customer feedback,

 Short development iterations (sprints), and

 Working software delivered regularly.

There are no fixed rules for converting traditional processes to Agile.

Each organization can adapt its processes based on its needs while
following Agile principles

Seeking Lightweight Processes

Definition
Seeking Lightweight Processes means using simple, efficient, and
less time-consuming methods for planning, testing, tracking defects,
and measuring progress in Agile projects. The goal is to reduce
unnecessary documentation while still maintaining software quality.

Key Points

 Agile teams prefer simple and flexible processes instead of

heavy documentation.

 Traditional practices such as metrics, defect tracking, and test

planning are still important.

 Organizations may need to follow quality standards such as

CMMI(Capability Maturity Model Integration) and ISO 9000,
even when using Agile.

 Agile is compatible with these standards if the processes are kept

simple and focused on delivering value.

 The main objective is to deliver high-quality software quickly

with minimal unnecessary work.

Traditional Method:

 A tester writes a 50-page test plan before testing begins.

Agile Method:

 The tester creates a 1–2 page test plan with essential test
scenarios and continuously updates it during the sprint.

Scenario: Online Banking Application

A bank is developing an Online Banking System with features such as

Login, Balance Enquiry, Fund Transfer, and Transaction History.

Traditional Process

 The tester writes a 100-page test plan.

 All testing is done after the developers finish coding.

 Defects are reported only at the end of the project.

 The customer waits several months before seeing the software.

Agile (Lightweight Process)

 The team plans to develop the Fund Transfer feature in a 2-week

sprint.
  The tester prepares a simple checklist instead of a lengthy test
plan.

 Developers and testers work together every day.

 Automated tests run whenever new code is added (Continuous

Testing).

 Defects are logged immediately and fixed during the same sprint.

 At the end of the sprint, the team demonstrates the Fund Transfer
feature to the bank manager and collects feedback.

Metrics in Agile Testing

Metrics are quantitative measurements that help an Agile team monitor

its performance, improve processes, and deliver better business value.

Metrics help teams to:

 Measure project progress.

 Identify bottlenecks and delays.

 Improve software quality.

 Support better decision-making.

 Encourage continuous improvement.

 Ensure customer satisfaction.

Note: Metrics should guide improvement, not be used to judge or punish

individual team members.

Lean Measurements

Lean Software Development encourages using fewer but more

meaningful metrics.

Goal of Lean Metrics

 Reduce unnecessary measurements.

 Focus on measurements that improve customer value.

 Encourage teamwork and collaboration.

 Deliver software faster with high quality.

Cycle Time
Definition

Cycle Time is the total time taken from a customer's feature request until
the software feature is delivered.

Formula

Cycle Time = Delivery Date – Feature Request Date

Example

Customer requests Online Bill Payment on 1st July.

Feature delivered on 11th July.

Cycle Time = 10 days

If the next feature takes only 6 days, the team has improved its process.

Team-Based Metrics

Lean recommends measuring the entire team's performance, not

individual performance.

Examples

 Cycle Time

 Release Frequency

 Customer Satisfaction

 Business Value Delivered

These metrics encourage developers, testers, and business analysts to

work together.

Defect Fix Time (Latency)

Defect Fix Time (Latency) is the time taken to fix a defect after it has
been reported.

Defect Fix Time = Defect Fixed Date – Defect Reported Date

Example

Bug reported on Monday

Bug fixed on Wednesday

Defect Fix Time = 2 days

Lower defect fix time indicates better collaboration and faster delivery.

Financial Return (ROI)

Definition

Return on Investment (ROI) measures whether the software provides

sufficient business value compared to its development cost.

Formula
Profit−Cost
ROI= ×100
Cost

Example

Development Cost = ₹10,00,000

Profit Earned = ₹15,00,000

ROI = 50%

A higher ROI means the project delivers greater business value.

Business Goal Metrics

Agile teams should identify business goals and measure whether those
goals are achieved.

Example

Business Goal: Increase online customers.

Metrics:

 Number of new customer registrations

 Increase in website visitors

 Number of app downloads

 Customer retention rate

Why We Need Metrics

Metrics are numerical measurements used to monitor, evaluate, and improve the
performance, quality, and progress of a software project.

Why Do We Need Metrics?

Metrics help Agile teams:

 Measure project progress.

 Monitor software quality.

 Detect problems early.

 Track whether goals are being achieved.

 Support continuous improvement.

 Motivate the team.

 Help customers understand project status.

Metrics should be used as guideposts(They tell the team whether they are
moving in the right direction), not as tools to blame or punish individuals.

If code coverage suddenly drops from 75% to 65%, the team investigates
the reason.

Focus on Trends, Not Individual Numbers

A single metric has little meaning.

Teams should observe:

 Whether quality is improving.

 Whether delivery is becoming faster.

 Whether customer satisfaction is increasing.

Example

Code
Sprint
Coverage

Sprint
70%
1

Sprint
72%
2
 Code
Sprint
Coverage

Sprint
75%
3

The increasing trend shows continuous improvement.

Metrics Help Track Progress

Metrics help everyone—including customers—monitor project progress

during:

 An iteration (Sprint)

 A release

 An epic

Burndown Chart

A Burndown Chart shows how much work remains in a sprint.

Interpretation

 Line moving downward → Project is progressing well.

 Line moving upward → Warning sign (red flag).

The team should investigate the reason.

Metrics Can Motivate the Team

Properly used metrics encourage improvement and celebrate

achievements.

Example

A development team tracks the number of automated unit tests.

Milestones:

 100 tests

 1,000 tests

 3,000 tests

Each milestone is celebrated because it reflects continuous improvement.

However, more tests do not always mean better quality. The tests
must also be effective.

What not to do with metrics

Do Not Use Metrics to Judge Individuals

One of the biggest mistakes is using metrics to evaluate the performance

of individual team members.

For example:

“Tester A found 50 defects, but Tester B found only 20 defects, so Tester A

is a better tester.”

This conclusion may be wrong.

Tester B may have worked on a smaller or better-tested module, while

Tester A may have worked on a complex module with many problems.

Therefore: Metrics should be used as guideposts for improvement,

not as weapons against individuals.

Do Not Reward Teams Only for Good Numbers

If teams are rewarded or punished based only on metrics, people may

change their behavior just to improve the numbers.

Metrics Can Create the Wrong Motivation

Metrics should encourage improvement, not fear.

If developers are constantly criticized because their defect count is high,

they may become more concerned about protecting their numbers
than improving software quality.

Similarly, if testers are criticized for finding too few defects, they may feel
pressure to report unnecessary defects simply to increase their numbers.

Conclude that Metrics should be used as guideposts to measure progress

and identify areas for improvement, not as a means of judging or
punishing individual team members or teams.”

Communicating Metrics

1. Meaning of Communicating Metrics

Communicating metrics means making important measurements

visible and understandable to the people who need them.

Metrics are useful only when people can:

 See them

 Understand them

 Discuss them
  Take action based on them

One of the most effective ways to communicate metrics is through large,

visible charts or dashboards.

Examples:

 Bar charts

 Line graphs

 Progress charts

 Dashboards

 Build status boards

 Test-result displays

Daily Build Status

-----------------------------

Tests Passed: 3,062

Tests Failed: 12

Automation: 85%

Build Status: PASS

Defects Open: 18

-----------------------------

Metrics ROI

1. Meaning of Metrics ROI

ROI (Return on Investment) means comparing the value gained from

a metric with the time, effort, and cost required to collect and
maintain it.

Defect Tracking

Defect Tracking System (DTS) is a tool used to record, manage, and

track software defects or bugs.

Why use a Defect Tracking System?

1. Convenience

o Stores complete bug details in one place.

o Includes steps to reproduce, severity, priority, status,

environment, browser, etc.
 o Screenshots, logs, and files can also be attached.

2. Knowledge Base

o Old defects can help the team understand previously found

problems.

o Developers and testers can find previous solutions easily.

o Useful for intermittent bugs that are difficult to reproduce.

3. Remembering Solutions

o Records the cause of a defect and how it was fixed.

o Helps when the same problem occurs again.

o Reduces dependence on people's memory.

4. Large or Distributed Teams

o Useful when many teams work on the same project.

o Team members in different locations can access the same

defect information.

5. Customer Support

o Helps support teams know which customer-reported defects

were fixed.

o They can also identify defects that are still pending.

o Makes it easier to provide information to customers.

6. Metrics

o Defect information can be used to calculate and analyze

defect rates.

o Helps the team understand the quality of the software.

o However, not every bug needs to be counted as a defect.

7. Traceability

o A DTS can link defects with test cases.

o However, not every defect needs a test case.

o Examples: spelling mistakes, usability problems, and bugs

found during exploratory testing.

Example:
Suppose you are testing an Online Banking Application and find a login
defect.

A Defect Tracking System (DTS) record could look like this:

Field Example

Defect ID BUG-101

Title Login fails with valid password

User cannot log in even after entering correct username

Description
and password.

Steps to 1. Open banking website 2. Enter valid username 3.

Reproduce Enter valid password 4. Click Login

Expected
User should successfully log in.
Result

Actual Result Error message "Invalid credentials" is displayed.

Severity High

Priority High

Status Open

Assigned To Developer

Environment Chrome, Windows 11

Screenshot/
Attached
Log

Resolution Password validation code corrected

Retest Result Passed

Final Status Closed

Why Shouldn’t We Use a DTS

A Defect Tracking System (DTS) is useful, but Agile teams may decide
not to use a formal DTS when defects can be handled quickly through
direct communication and simple tracking.

1. Less Need for a DTS in Agile

 Agile and Lean focus on quality, collaboration, and quick

feedback.
  If the development process is good, defects should be fewer.

 Simple defects can be tracked using cards or task boards.

2. DTS Can Reduce Communication

 Testers may enter a defect into the system instead of talking to

developers.

 Developers may simply read the report without discussing the

problem.

 Direct communication between tester and developer can solve

problems faster.

3. Time-Consuming Process

A defect may go through many steps:

Report → Triage → Assign → Analyze → Fix → Reassign → Retest →

Close

 Writing detailed defect reports takes time.

 Developers may misunderstand the defect.

 The defect may require several rounds of discussion and correction.

4. Defects Become a Queue

 Open defects in a DTS can become a backlog of unfinished work.

 Lean considers unnecessary inventory or waiting as waste.

 Teams should try to reduce the number of pending defects.

5. Direct Communication Can Be Faster

Instead of writing a long defect report:

Tester finds bug → Talks to developer → Shows the problem →

Developer fixes it → Tester verifies

This can be much faster for simple defects.

6. Choose DTS Carefully

If a team decides to use a DTS:

 Keep it simple and easy to use.

 Make sure the whole team can use it.

 Choose a tool based on the team's actual needs.

 Avoid tools that create unnecessary work.

7. Make Defects Visible

Even without a formal DTS, defects should be visible to the whole

team.

For example, use a story board:

 🟨 Yellow card → Normal bug

 🟥 Red card → High-priority or critical bug

 Other cards → Stories and testing/development tasks

This allows everyone to quickly see the status of defects.

8. Main Focus

The goal is not simply to track defects.

The main goal is:

Deliver a high-quality product quickly and provide value to the

customer.

Defect Tracking Tools:

 Jira
 Bugzilla
 Azure DevOps
 MantisBT
 Redmine
 YouTrack
 GitHub Issues
 Trac
 Trello
 Zoho BugTracker