Compare commits
9 Commits
v6.0.0-alp
...
docs/updat
| Author | SHA1 | Date | |
|---|---|---|---|
|
81c2776f75 | ||
|
|
b4508c6c73 | ||
|
|
3883949b57 | ||
|
|
860341534c | ||
|
|
cf0a52189e | ||
|
|
eb999e8c82 | ||
|
|
b97376f8fa | ||
|
|
83b09212ca | ||
|
|
bd79dd9752 |
116
README.md
116
README.md
@@ -5,20 +5,74 @@
|
||||
[](https://nodejs.org)
|
||||
[](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
**The Universal Human-AI Collaboration Platform**
|
||||
|
||||
IMPORTANT NOTE: ALPHA is potentially an unstable release that could drastically change in many ways. While we hope that is not the case, know that it could - your using and testing it during this time though is much appreciated. Please help us out by filing issues or reaching out in Discord to discuss.
|
||||
|
||||
IMPORTANT NOTE 2: ALPHA is not complete - there are still many small and big features, polish, doc improvements, and more agents and workflows coming ahead of the beta release!
|
||||
|
||||
IMPORTANT NOTE 3: ALPHA Web Bundles and Agents are not fully working yet - so you will need to use a good quality IDE to test many of the features, especially with the BMad Method module. BUT - the new agent builder and stand alone agent feature can work great with weaker models - this will still evolve over the coming weeks.
|
||||
|
||||
BMad-CORE (Collaboration Optimized Reflection Engine) is a framework that brings out the best in you through AI agents designed to enhance human thinking rather than replace it. Unlike traditional AI tools that do the work for you, BMad-CORE's specialized agents guide you through the facilitation of optimized collaborative reflective workflows to unlock your full potential across any domain. It is this magic that powers the BMad Method, which is just one of the many modules that exist or are coming soon.
|
||||
|
||||
**[Subscribe to BMadCode on YouTube](https://www.youtube.com/@BMadCode?sub_confirmation=1)** and **[Join our amazing, active Discord Community](https://discord.gg/gk8jAdXWmj)**
|
||||
|
||||
⭐ **If you find this project helpful or useful, please give it a star in the upper right-hand corner!** It helps others discover BMad-CORE and you will be notified of updates!
|
||||
|
||||
## The Universal Human-AI Collaboration Platform
|
||||
|
||||
📋 **[View v6 Alpha Open Items & Roadmap](./v6-open-items.md)** - Track what's being worked on and what's coming next!
|
||||
|
||||
### ⚠️ Important Alpha Notes
|
||||
|
||||
**Note 0 - Frequent Updates:** Updates to the branch will be frequent. When pulling new updates, it's best to delete your node_modules folder and run `npm install` to ensure you have the latest package dependencies.
|
||||
|
||||
**Note 1 - Alpha Stability:** ALPHA is potentially an unstable release that could drastically change. While we hope that isn't the case, your testing during this time is much appreciated. Please help us out by filing issues or reaching out in Discord to discuss.
|
||||
|
||||
**Note 2 - Work in Progress:** ALPHA is not complete - there are still many small and big features, polish, doc improvements, and more agents and workflows coming ahead of the beta release!
|
||||
|
||||
**Note 3 - IDE Required:** ALPHA Web Bundles and Agents are not fully working yet - you will need to use a good quality IDE to test many features, especially with the BMad Method module. However, the new agent builder and standalone agent feature can work great with weaker models - this will still evolve over the coming weeks.
|
||||
|
||||
**Note 4 - Contributing:** If you would like to contribute a PR, make sure you are creating your PR against the Alpha Branch and not Main.
|
||||
|
||||
## Alpha Installation and Testing
|
||||
|
||||
**Prerequisites**: [Node.js](https://nodejs.org) v20+ required
|
||||
|
||||
### Option A
|
||||
|
||||
Thank you Lum for the suggestion - here is a one-shot instruction to clone just the alpha branch and get started:
|
||||
|
||||
`git clone --branch v6-alpha --single-branch https://github.com/bmad-code-org/BMAD-METHOD` and then cd into this directory and run `npm install`.
|
||||
|
||||
### Option B
|
||||
|
||||
Here are the more detailed step-by-step instructions:
|
||||
|
||||
Clone the repo with either:
|
||||
|
||||
- `gh repo clone bmad-code-org/BMAD-METHOD`
|
||||
- `git clone https://github.com/bmad-code-org/BMAD-METHOD.git`
|
||||
- `git@github.com:bmad-code-org/BMAD-METHOD.git`
|
||||
and then cd into the BMAD-METHOD folder.
|
||||
|
||||
You will then need to change to the branch as that will have cloned main, so type:
|
||||
- `git checkout v6-alpha`
|
||||
- type `git status` and you should see:
|
||||
`On branch v6-alpha. Your branch is up to date with 'origin/v6-alpha'.`
|
||||
|
||||
### Node Modules install
|
||||
|
||||
Now you must install the node_modules with `npm install` - once complete, you should see you have a `node_modules` folder at the root of your project. (BMAD-METHOD/node_modules)
|
||||
|
||||
### Install to your new or existing project folder
|
||||
|
||||
Now you can run `npm run install:bmad` and follow the installer questions.
|
||||
|
||||
NOTE: One of the first questions will ask for a destination - do not accept the default, you want to enter the full path to a new or existing folder of where your project is or will be. If you choose a net new folder, you will have to confirm you want the installer to create the directory for you.
|
||||
|
||||
The Core Module will always be installed. The default initial module selection will be BMM for all the core BMad Method functionality and flow from brainstorming through software development.
|
||||
|
||||
**Note on installation:** All installs now go to a single folder called `bmad` instead of multiple folders. When you install a module, you may still see folders other than the one you selected in the destination/bmad folder.
|
||||
|
||||
This is intentional and not a bug - it will copy over to those other folders only the minimum that is needed because it is shared across the modules. For example, during Alpha to test this feature, BMM relies on the brainstorming feature of the CIS and some items from CORE - so even if you only select BMM, you will still see bmad/core and bmad/cis along with bmad/bmm.
|
||||
|
||||
## What is the new BMad Core
|
||||
|
||||
BMad-CORE (Collaboration Optimized Reflection Engine) is a framework that brings out the best in you through AI agents designed to enhance human thinking rather than replace it.
|
||||
|
||||
Unlike traditional AI tools that do the work for you, BMad-CORE's specialized agents guide you through the facilitation of optimized collaborative reflective workflows to unlock your full potential across any domain. This magic powers the BMad Method, which is just one of the many modules that exist or are coming soon.
|
||||
|
||||
## What Makes BMad-Core Different
|
||||
|
||||
**Traditional AI**: Does the thinking for you, providing average, bland answers and solutions
|
||||
@@ -54,31 +108,33 @@ BMad-CORE works in ANY domain through specialized modules (previously called exp
|
||||
- **BMad BoMB (bmb)**: The BMad Builder is your Custom Agent, Workflow, and Module authoring tool - it's now easier than ever to customize existing modules or create whatever you can imagine as a standalone module.
|
||||
- **Creative Intelligence Suite (cis)**: Unlock innovation, problem-solving, and creative thinking! Brainstorming that was part of the BMad Method in the past is now part of this standalone module along with other workflows. The power of BMad modules still allows modules to borrow from each other - so the CIS, while standalone, also powers the brainstorming abilities for certain agents within the BMad Method!
|
||||
|
||||
## Alpha Installation and Testing
|
||||
|
||||
**Prerequisites**: [Node.js](https://nodejs.org) v20+ required
|
||||
|
||||
Clone this repo ALPHA BRANCH to a folder. From the root of the folder, run `npm run install:bmad` and follow the installer questions.
|
||||
|
||||
The Core Module will always be installed. The default initial module selection will be BMM for all the core BMad Method functionality and flow from brainstorming through software development.
|
||||
|
||||
Note on installation: All installs now go to a single folder called `bmad` instead of multiple folders. When you install a module, you may still see folders other than the one you selected in the destination/bmad folder. This is intentional and not a bug - it will copy over to those other folders only the minimum that is needed because it is shared across the modules. For example, for now during Alpha to test this feature - BMM relies on the brainstorming feature of the CIS and some items from CORE - so this is why even if you only select BMM, you will still see bmad/core and bmad/cis along with bmad/bmm.
|
||||
|
||||
## What's New in V6-ALPHA
|
||||
|
||||
Stability, customizability, installation Q&A, massive prompt improvements.
|
||||
|
||||
Everything has been rewritten from the ground up with best practices and advances learned over previous versions, standardizing on prompt format techniques. There is a lot more core usage of XML or XML-type tags within markdown, with many conventions and standards that drastically increase adherence of the agents.
|
||||
Everything has been rewritten from the ground up with best practices and advances learned over previous versions, standardizing on prompt format techniques. There is much more core usage of XML or XML-type tags within markdown, with many conventions and standards that drastically increase agent adherence.
|
||||
|
||||
Customizability is a key theme of this new version. All agents are now customizable by modifying a file under the installation bmad/\_cfg/agents. Every agent installed will generate an agent file that you can customize. The nice thing about this is when agents change or update in future versions, your customizations in these sidecar files will never be lost! You can change the name, their personas, how they talk, what they call you, and most exciting - what language they communicate in!
|
||||
**Customizability** is a key theme of this new version. All agents are now customizable by modifying a file under the installation bmad/\_cfg/agents. Every agent installed will generate an agent file that you can customize.
|
||||
|
||||
The BMad installer is 100% new from the ground up. First, along the way you will add your name (what the agents will call you and what you will author documents as), what language you want the agents to talk to you in, and every module you select will have its own set of questions to customize the experience. Also, when you install, a consolidated agent party is created so now when you use party-mode in the IDE, it is super efficient for the agent running the party to simulate all installed agents. Post alpha release, this will manifest itself in many interesting ways in time for beta - but for now, have fun with party mode and epic sprint retrospectives!
|
||||
The nice thing about this is when agents change or update in future versions, your customizations in these sidecar files will never be lost! You can change the name, their personas, how they talk, what they call you, and most exciting - what language they communicate in!
|
||||
|
||||
The **BMad installer** is 100% new from the ground up. Along the way you will add:
|
||||
|
||||
- Your name (what the agents will call you and how you'll author documents)
|
||||
- What language you want the agents to communicate in
|
||||
- Module-specific customization options
|
||||
|
||||
When you install, a consolidated agent party is created so now when you use party-mode in the IDE, it is super efficient for the agent running the party to simulate all installed agents. Post alpha release, this will manifest itself in many interesting ways in time for beta - but for now, have fun with party mode and epic sprint retrospectives!
|
||||
|
||||
Speaking of installation - everything will now install to a single core bmad folder. No more separate root folders for every module! Instead, all will be contained within bmad/.
|
||||
|
||||
All IDE selections now support the option to add in special install functionality per module. As an example with the alpha release, if you select the BMad Method and Claude Code, you will have an option to install pre-created Claude sub-agents. Not only do they get installed, but certain workflows will have injected into their instructions key indicators to the agent when to activate the sub-agents, removing some non-determinism. The sub-agent experience is still undergoing some work, so install them if you choose, and remove them if they become a pain.
|
||||
All IDE selections now support the option to add special install functionality per module.
|
||||
|
||||
Also, when you read about the BoMB below, it will link to more information about various features in this new evolution of the BMad Code - one of the exciting ones is the new agent types - there are 3 now! The most exciting, with more info coming soon, are the new standalone tiny agents that you can easily generate and deploy free from any module - specialized for your own exact needs.
|
||||
For example, with the alpha release, if you select the BMad Method and Claude Code, you will have an option to install pre-created Claude sub-agents. Not only do they get installed, but certain workflows will have injected into their instructions key indicators to the agent when to activate the sub-agents, removing some non-determinism.
|
||||
|
||||
The sub-agent experience is still undergoing some work, so install them if you choose, and remove them if they become a pain.
|
||||
|
||||
When you read about the BoMB below, it will link to more information about various features in this new evolution of BMad Code. One of the exciting features is the new agent types - there are 3 now! The most exciting are the new standalone tiny agents that you can easily generate and deploy free from any module - specialized for your exact needs.
|
||||
|
||||
### BMad Method
|
||||
|
||||
@@ -90,7 +146,7 @@ To test and experience this now, here is the new main flow for BMM v6 alpha:
|
||||
|
||||
(Docs will be all linked in soon with new user guide and workflow diagrams coming this week)
|
||||
|
||||
NOTE: Game Development expansion packs are all being rolled into the official BNad Method module - along with any more game engine platforms being added. Additionally game development planning for the GDD is not only scale adpative, but also adapts to the type of game you are making - so you can plan all that is needed for your dream game!
|
||||
**NOTE:** Game Development expansion packs are all being rolled into the official BMad Method module - along with any more game engine platforms being added. Additionally, game development planning for the GDD is not only scale adaptive, but also adapts to the type of game you are making - so you can plan all that is needed for your dream game!
|
||||
|
||||
#### **PHASE 1 - Analysis**
|
||||
|
||||
@@ -124,7 +180,9 @@ NOTE: Game Development expansion packs are all being rolled into the official BN
|
||||
|
||||
**Architect or Game Architect:**
|
||||
|
||||
Just like the scale-adjusted planning, architecture is the same. No more document sharding though!! Now in the IDE you create an architecture that adapts to the type of project you are working on - based on the inputs from your PRD, it will adapt the sections it includes to your project type. No longer is the architecture biased just towards full stack or back-end APIs. There are many more options now, from embedded hardware to mobile to many other options - with many more coming with beta.
|
||||
Just like the scale-adjusted planning, architecture is the same. No more document sharding though!
|
||||
|
||||
Now in the IDE you create an architecture that adapts to the type of project you are working on - based on the inputs from your PRD, it will adapt the sections it includes to your project type. No longer is the architecture biased just towards full stack or back-end APIs. There are many more options now, from embedded hardware to mobile to many other options - with many more coming with beta.
|
||||
|
||||
- `solution-architecture`
|
||||
|
||||
@@ -134,7 +192,7 @@ Once the full architecture is complete, you can still use the PO to run the chec
|
||||
|
||||
- `tech-spec`
|
||||
|
||||
The tech spec pulls all technical information from all planning thus far, along with any further research needed from the web to produce an **Epic Tech Spec** - each epic will have one. This is going to make the SM even more capable of finding the info it needs for each story when we get to phase 4!!
|
||||
The tech spec pulls all technical information from all planning thus far, along with any further research needed from the web to produce an **Epic Tech Spec** - each epic will have one. This is going to make the SM even more capable of finding the info it needs for each story when we get to phase 4!
|
||||
|
||||
---
|
||||
|
||||
@@ -149,7 +207,7 @@ Before the dev starts, the SM will:
|
||||
1. `create-story`
|
||||
2. `story-context` _(NEW!)_
|
||||
|
||||
**Story-context** is a game-changing new feature beyond what we had with create-story in the past. Create-story still pulls in all the info it needs from the tech-spec and elsewhere as needed (including previously completed stories), but the generation of the new story-context takes it up a whole new level.
|
||||
**Story-context** is a game-changing new feature beyond what we had with create-story in the past. Create-story still pulls in all the info it needs from the tech-spec and elsewhere as needed (including previously completed stories), but the generation of the new story-context takes it to a whole new level.
|
||||
|
||||
This real-time prep means no more generic devLoadAlways list of story files. During the alpha phase, we will be tuning what goes into this context, but this is going to supercharge and specialize your dev to the story at hand!
|
||||
|
||||
|
||||
29
package-lock.json
generated
29
package-lock.json
generated
@@ -9,8 +9,7 @@
|
||||
"version": "6.0.0-alpha.0",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@kayvan/markdown-tree-parser": "^1.5.0",
|
||||
"bmad-method": "^4.30.3",
|
||||
"@kayvan/markdown-tree-parser": "^1.6.1",
|
||||
"boxen": "^5.1.2",
|
||||
"chalk": "^4.1.2",
|
||||
"cli-table3": "^0.6.5",
|
||||
@@ -2397,32 +2396,6 @@
|
||||
"readable-stream": "^3.4.0"
|
||||
}
|
||||
},
|
||||
"node_modules/bmad-method": {
|
||||
"version": "4.40.0",
|
||||
"resolved": "https://registry.npmjs.org/bmad-method/-/bmad-method-4.40.0.tgz",
|
||||
"integrity": "sha512-FE+5GprBOf2x3AIpeH8iVJF3/JXtzTWbPSDTwUS3Y0Dq0IaW82FxwyiFykTRxPW/oDEK6YCyNkU4EO2Lq8E89A==",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@kayvan/markdown-tree-parser": "^1.5.0",
|
||||
"bmad-method": "^4.30.3",
|
||||
"chalk": "^4.1.2",
|
||||
"commander": "^14.0.0",
|
||||
"fs-extra": "^11.3.0",
|
||||
"glob": "^11.0.3",
|
||||
"ignore": "^7.0.5",
|
||||
"inquirer": "^8.2.6",
|
||||
"js-yaml": "^4.1.0",
|
||||
"ora": "^5.4.1",
|
||||
"semver": "^7.6.3"
|
||||
},
|
||||
"bin": {
|
||||
"bmad": "tools/bmad-npx-wrapper.js",
|
||||
"bmad-method": "tools/bmad-npx-wrapper.js"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=20.10.0"
|
||||
}
|
||||
},
|
||||
"node_modules/boolbase": {
|
||||
"version": "1.0.0",
|
||||
"resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz",
|
||||
|
||||
@@ -54,8 +54,7 @@
|
||||
]
|
||||
},
|
||||
"dependencies": {
|
||||
"@kayvan/markdown-tree-parser": "^1.5.0",
|
||||
"bmad-method": "^4.30.3",
|
||||
"@kayvan/markdown-tree-parser": "^1.6.1",
|
||||
"boxen": "^5.1.2",
|
||||
"chalk": "^4.1.2",
|
||||
"cli-table3": "^0.6.5",
|
||||
|
||||
@@ -17,15 +17,14 @@
|
||||
</critical-actions>
|
||||
<cmds>
|
||||
<c cmd="*help">Show numbered cmd list</c>
|
||||
<c cmd="*init-test-framework" exec="{project-root}/bmad/bmm/testarch/framework.md">Initialize production-ready test framework architecture</c>
|
||||
<c cmd="*framework" exec="{project-root}/bmad/bmm/testarch/framework.md">Initialize production-ready test framework architecture</c>
|
||||
<c cmd="*atdd" exec="{project-root}/bmad/bmm/testarch/atdd.md">Generate E2E tests first, before starting implementation</c>
|
||||
<c cmd="*create-automated-tests" exec="{project-root}/bmad/bmm/testarch/automate.md">Generate comprehensive test automation</c>
|
||||
<c cmd="*risk-profile" exec="{project-root}/bmad/bmm/testarch/risk-profile.md">Generate risk assessment matrix</c>
|
||||
<c cmd="*automate" exec="{project-root}/bmad/bmm/testarch/automate.md">Generate comprehensive test automation</c>
|
||||
<c cmd="*test-design" exec="{project-root}/bmad/bmm/testarch/test-design.md">Create comprehensive test scenarios</c>
|
||||
<c cmd="*req-to-bdd" exec="{project-root}/bmad/bmm/testarch/trace-requirements.md">Map requirements to tests Given-When-Then BDD format</c>
|
||||
<c cmd="*trace" exec="{project-root}/bmad/bmm/testarch/trace-requirements.md">Map requirements to tests Given-When-Then BDD format</c>
|
||||
<c cmd="*nfr-assess" exec="{project-root}/bmad/bmm/testarch/nfr-assess.md">Validate non-functional requirements</c>
|
||||
<c cmd="*gate" exec="{project-root}/bmad/bmm/testarch/tea-gate.md">Write/update quality gate decision assessment</c>
|
||||
<c cmd="*review-gate" exec="{project-root}/bmad/bmm/tasks/review-story.md">Generate a Risk Aware Results with gate file</c>
|
||||
<c cmd="*ci" exec="{project-root}/bmad/bmm/testarch/ci.md">Scaffold CI/CD quality pipeline</c>
|
||||
<c cmd="*gate" exec="{project-root}/bmad/bmm/testarch/gate.md">Write/update quality gate decision assessment</c>
|
||||
<c cmd="*exit">Goodbye+exit persona</c>
|
||||
</cmds>
|
||||
</agent>
|
||||
|
||||
155
src/modules/bmm/testarch/README.md
Normal file
155
src/modules/bmm/testarch/README.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
last-redoc-date: 2025-09-30
|
||||
---
|
||||
|
||||
# Test Architect (TEA) Agent Guide
|
||||
|
||||
## Overview
|
||||
|
||||
- **Persona:** Murat, Master Test Architect & Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.
|
||||
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project level and compliance demands.
|
||||
- **Use When:** Project level ≥2, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required.
|
||||
|
||||
## Prerequisites & Setup
|
||||
|
||||
1. Run the core planning workflows first:
|
||||
- Analyst `*product-brief`
|
||||
- Product Manager `*plan-project`
|
||||
- Architect `*solution-architecture`
|
||||
2. Confirm `bmad/bmm/config.yaml` defines `project_name`, `output_folder`, `dev_story_location`, and language settings.
|
||||
3. Ensure a test harness exists; if not, schedule `*framework` before development.
|
||||
4. Skim supporting references under `./testarch/`:
|
||||
- `tea-knowledge.md`
|
||||
- `test-levels-framework.md`
|
||||
- `test-priorities-matrix.md`
|
||||
|
||||
## High-Level Cheat Sheets
|
||||
|
||||
### Greenfield Feature Launch (Level 2)
|
||||
|
||||
| Phase | Test Architect | Dev / Team | Outputs |
|
||||
| ------------------ | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| Setup | - | Analyst `*product-brief`, PM `*plan-project`, Architect `*solution-architecture` | `{output_folder}/product-brief*.md`, `PRD.md`, `epics.md`, `solution-architecture.md` |
|
||||
| Pre-Implementation | Run `*framework` (if harness missing), `*ci`, and `*test-design` | Review risk/design/CI guidance, align backlog | Test scaffold, CI pipeline, risk & coverage strategy |
|
||||
| Story Prep | - | Scrum Master `*create-story`, `*story-context` | Story markdown + context XML |
|
||||
| Implementation | (Optional) Trigger `*atdd` before dev to supply failing tests + checklist | Implement story guided by ATDD checklist | Failing acceptance tests + implementation checklist |
|
||||
| Post-Dev | Execute `*automate`, re-run `*trace` | Address recommendations, update code/tests | Regression specs, refreshed coverage matrix |
|
||||
| Release | Run `*gate` | Confirm Definition of Done, share release notes | Gate YAML + release summary (owners, waivers) |
|
||||
|
||||
<details>
|
||||
<summary>Execution Notes</summary>
|
||||
|
||||
- Run `*framework` only once per repo or when modern harness support is missing.
|
||||
- `*framework` followed by `*ci` establishes install + pipeline; `*test-design` then handles risk scoring, mitigations, and scenario planning in one pass.
|
||||
- Use `*atdd` before coding when the team can adopt ATDD; share its checklist with the dev agent.
|
||||
- Post-implementation, keep `*trace` current, expand coverage with `*automate`, and finish with `*gate`.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
|
||||
|
||||
1. **Planning:** Analyst runs `*product-brief`; PM executes `*plan-project` to produce PRD and epics; Architect completes `*solution-architecture` for the new module.
|
||||
2. **Setup:** TEA checks harness via `*framework`, configures `*ci`, and runs `*test-design` to capture risk/coverage plans.
|
||||
3. **Story Prep:** Scrum Master generates the story via `*create-story`; PO validates using `*assess-project-ready`.
|
||||
4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
|
||||
5. **Post-Dev & Release:** TEA runs `*automate`, re-runs `*trace`, and finishes with `*gate` to document the decision.
|
||||
|
||||
</details>
|
||||
|
||||
### Brownfield Feature Enhancement (Level 2–3)
|
||||
|
||||
| Phase | Test Architect | Dev / Team | Outputs |
|
||||
| ----------------- | ------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| Refresh Context | - | Analyst/PM/Architect rerun planning workflows | Updated planning artifacts in `{output_folder}` |
|
||||
| Baseline Coverage | Run `*trace` to inventory existing tests | Review matrix, flag hotspots | Coverage matrix + initial gate snippet |
|
||||
| Risk Targeting | Run `*test-design` | Align remediation/backlog priorities | Brownfield risk memo + scenario matrix |
|
||||
| Story Prep | - | Scrum Master `*create-story` | Updated story markdown |
|
||||
| Implementation | (Optional) Run `*atdd` before dev | Implement story, referencing checklist/tests | Failing acceptance tests + implementation checklist |
|
||||
| Post-Dev | Apply `*automate`, re-run `*trace`, trigger `*nfr-assess` if needed | Resolve gaps, update docs/tests | Regression specs, refreshed coverage matrix, NFR report |
|
||||
| Release | Run `*gate` | Product Owner `*assess-project-ready`, share release notes | Gate YAML + release summary |
|
||||
|
||||
<details>
|
||||
<summary>Execution Notes</summary>
|
||||
|
||||
- Lead with `*trace` so remediation plans target true coverage gaps. Ensure `*framework` and `*ci` are in place early in the engagement; if the brownfield lacks them, run those setup steps immediately after refreshing context.
|
||||
- `*test-design` should highlight regression hotspots, mitigations, and P0 scenarios.
|
||||
- Use `*atdd` when stories benefit from ATDD; otherwise proceed to implementation and rely on post-dev automation.
|
||||
- After development, expand coverage with `*automate`, re-run `*trace`, and close with `*gate`. Run `*nfr-assess` now if non-functional risks weren't addressed earlier.
|
||||
- Product Owner `*assess-project-ready` confirms the team has artifacts before handoff or release.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
|
||||
|
||||
1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*plan-project` to update PRD, analysis, and `epics.md`; Architect triggers `*solution-architecture` capturing legacy payment flows.
|
||||
2. **Baseline Coverage:** TEA executes `*trace` to record current coverage in `docs/qa/assessments/atlas-payment-trace.md`.
|
||||
3. **Risk & Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
|
||||
4. **Story Prep:** Scrum Master generates `stories/story-1.1.md` via `*create-story`, automatically pulling updated context.
|
||||
5. **ATDD First:** TEA runs `*atdd`, producing failing Playwright specs under `tests/e2e/payments/` plus an implementation checklist.
|
||||
6. **Implementation:** Dev pairs with the checklist/tests to deliver the story.
|
||||
7. **Post-Implementation:** TEA applies `*automate`, re-runs `*trace`, performs `*nfr-assess` to validate SLAs, and closes with `*gate` marking PASS with follow-ups.
|
||||
|
||||
</details>
|
||||
|
||||
### Enterprise / Compliance Program (Level 4)
|
||||
|
||||
| Phase | Test Architect | Dev / Team | Outputs |
|
||||
| ------------------- | ------------------------------------------------ | ---------------------------------------------- | --------------------------------------------------------- |
|
||||
| Strategic Planning | - | Analyst/PM/Architect standard workflows | Enterprise-grade PRD, epics, architecture |
|
||||
| Quality Planning | Run `*framework`, `*test-design`, `*nfr-assess` | Review guidance, align compliance requirements | Harness scaffold, risk + coverage plan, NFR documentation |
|
||||
| Pipeline Enablement | Configure `*ci` | Coordinate secrets, pipeline approvals | `.github/workflows/test.yml`, helper scripts |
|
||||
| Execution | Enforce `*atdd`, `*automate`, `*trace` per story | Implement stories, resolve TEA findings | Tests, fixtures, coverage matrices |
|
||||
| Release | Run `*gate` | Capture sign-offs, archive artifacts | Updated assessments, gate YAML, audit trail |
|
||||
|
||||
<details>
|
||||
<summary>Execution Notes</summary>
|
||||
|
||||
- Use `*atdd` for every story when feasible so acceptance tests lead implementation in regulated environments.
|
||||
- `*ci` scaffolds selective testing scripts, burn-in jobs, caching, and notifications for long-running suites.
|
||||
- Prior to release, rerun coverage (`*trace`, `*automate`) and formalize the decision in `*gate`; store everything for audits. Call `*nfr-assess` here if compliance/performance requirements weren't captured during planning.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Worked Example – “Helios Ledger” Enterprise Release</summary>
|
||||
|
||||
1. **Strategic Planning:** Analyst/PM/Architect complete PRD, epics, and architecture using the standard workflows.
|
||||
2. **Quality Planning:** TEA runs `*framework`, `*test-design`, and `*nfr-assess` to establish mitigations, coverage, and NFR targets.
|
||||
3. **Pipeline Setup:** TEA configures CI via `*ci` with selective execution scripts.
|
||||
4. **Execution:** For each story, TEA enforces `*atdd`, `*automate`, and `*trace`; Dev teams iterate on the findings.
|
||||
5. **Release:** TEA re-checks coverage and logs the final gate decision via `*gate`, archiving artifacts for compliance.
|
||||
|
||||
</details>
|
||||
|
||||
## Command Catalog
|
||||
|
||||
| Command | Task File | Primary Outputs | Notes |
|
||||
| -------------- | -------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
|
||||
| `*framework` | `testarch/framework.md` | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs | Use when no production-ready harness exists |
|
||||
| `*atdd` | `testarch/atdd.md` | Failing Acceptance-Test Driven Development, implementation checklist | Requires approved story + harness |
|
||||
| `*automate` | `testarch/automate.md` | Prioritized specs, fixtures, README/script updates, DoD summary | Avoid duplicate coverage (see priority matrix) |
|
||||
| `*ci` | `testarch/ci.md` | CI workflow, selective test scripts, secrets checklist | Platform-aware (GitHub Actions default) |
|
||||
| `*test-design` | `testarch/test-design.md` | Combined risk assessment, mitigation plan, and coverage strategy | Handles risk scoring and test design in one pass |
|
||||
| `*trace` | `testarch/trace-requirements.md` | Coverage matrix, recommendations, gate snippet | Requires access to story/tests repositories |
|
||||
| `*nfr-assess` | `testarch/nfr-assess.md` | NFR assessment report with actions | Focus on security/performance/reliability |
|
||||
| `*gate` | `testarch/gate.md` | Gate YAML + summary (PASS/CONCERNS/FAIL/WAIVED) | Deterministic decision rules + rationale |
|
||||
|
||||
<details>
|
||||
<summary>Command Guidance & Context Loading</summary>
|
||||
|
||||
- Each task reads one row from `tea-commands.csv` via `command_key`, expanding pipe-delimited (`|`) values into checklists.
|
||||
- Keep CSV rows lightweight; place in-depth heuristics in `tea-knowledge.md` and reference via `knowledge_tags`.
|
||||
- If the CSV grows substantially, consider splitting into scoped registries (e.g., planning vs execution) or upgrading to Markdown tables for humans.
|
||||
- `tea-knowledge.md` encapsulates Murat’s philosophy—update both CSV and knowledge file together to avoid drift.
|
||||
|
||||
</details>
|
||||
|
||||
## Appendix
|
||||
|
||||
- **Supporting Knowledge:**
|
||||
- `tea-knowledge.md` – Murat’s testing philosophy, heuristics, and risk scales.
|
||||
- `test-levels-framework.md` – Decision matrix for unit/integration/E2E selection.
|
||||
- `test-priorities-matrix.md` – Priority (P0–P3) criteria and target coverage percentages.
|
||||
s
|
||||
@@ -1,38 +0,0 @@
|
||||
<!-- Powered by BMAD-CORE™ -->
|
||||
|
||||
# Risk Profile v2.0 (Slim)
|
||||
|
||||
```xml
|
||||
<task id="bmad/bmm/testarch/risk-profile" name="Risk Profile">
|
||||
<llm critical="true">
|
||||
<i>Set command_key="*risk-profile"</i>
|
||||
<i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the row where command equals command_key</i>
|
||||
<i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md focusing on risk-model guidance</i>
|
||||
<i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as the full instruction set</i>
|
||||
<i>Split pipe-delimited values into actionable items</i>
|
||||
<i>Keep assessment grounded in evidence from PRD/architecture/story files—do not restate requirements as risks</i>
|
||||
</llm>
|
||||
<flow>
|
||||
<step n="1" title="Preflight">
|
||||
<action>Verify prerequisites; stop if halt_rules trigger</action>
|
||||
</step>
|
||||
<step n="2" title="Execute Risk Analysis">
|
||||
<action>Follow flow_cues to distinguish requirements from genuine risks and score probability × impact</action>
|
||||
<action>Use knowledge heuristics to calibrate scoring (score 9 rare, ≥6 notable) and recommend mitigations</action>
|
||||
</step>
|
||||
<step n="3" title="Deliverables">
|
||||
<action>Produce artifacts described in deliverables (assessment markdown, gate snippet, mitigation plan)</action>
|
||||
<action>Summarize key findings with clear recommendations</action>
|
||||
</step>
|
||||
</flow>
|
||||
<halt>
|
||||
<i>Apply halt_rules from the CSV row without modification</i>
|
||||
</halt>
|
||||
<notes>
|
||||
<i>Use notes column for calibration reminders</i>
|
||||
</notes>
|
||||
<output>
|
||||
<i>Risk assessment report + gate summary</i>
|
||||
</output>
|
||||
</task>
|
||||
```
|
||||
@@ -1,11 +1,9 @@
|
||||
command,title,when_to_use,preflight,flow_cues,deliverables,halt_rules,notes,knowledge_tags
|
||||
*framework,Initialize test architecture,Run once per repo or when no production-ready harness exists,package.json present|no existing E2E framework detected|architectural context available,"Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded",playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions,"If package.json missing OR framework already configured, halt and instruct manual review","Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors",philosophy/core|patterns/fixtures|patterns/selectors
|
||||
*tdd,Acceptance Test Driven Development,Before implementation when team commits to TDD,story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place,Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop,Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements,"If criteria ambiguous or framework missing, halt for clarification",Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green,philosophy/core|patterns/test-structure
|
||||
*automate,Automation expansion,After implementation or when reforging coverage,all acceptance criteria satisfied|code builds locally|framework configured,"Review story source/diff to confirm automation target; ensure fixture architecture exists (mergeTests for Playwright, commands for Cypress) and implement apiRequest/network/auth/log fixtures if missing; map acceptance criteria with test-levels-framework.md guidance and avoid duplicate coverage; assign priorities using test-priorities-matrix.md; generate unit/integration/E2E specs with naming convention feature-name.spec.ts, covering happy, negative, and edge paths; enforce deterministic waits, self-cleaning factories, and <=1.5 minute execution per test; run suite and capture Definition of Done results; update package.json scripts and README instructions",New or enhanced spec files grouped by level; fixture modules under support/; data factory utilities; updated package.json scripts and README notes; DoD summary with remaining gaps; gate-ready coverage summary,"If automation target unclear or framework missing, halt and request clarification",Never create page objects; keep tests <300 lines and stateless; forbid hard waits and conditional flow in tests; co-locate tests near source; flag flaky patterns immediately,philosophy/core|patterns/helpers|patterns/waits|patterns/dod
|
||||
*ci,CI/CD quality pipeline,Once automation suite exists or needs optimization,git repository initialized|tests pass locally|team agrees on target environments|access to CI platform settings,"Detect CI platform (default GitHub Actions, ask if GitLab/CircleCI/etc); scaffold workflow (.github/workflows/test.yml or platform equivalent) with triggers; set Node.js version from .nvmrc and cache node_modules + browsers; stage jobs: lint -> unit -> component -> e2e with matrix parallelization (shard by file not test); add selective execution script for affected tests; create burn-in job that reruns changed specs 3x to catch flakiness; attach artifacts on failure (traces/videos/HAR); configure retries/backoff and concurrency controls; document required secrets and environment variables; add Slack/email notifications and local script mirroring CI",.github/workflows/test.yml (or platform equivalent); scripts/test-changed.sh; scripts/burn-in-changed.sh; updated README/ci.md instructions; secrets checklist; dashboard or badge configuration,"If git repo absent, test framework missing, or CI platform unspecified, halt and request setup",Target 20x speedups via parallel shards + caching; shard by file; keep jobs under 10 minutes; wait-on-timeout 120s for app startup; ensure npm test locally matches CI run; mention alternative platform paths when not on GitHub,philosophy/core|ci-strategy
|
||||
*risk-profile,Risk profile analysis,"After story approval, before development",story markdown present|acceptance criteria clear|architecture/PRD accessible,"Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS with category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; prepare gate summary with residual risk",Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; gate YAML snippet summarizing totals; mitigation matrix with owners and due dates,"If story missing or criteria unclear, halt for clarification","Category definitions: TECH=unmitigated architecture flaws, SEC=missing controls/vulnerabilities, PERF=SLA-breaking performance, DATA=loss/corruption scenarios, BUS=user/business harm, OPS=deployment/run failures; rely on evidence, not speculation; score 9 -> FAIL, 6-8 -> CONCERNS; most stories should have 0-1 high risks",philosophy/core|risk-model
|
||||
*test-design,Test design playbook,"After risk profile, before coding",risk assessment completed|story acceptance criteria available,"Break acceptance criteria into atomic scenarios; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage and prefer lower levels when possible; assign priorities using test-priorities-matrix.md (P0 revenue/security, P1 core journeys, P2 secondary, P3 nice-to-have); map scenarios to risk mitigations and required data/tooling; follow naming {epic}.{story}-LEVEL-SEQ and plan execution order",Test-design markdown saved to docs/qa/assessments; scenario table with requirement/level/priority/mitigation; gate YAML block summarizing scenario counts and coverage; recommended execution order,"If risk profile missing or acceptance criteria unclear, request it and halt","Shift left: unit first, escalate only when needed; tie scenarios back to risk mitigations; keep scenarios independent and maintainable",philosophy/core|patterns/test-structure
|
||||
*trace,Requirements traceability,Mid-development checkpoint or before review,tests exist for story|access to source + specs,"Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary",Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps,"If story lacks implemented tests, pause and advise running *tdd or writing tests","Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage",philosophy/core|patterns/assertions
|
||||
*nfr-assess,NFR validation,Late development or pre-review for critical stories,implementation deployed locally|non-functional goals defined or discoverable,"Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions",NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners,"If NFR targets undefined and no guidance available, request definition and halt","Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist",philosophy/core|nfr
|
||||
*review,Comprehensive TEA review,Story marked ready; tests passing locally,traceability complete|risk + design docs available|tests executed locally,"Determine review depth (deep if security/auth touched, no new tests, diff >500, prior gate FAIL/CONCERNS, >5 acceptance criteria); follow flow cues to inspect code quality, selectors, waits, and architecture alignment; map requirements to tests and ensure coverage matches trace report; perform safe refactors when low risk and record others as recommendations; prepare TEA Results summary and gate recommendation",Updated story markdown with TEA Results and recommendations; gate recommendation summary; list of refactors performed and outstanding issues,"If prerequisites missing (tests failing, docs absent), halt with checklist","Evidence-focused: reference concrete files/lines; escalate security/performance issues immediately; distinguish must-fix vs optional improvements; reuse Murat patterns for helpers, waits, selectors",philosophy/core|patterns/review
|
||||
*framework,Initialize test architecture,Run once per repo or when no production-ready harness exists,package.json present|no existing E2E framework detected|architectural context available,"Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded",playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions,"If package.json missing OR framework already configured, halt and instruct manual review","Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors",philosophy/core|patterns/fixtures|patterns/selectors
|
||||
*gate,Quality gate decision,After review or mitigation updates,latest assessments gathered|team consensus on fixes,"Assemble story metadata (id, title); choose gate status using deterministic rules (PASS all critical issues resolved, CONCERNS minor residual risk, FAIL critical blockers, WAIVED approved by business); update YAML schema with sections: metadata, waiver status, top_issues, risk_summary totals, recommendations (must_fix, monitor), nfr_validation statuses, history; capture rationale, owners, due dates, and summary comment back to story","docs/qa/gates/{story}.yml updated with schema fields (schema, story, story_title, gate, status_reason, reviewer, updated, waiver, top_issues, risk_summary, recommendations, nfr_validation, history); summary message for team","If review incomplete or risk data outdated, halt and request rerun","FAIL whenever unresolved P0 risks/tests or security holes remain; CONCERNS when mitigations planned but residual risk exists; WAIVED requires reason, approver, and expiry; maintain audit trail in history",philosophy/core|risk-model
|
||||
*nfr-assess,NFR validation,Late development or pre-review for critical stories,implementation deployed locally|non-functional goals defined or discoverable,"Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions",NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners,"If NFR targets undefined and no guidance available, request definition and halt","Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist",philosophy/core|nfr
|
||||
*tdd,Acceptance Test Driven Development,Before implementation when team commits to TDD,story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place,Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop,Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements,"If criteria ambiguous or framework missing, halt for clarification",Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green,philosophy/core|patterns/test-structure
|
||||
*test-design,Risk and test design planning,"After story approval, before development",story markdown present|acceptance criteria clear|architecture/PRD accessible,"Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS using category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; break acceptance criteria into atomic scenarios mapped to mitigations; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage, prefer lower levels when possible; assign priorities using test-priorities-matrix.md; outline data/tooling prerequisites and execution order",Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; mitigation matrix with owners and due dates; coverage matrix with requirement/level/priority/mitigation; gate YAML snippet summarizing risk totals and scenario counts; recommended execution order,"If story missing or criteria unclear, halt for clarification","Category definitions: TECH=architecture flaws; SEC=missing controls/vulnerabilities; PERF=SLA risk; DATA=loss/corruption; BUS=user/business harm; OPS=deployment/run failures; rely on evidence, not speculation; tie scenarios back to risk mitigations; keep scenarios independent and maintainable",philosophy/core|risk-model|patterns/test-structure
|
||||
*trace,Requirements traceability,Mid-development checkpoint or before review,tests exist for story|access to source + specs,"Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary",Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps,"If story lacks implemented tests, pause and advise running *tdd or writing tests","Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage",philosophy/core|patterns/assertions
|
||||
|
||||
|
@@ -1,39 +1,43 @@
|
||||
<!-- Powered by BMAD-CORE™ -->
|
||||
|
||||
# Test Design v2.0 (Slim)
|
||||
# Risk & Test Design v3.0 (Slim)
|
||||
|
||||
```xml
|
||||
<task id="bmad/bmm/testarch/test-design" name="Test Design">
|
||||
<task id="bmad/bmm/testarch/test-design" name="Risk & Test Design">
|
||||
<llm critical="true">
|
||||
<i>Set command_key="*test-design"</i>
|
||||
<i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i>
|
||||
<i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to reinforce Murat's coverage heuristics</i>
|
||||
<i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as guidance</i>
|
||||
<i>Split pipe-delimited values into actionable lists</i>
|
||||
<i>Keep documents actionable—no verbose restatement of requirements</i>
|
||||
<i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md for risk-model and coverage heuristics</i>
|
||||
<i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as the execution blueprint</i>
|
||||
<i>Split pipe-delimited values into actionable checklists</i>
|
||||
<i>Stay evidence-based—link risks and scenarios directly to PRD/architecture/story artifacts</i>
|
||||
</llm>
|
||||
<flow>
|
||||
<step n="1" title="Preflight">
|
||||
<action>Confirm required inputs (risk profile, acceptance criteria)</action>
|
||||
<action>Abort using halt_rules if prerequisites missing</action>
|
||||
<action>Confirm story markdown, acceptance criteria, and architecture/PRD access.</action>
|
||||
<action>Stop immediately if halt_rules trigger (missing inputs or unclear requirements).</action>
|
||||
</step>
|
||||
<step n="2" title="Design Strategy">
|
||||
<action>Follow flow_cues to map criteria to scenarios, assign test levels, set priorities</action>
|
||||
<action>Use knowledge heuristics for ratios, data factories, and cost vs confidence trade-offs</action>
|
||||
<step n="2" title="Assess Risks">
|
||||
<action>Follow flow_cues to filter genuine risks, classify them (TECH/SEC/PERF/DATA/BUS/OPS), and score probability × impact.</action>
|
||||
<action>Document mitigations with owners, timelines, and residual risk expectations.</action>
|
||||
</step>
|
||||
<step n="3" title="Deliverables">
|
||||
<action>Create artifacts defined in deliverables (strategy markdown, tables)</action>
|
||||
<action>Summarize guidance for developers/testers</action>
|
||||
<step n="3" title="Design Coverage">
|
||||
<action>Break acceptance criteria into atomic scenarios mapped to mitigations.</action>
|
||||
<action>Choose test levels using test-levels-framework.md, assign priorities via test-priorities-matrix.md, and note tooling/data prerequisites.</action>
|
||||
</step>
|
||||
<step n="4" title="Deliverables">
|
||||
<action>Generate the combined risk report and test design artifacts described in deliverables.</action>
|
||||
<action>Summarize key risks, mitigations, coverage plan, and recommended execution order.</action>
|
||||
</step>
|
||||
</flow>
|
||||
<halt>
|
||||
<i>Follow halt_rules from the CSV row</i>
|
||||
<i>Apply halt_rules from the CSV row verbatim.</i>
|
||||
</halt>
|
||||
<notes>
|
||||
<i>Apply notes column for extra context</i>
|
||||
<i>Use notes column for calibration reminders and coverage heuristics.</i>
|
||||
</notes>
|
||||
<output>
|
||||
<i>Lean test design document aligned with risk profile</i>
|
||||
<i>Unified risk assessment plus coverage strategy ready for implementation.</i>
|
||||
</output>
|
||||
</task>
|
||||
```
|
||||
|
||||
37
v6-open-items.md
Normal file
37
v6-open-items.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# v6 Pending Items
|
||||
|
||||
## Needed before Alpha → Beta
|
||||
|
||||
Aside from stability and bug fixes found during the alpha period - the main focus will be on the following:
|
||||
|
||||
- Single Agent web bundler finalized
|
||||
- Team Web Bundler functional
|
||||
- bmm `testarch` converted to a standalone module or integrated into the BMM workflow's after aligned with the rest of bmad method flow.
|
||||
- All project levels (0 through 4) manual flows validated through workflow phase 1-4
|
||||
- level 0 (simple addition or update to existing project) workflow is super streamlined from explanation of issue through code implementation
|
||||
- simple spec file -> context -> implementation
|
||||
- level 1 (simple update to existing, or a very simple oneshot tool or project)
|
||||
- NPX installer
|
||||
- github pipelines, branch protection, vulnerability scanners
|
||||
- improved subagent injections
|
||||
- bmm existing project scanning and integration with workflow phase 1-4 improvements
|
||||
|
||||
## Needed before Beta → v0 release
|
||||
|
||||
Once the alpha is stabilized and we switch to beta, work on v4.x will freeze and the beta will merge to main. The NPX installer will still install v4 by default, but people will be able to npm install the beta version also.
|
||||
|
||||
- Orchestration tracking works consistently across all workflow phases on BMM module
|
||||
- Module repository and submission process defined
|
||||
- Final polished documentation and user guide for each module
|
||||
- Final polished documentation for overall project architecture
|
||||
- MCP Injections based on installation selection
|
||||
- TDD Workflow Integration
|
||||
- BMad-Master BMad-Init workflow will be a single entrypoint agent command that will set the user on the correct path and workflow. BMad-Init will become very powerful in the future, empowering the BMad Master to be a full orchestrator across any current or future module.
|
||||
|
||||
## Late Beta or Post v0 official release items
|
||||
|
||||
- Installer offers installation of vetted community modules
|
||||
- DevOps Module
|
||||
- Security Module
|
||||
- BoMB improvements
|
||||
- 2-3 functional Reference Architecture Project Scaffolds and community contribution process defined
|
||||
Reference in New Issue
Block a user