The Test Data Generator (TDG) is a serverless application, written in python with an angular frontend. And while this is the technical answer, it doesn't answer the question. Even worse, you probably have more questions now.
In software testing, it is not always easy to acquire valid, diverse, and complex test data. At b.ignited we recognized this struggle. That's why a couple of our Automation Engineers worked together to create our own TDG for the world to use. The TDG is our attempt to generate valid test data, with a heavy focus on unique numbers and identifiers. And we do this because it is quite difficult to type a correct Social Security Number or IBAN, without first having to do complex calculations.
One of the major hurdles inside testing is finding valid, randomized test data. How many projects do you know where there is a list of IBAN's or social security numbers somewhere in confluence. And let's be honest here, ‘somewhere in confluence’ is painfully true.
Our Test-Data-Generator is built specifically to provide testers with easy access to valid test data, regardless of the complexity of that data. And we wanted to provide for both our manual tester colleagues as our own automation needs.
During one of my projects, I needed several unique identifiers. And as I've mentioned before, there was a confluence page filled with any number I could want. Well, except when the test case required a social security number for a pensioner.
So I did what any engineer would do and opened Google to look for a social security number generator. That test case finished, I moved on to the next. Which presented itself with the same problem. This time it was a child younger than 6 years but older than 4 years. So with renewed hope in the confluence page, I started looking. Obviously, my hopes were quickly and soundly dashed. No one has ever come back happy from confluence.
For the next few days, that was my routine. I needed a social security number, I checked the confluence, got disappointed, and turned to Google.
Until I needed something different, an insurance case file. Again I got the advice to turn to confluence. Which gave me a list of about 50 numbers, all of which were already used. And because they were used, they were useless to me unless I cleaned the database.
And that was the proverbial drop that broke the camel's back. In all my frustration, I did what any engineer would do. I wrote some code. Using python, the first iteration of the Test-Data-Generator was alive. Granted, this was a fairly basic CLI program, but it represented something more. Freedom from the tyranny of confluence, randomized test data.
The obvious next step was, besides expansion, to share my program with anyone who wanted it. One of the first considerations was that my fellow testers preferred not to use a CLI program. So the application required a user interface. Converting a python command line program into something with buttons was a new and exciting challenge.
After hardly any deliberation and consideration, I opted to use Tkinter. The tiny Test-Data-Generator started on a path towards it second iteration. Extra functions got added alongside the user interface.
But the most telling change, was the first user feedback. People started to use the Test-Data-Generator. In some sense, those were the first alpha testers of our application. To share the app, it even existed as an executable for a very short period of time. Let's call that iteration 2.5.
After a long period of silence, together with my colleagues at b.ignited we resurrected the application, or at least the idea of the Test-Data-Generator. We needed a way to reach everyone.
This was the point where the Test-Data-Generator was no longer my little application. Together with several colleagues, we transformed the tiny CLI that, into a network of AWS lambda functions, cloud be managed by AWS Serverless application management, triggered by the API gateway for all to use. And to enjoy.
And for those that wonder about the frontend, that’s a story for another time.
As always, happy testing!