01
Smoke
Example: Every build: sign-in, the main journey, payments or submissions
Approach: A short suite that must pass before any further testing starts
Functional Testing
Functional and regression testing services
A large test suite can still miss the one boundary or state change where the defect sits. Agnotic Technologies designs functional and regression tests from your requirements, traces each one back, and tiers the suite so every release runs the right checks.
Test design techniquesTraceabilityTiered regressionFlaky test control
Trusted by global innovators
Functional and regression testing
What is functional testing?
Functional testing checks that software does what its requirements say, one requirement at a time, and regression testing checks that a change did not break what already worked. Agnotic Technologies designs both as test design work: choosing a technique per requirement, tracing every test to a requirement and tiering the regression suite by risk.
This page is the method behind the functional testing card on our QA and testing page. Automation frameworks, security testing and performance testing are separate engagements.
We choose the technique before we write the cases. The technique decides which inputs, combinations and states get tested, and that is where most missed defects come from.
Decision table
Which test design technique fits each requirement?
We tag every requirement with its type, then design its tests with the matching technique.
| Requirement type | Technique | Example test case |
|---|---|---|
| Inputs with valid ranges (age, amount, quantity) | Equivalence partitioning and boundary value analysis | The field accepts the minimum and maximum, and rejects one step below and above, each with the right message |
| Business rules with several conditions (discounts, eligibility) | Decision table testing | One case per combination of conditions: member or not, over or under the threshold, coupon or none |
| Workflows with states (order, claim, approval) | State transition testing | A cancelled order cannot be shipped; a shipped order can be returned but not cancelled |
| Many configuration options (browsers, roles, plans) | Pairwise or combinatorial testing | Every pair of role and plan appears in at least one test, without testing every full combination |
| Integrations with other systems | Interface and contract testing | A declined payment response leaves the order unpaid and offers a retry |
| End-to-end user journeys | Scenario testing from acceptance criteria | Given a returning customer with a saved card, when they reorder, then the order uses the saved address |
Exploratory sessions run beside these scripted cases, aimed at the areas where the techniques give the least coverage.
How does a traceability matrix prove coverage?
A requirements traceability matrix links each requirement to the test cases that check it, and each failed test to the defect it raised. It answers the question a release manager asks: which requirements have we tested, and which still have open defects?
We keep the matrix in your test management tool or issue tracker rather than a spreadsheet, so it updates as tests run. Requirements with no linked test show up before the release, not after it.
The same links make regression scope easier. When a requirement changes, the matrix shows which tests to update and rerun.
Regression tiers
How is a regression suite tiered?
Three tiers with their own selection rules, so each release runs the right checks without running everything every time.
02
Targeted
Example: Every change: tests linked to the changed requirements and the modules the change touches
Approach: Selected from the traceability matrix and the change set, plus tests for areas with recent defects
03
Full
Example: Before a major release or after a platform or framework upgrade
Approach: The whole suite, low-risk areas included, with results recorded against the matrix
Flaky tests
How do we handle flaky tests?
A test that sometimes fails teaches the team to ignore failures. These are our rules.
- A test that fails and then passes on retry is logged as flaky, never as passed
- Flaky tests go on a quarantine list with an owner, and stop blocking releases only while they are quarantined
- Each one is diagnosed: timing, test data, environment, or a real intermittent defect
- Real intermittent defects are raised as defects, not retried away
- The quarantine list is reviewed every sprint and kept short
- Exploratory sessions cover the areas that quarantined tests leave open
Acceptance testing
How does acceptance testing with your team work?
Your product owner decides what done means; we make it testable.
1.
Agree acceptance criteria
Each story gets criteria written as examples that your product owner signs off before development starts.
Criteria2.
Run scripted and exploratory tests
Scripted cases from the techniques above, plus time-boxed exploratory sessions on risky areas.
Test3.
Review results with you
A short report per release: requirements covered, open defects by severity, and what was not tested and why.
AcceptWho it is for
Teams that use our functional and regression testing
Teams that need test design, not only test execution.
Product teams without QA engineers
Developers who write unit tests but need someone to design and run tests against the requirements.
Teams with a large, slow suite
Suites that take too long to run, retiered so most changes need only smoke and targeted tests.
Releases after a major upgrade
Framework, database or platform upgrades that need a full regression run with evidence.
Products with complex business rules
Pricing, eligibility or approval rules tested with decision tables rather than guesswork.
Regression testing for startups
A lean smoke and targeted suite that grows with the product.
Teams preparing for a buyer's review
A traceability matrix and test records a customer or auditor can read.
Techniques
Techniques and formats we use
Test design techniques and the formats we record tests in.
Equivalence partitioningBoundary value analysisDecision tablesState transitionsGherkinNIST SP 800-142
Facts and sources
Facts behind functional and regression testing
References for the techniques and rules on this page, each linked to its primary source.
NIST's guide to combinatorial testing rests on the finding that most faults are caused by interactions between a relatively small number of parameters, so t-way tests can cover them without testing every combination.
Source: NIST SP 800-142, Practical Combinatorial TestingPlaywright Test classifies a test that fails on the first run but passes when retried as "flaky", separately from tests that passed first time or failed every retry.
Source: Playwright documentation: RetriesGherkin, the format used for executable acceptance criteria, structures each scenario as steps that start with Given, When and Then, with Scenario Outline and Examples for data-driven cases.
Source: Cucumber documentation: Gherkin referenceThe ISTQB Glossary defines confirmation testing, with retesting as its synonym, as a type of change-related testing performed after fixing a defect to confirm that a failure caused by that defect does not reoccur.
Source: ISTQB Glossary, confirmation testing
Scope and cost
What drives the cost of functional testing services?
We do not publish prices. These drive the size of the work.
Requirements
How many requirements or stories are in scope, and how well they are written down.
Platforms
Web, iOS, Android and the browsers and devices each needs.
Business rule complexity
How many rules need decision tables or combinatorial designs.
Existing suite
Whether we start fresh or retier and repair an existing suite.
Release rhythm
How often you release and how much regression each release needs.
Evidence needs
Whether a buyer, auditor or regulator needs formal test records.
Frequently Asked Questions
Functional testing checks a feature against its requirements, usually when it is new or changed. Regression testing reruns earlier tests to check that a change did not break something that already worked. The same test cases often serve both.
Retesting, also called confirmation testing, reruns the test that failed after a fix, to confirm the failure caused by that defect does not come back. Regression testing reruns tests around the change, to find defects introduced or uncovered in areas that did not change. A fix usually gets both: the retest first, then the regression tier for that area.
We do not publish prices. Cost depends on the requirements in scope, platforms, business rule complexity, the state of any existing suite, how often you release and the evidence you need. You get a written proposal after the scoping call.
Design comes first either way. Stable tests that run on every release are worth automating; tests for features still changing, and exploratory sessions, stay manual. We mark each designed test with that decision.
From the traceability matrix and the change set: the smoke suite, every test linked to the changed requirements, tests for modules the change touches, and tests in areas that had defects recently.
Yes. If you need the results to be independent of that vendor, for example before you accept a release, see our independent software testing service, which adds rules on reporting and disputes.
Yes. A common start is designing tests for one high-risk area and setting up the smoke suite, then extending tier by tier.
AI tools may help draft test cases from requirements, but a test engineer checks every case against the technique and the requirement, and the traceability links are reviewed by a person.