Overview of Technical Testing

This week's blog comes from our guest writer, Renée Mineart.

One of the first lessons taught in every writing class I’ve ever taken is the concept of “show, don’t tell”. 

When writing a bit of prose, you always want to show the reader what is happening in a scene as opposed to a short summary telling them what happened. “Bob fell out of the tree” isn’t nearly as impactful as “Bob put his full body weight on the branch beneath his hand as he planned the next stage of his climb but the branch was unable to support his weight."

"There was a crack, then a second crack as a look of shock crossed Bob’s face along with a sharp intake of air. His screaming rang throughout the neighbourhood as he fell down between the branches, landing, to his great relief, on the pile of leaves he’d just been raking." Isn’t that more impactful? Not just for Bob. 

The idea behind "show, don’t tell" is so the reader can visualise and feel what the character is experiencing. That’s how we keep a story engaging and the reader interested. We can bring this same approach of engaging with our audience into the software development and testing world by changing it slightly. Instead of “show, don’t tell”, we’ll take the approach of “show-and-tell”.

When I first learned HTML and CSS, I bought a book on the subject and went through it page-by-page, reproducing every exercise from the book on my computer. I made notes in the book and used an excessive amount of post-it notes to flag key topics that I’d want to return to. 

When I taught myself Power BI several years later, I used training videos or the visual 'show-and-tell'. I don’t have a Power BI book full of post-it notes but I do have a stack of bookmarks for YouTube videos in its place. 

Communication in the agile development world tends to be very fluid and frequent. As part of the development team, we have daily scrum meetings that are very short and focused on that day’s activities. We have planning meetings and user storyboard meetings then we wrap up a sprint with retrospective meetings. All of these meetings are designed to keep everyone on the same page and the project moving forward. 

This isn’t to imply that documentation isn’t important. It is. But we also need to appreciate when a bit of show-and-tell will help to get our message across in a more powerful and impactful way. This is particularly helpful when it comes to user acceptance testing (UAT) and engaging with people outside the dev/test world. 

For one project on which I was a User-Tester, we were given a huge spreadsheet detailing what needed to be tested, who already tested it, what their results were, what the developers were looking for, what criteria to use, etc., etc. The spreadsheet had about 300 rows of information and was 20 or so columns wide. The instructions were far more daunting than the actual testing we were being asked to do. In fact, I would say the spreadsheet was very off-putting to the whole process. 

As a User-Tester, I didn’t want or need to know all of that information, and I certainly didn’t want to take the time to decipher what parts of it I did need to know and what parts I could ignore. I just needed to know how to log in and what sections they wanted me to break. I mean test.

This is where a short show-and-tell session works great! The key is, just as with storytelling, the audience needs to be able to visualise what you are asking them to do. Sometimes, nothing beats just sitting down with someone, showing them what they need to test and being on-hand to answer questions. 

Your User-Tester may be putting off doing the UAT because they just can’t get their head around what needs to be tested. Taking five minutes to show them how to log in, get to the right screen and do the testing may be all that is needed to get things moving forward. 

Often, this five-minute chat, while looking over their shoulder or sharing a screen, is much more effective than a ten-page document or massive spreadsheet with step-by-step instructions that took hours to write. 

What if you have twenty or thirty users all doing UAT on a project? Then I’d suggest booking three or four drop-in sessions where they can log in remotely (or attend in person) and get a short tutorial on how to get started. I’ve found this very simple method of communicating with users will significantly increase user participation and feedback. Especially if it gives them a face and a name to go to with questions and outcomes. 

In fact, in the above example where we were given a large spreadsheet, the Project Manager did replace this with a number of drop-in sessions. He did this because the testing had stalled. Why did it stall? His User-Testers couldn’t figure out how to get started and were put off by the huge amount of information. 

You can also apply this same approach when going back to the development team with the results of the testing. Yes, you do need to document and capture all the defects and bugs in some detail. However, you’ll find that a short meeting where you can demonstrate the errors to the dev team may help them to understand and visualise the problem a lot faster.

Then, the documentation becomes supporting material and a document trail of bug fixes. It doesn’t really matter if you are working in the world of words or software development. The objective is the same; engage with your audience in such a way that they can digest and remember the information. Often, the best way to accomplish this is to engage with them visually. Show-and-tell is always better than just telling.