azaion/gps-denied-onboard

Fork 0

mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-23 08:11:12 +00:00

Files

T

Oleksandr Bezdieniezhnykh 1f634c2604

ci/woodpecker/push/02-build-push Pipeline failed

Details

Update demo replay validation and testing documentation

- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests.
- Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps.
- Updated architectural documentation to include the new demo replay operator flow and its dependencies.
- Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation.
- Added new entries in the dependencies table for upcoming tasks related to the demo replay flow.

These changes improve clarity and usability for operators and developers working with the demo replay system.

2026-06-20 11:24:43 +03:00

2.5 KiB

Raw Blame History

Phase 2: Test Scenario Specification

Role: Professional Quality Assurance Engineer Goal: Produce detailed black-box test specifications covering blackbox, performance, resilience, security, and resource limit scenarios. Constraints: Spec only — no test code. Tests describe what the system should do given specific inputs, not how the system is built.

Steps

Based on all acquired data, acceptance_criteria, and restrictions, form detailed test scenarios:

Define test environment using .cursor/skills/plan/templates/test-environment.md as structure
Define test data management using .cursor/skills/plan/templates/test-data.md as structure
Write blackbox test scenarios (positive + negative) using .cursor/skills/plan/templates/blackbox-tests.md as structure
Write performance test scenarios using .cursor/skills/plan/templates/performance-tests.md as structure
Write resilience test scenarios using .cursor/skills/plan/templates/resilience-tests.md as structure
Write security test scenarios using .cursor/skills/plan/templates/security-tests.md as structure
Write resource limit test scenarios using .cursor/skills/plan/templates/resource-limit-tests.md as structure
Build traceability matrix using .cursor/skills/plan/templates/traceability-matrix.md as structure

Self-verification

Every acceptance criterion is covered by at least one test scenario
Every restriction is verified by at least one test scenario
Every test scenario has a quantifiable expected result from input_data/expected_results/results_report.md
Expected results use comparison methods from .cursor/skills/test-spec/templates/expected-results.md
Positive and negative scenarios are balanced
Consumer app has no direct access to system internals
Test environment matches project constraints (see phases/hardware-assessment.md, which runs before Phase 4)
External dependencies have mock/stub services defined
Traceability matrix has no uncovered AC or restrictions

Save action

Write all files under TESTS_OUTPUT_DIR:

environment.md
test-data.md
blackbox-tests.md
performance-tests.md
resilience-tests.md
security-tests.md
resource-limit-tests.md
traceability-matrix.md

Blocking

BLOCKING: Present test coverage summary (from traceability-matrix.md) to user. Do NOT proceed to Phase 3 until confirmed.

Capture any new questions, findings, or insights that arise during test specification — these feed forward into downstream skills (plan, refactor, etc.).

2.5 KiB Raw Blame History