In some testing environments, there is a belief that using production data to test your software will ensure that you will find bugs and therefore create the right tests both in quality and quantity.
There are too many things wrong with this way of testing. If one is waiting for bugs and edge cases to be found in production in order to fix and prevent bugs in the code base, then it points to major weaknesses in the testing environment. Some of these weaknesses include:
Inadequate testing prior to production deployments which leads to the high probability that many bugs will appear in production yielding a bad user experience and possibly the corruption of production data.
Few, if any, unit tests for testing small blocks of business logic.
Few, if any, integration tests to check the results of larger interacting units of code.
Few if any load tests to check the code under load.
Little to no functional tests, manual or automated, to validate the user interface is stable and bug free.
Test data that is written around production data is production dependent which means, as soon as the production code changes (and it will), all of the tests dependent on static production data conditions and formats will fail or at minimum become obsolete and no longer used.
Reactive Testing is the philosophy of waiting to write tests for bugs after they have been uncovered in production. It’s costly and built around a failure mentality. It’s like waiting until you’ve lost the game to study how your opponent beat you during the game (reactive) as opposed to scouting out your opponent long before the game, learning their strength and weaknesses and being prepared to win the game before it is played (proactive).
Proactive Testing is finding infinite ways to test and break your software before it goes to production. The overall goal should be testing 100% of the code base. A testing team settling for anything less is not prepared to win the game.
So, how do you become proactive? How do you test without production data? You become proactive and take control of the testing environment by creating Synthetic test data. What is Synthetic test data? It is data that is generated to meet the requirements of the tests you need to run in order to validate your code base. The generation of good synthetic test data gives one the autonomy to think and implement infinite solutions to test ones code base (proactive). Good synthetic test data allows one to:
Generate small amounts of data to unit test small units of code
Create complex scenarios to test difficult integrations challenges
Build large sums of data for load and performance testing
Produce realistic synthetic test data to achieve accurate functional testing
