Past the happy path
You Have Time for the Happy Path. The Bug Isn’t on It.
Reach the branches your team never gets to. Pie explores your app, writes tests under each feature it finds and runs what you confirm. Your rules add the wrong inputs.
Each release
Two Days by Hand. Before It Can Ship.
Get your testing days back. Hand the functional testing pass to Pie and your team builds instead. Slide in your numbers to see what it costs today.
- hours a month on functional testing today
- 64
- what that costs a year
- $49,920
Book a demo → In the demo, we’ll work out what Pie takes off it.
Where tests come from
You Say What Should Happen. Pie Writes the Test.
Get the tests your team never had time to write. Pie drafts them in plain English, and your team decides which ones run.
-
You Put a Rule in a Sentence
Do it in Chat and Pie drafts the test. It’s how wrong-input cases get in.
-
Pie Explores Your App
It finds the key features and writes tests under each one.
-
You Bring the Cases You Have
When you start with Pie, we import the ones you run today.
Pie Drafts the Test
The objective, the steps and what should be verified.
A sample test
An Expired Code Is Rejected
Confirmed
Your team confirms it, and it joins your suite.
Read every test
A Test You Can Read. A Result You Can Check.
Know what passed and what didn’t. Each test lists its steps and what Pie checks. This one is real, from Pie testing Pie.
- Grouped by feature.Here, the Test Suites page in our own app. Each test shows its result.
- What should happen.Each step says what the app should do, so anyone on your team can check it.
- What counts as a fail.Write it into the test and a miss shows as a fail.
What comes back
Eleven Invites. One Silent Button. Pie Caught It in Pie.
Your developer starts on the fix, not the repro. This bug is ours. Pie entered eleven team invites, pressed Send and the button went quiet, with no success and no error.
- There it is.Pie wrote this test itself, from a pull request.
- Each issue reads like this.What should have happened and what did. The one open here is a 500 on our settings page.
- You make the call.Track it and Pie re-checks it on every run, or dismiss it.
The basics
New to Functional Testing? Start Here.
Get up to speed in eight short answers, from what it is to how to automate it. The guides go deeper.
Functional testing checks that each feature does what it should. You give it an input, take an action and compare the result with what the requirements say.
Most of it looks at the app from the outside, the way a customer would, and not at how the code is written.
Our guide to functional testing covers the types and the tools.
A shopper enters a promo code at checkout. A valid code should take the discount off. A wrong code should show an error. An expired code should be rejected.
Each of those is a functional test, and each compares what happened with what should have.
Functional testing checks what the app does. Non-functional testing checks how well it does it, such as speed, load, security and reliability.
A checkout that works but takes a minute passes one and fails the other.
Our guide to non-functional testing covers the types.
Functional testing asks whether a feature does what it should. Regression testing asks whether what used to work still does. Smoke testing asks whether a new build works at all. End-to-end testing asks whether a whole journey works, start to finish.
The same test can do more than one of these jobs.
Start with what costs you most when it breaks, usually sign-in, checkout and payments. For each one, test the right input, then the wrong one, the empty one and the expired one.
Those unhappy paths are negative testing, and they’re where a happy-path pass stops looking. A test plan helps you decide what to leave out.
The repeat tests can. Deciding what a feature should do stays with your team.
By hand there’s no setup, but every pass costs hours. Playwright and Cypress are free and exact, but someone has to write the scripts and keep them working. An agent like Pie runs tests written in plain English, with no locators to break.
Usually QA, and often developers and product managers on smaller teams. Product managers tend to know the rules best, even when someone else runs the tests.
With tests in plain English, anyone who knows what a feature should do can read one and check it. Before a release, user acceptance testing adds the customer’s view.
You’re checking the same rules on more platforms, with more builds and screens that differ by device. Each platform can have its own suite, and a run starts from a build instead of a URL.
Pie tests iOS apps on the iOS Simulator (a simulator .app build) and Android apps on the Android Emulator (an .apk).
Our mobile app testing guide covers the rest.
Customers
Faster Releases, Without Breaking What Works.
“As we scale our products and offerings it’s really important to make sure we don’t ship something that breaks the existing experience for our users.”
“After evaluating multiple vendors, Pie was the only solution that consistently executed our most complex end‑to‑end workflows with reliability across builds.”
Security
Yes, Security Will Ask. Here’s What to Tell Them.
- You Pick the Test Account.Pie signs in with the test login you give it. A setup script can call your test API to create the data first.
- We Never Use Your Source Code to Train AI Models.Source code here means the files and code changes in your repositories.
- Logins Reach Pie’s Agents Only While a Test Runs.You keep them in Pie’s credential settings.
- Pie Has a SOC 2 Type 2 Report.Our most recent report is available on request. Data is encrypted in transit.