Files
redis-gui-foundation/docs/qa/test-strategy.md
Senior Frontend Engineer b6cbe5a47e docs(project): refresh baseline verification artifacts
Check in the PM product requirements, refreshed QA acceptance evidence, shared execution split plans, and current-phase status notes so the repo matches the current delivery baseline.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-03-31 10:15:39 +00:00

2.6 KiB

QA Test Strategy

Date: 2026-03-31 Owner: QA Engineer

Test Objectives

  • Validate Redis GUI V1 against explicit acceptance criteria, not against "it runs on my machine".
  • Cover both happy paths and failure paths for connection, browsing, editing, TTL, console, and destructive actions.
  • Keep release blocking conditions visible before packaging and launch week.

Test Layers

Layer Purpose Expected Automation Exit Signal
Unit Validate pure logic, parsing, serialization, and state transitions High Deterministic CI pass
Integration Validate Redis protocol handling, repository layer, seed setup, and persistence boundaries Medium Seeded Redis scenarios pass
UI smoke Validate launch, connect, browse, edit, TTL, console, dangerous-action confirmation Medium One repeatable smoke flow per OS passes
Regression Validate previously broken paths and high-risk areas before release Mixed No open critical regressions
Release readiness Validate artifact, install, uninstall, and basic recovery behavior Low to medium Checklist complete with evidence

Environments

  • Linux: current local environment available to QA, but the present session is headless and cannot capture a real Tauri window.
  • macOS: required for release acceptance, currently not provisioned in this repository.
  • Windows: required for release acceptance, currently not provisioned in this repository.

Test Data Strategy

  • Maintain one documented seed dataset for predictable keys, TTL, and value shapes.
  • Track Redis version used for QA evidence.
  • Ensure cleanup steps return the environment to a known state.

Evidence Standard

  • Every pass or fail must cite the command, artifact, or screenshot used.
  • "Blocked" is valid only when the missing prerequisite is named.
  • "Not run" is distinct from "Pass" and must remain visible in checklists.

Current Gaps On 2026-03-31

  • The highest-risk gap is still missing real-window desktop evidence for connect, browse, inspect, string save, TTL update, and command execution in a GUI-capable session.
  • pnpm run desktop:tauri:build:all still fails in the AppImage linuxdeploy stage, so the full Linux bundle path is not release-ready.
  • No validated macOS or Windows build, install, launch, or smoke evidence exists.
  • Linux installer install and uninstall checks are still absent even though .deb and .rpm artifacts are reproducible.
  • Docker-backed smoke reproducibility currently depends on direct fixture scripts; there is still no Dockerfile or compose asset to standardize the environment handoff.