Spring GDS 25th Anniversary
A logistics company that ships to 190 countries built something to ship to itself.
Functional testing checks that a feature does what the requirements say it should. You give it an input, you check the output against the expected result. Does the discount code knock 10% off the total? Does the search box return matching products? Does a wrong password get rejected? It treats the software as a black box. What happens inside the code doesn't matter, only that the behavior is correct.
This sets it apart from non-functional testing, which measures qualities like speed, security, or how the system holds up under load. Functional testing answers "does it work," not "how well." It also sits at a different scope than end-to-end testing. Functional testing usually verifies one capability against its spec, while E2E chains many capabilities into a full user journey across real systems. A functional test might confirm that the "reset password" endpoint sends an email; an E2E test follows the link, sets a new password, and logs back in.
Functional tests span every level of detail. A unit test on a single pricing function is functional. So is a manual tester clicking through a registration form. So is an automated suite hitting an API and asserting on the response. The common thread is the same: behavior measured against a defined requirement, which is why clear acceptance criteria make functional testing far more useful than vague ones.
We tie functional tests to requirements, not to guesses about what a feature might do. When we agree on acceptance criteria with a client at the start, those become the assertions later. A test that maps to a written requirement tells you something. A test that maps to nothing just inflates the numbers.
Most of this runs as automated testing inside the pipeline, so every change gets checked against the spec before it merges. We keep the fast functional and integration tests doing the heavy lifting and reserve slower full-journey runs for the flows that carry real risk. When a client's product has grown faster than its test suite, we help close that gap: pin down what each feature is supposed to do, then make the tests prove it.
Need to know your features actually do what they promise? Let's check.
A logistics company that ships to 190 countries built something to ship to itself.
Turning a brand into a working business.
Half a million people. One app. Zero chaos.















