Swantide reads your org's metadata — every flow, validation rule, Apex class, and trigger — so it already knows how your org is supposed to behave. That makes it a powerful testing partner: it can tell you what to test, write your UAT scripts and test-case matrices, plan the test data, surface the edge cases people forget, generate Apex test classes, and map your regression scope — all grounded in your actual configuration instead of generic advice.
Every prompt below is copy-paste ready. Run them in the AI Assistant, one component per conversation, and swap the placeholders (in [BRACKETS]) for a real flow, rule, class, or object from your org.
How to get the best results
Anchor every prompt to a real component. Paste in the actual flow, rule, or class name. Swantide pulls its real definition and reasons over what it truly does — that's where the accuracy comes from.
One component per chat. A fresh conversation per flow, rule, or class keeps each answer focused and deep.
Ask by behavior, not just by name. "The record-triggered flows that run on Opportunity" beats "flows named Opportunity" — it finds the automation that a name search would miss. If a count ever looks suspiciously low, confirm it in the Data Dictionary.
Review before you run. A generated test class or UAT script is an excellent first draft — read it, then execute it in a sandbox. Swantide does the heavy lifting; you keep the judgment.
Swantide reads metadata, not your records. For questions that need record data — "how many records would fail this rule?", "which fields are actually populated?" — use the data-probe loop: Swantide writes the exact query, you run it, and paste the numbers back for it to interpret.
Managed packages are a boundary, not a blind spot. Swantide can't see inside installed packages (CPQ, etc.), but it sees all the automation and code you built around them — which is exactly what your tests need to cover.
The library at a glance
# | Section | What it does |
1 | Know what to test | Build your test scope from the org's real automation |
2 | UAT scripts for business users | Step-by-step, executable scripts with sign-off |
3 | Test-case matrices | Pass/fail cases for validation rules and field logic |
4 | Test data planning | The exact records to create to hit every path |
5 | Edge & negative cases | The scenarios testers usually miss |
6 | Apex test classes | Bulk-safe, best-practice developer tests |
7 | Regression scope | What to re-test after a change |
8 | Investigate a failed test | Trace why something didn't behave as expected |
9 | Bridge to record data | Coverage questions that need actual records |
10 | Build the full test plan | Pull it all together into a coverage checklist |
1 — Know what to test
Before you write a single test case, find out everything that governs the thing you're testing. Swantide reads it straight from the org.
Scope an object:
I'm planning the test coverage for the [OBJECT] object. Walk me through everything that governs its behavior that a tester needs to cover: the record-triggered flows that run on [OBJECT], the Apex triggers on it, and its validation rules. Group them by what they do and put the most business-critical ones first, so I know where to focus my testing. |
Understand one process end to end:
Explain what the [FLOW NAME] flow does, step by step — every decision branch, what it reads, and what records or fields it changes. I'm about to test it and need to understand each path I'll have to cover. |
2 — UAT scripts for business users
Turn an automation you didn't build into a script a business user can run — setup, steps, expected results, and a sign-off column.
Script a flow:
Create a UAT test script for the [FLOW NAME] flow, written for a business user to execute. For each case give the setup, the exact steps to perform in the UI, and the expected result. Cover the main happy path plus the important negative and edge cases, and format it as a numbered test-case table with a pass/fail sign-off column. |
Script an end-to-end process:
Write a UAT script for the end-to-end [PROCESS, e.g. Lead-to-Opportunity conversion] as a user experiences it. Include the required fields, the validation rules a user will hit, and the automation that fires along the way, with the expected result at each step. Format it as a test-case table with a sign-off column. |
3 — Test-case matrices
Every rule becomes two cases: one that should fail and one that should pass, with the exact field values to set.
All rules on an object:
Write a test-case matrix for the validation rules on the [OBJECT] object, for a QA tester to execute manually. For each rule: a plain-language description of what it enforces, one test case that should trigger the error (with the exact field values to set), and one that should pass. Put the most business-critical rules first. |
One rule, in depth:
Take the [VALIDATION RULE] rule on [OBJECT]. Explain in plain English exactly what it enforces, then give me the full set of test cases to prove it works — every field-value combination that should be blocked and every one that should be allowed. Include any record-type exceptions or bypass conditions in the formula, since those are easy to test wrong. |
4 — Test data planning
Half of testing is figuring out what data to set up. Let Swantide derive it from the logic.
Data to exercise a flow's branches:
I'm about to test the [FLOW NAME] flow. Based on what it actually does, tell me the set of test records and field values I need to create to exercise each of its decision paths — the happy path and each branch. For each path, give the specific field values to set and which branch it exercises. |
A full data set for an object:
I need a test-data set for the [OBJECT] object that exercises its automation and validation rules. Tell me what records to create — with which field values and record types — to hit every rule and every automation path at least once. Present it as a table of records with the fields to set on each. |
5 — Edge & negative cases
The cases that slip through UAT and surface in production — pulled from the real logic, with the reason each is easy to miss.
For the [VALIDATION RULE or FLOW] on [OBJECT], list the negative and edge cases a tester should try to break it — unusual field-state combinations, record-type exceptions, prior-value transitions, and anything a bypass setting could hide. For each one, tell me why it's easy to miss in normal testing. |
Look at the [FLOW NAME] flow and tell me where it could fail or behave unexpectedly under edge conditions — null values, bulk updates, missing related records, or recursive re-triggering. These are the scenarios I want to add to my test plan. |
6 — Apex test classes
For the developers and technical testers: real, bulk-safe test code against your actual classes — not a template.
A test class for a class or trigger:
Write an Apex test class for the [APEX CLASS] class to 90%+ coverage. Include positive and negative cases, bulk-safe test data (200 records), and real assertions, following Apex test best practices — no hardcoded IDs, no SeeAllData. Fetch the full class body first so the tests match what it actually does. |
An async class (Queueable / Batch / Schedulable):
Write an Apex test class for the [CLASS], which is a [Queueable / Batch / Schedulable]. Include the proper Test.startTest() / Test.stopTest() async handling, a bulk case, positive and negative paths, and assertions on the async job result. Follow best practices — no hardcoded IDs, no SeeAllData. |
Strengthen an existing test:
Review the [TEST CLASS] test class. Is it asserting meaningful behavior, or just running code for coverage? Point out weak or missing assertions, negative cases it skips, and any paths in [CLASS UNDER TEST] it doesn't exercise — then show me how to strengthen it. |
7 — Regression scope
Ask "what's my regression scope?" before you change something — not after it breaks in UAT.
I'm about to change the [COMPONENT, e.g. Apex trigger or flow] on [OBJECT]. Before I do, tell me what I need to regression-test: what this component touches, what downstream automation could be affected, and which areas of the app a tester should re-check after the change. Rank the areas by risk. |
We're planning to change [FIELD / picklist value / stage] on [OBJECT]. What automation, validation rules, reports, and Apex reference it, and what should QA re-test to make sure nothing downstream breaks? |
8 — Investigate a failed test
When something doesn't behave as expected during testing, Swantide walks the real automation path instead of guessing.
During testing, [SYMPTOM, e.g. the confirmation email isn't sent when a record is created]. Which flows or Apex are involved in that behavior, and what conditions would cause it not to happen? Walk me through the automation path and rank the most likely causes. |
A tester is getting this validation error on [OBJECT]: "[paste the error message]". Which validation rule produces it, what exactly triggers it, and what field values would satisfy it? Explain why it might be firing when they don't expect it. |
9 — Bridge to record data
Swantide reads your configuration, not the records inside it. For coverage questions that need real records, it writes the query — you run it and paste the numbers back.
I want to know how many existing [OBJECT] records would fail the [VALIDATION RULE] if it were enforced, so I can gauge the blast radius before testing. You know the field API names — write me a SOQL query I can run in Developer Console or Workbench that counts records matching the rule's error condition. I'll run it and paste the number back. |
To build realistic test data, I need to see the shape of real records. Write me a SOQL query that returns a representative sample of [OBJECT] records with the fields that drive the [FLOW NAME] flow, so I can model my test records on real examples. I'll run it and share the results. |
10 — Build the full test plan
Pull the pieces together into one structured plan QA can sign off against. Run this once you've scoped the feature.
I'm building the test plan for [FEATURE / OBJECT / RELEASE]. Based on the automation, validation rules, and Apex involved, produce a structured test plan: the areas to cover, the test cases per area (happy path, negative, edge), the test data needed, and a coverage checklist QA can sign off against. Format it so I can hand it straight to the testing team. |
A tip to close on: for anything shaped like "find or list everything" — every flow on an object, every field that references X — the Data Dictionary and References views in Swantide are the complete, exportable source of truth. Use the Assistant to reason and generate; use the catalog to enumerate.