NIZU Live Testing — Best practices

These recommendations help your team get reliable, repeatable results from NIZU Live Testing.

Set up

• One product per project. Bind every tested project to a product before running cycles, so defects and regressions are attributed correctly and the regression chart is meaningful.
• Always keep a smoke suite. Give each project a smoke suite that holds the few critical checks that must pass on every release.
• Grant permissions deliberately. Only give "Execute test cases" and "File defects" to people who actually test, and reserve "Sign off runs" for leads. Keep the app hidden from teams that do not need it.

Write good test cases

• One clear outcome per case. A case should test a single behaviour with an unambiguous expected result.
• Use numbered steps. Break the case into small, ordered steps so any tester can follow it the same way. Add a screenshot to a step when the UI is not obvious.
• Mark mandatory cases. Flag the cases that must be executed before a run can be approved, so critical paths are never skipped.
• Keep cases reusable. Write cases so they can be run again in the next cycle without editing.
• Link a case to its developer task. When a case covers a specific piece of work, link it to that developer's task. If the case later fails or regresses, the bug is assigned straight to the responsible developer — no triage needed.

Run cycles consistently

• Claim before you execute. Claiming a case avoids two testers running the same one and feeds the live race.
• Tick steps as you go. Use the step checkboxes during execution so you do not lose your place and others can see progress.
• Run a full cycle per build. Start a fresh cycle for each release or significant change rather than reusing an old one.

Report failures well

• Describe the actual result clearly. The "actual" field is the bug report — say exactly what happened, not just "it failed".
• Always attach evidence. A screenshot or short screen recording turns a vague report into a fixable one.
• Set an honest severity. Reserve blocker and critical for failures that truly stop release; over-using them hides the real priorities.
• Let the task flow do its job. Each failure opens a linked developer task automatically — keep the defect and its task moving through their statuses together.

Use the data

• Watch the regression chart. A rising trend of regressions is an early warning that quality is slipping; act on it before it grows.
• Confirm or dismiss regressions. Move each detected regression through its lifecycle so the count reflects reality and false alarms are dismissed.
• Watch the cycle timing. Use the per-cycle duration and the average testing time to plan releases and spot cycles that drag — a long duration with low progress usually means testers are blocked.
• Make the race a team ritual, not a weapon. The live race is there to make a testing push fun and visible — use it to celebrate progress, not to rank people.