In part 1 of this article we have seen the unique challenges faced by testers when they need to test a production instance for a SaaS application. In this part of the article we will see how we can tackle those challenges which we have seen in part 1.
Let us take the first problem we had sighted in part 1. It was to deal with testing data being used by actual users. When testers test a software application, they create some test data. Since in this case, the test data created will be on the same database as the one being used by actual users, the test data will be visible to actual users and by mistake they can use it. This will obviously create false transactions. How? Suppose, a tester has created a test warehouse named “warehouse1” and saved it. This data will be visible to actual users and if any of these users is transferring some material to this warehouse then it will be a wrong transaction as this warehouse actually does not exist.
I guess, now you may understand the problem of having test data in the user database. So how to avoid such occurrences? One way is to name test data uniquely so that all testers know a piece of test data immediately. Similarly this unique way of naming test data should be communicated to actual users So that they also know it is a piece of test data when they encounter one during their normal working with the application. One good way is to prefix all test data. For example, we can have test data with prefix of “QA_”. This way, all testing data will look unique and can be easily distinguished from normal user data.
One more good idea about testing data is to delete test data after testing is complete. This technique is especially useful when we have automation scripts and testers run these automation scripts to do their sanity, performance, security and other kinds of tests. The automation scripts should contain commands to first create test data and then delete test data when the script completes testing the application.
We will discuss strategies to deal with other problems in testing on production instances in part 3 of this article.