Devices for Internet of Things (IoT) are often small, battery powered products with limited functionality. Typical setup includes small sensors, a simple display and some form of communication, e.g. over Bluetooth Low Energy. All of the software is run by a MCU (Micro Controller Unit) that contains most of the control logic required to drive the extra functionality, be that sensors with data collecting, or communication over BT.
These products are manufactured typically in mass production volume where BOM (Bill of Materials) costs are kept under tight control and production must run efficiently. The manufacturing of IoT devices includes the production testing of all units. This means that after the SMD process each unit is tested to ensure that all hardware components have been soldered properly, no short-circuits are present and - in general - the parts of the unit work as they should. The production testing exists in some form for all of the units manufactured. Once the produced unit has passed production testing at the factory final software will be installed with SKU configuration and finally packaged, ready for customer.
The Typical Way of Testing
In normal situation the production testing is the first stage where the unit is powered up and in most cases starts to "run software". We call this first software production testing software (PTSW) as it is used to test the manufactured product. Production testing itself consists of three separate entities, each of which has its own role in the factory. These entities are: production testing software in the device under testing (DUT), automation software in control of executing the tests and collecting the results, and background data storage used to collect and store the results as per unit, identified by e.g. a serial number.
Back in the old days it was common to develop the testing software as a software system separately for each product. This approach included most of the tests as software, inside the MCU. This development model produced many different architectures, with different designs and a large variety in software that basically does one simple thing: tests hardware components for existence and correct function. As you know, software tends to evolve...so we did some critical thinking on whether it makes sense to do the same thing differently each time - or whether we could come up with a more efficient approach? Turns out the concept can be made quite a bit simpler by aiming at higher reuse in the software and quicker implementation - both at the same time!