> ## Documentation Index > Fetch the complete documentation index at: https://quashbugs.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting Prompts > Avoid the usual prompt pitfalls that yield shallow or unexecutable tests, with a direct fix for each pattern. ## Too vague **The prompt:** ``` Test login ``` **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. ``` Generate tests for the login feature including: - Valid email and password → verify home dashboard loads - Invalid password → verify error message "Incorrect password" appears - Unregistered email → verify error message "No account found" appears - Empty email field → verify inline validation error appears - Empty password field → verify inline validation error appears - Account locked after 5 failed attempts → verify lockout message Use the exact field names "Email Address" and "Password" and the button label "Sign In". ``` ## Too broad in a single prompt **The prompt:** ``` Test the entire app ``` **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. ``` Generate tests for the checkout flow from cart to order confirmation. ``` Then in a follow-up or new recipe: ``` Generate tests for the user profile and settings screens. ``` 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:** ``` Test the payment flow ``` **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. ``` Test the payment flow with a valid credit card and verify: - The payment processes successfully - The order confirmation screen appears with the correct total - The order number is displayed - A confirmation email is sent to the user's email address ``` This applies to negative scenarios too: ``` Test the payment flow with an expired credit card and verify: - The error message "Card expired. Please use a different card." appears - No charge is created - The user remains on the payment screen with the form still filled ``` ## Relying on assumed knowledge **The prompt:** ``` Test the usual checkout ``` **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. ``` Test the standard checkout flow for a logged-in user with items in cart: 1. Review cart contents 2. Enter delivery address 3. Select credit card payment 4. Apply promo code SAVE20 5. Confirm order 6. Verify order confirmation screen with correct total after discount ``` 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:** ``` Test validation on the signup form ``` **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. ``` Test validation on the signup form: - Empty name → verify "Name is required" appears below the field - Invalid email → verify "Please enter a valid email address" appears - Short password → verify "Password must be at least 8 characters" appears ``` If you do not know the exact messages, say so and ask Megumi to infer from context: ``` Test validation on the signup form. Use the error messages shown in the attached Figma designs. If a message is not specified in the designs, use a reasonable placeholder and flag it for review. ``` ## Mixing generation and execution concerns **The prompt:** ``` Generate tests for checkout and run them on my Pixel 6 ``` **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. ``` Generate comprehensive tests for the checkout flow including happy path, payment failures, and promo code edge cases. ``` 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. ``` Make test 3 more specific — name the UI elements and include the exact error message text. ``` ``` Add edge cases for network timeout and session expiry to the existing tests. ``` ``` Change all tests to Critical priority and add setup steps that assume the user is already logged in. ``` 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