mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-23 01:41:14 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- 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.
2.4 KiB
2.4 KiB
Phase 1: Input Data & Expected Results Completeness Analysis
Role: Professional Quality Assurance Engineer Goal: Assess whether the available input data is sufficient to build comprehensive test scenarios, and whether every input is paired with a quantifiable expected result. Constraints: Analysis only — no test specs yet.
Steps
- Read
_docs/01_solution/solution.md - Read
acceptance_criteria.md,restrictions.md - Read testing strategy from
solution.md(if present) - If
DOCUMENT_DIR/architecture.mdandDOCUMENT_DIR/system-flows.mdexist, read them for additional context on system interfaces and flows - Read
input_data/expected_results/results_report.mdand any referenced files ininput_data/expected_results/ - Analyze
input_data/contents against:- Coverage of acceptance criteria scenarios
- Coverage of restriction edge cases
- Coverage of testing strategy requirements
- Analyze
input_data/expected_results/results_report.mdcompleteness:- Every input data item has a corresponding expected result row in the mapping
- Expected results are quantifiable (contain numeric thresholds, exact values, patterns, or file references — not vague descriptions like "works correctly" or "returns result")
- Expected results specify a comparison method (exact match, tolerance range, pattern match, threshold) per the template
- Reference files in
input_data/expected_results/that are cited in the mapping actually exist and are valid
- Present input-to-expected-result pairing assessment:
| Input Data | Expected Result Provided? | Quantifiable? | Issue (if any) |
|---|---|---|---|
| [file/data] | Yes/No | Yes/No | [missing, vague, no tolerance, etc.] |
- Threshold: at least 75% coverage of scenarios AND every covered scenario has a quantifiable expected result (see
.cursor/rules/cursor-meta.mdcQuality Thresholds table) - If coverage is low, search the internet for supplementary data, assess quality with user, and if user agrees, add to
input_data/and updateinput_data/expected_results/results_report.md - If expected results are missing or not quantifiable, ask user to provide them before proceeding
Blocking
BLOCKING: Do NOT proceed to Phase 2 until the user confirms both input data coverage AND expected results completeness are sufficient.
No save action
Phase 1 does not write an artifact. Findings feed Phase 2.