Tools are great. Tools can make you and your colleagues’ work lives so much less tedious on a daily basis.
Where I work we have various long, complex processes that are incredibly easy to get wrong and spend half an hour trying to figure out what the problem was. Was it step one? Step five? Who knows – start again!
The biggest culprit for this kind of frustration is our “order” making system. It’s big, complex, and requires filling in around 25 fields in a CSV each time you want to make a single order. Several of these fields – when grouped together – must be unique from any other order made on the system. Several fields have very specific values that they must be. Making an order is like navigating a minefield, especially for new members of QA, who are likely to encounter this system days after starting.
If you’ve read the title of this blog post, you know where this is going. So how does a QA/test tool help out here?
The Manual Process
This order system we have has several steps to it that require very specific actions.
- Create a CSV with very finicky requirements for several field values
- Zip it up in a file that requires a very specific name (that changes on a daily basis)
- Make sure you password that zip file with a very specific password
- Send that file either via email or SFTP to one of several different locations depending on environment
- Wait a while for the file to be consumed and your order to be created
Each order could take upwards of 20 minutes of faff to complete when done entirely manually.
In our tool we’ve made it possible to complete the entire process from start to finish in under 10 seconds.
Default Everything
For CSV creation, the majority of fields are presented to the tester as free-text boxes with default values. Where possible these values are randomised, but always randomised to valid and realistic choices. E.g. we pick from a pool of first names, surnames etc.
For the majority of the times we have to run through this process, we end up only filling in 2 of the 25 fields by hand. The default values get us most of the way. That’s a huge time saving.
Lock It Down (But Not Too Much)
For CSV fields that only allow specific values, we lock them down using select boxes, just like on a website. The select list is populated with all the valid values, as well as some invalid ones (that are clearly marked as such). This allows the tester to see all the available values, whilst also being able to send an invalid value for more extensive testing of negative paths as required.
To make the tool as versatile as possible, I would recommend avoiding making it “too helpful”. What I mean by this is locking field values down too heavily. Always allow bad values if the tester really wants to put them in. We want to guide them to the happy path, but allow them to veer off when they need to.
Abstract Out Tedium
The tool completely abstracts the next few parts of the process. Zipping up and sending the file is done with the click of a button. There’s no value in our testers going through this process by hand, it’s tedious busywork. As long as testers understand enough about the process that’s going on in the background, they really don’t need to go through it each time.
Environment choice is handled in much the same way. Testers get to pick an easily recognised name from a list rather than having to remember various different server URLs, and folder locations on those. The tool just handles it.
Good Feedback
After the order is sent to the server, the tool goes into a “checking if stuff worked” mode. It loops until it finds a specific entry in the database that tells us the request succeeded or failed.
The first piece of feedback we use here is a progress bar. This bar switches colours depending on what’s happening. Blue means the order request is in progress. Green means success. Red means the process errored/failed in some way. It’s basic stuff, but its importance shouldn’t be overlooked.
For any failures, we present them to the tester in an output log within the GUI. This output includes any information that was stored about the specific problem straight from the process that consumes the orders. This saves a lot of time explaining to our testers where the errors are stored in the database, as well as having to track down the specific row each time a problem occurs. Easy access to available information is key here.
QA Goose 