Why Relatable Data Is Important for Test Data Generation and Functional Testing

by Gregg Bolinger on June 7, 2013

First let me just say that any kind of test data is better than no test data.  That said, some test data is better than others for certain testing scenarios.  In this article I want to look at ways generic test data might be generated and how it can be sub-optimal for functional testing.

A lot of generators available today allow an engineer to generate a lot of generic data.  An example of a generic data generator might be a Name Generator.  While these have their place in the test data generation universe, they aren’t ideal for functional testing.  But why?

Let’s consider a list that might be generated by a generic Name Generator:

  • John Adams
  • Betty Smith
  • Henry James
  • Jim Bean
  • Sara Frank

There’s lots of great reasons to use this kind of data for testing.  However, let’s assume the QA engineer is testing user profile information management.  There is some sort of login associated to each user.  The QA engineer logs into the test server and the profile says Henry James.  Considering there might be tens of thousands of users in the system is there any way for the QA engineer to say with 100% confidence that Henry James is the correct data associated to the login that was used?  Before you think too hard about this, the answer is no.  Not without looking at the source of the data to verify.

Random generators suffer from the same limitations.  Again, while they have their place, it makes functional testing extremely difficult.  Including automated functional testing with tools like Geb or Selenium.

Relatable test data is a way to take various pieces of generated test data and ensure that at a glance you know they are correctly associated to each other.  Ask yourself how important it is that you see Sara Frank when testing.  Is seeing Jim Bean proving anything for you?  Consider this:

Name

  • Name_10001
  • Name_10002
  • Name_10003
  • Name_10004

Address

  • street_10001
  • street_10002
  • street_10003
  • street_10004

Avatar

  • image_10001
  • image_10002
  • image_10003
  • image_10004

Now let’s assume that the QA Engineer logged in with the username: user_10003@test.com

When they visit the user profile page they see:

Name: Name_10003

Address: street_10003

Avatar: image_10003

The QA Engineer is immediately able to confirm that all the correct data is being displayed.  An automated test can be scripted to look for specific data points based on the login information and assert with equal confidence.

There are a multitude of testing scenarios where the actual data doesn’t really matter as much as data being there.  However, for functional testing, where the human eye must confirm the data to be accurate or an automated system must be able to assert with 100% accuracy, relatable test data is vital.

 

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: