The broadest question I get from the website is why a test platform is worth building for a given product.

To pause a beat: a test platform is a body of code that runs your product through its paces. It’s custom code, as is your product. If your product performs multiple operations at the same time so does the test platform. If your product has to meet specific conditions (such as don’t corrupt the data) the test platform ensures the product meets those conditions in all the places it’s required. If your product has to weather a variety of failures a test platform puts the product through its paces to guarantee that it does.

If you are an Engineering Manager you may be thinking the above specification cuts a wide swath for your given product. There may be a number of interfaces to drive or operating conditions to accommodate. It may be a significant effort to put together a test platform and it may require hiring staff with particular talents to do the job. Well, that is probably true. Your product took a lot of time and specific talent to create; why should a definitive test platform for it be easy to staff and trivial to build? And don’t forget the automation of the testing itself: there are many techniques that give test code the ability to run through a multitude of test conditions in a reasonable amount of wall-clock time, in combinations manual testing could never achieve.

Overall the test platform is used by Engineering to both drive and gauge a product’s functionality and readiness, beyond unit and functional tests. If you’re going to skimp on testing, the test platform level is probably not the place to do it.