AlterspectiveCapability Self-Tests

Start

Capability Self-Tests

One click tells you whether a capability works right now

Five modules · about 50 minutes · for builders and for client IT

Start

What you will be able to do

Explain why

Know before users do

Read a result

PASS, FAIL, ERROR

Build one

Step by step

Prove it

Four layers

Run it

Item or Health Board

Read more: Explainer

Start

Who this is for

Builders

Developers and configurators. You ship a self-test with every custom capability.

Runners

Client IT and support. You run self-tests and read the Health Board.

Everyone: modules 1, 2 and 3. Builders: also 4 and 5.

Read more: SELFTEST standard

Module 1

1. Why self-tests

Know before your users do.

1 · Why

Custom work can break quietly

Upgrades

A platform or plugin update changes behaviour.

Settings

A setting or permission changes.

Credentials

A key or password expires.

No error on screen. Users find it first, unless you test.

Read more: DEC-040

1 · Why

One click, one answer

You seeExample
VerdictFAIL
Which checkDocument found on the case
WhyCase 34157 has no document 452
What to doUse a listed document ID, or leave it blank

Read more: Explainer

1 · Why

Five principles

Read more: Core principles

Module 2

2. Read a result

Verdicts, checks, and where to look.

2 · Read

Three verdicts

PASS

It works.

FAIL

A check proved it broken.

ERROR

No conclusion. The test could not decide.

RUNNING shows while it runs. A PASS counts only when a Functional check passed.

Read more: SELFTEST-03, 07

2 · Read

The run has a verdict. Each check has a status.

PASSthe check is met
FAILthe check proved a fault
WARNnot allowed to do an extra look, or slow
SKIPPEDan earlier check failed
ERRORthe self-test engine broke

Read more: SELFTEST-06

2 · Read

Checks run in this order

set-up and data the capability the self-test

Read more: Check categories

2 · Read

Where the answer appears

Self-test item after a run: Result PASS, What happened: FirstAML Download Document works, 9 checks passed, 1 warning. What to do next: nothing to do, with the folder that holds the test PDF.
A PASS on the item

Result, What happened and Check that failed sit at the top of the item.

A PASS means no check failed and the outcome was proved.

Read more: SELFTEST-03, 07

2 · Read

A FAIL names the check and the fix

Self-test item: Result FAIL, Check that failed: Document found on the case, What to do next: use one of the document IDs listed in the check, or leave the field blank.
A deliberate FAIL

Check that failed and What to do next are plain words.

The download checks are SKIPPED. Nothing was downloaded.

Read more: SELFTEST-05

2 · Read

The Health Board shows every check

Self-test health board: FirstAML Download Document PASS, with the checks open, listing ten checks, each with its status, detail and time.
The Health Board with checks shown

One row per self-test. Show checks lists every check and its time.

Read more: SELFTEST-16

2 · Quick check

PASS, but “plugin installed” says WARN (HTTP 403). Broken?

Reveal the answer

We cannot say it is broken. An extra look was refused: WARN. If checking the result is refused: ERROR.

Read more: SELFTEST-06

Module 3

3. Run it and keep it running

For client IT and support.

3 · Run

Run a self-test

Self-test item ribbon with the Run Self-Test button next to Reassign and Delegate.
The item ribbon
  1. Create the Self-Test item. You are the owner.
  2. Leave inputs blank, or fill them.
  3. Press Run Self-Test.
  4. Reopen the item.

Only IT and support roles run self-tests. Their team must read the test matter, or the result is ERROR (slide 30).

Read more: SHA-001-26 · SELFTEST-23

3 · Run

Act on the answer

Self-test item fields: Run reference, Finished and Took.
The run reference is lower on the item. A check with WARN? Read its detail.

Read more: SELFTEST-05, 08

3 · Run

Run again from the Health Board

Self-test health board row: FirstAML Download Document PASS, finished 4 Oct 2026, took 6 s, writes test data, with Run again, Open last run and Show checks (10).
A Health Board row

Writes test data tells you this test changes data.

Read more: SELFTEST-16

3 · Run

When to run it again

After every change

Release, plugin upgrade, configuration reload.

In production?

It changes data. Fixture only, outside production, unless the client has approved it in writing.

Read more: SELFTEST-22

Module 4 · builders

4. Build one

The runbook, step by step.

4 · Build

The shape of a self-test

self-test step capability under test where people see it

Read more: Shape of a self-test

4 · Build

Names start with alt-test-

Typealt-test-<area>-entity-<capability>
Workflowalt-test-<area>-wf-<capability>
Inputs formalt-test-<area>-form-<capability>
Register fieldalt-test-shared-ff-latest-<capability>

A test that changes data sets dataChanging: true.

Read more: SELFTEST-17

4 · Build · step 0

Shared pieces, once per tenant

Base typealt-test-shared-entity-base
Result formalt-test-shared-form-selftest-result
Fixture[TEST] Self-Test Fixture
Registerone work item
BoardHealth Board on Tests

Set the base’s aspects before any child type exists.

Read more: SHA-001-26 step 0

4 · Build · step 1

Design the checks on paper first

Read more: SHA-001-26 step 1

4 · Build · step 2

Two scripts around the real action

No $model. text anywhere. Sharedo rewrites it on publish.

Read more: SHA-001-26 step 2

4 · Build

One result contract

{
  "schema": "alt.selftest.result/1",
  "verdict": "FAIL",
  "failedCheck": "document-found",
  "runRef": "ST-20261003105249-398033",
  "checks": [ {
    "id": "document-found",
    "title": "Document found",
    "category": "Contract",
    "status": "FAIL",
    "detail": "...", "ms": 0
  } ]
}
Shortened

Same JSON for every self-test. One board reads them all.

Read more: SELFTEST-04

4 · Build

Safe, honest checks

Prove it independently

Read the outcome back.

Nothing private

Fixed words. Raw errors go to the log.

Never stuck on RUNNING

Errors still write a full ERROR.

Every run is fresh

A known bug must not stay red.

Read more: SELFTEST-09..12

4 · Build · step 5

Put it on the tenant

1

Review first

Before publishing

2

Forms and type

[ ] in help text

3

Publish

Modeller

4

Add the button

Blade ribbon

5

Lock access

IT roles; check it

6

Force reload

Everything

Read more: SHA-001-26 step 5 · SELFTEST-21, 23

4 · Build · access

Give a team access

1

Team

Runners

2

Role

Every test type

3

Rule

Finds the team

4

Workflow

Adds the team

5

Test matter

Team reads it

Check: npm run selftest:access -- --tenant X. Fix: add --apply.

Then press the button as a real runner.

Read more: PRAC-008 · AILES-119 · AIMETH-023

4 · Build

Platform rules to know

API saveDraft only. Publish.
API create triggerMay not fire. Use a button.
Tasks open as a bladeUse the Blade ribbon.
SearchCannot see test items.
<Angle brackets>Stripped. Use [ ].

Read more: Pitfalls

Module 5 · builders

5. Test the test

A wrong verdict is worse than none.

5 · Prove

Four layers, each catches different faults

1 Harness

Wrong verdicts, leaks, crashes

2 Build

Placeholders, $model.

3 Live

Permissions, caches, compile

4 Review

Unhandled shapes, leak paths

Report each layer on its own. Never just “tested”.

Read more: SELFTEST-18..21

5 · Prove · layer 1

Layer 1: the harness

Read more: SHA-001-26 step 3

5 · Prove · layer 2

Layer 2: the build step

Read more: SELFTEST-19

5 · Prove · layer 3

Layer 3: the live check

Working setup

Must PASS.

Broken on purpose

Must FAIL, naming the expected check.

Record both run references. Then open the item and the board yourself.

Read more: SELFTEST-20

5 · Prove · layer 4

Layer 4: the review

Before publishing

First review, before any tenant.

On the final code

Review again after live fixes.

Every finding

Including the reviewer’s summary.

Read more: SELFTEST-21

5 · Quick check

Unit tests green, demo worked. Delivered?

Reveal the answer

No. Publish it. Run the live check: one PASS, one deliberate FAIL. Look at the item. Get an automated review of the latest code.

Read more: SELFTEST-20, 21

Close

Before you say “delivered”

1

Names and button

alt-test-, one button

2

Next steps

One per failing check

3

Harness

Every FAIL, leaks, throws

4

Live check

Published: PASS and FAIL

5

Board and review

Result shows, review done

Read more: Checklist

Novice

Question 1 of 10

A finished self-test shows ERROR. What does that mean?

A The capability is broken
B The self-test could not reach a conclusion
C The capability works, with a warning
D The test is still running
Novice

Question 2 of 10

A supplemental check (reading the plugin list) gets HTTP 403. What status should it show?

A FAIL
B ERROR
C WARN
D PASS
Novice

Question 3 of 10

How does a person start a self-test on its item?

A Press the Run Self-Test button
B It runs by itself when the item is created
C Publish the workflow again
D Open the Modeller
Expert

Question 4 of 10

A board reads a result that is just {"verdict": "PASS"} with no checks. What should it show?

A PASS
B PASS with a warning
C Nothing, and count it as PASS
D Not PASS: no proof, so it fails closed
Expert

Question 5 of 10

How must the functional check prove the outcome?

A Trust the action's success flag
B Read the outcome back and count only this run's artefact
C Check that any file is in the folder
D Ask the user to look
Expert

Question 6 of 10

The action fails with a server error the self-test does not recognise. Where does the raw text go?

A The workflow log; the item gets a fixed sentence and the run reference
B The item's What happened field
C The Health Board
D Nowhere; it is dropped
Expert

Question 7 of 10

Why does the standard make each run publish its result to a register item?

A To keep a backup
B Because the item is deleted after the run
C Search cannot list self-test items, so the board reads one item
D To send an email
Master

Question 8 of 10

Every second run FAILs on a known, tracked defect. What should the default inputs do?

A Nothing; red is honest
B Turn the check into a WARN
C Remove the check
D Fresh target per run, defect reproducible by a typed input and listed in knownIssues
Master

Question 9 of 10

You saved the workflow through the API, ran it, and saw the old behaviour. Why?

A The browser cache is stale
B An API save is a draft; publish it in the Modeller
C The button points to the wrong item
D The harness is wrong
Master

Question 10 of 10

Which statement about the four verification layers is right?

A The live check makes the others unnecessary
B Green unit tests are enough for review
C Each layer catches faults the others miss, so report them separately
D Only the automated review matters

Your results

Resources

Keep going