Tests at the system level face several problems that unit tests do not, but none is so persistently and universally troublesome as test data. Your test expects the system-under-test to contain data in some state: customer accounts with certain characteristics, documents of certain sizes, inventory records of a certain kind, whatever. How do you ensure that the system actually contains the expected data? How do you tie the data to the test so you can track which test expects what? How do you prevent one test from contaminating data required by another? In this session, 20 year testing veteran Mike Duskis won’t present a universal solution because he is unaware of one, but he will help you understand the problem and provide a toolbox of options that may be more or less suitable for your context. Then he will show you a recent breakthrough at CyberGRX: a mechanism that allows tests to declare their data requirements using a YAML dialect and then assume the data will be there for them.