distributedlife

Something that I don’t see many testers realising is that there is more than one type of data in your data stores. There are in fact two types; identity data and anonymous data.

Both of these present challenges to how you setup your manual test cases and whether your automated scripts will have longevity. I won’t talk about anonymous data too much as it is the most common you see it everywhere. If you have a spreadsheet (data) on your personal drive that only you can access (a privilege) the spreadsheet is still anonymous data. What determines if you can see it is the privilege and it’s the privilege that is the identity data.

The problem with identity and anonymous data is that they are a form of state data; data that needs to exist before you start your test. That spreadsheet needs to exist and your user needs to have that privilege. This setup process wastes time and isn’t testing.

I see manual testers over and over again setup their account to have the privilege; test accessing the spreadsheet. Then they will remove the access and try again. A new cycle commences and they start again.

If you’re writing automation tests that simulate the UI then you can speed up the test execution but at the cost of automating data setup. Data setup isn’t part of the test and these extra steps make your automation scripts more fragile. If the data setup process changes then your script breaks.

If you’re writing service tests then you don’t get the UI and you can’t run the manual steps beforehand otherwise it wouldn’t be automated. So you’re left with two choices that force you into better testing habits: you create the data in advance or you create it on the fly.

The former introduces management issues. How do you ensure the data remains consistent for the life of the test? What do you do if the data you need doesn’t exist? What if you want to delete data during a test? The second option increases complexity. How do we create the data easily, reliably and without making our test brittle?

Creating Identity Data

With identity data where possible I try wherever possible to create this data in advance. When I need a user with spreadsheet rights then I log on with User HasAccessToSpreadsheets. I need a user without access; then I log in with User NoAccessToAnything. Overtime you will increase user identities so you will need to write them down in a safe place. I’ve got 140 in my list at the moment. Not all are allocated but I need room to grow.

One of the biggest benefits I get from prepared identity data is that my automation scripts are identical except for the identity the test is run under and the expected outcome. When you’re testing the various aspects of security this is how it should be; reducing complexity wherever possible.

If you can’t pre-create your data because the number of user identities will blow out you have then I recommend you create as much data as possible and automate the creation of the remaining data.

Example: The recently viewed web pages in your browser. The user identity can exist in advance (you only need one with enough permissions to do the work) and the web-sites can exist as well. All you will be creating is the relationship between the user identity and the web-sites. The process is: at the start of the test delete the history list and create it as you need with one, two or fifty entries. Next test; same user identity, delete the history and recreate it to test your next scenario.

This way you can keep your user identity count low whilst still gaining the benefits of prebuilt data.

Creating Anonymous Data

The decision to manually or dynamically create anonymous data is usually based on the complexity of it. If you need a 2GB file to test whether or not the File Upload service you have been asked to test will work, you are not going to create it on the fly. You have that file waiting to be used, right next to the zero byte file and files with unconventional names.

If you’re manual testing then I would also lean towards creating the data in advance. Manual testing and UI automation should be from the purist testing approach and not create data on the fly. Spend a day or two at the start of the project creating all the data you need. It’ll save you time later on.

If you’re automating services or integration components and can create anonymous data on the fly then do so. It’s save you time and reduce the complexity of the scripts.