GUI / Report / Application to help non-Technical testers extract “Test Data” needed for test

Community Discussion Automation Test
#1

Hi all,
Our UAT teams have several hundred scripts which require specific data for each scenario. the scenarios or “test personas” can be reused in future changes and development and the associated data is continuously refreshed.
The suite of scripts are in place but not automated / batch job. The business periodically ask for test data to meet their tests and I would like to give them the ability to self-serve.
To start with I would like to get them a Report where they can complete the following:
• select which test data records they need using checkboxes.
• if they need to run the full suite (obvious performance issues!) they can do so with 1 click
• there is a description on the each scenario but maybe a potential to have further filters on common searches within the data.
• the data could be exported to excel for their use.
• the ability to define how many records (SELECT TOP 100) need to be returned in the resulting data.
• the ability by myself to continuously add and edit new scenarios within the test data report.
Screen mockup included.

image
image940×289 58.3 KB

Are there any OOTB or Template Reports on PowerBI / Tableau examples that would meet such a requirement? Maybe a web application needs to be developed?
Any feedback appreciated.

#2

Hi Dave, I’ve never dealt directly with a UAT team before, is this subcontracted?

I suspect there is one big thing going worrying me here structure-wise, but then still a real need for a good tool… but that’s in itself another smoking gun. I’ve been planning to create such a tool myself(Profile - davecoleman - The Club) , but not sure how it should look or work, you may notice a recent thread on this very same topic. Generic in-house test data generator with a GUI. What might this look like? - #12 by devtotest

Problem #1 is that “the business” are asking “the builders” for a template machine that creates data that is following business logic and is thus data-consistent, to rules which “the business” itself created. The builders of the software are probably not supposed to be separate from the business, but it can happen. So ideally, they should be configuring the tool whatever the tool is. This is a warning that you might have a “team” that is being lazy, by just asking for data. If not actually thinking about what we do, the minute we stop thinking, we are not longer testing anything at all, and the entire exercise stops being quality centric, since it’s not testing anymore: (James Bach words, not mine Why Scripted Testing is Not for Novices - Satisfice, Inc. . )

I don’t disagree, you need a tool for this, but the tool needs to be configured by someone in “the business”, not by someone in “the builders” team.

Problem #2 Two teams, will want different things. Any such tool needs to be able to inject “bad user” data, or data that tries to break the business logic or the actual “input guards”. I seriously doubt that the first group of users of the tool want that at all, but your team clearly will want such a capability (I know I do.) I would also be wanting to regularly change and update the tool, for evil and also for good purposes (like differing app versions). This would be at variance with what the business want, and IMHO they are better of rolling their own generator app in the longer term as a way of creating a better responsibility as well as change management separation.

Starting to think a lightweight “locally hosted” portable web app might do what we are wanting here, and have found a source of data which might be used - will need to check commercial license on doing that. My concern is that the definition of what fields to output and what “options” are valid becomes a DSL(domain-specific language) itself if we let it.