Skip to main content
GullySystem

Functional, Regression and Smoke Testing

Three checks that answer different questions: does a feature work as intended, has an old feature quietly broken, and is a fresh deployment alive at all. GullySystem runs all three on a rhythm matched to your release schedule.

Three Questions, Answered on Different Schedules

Functional testing asks whether a specific feature behaves as intended, and runs once a feature is built. Regression testing asks whether everything that already worked still works, and runs before every release regardless of what changed. Smoke testing asks the narrowest question of all — did the deployment succeed at all — and runs immediately after a build reaches an environment, before any deeper testing begins.

What Happens When Only One of the Three Runs

  • A new feature is checked in isolation while the discount rule it touches breaks invoicing elsewhere
  • A deployment fails silently and the team spends an hour testing a page that never loaded
  • Regression is skipped under deadline pressure and the same defect returns two releases later
  • Functional sign-off is given on staging, then the production deployment is never smoke-tested at all
  • Nobody can say which of the three failed, so every release feels equally risky regardless of size

How Each One Is Built

Functional Test Cases

Written against the stated requirement for a feature, covering the intended path and the inputs it was never designed to accept.

Regression Suite

A maintained set covering existing behaviour across the application, added to as features are built and re-run before each release.

Smoke Checklist

A short list of the essentials — login, the primary journey, the payment step — confirmed alive within minutes of a deployment, before deeper testing starts.

Retirement of Stale Cases

Cases for removed or replaced features are dropped from the suite so it keeps testing what the product actually is today, not what it used to be.

A Logistics Fleet App, as an Example

A logistics company adds a new fuel-claim feature to its driver app. Functional testing checks the claim form, approval flow and receipt upload against what was specified. Regression re-runs trip logging, route assignment and payroll export, because the new feature shares a database table with payroll. A five-minute smoke pass after the release confirms drivers can still log in and start a trip before anyone looks at the fuel claims at all.

FAQ

Frequently asked questions

Do we need all three, or can we pick one?

Most teams need all three, because they catch different failures. A release with only functional testing can still ship a broken login if regression is skipped, and a release with only regression can still miss that the new feature itself does not work. Smoke testing is cheap enough to run every time regardless.

How often should regression be run?

Before every release that reaches production, not on a calendar schedule. The suite is re-run against the specific build going out, because the point is to prove that build has not disturbed existing behaviour, not to confirm the application worked at some point in the past.

What drives the cost of maintaining a regression suite?

How many journeys and user roles it covers, how often it needs to run, and whether it is executed manually or automated. A suite covering a handful of critical paths costs far less to maintain than one attempting to cover every screen.

What decides how long a testing cycle takes?

The size of the regression suite, how many defects the functional pass finds, how quickly fixes are deployed for retesting, and whether smoke and regression are automated or run by hand each time.

Can this work with our existing release pipeline?

Yes. Smoke checks and automated regression can be wired to run on a schedule or triggered by a deployment, with results published wherever your team already looks, or run manually if that suits your release size better.

What do you need from us to begin this cycle?

The requirement or specification for the feature under functional test, access to a stable build, and a list of the journeys the business would consider unacceptable to have broken by a release.

Talk to us

Tell us what you need.

Send a short brief and one of our engineers will come back to you — usually the same day.

  • No obligation
  • We reply the same working day
  • Your details stay private

Your details are private and secure. Protected by reCAPTCHA.