Self-healing tests means:

Automated test scripts can adjust themselves when small changes happen in the application, especially in the UI.

What does “locator” mean?

In test automation, a locator is how the test finds an element on the screen.

Example:

Click the Login button

The automation tool needs to find the Login button using something like:

id = loginButton

or

xpath = /html/body/div/button[1]

or

text = Login

What problem happens?

Suppose the developer changes the button ID:

Old: id = loginButton
New: id = signInButton

A normal automated test may fail because it cannot find loginButton.

But the application may still be working. The test failed because the locator changed, not because the feature is broken.

Self-healing test example

A self-healing test may say:

“I cannot find loginButton, but I see another button with similar text, same location, and same function. It is probably the same Login button.”

So the automation adapts and continues the test.

Simple classroom explanation

Self-healing tests reduce false failures caused by small UI changes.

They are useful when:

• button IDs change,
• page layout changes slightly,
• CSS class names change,
• element location changes,
• text changes slightly from “Login” to “Sign in.”

Important warning

Self-healing does not mean tests are always correct.

You can tell students:

“Self-healing tests are helpful, but humans still need to review important changes. If the test heals itself incorrectly, it may hide a real defect.”

Easy teaching line

Self-healing test automation means the test can still find the right UI element even when the technical locator changes.

REF: AI Tools as is

Yes. Debrief means the short discussion after the activity.

After students finish the RCA/Fishbone/Five Whys activity, you ask them to share what they found.

Meaning of this line

One group shares one strong DoD item

It means:

Each group should give one good Definition of Done checklist item that could prevent this problem from happening again.

Example classroom instruction

You can say:

“Now we will debrief. Each group, please share one strong Definition of Done item that would have prevented the checkout crash or mobile button issue.”

Strong DoD examples students may give

Best example answer

A strong DoD item would be:

A user story cannot be marked Done unless it passes functional testing on both desktop and mobile, all acceptance criteria are verified, and no critical defects remain open.

How to explain debrief to students

“Debrief means we stop the group work and learn from each other. We are not only checking the answer. We are asking: what did your group discover, and how would you improve the process next time?”

REF: AI Tools as is

Fishbone helps find the root cause by organizing possible causes into categories, so the team does not jump to one quick answer or blame one person too early. It is a visual RCA tool used to identify possible causes of a problem.

Simple explanation for students

“Fishbone does not automatically give the root cause. It helps the team brainstorm, organize, compare, and narrow down possible causes until the most likely root cause becomes visible.”

How it works

Problem:

Checkout crashes 40% of the time

Fishbone categories:

People --------\
Process --------\
Tools -----------> PROBLEM: Checkout crashes 40% of the time
Testing --------/
DoD ------------/
Environment ---/

Then the team asks:

How it leads to the root cause

After listing possible causes, the team looks for the causes that are most likely, most repeated, or supported by evidence.

For example, the team may discover:

The checkout failed mostly on mobile devices, but mobile testing was not part of the Definition of Done.

So the root cause may be:

The team’s Definition of Done did not require mobile checkout testing before release.

Teaching line

Fishbone helps us move from “What went wrong?” to “What could have caused it?” and then to “Which cause should we fix so the problem does not happen again?”

Ref: AI Tools as is

Yes. Fishbone Analysis should usually be shown as a diagram, because it is a visual Root Cause Analysis tool. It is also called an Ishikawa Diagram or Cause-and-Effect Diagram. Your slide defines it as a visual tool for identifying possible causes of a specific problem.

Simple Fishbone Diagram Example

Problem:

Checkout crashes 40% of the time

                           People
               Not enough QA training
                    No reviewer assigned
                              \
                               \
Process ------------------------\ 
No mobile test checklist          \
No release approval step           \
                                  \
Tools ----------------------------->  PROBLEM:
Test automation missed mobile      Checkout crashes
No crash-monitoring tool           40% of the time
                                  /
Testing --------------------------/
Only happy-path tests
No stress / edge-case tests
                                 /
Definition of Done -------------/
AC checked, but mobile testing missing
Security/performance not checked
                                 /
Environment -------------------/
Different mobile browsers
Production data different from test data

How to explain it to students

“The fish head is the problem. The bones are major cause categories. Under each bone, we write possible causes. We are not choosing the final answer immediately. First, we brainstorm possible causes. Then we analyze which causes are most likely to be the real root cause.”

Cleaner classroom version

People --------\
Process --------\
Tools -----------> PROBLEM: Checkout crashes 40% of the time
Testing --------/
DoD ------------/
Environment ---/

Then students add details under each category.

Example causes

Teaching line

Fishbone helps the team avoid blaming one person too quickly. It shows that quality problems usually come from multiple causes: people, process, tools, testing, and environment.

Ref: AI Tools

Pull system in Kanban means:

Work is started only when the next person or stage has capacity.

It is the opposite of a push system, where managers or upstream teams keep assigning work even when people are already overloaded.

Simple explanation

Kanban example

Board:

To Do → In Progress → Review → Done

Suppose In Progress WIP limit = 3.

If there are already 3 items in In Progress, the team cannot pull another item from To Do.

They must first finish something and move it to Review or Done.

Simple class example

“In Kanban, we do not keep starting new work just because work exists. We pull work only when there is available capacity.”

Example with Review

If Review WIP limit = 2 and Review already has 2 items, the developer should not push another completed item into Review. Instead, the team may help clear Review first.

Teaching line

Pull system means: finish work before starting more work.
It protects the team from overload and keeps work flowing smoothly.

REF: AI Tools as is

In Kanban, you can set WIP limits on both:

In Progress and Review

They should have separate limits, because they control different types of work.

Your slide says WIP limits are the maximum number of items allowed in each workflow stage, used to prevent overload and identify bottlenecks early.

Simple board example

Best classroom answer

We set WIP limits on the active work columns, especially In Progress and Review.
In Progress limit controls how much work the team starts.
Review limit controls how much work is waiting for testing, approval, or feedback.

Example

Suppose the team has 4 people:

This means:

• Maximum 3 items can be actively worked on.
• Maximum 2 items can wait in review.
• If Review already has 2 items, no one should move another item into Review until one item moves to Done.

Teaching line

In Kanban, we do not want many tasks half-finished. We want work to flow. So we limit active work in In Progress and Review to expose bottlenecks and help the team finish before starting more.

REF: AI Tools as is

For Kanban, these three metrics measure flow — how smoothly work moves from request to completion.

Your Agile metrics slides define throughput as the number of work items completed in a given time period, lead time as the time from request to delivery, and cycle time as the time from active work start to completion.

Simple teaching explanation

Lead time = customer waiting time.
Cycle time = team working time.
Throughput = how many items the team finishes.

Example using Kanban board

A task moves like this:

Backlog → To Do → In Progress → Review → Done

Suppose:

• Student submits a helpdesk request on Monday
• Team starts working on it on Wednesday
• Team finishes it on Friday

Then:

Key difference

Lead time includes waiting time. Cycle time only includes active work time.

So if work sits in To Do for 4 days before anyone starts, that waiting time increases lead time, but not cycle time.

REF: AI Tools as is

Your slides define velocity as a key Agile metric that measures how much work a team completes during a sprint and helps forecast future sprint capacity.

Your slides use burndown scenarios to interpret sprint progress, including teams being ahead of the ideal line, behind but still reaching the target, flatlining because of blockers, or showing erratic progress.

Simple teaching explanation:

Velocity tells us how much the team usually completes. Sprint burndown tells us whether the current sprint is progressing toward completion.

Example for students:

If our team usually completes 20 story points per sprint, we should not plan 45 story points for the next sprint. During the sprint, the burndown chart helps us check whether the remaining work is decreasing fast enough.

A good solution would be:

If the Review column exceeds its WIP limit, I would stop pulling new work into Review and focus the team on clearing the bottleneck. The goal is to finish and move existing work forward before starting or adding more work.

Step-by-step action

Example answer

Suppose the Review WIP limit is 2, but there are 4 items in Review.

I would not allow another item to move from In Progress to Review. Instead, the team should help complete the review of the 4 existing items. If the issue is that only one person is doing all reviews, another qualified team member should help. If the issue is unclear acceptance criteria, the Product Owner should clarify them. Once two items pass review and meet the Definition of Done, they can move to Done, and then new items may enter Review.

Best short answer for students

If Review exceeds its WIP limit, the team should stop starting new work, focus on finishing the items already in Review, identify and remove the bottleneck, and only move new items into Review when capacity becomes available. The team should also discuss the cause and improve the process so the overload does not continue.

REF: AI Tools/ChatGPT

Yes — DoD means Definition of Done.

Acceptance Criteria and Definition of Done are related, but they are not the same.

Your slides define Acceptance Criteria as clear, testable conditions that must be met for story completion, with formats such as Given–When–Then or checklist style.

Your slides define Definition of Done as the shared understanding of what “complete” means for every user story, including code review, testing, integration, acceptance criteria verification, documentation, performance, accessibility, and security checks.

Simple example

User story:

As a student, I want to reset my password so that I can access my account if I forget it.

Acceptance Criteria:

• User can request password reset by email.
• Reset link expires after 30 minutes.
• User receives a confirmation message after password change.

Definition of Done:

• Code is reviewed.
• Unit tests pass.
• Feature tested in staging.
• Acceptance criteria are verified.
• Documentation updated.
• Security review completed if needed.

Simple class explanation

Acceptance Criteria answer: “What must this specific story do?”
Definition of Done answers: “What must be true before any story is considered complete?”

So if students ask, you can say:

A story is not truly done just because it was coded. It must satisfy its own acceptance criteria and also meet the team’s Definition of Done.

REF: AI Tools/ChatGPT as is