An important factor in automation framework design is managing your test data. Mismanaged test data for complex applications, for instance an ERP, could make life miserable. I often see teams not putting enough focus on this making their automated scripts flaky .<\/span><\/p>\n

Understand the product<\/h2>\n

Certain traits are common between application types, ERPs would have very complex test data, SaaS applications providing simple services, might have limited test data requirements and so on. However, it is paramount to understand<\/p>\n

1. your application and the kind of data the tests might need.<\/p>\n

2. Different methods through which the data can be created and removed (front end, web services, SQL scripts).<\/p>\n

3. The amount of test data you would need per test, I automated products having 5 \u2013 10 fields per test and 150 \u2013 300 fields per test too. A large amount of data would have a VERY AMUSING impact on your tests.<\/p>\n

Components of test data management<\/h2>\n

There are three main things to consider for your test management strategy. You can use different patterns which will use a combination of these factors.<\/p>\n

\n
• Storing test data<\/li>\n
• Creating test data<\/li>\n
• Cleaning test data<\/li>\n<\/ul>\n

  The image below will give you a quick summary<\/p>\n<\/div><\/span>

  Storing data<\/h3>\n

  what test data you scripts needs would have to be stored somewhere. Teams start with writing needed data within the scripts, then into excel files. I personally am not a big fan of writing data in excel, but if it serves the purpose then fine.<\/span><\/p>\n

  Creation & deletion strategies<\/span><\/h3>\n

  You might want to create test data for the AUT (Application under test) or a downstream application which in turn will be used by your AUT.\u00a0 There are many ways in which data can be created \/ deleted and here are some common ones.<\/p>\n

  Through API<\/h4>\n

  Create needed data by calling the application’s API. This is relatively a more robust way and less time consuming. However sometimes some applications do not services developed in an intuitive manner making it difficult to use them. Secondly stability of these services can be an issue depending on what infrastucture \/ or environment the application is running on. Deletion might be a bit trickier here.<\/p>\n

  If you have a legacy application and the services are not not built very well, a ‘test data creation’ wrapper service can be created to facilitate that.<\/p>\n

  Through UI<\/h4>\n

  Create data by running the flow in the UI. Thankfully I’ve never had to do this in any project I worked on, however have seen some folks doing this. Not recommended at all.<\/p>\n

  In the database<\/h4>\n

  Another way is to create needed data in the database of directly. Writing SQL statements to create data needed can be tricky, the business logic might keep changing and you might run into issues of not creating data the way the application current version is supposed to.<\/p>\n

  Deletion might be easier, but again you’d want to be sure your not disturbing the process flow of the application.<\/p>\n

  Deletion of data<\/h4>\n

  A lot of folks just don’t delete data, and create new records every time. Might not have adverse affects in the short run, but you should have a purging strategy to remove all that data.<\/p>\n

  In some teams I’ve seen the restore to an old baseline state after few months which could be an option.<\/p>\n<\/div><\/span>

  <\/h2>\n

  Design patterns<\/h2>\n

  There are some common design patterns teams follow to manage their test data. A summary of the few discussed in the image:<\/p>\n

  Create & delete<\/h3>\n

  The no brainer method is to create a specific record each time you run the test. Creation can be done through, again, Front end UI, web services or scripts adding rows to the database. The bright side here is it\u2019s easy to debug and update. If this can be done in a very reliable and efficient way, no harm in using this.<\/p>\n

  However I’ve noticed many times reams under-estimate the problems they’ll run into while using this and eventually end up creating flaky tests. Make sure to have a robust creation mechanism and deletion strategy.<\/p>\n

  Create records needed<\/h3>\n

  Slightly different from the one above, don’t attempt to delete data. Just keep creating new records. Again if that can work for your application, no harm. However it’s likely if you have a lot of transactional data in your application this might not work. If you don’t delete records and keep creating new ones eventually you might run into no\u00a0 more room to create new records due to how data is processed in the AUT.<\/p>\n

  Even if you don’t have to delete, you’ll have to purge them at some point in time.<\/p>\n

  Random data<\/h3>\n

  Some might not like the \u2018delete at the end\u2019 part, I don\u2019t! Sometimes cleaning test data feels like getting that body fat off, every time we reach a great formula to solve the problem, it finds a new way to \u2018stick around\u2019.<\/p>\n

  The idea for random data is creating a new record every time we run the test. This way the record created last time does not affect our test. Since silver bullets do not exist, random data also has problems. Firstly, creating truly random data. This is more of a math problem, most algorithms tend to start repeating a pattern and the string generated is no longer as \u2018random\u2019. Secondly, if we keep adding body fat, eventually organs start to fail. Similarly, the test environment will over load reaching a point where it becomes unmanageable. We might have to get liposuction at some stage then!<\/p>\n

  Dependent data<\/h3>\n

  For x number of tests, you would need x test data creation methods. Some tests can use data created by the previous test. For instance, a shopping cart application test case verifying a cart payment would need test data adding products to the cart first. Instead of adding data as a pre-requisite to this test, use data created by the test adding a product to the cart.<\/p>\n

  Main drawback here, if the previous test fails, the next test will fail due to the previous test which we do not want.<\/p>\n

  Add to AUT<\/h3>\n

  Some tests do not perform transactions on any record, which means the data remain in the same state, before and after the test. Such tests can use data created in the application once, and no need to create or clean again.<\/p>\n

  This method has no real drawbacks that I came across (yes, sort of a silver bullet). However, you would not find many test scenarios where test data does not change during the test. Where this can work, the best strategy to use.<\/p>\n

  Restore DB<\/h3>\n

  The last and most favorite of mine, have a baseline version of the AUT. Create all needed data for each script separately and take a snapshot of the database. Before each execution, restore the DB. This way you;ll not have to create data or remove it at the end.<\/p>\n

  The process is a bit lengthy, but if you have lots of transactional data, this will work like a charm.<\/p>\n<\/div>

  <\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[39],"tags":[],"yoast_head":"\n