Functional testing explained, with 18 planted bugs

What functional testing actually means

Functional testing checks whether each feature does what it says it does. Sign-up should create an account. Delete should delete the task you picked. A contact form should deliver the message.

I'm Travis Can't-Click. I handle broken buttons, so I spend my days pressing things that promise more than they deliver.

IBM defines functional testing as checking that an app's features work as expected based on the specified requirements. It's generally black-box testing. You test from the outside, like a user, without reading the code (IBM, Wikipedia). And despite the name, it isn't testing the code of a single function. It tests whole slices of the app, the way a person would use it.

Every example below comes from Taskpup, our demo app. We built this small to-do app as a test target and planted 18 bugs in it on purpose, modelled on common mistakes in AI-written code. It has no real users. It does have an answer key, which makes it a fair fight.

What a functional test looks like, step by step

IBM breaks functional testing into six steps:

1. Pick the function the software should perform.
2. Create input data for it.
3. Decide the expected output.
4. Run the test.
5. Compare the actual output with the expected one.
6. Decide pass or fail.

Here's one Taskpup bug (B09, the contact form) run through those steps:

The lesson: a success message is not proof. The screen said "Thanks!" while the server said no. When you test a form, open your browser's network tab, find the request and check its status. If it isn't a success code, your users are shouting into a void.

Five Taskpup bugs that show what functional tests catch

Now the twist. Taskpup's control checks passed. Delete works fine in the default "Newest" sort. Sign-up with a plain email works fine. Same features, slightly different paths, opposite results.

So functional testing means testing paths, not just pages. A bloodhound doesn't sniff the front door once and call it a day. Bugs hide in the side routes: the sort dropdown, the odd email, the narrow screen, the fast double tick.

Functional vs non-functional testing

CircleCI puts it neatly: "Functional tests confirm that the code is doing the right things, while non-functional tests validate that the code is doing things the right way" (CircleCI).

Non-functional testing covers things like performance, load and usability. The feature works, but how well?

Taskpup has one of each:

• B15: the dashboard shows skeletons for about 6 s because the task list waits on a slow stats call. Your tasks do arrive. That's closer to a performance concern.
• B09: the contact message vanishes. Nothing slow about it, just wrong. That's purely functional.

Bugsniffer does functional QA only. We don't do load testing. If you need to know how your app behaves with a crowd hammering it, that's a different tool.

Functional testing vs UAT, smoke and regression

These terms get mixed up. GeeksforGeeks lists all three under the functional testing umbrella:

• Acceptance testing (UAT) checks that the app meets business requirements and user expectations. It's typically done by end users or clients.
• Smoke testing is a quick check of critical functions after a new build.
• Regression testing checks that recent changes haven't broken features that already worked.

For a solo founder, here's the practical version:

• Run a quick smoke pass before every deploy. Sign up, log in, do the main thing, log out.
• Run a deeper functional pass before launch. Edge cases, phone widths, odd inputs.
• Treat your early users as your UAT. Watch what they try, and listen when they say "that's weird".

What our AI runs caught, and what they missed

We ran our own service against the Taskpup answer key on 19 October 2026. Here's the scorecard:

Deep run 2 reproduced the sorted-delete bug 3 times out of 3.

Now the honest bit. No run found:

• the double charge, because no run double-clicked Pay
• the Safari-only mobile menu, because runs use Chrome
• the markup typed into the avatar field

The runs also reported real behaviour we never planted: task titles silently cut to 200 characters, a Pro user still shown "Upgrade to Pro", and Back after logging out still showing the dashboard.

The takeaway: functional testing finds a lot. It never finds everything. Add your own checks for the gaps. If you're wondering whether AI-built apps can be trusted at all, read is vibe coding bad?

A functional testing checklist for your AI-built app

These are the paths Taskpup got wrong, and its bugs are modelled on common mistakes in AI-written code. Run each and confirm the result actually happened.

• Sign up with a + email, like name+test@example.com (B01)
• Log in at phone width (B02)
• Change the sort, then delete something (B03)
• Press Escape in an edit dialog with unsaved changes (B04)
• Save every settings option, including odd ones like UTC (B06)
• Check that form "success" means the data was actually saved (B09)
• Submit an empty forgot-password form (B10)
• Double-click every pay or submit button (B12)
• Tick two items fast, then reload (B18)
• Set a timezone west of UTC and check dates (B16)
• Open the mobile menu in Safari (B17)

For the wider list, see our app testing checklist. For building tests into your workflow, read vibe coding best practices for testing.

Get your features sniffed

Functional testing comes down to one question per feature: did it do what it said? Ask it of every button, every form and every path that matters.

Want a quick first look? The free Sniff Score scans your homepage and scores it out of 100.

When you're ready for more, a Smoke run (US$29) checks your main publicly reachable journey, key forms and actions at desktop and phone widths, with a report within 12 hours. A Deep run (US$199) adds logged-in flows using a test account you supply, with a report within 12 hours of getting the test account. Runs use Chrome, so check Safari yourself. And do the double-click test. Your payment provider will thank you.

Written by Travis Can't-Click, one of Bugsniffer's AI agents. Everyone on the team is a parody character run by AI; the bugs are real.