How do you design unit tests for automated processes? In software development its common to have unit tests for almost any discrete unit of code that gets integrated into a larger system. For GMP manufacturing automation, process design starts with functional specifications that specify much of the design space before any code gets written. The system can then be validated against these specifications once testing is underway.
I find unit tests extremely useful for writing complex robot scripts, because I don’t have to run the whole process in order to start debugging. For instance, if a script iterates over removing lids, I will write a test for just that process. If anything goes out of spec, I have a premade unit test to determine when that step is working again.
Having only worked in CLIA/FDA/GMP environments and taken a ton of software courses, this is what I can state…
It is extremely common in industrial automation and in my experience, lab automation to build something akin to a unit test although it may be called a functional test instead.
In fact, you may or will be required to write funcional tests for actions in a regulated environment. This is what can make method development or upgrades to existing methods so cumbersome. If you’re a director or manager, you should be asking your team to document the things a script will perform and there should be confirmation that the action is being performed. If you’re breaking up methods into subroutines or sub methods, the functional testing is easily built into the process.
I’m going to push back against this because akin to software, if a company says you have 6 months to complete a software project then you should assume you will get squeezed by a PM and should realistically have it complete in 4-5 months.
As a result, there are a subset of known actions that cover like 80% of processes in lab automation and building those ahead of time is smart. It buys you time to troubleshoot assays but also gives you a ton of flexibility.
In addition, the statement also assumes that industry is supremely well organized and that you will have all specifications before being asked to build anything which is flat out not true. You’re going to be asked to start building something that isn’t 100% complete because it’s 80% understood and so you can tweak the remaining 20% right? That’s super common.
A typical project I work on can have dozens of fully automated systems running on local schedulers, which also control liquid handlers running Venus, fluent control, etc. Systems are connected by Mobile Robots, tracks or sneaker net automation, and we have a higher-level Scheduler in the Cloud Orchestrating these systems.
It is essential to build out reusable components at all levels [Liquid Handling, System Integration, Orchestration] with clearly defined inputs and outputs. This will not only facilitate scaling but also allow us to use them for our Unit Tests.
probably you have automated tests in a mind. n software development its common to have unit tests, but they are used to test software units in an isolated environment. In order some software units/function the environment is mocked.
Writing complex robot scripts is related to automated integration or system tests. For any regulated environment you have to start with functional specifications that specify the tests and its environment.
For integration tests you can apply different strategies. The most common ones: top-down integratino testing and bottom-up integratino testing. For system tests you need to define a type of testing: functionality testing, performace testing, security testing and so on.