Course: Self-healing — 3. Exercises

Twenty-one hands-on exercises on self-healing and automatic fixes, with IBM Maximo. Before you start, read the course overview and complete the lab setup. P1-P8 refer to the setup page’s procedures.

Each exercise has:

• Goal: what you will see;
• Before you start: the preparation (always P8, then P2, usually P4);
• Steps: Where (AutoTestX or Maximo), Action, Expected result, and a box to tick;
• What happened: the explanation;
• Check yourself: a question to answer before moving on.

---

Module 1: Rules and their form

Exercise 1: Create, edit, disable, enable and delete a rule

Goal: manage a rule, and see that every change is a version in the audit trail.

Before you start: P8; P2 with the copy MX TC-01.

#	Where	Action	Expected result	✓
1	AutoTestX	Self-healing → Rules	Subtitle Rules decide which fixes apply without a review. Without a rule, every fix waits for a person.
2	AutoTestX	New rule	Dialog New rule. Defaults: Apply automatically; Dry run - only record what it would do; tier ≤ 1; confidence 85; Risk low; Seen in at least 2; All tests; Enabled
3	AutoTestX	Name TC-01 rule; untick All tests; tick MX TC-01; Save	Toast Saved “TC-01 rule” as v1. Card: Apply automatically · MX TC-01, priority 100, Dry run, tier ≤ 1 · confidence ≥ 85% · low risk · seen in 2+ runs, v1, changed by <you>
4	AutoTestX	Edit: Mode Active, confidence 90, priority 10, tick medium, step types click → Save	Toast … as v2; no Dry run badge; priority 10; confidence ≥ 90% · low/medium risk · click
5	AutoTestX	Disable	Toast Disabled “TC-01 rule”; badge Disabled
6	AutoTestX	Enable	Toast Enabled “TC-01 rule”; badge gone
7	AutoTestX	Delete → Cancel in the browser dialog	Rule still there
8	AutoTestX	Audit trail → Rule changes	Rule created and Rule changed for TC-01 rule; newest now v4
9	AutoTestX	Rules → Delete → OK	Toast Deleted “TC-01 rule”; trail: Rule deleted … at v4

What happened: a new rule starts cautious: a dry run, and only fixes seen in 2 runs. Every save, disable and enable is a new version of the rule, and the audit trail keeps each version. An automatic fix can always be traced to the exact rule version that made it.

Check yourself: why does a new rule start as a dry run?

Exercise 2: The rule form enforces the guardrails

Goal: see the limits a rule can never cross.

Before you start: P8.

#	Where	Action	Expected result	✓
1	AutoTestX	New rule, empty Name → Save	A rule needs a name of up to 80 characters.
2	AutoTestX	Name TC-02; Mode Active; tick high	A high-risk step can never be fixed automatically. Untick “high”. Save is refused too
3	AutoTestX	Untick high; tier Any, including AI (tier 2)	AI (tier 2) proposals can never be fixed automatically.
4	AutoTestX	Tier back to ≤ 1; tick medium; confidence 75	minConfidence 0.75 is below the system minimum of 0.78 for automatic fixes. (also after Save)
5	AutoTestX	Confidence 80	Message gone
6	AutoTestX	Minimum lead 150 → Save	minMargin must be a number from 0 to 1.
7	AutoTestX	Empty the lead; step types teleport → Save	Unknown step type: teleport
8	AutoTestX	Empty step types; untick All tests, tick nothing → Save	A scope must cover all tests, or name tests, tags, suites or components.
9	AutoTestX	Tick All tests; Preview this rule	Last 30 days: matched …
10	AutoTestX	Action Always require review; tick high; tier 2; confidence 10	No error; no A fix to a Ready test field
11	AutoTestX	Save	Toast Saved “TC-02” as v1; card Always require review, any tier · confidence ≥ 10% · low/medium/high risk
12	AutoTestX	New rule → Cancel; then delete TC-02	Nothing saved; rule gone

What happened: the guardrails bind only what a rule may apply. High-risk steps, AI proposals, and confidence below what the runner itself needs (70% low, 78% medium) are never applied automatically. A rule that asks for review cannot make a test worse, so it is not limited. The form warns as you type and the server checks again on save.

Check yourself: could a rule ever apply a fix to a Delete button automatically?

---

Module 2: Fixes without and with a rule

Exercise 3: Without a rule, fixes wait for a person

Goal: healing never changes a test on its own; a person approves or rejects.

Before you start: P8 (no rules in the project); P2 with MX TC-03.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v4 (P1)	PASS 10/10; steps 2, 4, 6, 8, 9 WARN
2	Maximo	P7 on v4	A new work order was saved
3	AutoTestX	Run report → step 9. Click Save (P5)	Fallback locator; heal panel; The test itself is unchanged. The fix is applied only once someone approves it.; Review suggestion →
4	AutoTestX	Open MX TC-03	Banner 5 self-healing suggestions are waiting for review…; step 9 still #toolactions_SAVE-tbb_image
5	AutoTestX	Review → Pending	Five cards (Enter user name, Sign in to Maximo, Click New Work Order, Point at Change Status, Click Save), each … in 1 run, Was / Proposed, Approve, Pick the element instead…, Reject
6	AutoTestX	Click Save → Approve	Toast Approved - saved as v…
7	AutoTestX	Click New Work Order → Reject, note Wrong toolbar button → Reject	Toast Rejected - this fix will not be suggested again for that step
8	AutoTestX	Approved, then Rejected	Approved by <you> (no rule badge); Rejected by <you>: “Wrong toolbar button”
9	AutoTestX	Overview	3 waiting for review
10	AutoTestX	Run on v4 again; reload; Pending	Click New Work Order not back; others … in 2 runs
11	AutoTestX	Audit trail for the test (P6)	Approved and Rejected entries

What happened: v4 renamed five ids. Each step was still found by a backup locator (Tier 0), so the run passed and the work order was saved. The run only suggested the fixes. Approving wrote one into the test; rejecting stopped that proposal for good.

Check yourself: if nobody approves the suggestions, will the next run still pass?

Exercise 4: An active rule fixes the toolbar automatically

Goal: the core flow. A rule applies fixes, and the rule is credited everywhere.

Before you start: P8; P2 with MX TC-04; P4 the standard click rule TC-04 clicks.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v4	PASS 10/10
2	AutoTestX	P3 → Approved → Decided by a rule	Sign in to Maximo, Click New Work Order, Click Save: Applied by rule “TC-04 clicks” v1 on … → v…, wand badge
3	AutoTestX	Chip off; Pending	Enter user name (Type) and Point at Change Status (Hover) wait
4	AutoTestX	Editor → step 9	The fix is the first locator; the old css is a backup
5	AutoTestX	Editor → History	Newest revision: badge TC-04 clicks v1
6	AutoTestX	Audit trail → Fixes and reverts	Applied by a rule for Click Save, − old / + new locator; Evidence: tier, confidence, risk, step type click is in click ✓
7	AutoTestX	Overview	automatic fixes this week
8	AutoTestX	Run on v4 again	Steps 4, 6, 9 PASS with Primary locator

What happened: the rule matched the three Click fixes and applied them right after the run, as if a person had clicked Approve. The Type and Hover steps were outside the rule’s step types, so they wait. From now on the fixed steps find Maximo’s new ids directly.

Check yourself: what would you change in the rule to also fix Enter user name?

---

Module 3: Safety

Exercise 5: A password field is never guessed at, nor fixed automatically

Goal: typing a password is high-risk: never into a guessed field, never auto-fixed.

Before you start: P8; P2 with MX TC-05; P4 rule TC-05 broad: Apply automatically, Active, only MX TC-05, confidence 78, low + medium, seen 1, step types empty.

#	Where	Action	Expected result	✓
1	AutoTestX	Watch on; run on Maximo v5	The password is not typed into the User name box
2	AutoTestX	Run report → step 3 (P5)	No note picked #username of 2 matches
3	AutoTestX	P3 → Approved	No card for Enter password
4	AutoTestX	Pending	Enter password waits, Risk high in red
5	AutoTestX	Editor → step 3	Still #password

What happened (intended): the step’s element is a password input, so the step is high-risk. The run must not act on a guessed element, and no rule may fix it. Known issue: see the course overview. The current release can fail steps 1-5. If it does, note it as found, and use it as an example of why fixes to sensitive steps need a person.

Check yourself: name three Maximo elements besides the password field that are high-risk.

---

Module 4: Rolling out a rule

Exercise 6: Dry run, then Active

Goal: check what a rule would do before letting it act.

Before you start: P8; P2 with MX TC-06; P4 the standard click rule TC-06, but keep Mode = Dry run.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v2	PASS
2	AutoTestX	Editor → step 9	Unchanged
3	AutoTestX	P3 → Pending	Click Save and Click New Work Order wait
4	AutoTestX	Audit trail → Held back	Left for review for Click Save: Not applied: the rule is in dry-run mode
5	AutoTestX	Rules → Preview against history	In the last 30 days, … would have been applied …; card would apply N
6	AutoTestX	Edit → Mode Active → Save	Toast … as v2
7	AutoTestX	Run on v2 again; Approved	Click Save: Applied by rule “TC-06” v2, … in 2 runs

What happened: in dry run, the rule recorded would apply and changed nothing. Preview against history replays recent suggestions through your rules, so you see the effect before switching on. The preview counts only the rules’ own conditions, not the daily limit or pauses.

Check yourself: where do you look to see what a dry-run rule would have done?

Exercise 7: “Always require review” beats “Apply automatically”

Goal: when rules overlap, the most cautious wins, whatever the priority.

Before you start: P8; P2 with MX TC-07; two rules, both Active, only MX TC-07, confidence 80, low + medium, seen 1, click: TC-07 apply (Apply automatically, priority 1) and TC-07 review (Always require review, priority 500).

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v2	PASS
2	AutoTestX	P3 → Approved / Pending	Approved empty; Click Save pending
3	AutoTestX	Audit trail → Held back → Rules checked (Click Save)	Verdict: always require review, badge TC-07 review
4	AutoTestX	Rules → Disable TC-07 review	Toast Disabled “TC-07 review”
5	AutoTestX	Run on v2; Approved	Click Save: Applied by rule “TC-07 apply” v1
6	AutoTestX	Audit trail → Rule changes	Rule changed for TC-07 review: …, disabled

What happened: require review beats reject, which beats apply. Priority only orders rules with the same action. A narrow “review this” rule can never be overridden by a broad “apply” rule.

Check yourself: with the review rule at priority 1 and the apply rule at 500, what happens?

Exercise 8: An auto-reject rule

Goal: close fixes nobody should spend time on.

Before you start: P8; P2 with MX TC-08; P4 rule TC-08 no hovers: Reject automatically, Active, only MX TC-08, confidence 50, low + medium + high, seen 1, step types hover.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v2	PASS; step 8 WARN
2	AutoTestX	P3 → Rejected + Decided by a rule	Point at Change Status: Rejected by rule “TC-08 no hovers” v1
3	AutoTestX	Audit trail → Changes	Rejected by a rule
4	AutoTestX	Editor → step 8	Unchanged
5	AutoTestX	Run on v2 again; Pending	Point at Change Status not offered again

What happened: the rule rejected the Hover fix as soon as it was filed. A rejected proposal is never offered again for that step. Reject rules may include high risk, because rejecting cannot change a test.

Check yourself: why is it safe for a reject rule to cover high-risk steps?

Exercise 9: Conditions: seen in 2 runs, low risk only

Goal: conditions decide which fixes are trusted.

Before you start: P8; P2 with MX TC-09; P4 rule TC-09: Apply automatically, Active, only MX TC-09, confidence 70, low only, seen in 2, step types empty.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v2	PASS
2	AutoTestX	P3 → Approved	Nothing: each fix seen once. Audit → Held back: no rule matched: a person reviews it
3	AutoTestX	Run on v2 again; Approved	Point at Change Status (Hover = low) applied by TC-09
4	AutoTestX	Pending	Click Save (Click = medium) waits, … in 2 runs

What happened: Seen in at least 2 runs waits until the same fix comes back, a guard against one-off glitches. Low risk only keeps Clicks (medium) for a person. The trail says only no rule matched, not which condition failed. Known issue: step 4 can fail in the current release; see the course overview.

Check yourself: which condition held back Point at Change Status after the first run?

---

Module 5: Where a rule applies

Exercise 10: Scope: a suite, then a named test

Goal: a rule acts only inside its scope; widen it on screen.

Before you start: P8. Two copies (P2): MX TC-10 A (editor → Test → Suite TC-10 suite → Save) and MX TC-10 B (no suite). Rule TC-10 scope: Apply automatically, Active, untick All tests, Suites TC-10 suite, confidence 80, medium, seen 1, click.

#	Where	Action	Expected result	✓
1	AutoTestX	Rules	Card Apply automatically · in suite TC-10 suite
2	AutoTestX	Run A and B on Maximo v2	Both PASS
3	AutoTestX	Self-healing for A → Approved	Click Save applied by TC-10 scope
4	AutoTestX	Self-healing for B → Pending	Click Save waits
5	AutoTestX	Edit → tick test MX TC-10 B → Save	Card MX TC-10 B; in suite TC-10 suite, v2
6	AutoTestX	Run B on v2; Approved	Applied by rule “TC-10 scope” v2

What happened: a test is in scope if it is ticked, in a ticked suite or has a listed tag. A good rollout starts with one suite you know well and widens step by step.

Check yourself: does a rule on a suite cover a test added to that suite later?

Exercise 11: Component steps need the component named

Goal: shared steps are only fixed when the rule names the component.

Before you start: P8; P2 with MX TC-11. Testing → Components → New component: source MX TC-11, name MX toolbar → Create component. New test MX TC-11 caller → Add → Call component MX toolbar, version 1 → Save; run it on v1. Rule TC-11: Apply automatically, Active, All tests, confidence 80, medium, seen 1, click.

#	Where	Action	Expected result	✓
1	AutoTestX	Run the caller on Maximo v2	PASS
2	AutoTestX	Self-healing for the caller → Pending	Click Save in component MX toolbar v1; Publishes Component “MX toolbar” as a new version…
3	AutoTestX	Edit TC-11 → Components: tick MX toolbar → Save	Card adds component MX toolbar
4	AutoTestX	Run the caller on v2; Approved	Fixes → Component v2 / v3
5	AutoTestX	Components → MX toolbar	New versions; Used by: the caller still on v1

What happened: one component fix changes every test that uses it, so All tests never covers component steps. Fixes publish a new component version; callers keep their pinned version until someone upgrades them.

Check yourself: why can a component fix not just edit version 1?

Exercise 12: A fix to a Ready test

Goal: by default a fix to a Ready test is a new Draft; a rule can keep it Ready.

Before you start: P8; P2 with MX TC-12 A and MX TC-12 B; in each editor Status → Ready → Save. Standard click rules TC-12 drafts (on A) and TC-12 keep (on B).

#	Where	Action	Expected result	✓
1	AutoTestX	Rules	TC-12 drafts: Ready tests get a Draft revision
2	AutoTestX	Edit TC-12 keep → A fix to a Ready test → Becomes the next Ready revision → Save	Ready tests get a new Ready revision
3	AutoTestX	Run A and B on Maximo v2	Both PASS
4	AutoTestX	A → History	Newest revision draft, badge TC-12 drafts; the Ready one unchanged
5	AutoTestX	B → History	Newest revision ready, badge TC-12 keep

What happened: a Ready test is what regression runs use. By default a rule’s fix goes into a Draft, so regression keeps the reviewed version until a Test Manager marks the fix Ready. Keep ready trusts the rule to publish directly.

Check yourself: which option would you use for a nightly regression suite, and why?

---

Module 6: Limits and pauses

Exercise 13: At most 3 automatic fixes per test per 24 hours

Before you start: P8; P2 with MX TC-13; rule TC-13: Apply automatically, Active, only MX TC-13, confidence 78, low + medium, seen 1, step types empty.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v4 (5 drifts)	PASS
2	AutoTestX	P3 → Approved	Exactly 3 applied by TC-13
3	AutoTestX	Pending	The other 2 wait
4	AutoTestX	Audit trail → Held back	Not applied: too many automatic fixes on this test in 24 hours; Evidence (limit 3)

What happened: the rule matched all five, but a test may receive at most three automatic fixes in a rolling 24 hours, across all rules. The rest wait for a person: many changes at once usually mean a redesign worth a look. The limit is fixed in the product, not a setting. On the Rules card the preview still lists these fixes as apply automatically - actually pending: the preview checks only the rule’s conditions.

Check yourself: do fixes that a person approves count toward the limit?

Exercise 14: Circuit breaker: a fix that breaks pauses the rule

Before you start: P8; P2 with MX TC-14; standard click rule TC-14.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v2	PASS; Click Save, Click New Work Order applied
2	AutoTestX	Run on Maximo v7	Step 9 FAIL (or healed): the fix no longer finds Save
3	AutoTestX	Rules	Paused for a test: TC-14 is paused for MX TC-14 - a step it fixed failed again, Let it fix again
4	AutoTestX	Overview	tripped · TC-14 paused for MX TC-14 · Its fix failed again
5	AutoTestX	Run on Maximo v4; P3 → Pending	Sign in to Maximo is not applied; it waits
6	AutoTestX	Audit trail → Held back	Not applied: the rule is paused for this test
7	AutoTestX	Rules → Let it fix again	Toast “TC-14” may fix MX TC-14 again; entry gone
8	AutoTestX	Run on v4 again; Approved	Sign in to Maximo applied by TC-14

What happened: a fix that stops working is evidence the rule is guessing on an unstable page. AutoTestX pauses the rule for the whole test instead of letting it re-fix again and again, until a person resets it.

Check yourself: what is the difference between this pause and the one in exercise 15?

---

Module 7: Undoing fixes

Exercise 15: Revert an automatic fix

Before you start: P8; P2 with MX TC-15; standard click rule TC-15; run on v2.

#	Where	Action	Expected result	✓
1	AutoTestX	P3 → Approved → Click Save → Revert	Note box, Revert, Cancel, ticked Pause the rule for this step
2	AutoTestX	Note Wrong button; keep ticked; Revert	Toast Reverted - saved as v…. The rule is paused for this step until an admin resets it.
3	AutoTestX	Reverted	Applied by rule “TC-15” v1, then reverted by <you> … It will not be suggested again for this step.
4	AutoTestX	Approved	Click New Work Order still applied
5	AutoTestX	Editor → step 9	#toolactions_SAVE-tbb_image again, as a new revision
6	AutoTestX	Rules	Paused: … - <you> reverted its fix
7	AutoTestX	Audit trail → Fixes and reverts	Reverted, “Wrong button”, The rule was paused for this step.
8	AutoTestX	Run on Maximo v3; Pending	A new Click Save fix waits (rule paused)
9	AutoTestX	Let it fix again; run on v3; Approved	New Click Save fix applied

What happened: a revert puts the previous locator back as a new revision (history is kept) and pauses the rule for that one step, so it does not repeat a fix a person undid. Other steps keep being fixed.

Check yourself: after a revert, is the same proposal ever suggested again?

Exercise 16: Revert without pausing; refused revert; “No longer applies”

Before you start: P8; P2 with MX TC-16; standard click rule TC-16; run on v2.

#	Where	Action	Expected result	✓
1	AutoTestX	Approved → Click Save → Revert → untick Pause the rule… → Revert	Toast Reverted - saved as v…. without the pause sentence; Rules: no pause
2	AutoTestX	Editor: step 6 → css img[title^="New Work Order"]; step 8 → css img[title^="Change Status"] → Save	Saved
3	AutoTestX	P3 → Approved → Click New Work Order → Revert → Revert	Error toast … changed since the fix …; card stays
4	AutoTestX	Editor → step 6	Your edit kept
5	AutoTestX	No longer applies	Point at Change Status: The step’s target was changed after this was suggested, so it no longer applies. No Approve

What happened: a revert is refused once someone has edited the step since the fix, because it would undo their newer decision. A pending suggestion whose step was edited by hand no longer applies: it answers an old question.

Check yourself: why is approving an outdated suggestion dangerous?

---

Module 8: Roles and the record

Exercise 17: A Tester can see, but not change

Before you start (as Admin): P8; P2 with MX TC-17; standard click rule TC-17; run on v2.

#	Where	Action	Expected result	✓
1	AutoTestX	Sign out (icon bottom-left); sign in as the Tester
2	AutoTestX	Self-healing → Rules	Only an Admin or Owner can change rules.; no New rule, Edit, Disable, Delete
3	AutoTestX	Self-healing for MX TC-17 → Pending	A Test Developer, Test Manager or Admin can approve this; no Approve
4	AutoTestX	Approved	No Revert
5	AutoTestX	Audit trail	Readable
6	AutoTestX	Sign out; sign in as Admin

What happened: everyone can see why a test changed. Changing tests and policies needs the right role. See People, roles and permissions.

Check yourself: which roles can approve a suggestion?

Exercise 18: Audit trail tools

Before you start: P8; P2 with MX TC-18; standard click rule TC-18; run on v2.

#	Where	Action	Expected result	✓
1	AutoTestX	Audit trail for the test, Changes	Applied by a rule for Click Save with the diff; no Suggested entries
2	AutoTestX	Everything	Also Suggested, Rules checked
3	AutoTestX	Held back	Rules checked only
4	AutoTestX	Rule changes	Nothing recorded of this kind.
5	AutoTestX	Chip One test only ✕ → Rule changes	Rule created for TC-18
6	AutoTestX	Back to the test’s trail → Changes; From = tomorrow	Nothing recorded of this kind.
7	AutoTestX	From = today	The fix is back
8	AutoTestX	Clear From; To = yesterday; then clear To	Nothing, then everything
9	AutoTestX	Verify integrity	Intact: all N entries of this project’s trail chain together…
10	AutoTestX	Export CSV	healing-audit-<date>.csv with an auto.applied row

What happened: rule changes belong to the project, so a single test’s trail does not show them. Verify integrity checks that no entry was edited, removed or reordered. See Self-healing audit trail.

Check yourself: where would an auditor look to see who switched a rule to Active?

---

Module 9: When a pass is not safe

Exercise 19: A guessed element must not be clicked, nor fixed automatically

Before you start: P8; P2 with MX TC-19; standard click rule TC-19.

#	Where	Action	Expected result	✓
1	AutoTestX	Watch on; run on Maximo v6	Step 9 clicks Save, or fails; never Change Status
2	AutoTestX	Run report → step 9	No note picked #… of N matches
3	AutoTestX	Step 10	Passes whenever step 9 passed or warned
4	Maximo	P7 on v6 (port 4416)	A work order saved by this run
5	AutoTestX	P3 → Approved	No Click Save fix applied by TC-19

What happened (intended): v6 renamed every icon and the link around it. The only backup locators left match all the toolbar icons, so AutoTestX cannot know which one is Save. It must not guess. Known issue: the current release may click the nearest icon (Change Status), report the step as found, and let the rule apply that locator. This is why the run report’s picked … of N matches note matters: a WARN that had to choose between several elements deserves a person’s look.

Check yourself: how do you recognise, in a run report, that a step was found by guessing?

---

Module 10: When the test changed since the run

A fix is found by a run, but a person approves it later, and the test may have been edited in between. These exercises show how AutoTestX checks a fix against the test as it is when you approve, so a fix never lands on a step it was not found for and never writes over someone’s save. See When the test changed since the run.

Exercise 20: “Still applies”, and a conflict

Goal: see the three ways a waiting fix can stand against a test that was edited after the run: unchanged, edited elsewhere, and edited around its locator.

Before you start: P8 (no rules in the project); P2 with MX TC-20. You work alone, in two browser tabs of the same window.

#	Where	Action	Expected result	✓
1	AutoTestX	Run on Maximo v4 (P1)	PASS 10/10; steps 2, 4, 6, 8, 9 WARN
2	AutoTestX	P3 → Pending	Five cards, as in Exercise 3. None has a grey Found on… line or an amber panel: nothing changed since the run
3	AutoTestX	Editor: step 10. Verify record saved → Run and failure → Timeout 30 seconds → Save	Toast Saved v…
4	AutoTestX	Back to Pending (F5)	Each card has a grey line with a clock: Found on v… (…); it was saved again since by <you> (…). This step is unchanged, so the fix still applies.
5	AutoTestX	Click New Work Order → Approve	Toast Approved - saved as Test v….
6	AutoTestX	Editor: steps 6 and 10	Step 6 has the new locator; step 10 still has 30 seconds. The fix went on top of your edit
7	AutoTestX	Editor: step 9. Click Save → Run and failure → Timeout 45 seconds → Save	Toast Saved v…. The purple banner shows an amber chip 1 for a step changed since
8	AutoTestX	Pending (F5) → Click Save	An amber panel instead of the usual buttons: This step was changed after the run that found this fix. A table: Timeout (ms), When found —, Now 45000. Buttons Apply to the step as it is now, Pick the element instead…, Reject
9	AutoTestX	Open MX TC-20 in a second tab: step 9 → Timeout 60 seconds → Save. Back to the first tab, without reloading	Toast Saved v… in the second tab
10	AutoTestX	First tab: Apply to the step as it is now	Red toast This step was changed since the page loaded. Review it again as it is now. Nothing is saved; the panel now shows 60000
11	AutoTestX	Apply to the step as it is now again	Toast Approved - saved as Test v…. (Your own open editor in the second tab is never a reason to ask)
12	AutoTestX	Editor (reload): step 9	The new locator, and Timeout still 60 seconds
13	AutoTestX	Audit trail for the test (P6) → Fixes and reverts	Two Approved entries, for Click New Work Order and Click Save

What happened: each suggestion remembers the revision its run executed and the step as it was. Approving checks the test as it is now. An edit elsewhere in the test (step 10) does not matter: the fix still applies, and is written on top of your edit. An edit to the step itself (its timeout, action or options) means the fix was found for a step that no longer exists, so you must look before you apply it, and you only apply it to the version you were shown. If the step’s locator had changed, the suggestion would move to No longer applies (Exercise 16).

Check yourself: in step 4, why does an edit to step 10 not stop the Click Save fix, while the edit in step 7 does?

Exercise 21: Someone else is editing the test

Goal: approving a fix while a colleague has the test open in the editor asks first, and only for a fix that would actually be saved.

Before you start (as Admin): P8; P2 with MX TC-21; run on v4 (five fixes wait). Project members → the Tester account → Project role Test Developer (only a role that can edit a test opens it for editing). Sign that account in, in a private window.

#	Where	Action	Expected result	✓
1	AutoTestX (private window)	Open MX TC-21; step 9 → Timeout 30 seconds → Save. Stay in the editor	Toast Saved v…. Editing took the test’s edit lock, and saving does not let go of it
2	AutoTestX (Admin)	P3 → Pending (F5) → Click Save	The amber conflict panel (as in Exercise 20, step 8). It comes first, before anything about the colleague
3	AutoTestX (Admin)	Apply to the step as it is now	No toast. An amber row with a lock: <colleague> is editing this test. Approving now means they must reload before they can save. Buttons Approve anyway, Cancel
4	AutoTestX (Admin)	Cancel	The panel comes back; the card is still pending
5	AutoTestX (Admin)	Apply to the step as it is now → Approve anyway	Toast Approved - saved as Test v….
6	AutoTestX (private window)	Rename the test to MX TC-21 B → Save	The dialog This test was saved by someone else, naming the Admin. Load theirs: step 9 has the new locator and still 30 seconds
7	AutoTestX (private window)	Go back to Test Cases	Leaving the editor lets go of the lock
8	AutoTestX (Admin)	Click New Work Order → Approve	Toast Approved - saved as Test v…. straight away: nobody is editing now
9	AutoTestX (Admin)	Project members → the account → Project role Tester; sign the private window out	Exercise 17 needs it back as a Tester

What happened: a fix saved under someone’s open editor would make their next save fail, so AutoTestX asks before writing it. It asks only once the fix is known to apply: a fix that no longer applies or conflicts says so first, because “approve anyway” could not help it. The colleague loses nothing: their save is stopped, and Load theirs shows both changes. The lock lasts until they leave the editor, or 15 minutes after their last edit.

Check yourself: in step 2, why does the conflict panel appear before the question about your colleague?

---

Wrap-up

You learned to…	Exercises
Read heals and decide them by hand	3
Let a rule fix safe steps, and trace its changes	4, 18
Roll a rule out safely: dry run → preview → active → scope	6, 9, 10
Combine rules	7, 8
Handle components and Ready tests	11, 12
Rely on the safety limits	2, 5, 13, 14
Undo a fix	15, 16
Spot a pass that is not safe	19
Approve a fix for a test that changed since its run, or that someone is editing	20, 21

Clean up: P8; delete the MX TC-… copies, MX TC-11 caller and the MX toolbar component; stop the drift proxy (Ctrl+C). Maximo keeps the work orders with the description AutoTestX self-heal check; delete them in Maximo if needed.