Skip to main content

​
Too vague

The prompt:
The problem: Megumi generates a single generic happy-path test — open the app, enter email and password, tap login, verify success. No edge cases, no error scenarios, no specific UI elements named. The fix: describe the scenarios, the expected outcomes, and the edge cases.

​
Too broad in a single prompt

The prompt:
The problem: Megumi tries to cover everything and produces shallow, generic tests that skim the surface of every feature without covering any of them thoroughly. The fix: break it into focused prompts per feature or flow. One recipe per feature area is the right default.
Then in a follow-up or new recipe:
Megumi produces better output when the scope is clear. If you need full app coverage, create separate recipes for each major feature and run them independently.

​
No expected outcomes

The prompt:
The problem: Megumi generates steps that navigate through the payment flow but does not include assertions about what should happen. The test confirms that steps ran — not that payment actually worked. The fix: always say what should be true at the end.
This applies to negative scenarios too:

​
Relying on assumed knowledge

The prompt:
The problem: Megumi does not know what “usual” means for your app. It does not know whether your checkout has a guest option, how many steps it involves, or which payment methods are supported — even if you have context attached. The fix: be explicit about the flow. Attached documents provide background knowledge, but your prompt should still describe the key scenarios.
Do not assume the PRD or Figma file is self-explanatory. Megumi reads them, but your prompt directs how it uses that information.

​
Not specifying error messages

The prompt:
The problem: Megumi generates tests that check for “an error message” without specifying which one. During execution, Mahoraga cannot verify a vague assertion — it does not know what text to look for. The fix: include the exact error message text when you know it.
If you do not know the exact messages, say so and ask Megumi to infer from context:

​
Mixing generation and execution concerns

The prompt:
The problem: Megumi generates tests. It does not run them. Running happens when you add tests to a suite and trigger execution, or when you write a task prompt. Mixing both in one prompt confuses the intent. The fix: use Test Studio for generation, then save and run separately.
After generation, save the tests to your library, add them to a suite, and run the suite on your Pixel 6.

​
Not using follow-up prompts

The problem: a user generates tests, finds them too generic, discards everything, and starts a new recipe with a more detailed prompt. The fix: stay in the session and refine. Megumi remembers the full conversation — you do not need to start over.
Iterating in the same session is faster and produces better results than starting over, because Megumi has the full conversation context to build on.

​
Checklist before prompting

Before sending your first prompt in a recipe, verify:
  • [ ] Context sources are attached (app, GitHub branch, Figma, Jira, PRD)
  • [ ] CONFIG is set (coverage depth, scope, platform, priority levels)
  • [ ] Your prompt names the specific feature or flow
  • [ ] Your prompt lists the key scenarios to cover
  • [ ] Your prompt includes expected outcomes for success and failure states
  • [ ] UI element names are included where you know them