The “Non-techie” Scrum Master Survival Guide: What is an Automated Test?

explaining software things in simple terms :)

You do not need “techie” skills to be a Scrum Master, but having “techie” awareness is in our opinion essential.

Look, if you’re working in a car manufacturing firm, is it reasonable that you know what a steering wheel is? Yes. Do you need to be an expert in putting one together? No. Similarly, if you work in a kitchen, is it a good idea to know that hot oil can burn you? Yes, do you need to be an expert cook? No! You may be able to watch a dance show and identify salsa, but that doesn't mean you have the skills to perform it.

This is what I mean by having awareness with “techie” stuff vs needing to have “techie” skill.

Yeah but why do I need to be aware of techie stuff?

Can you name me one competitive industry in the 21st century that DOESN’T use software? Pretty hard right?

The likelihood is, you’ll be working with a team who uses software in some capacity.

How can you help a team if you don’t understand some of the basics of the things that they do to create value? A football coach understands what a pass is, a volley, what the off-side rule means. This important to help the team improve. There are things the team are trying to achieve with the techie stuff that you will want to support. Helping management understand we need to build a continuous integration infrastructure, the power of pair-programming, the importance of keeping up with our automated tests.

Don’t worry if you don’t know what these things are because this is a miniseries, we will teach you the key software concepts you should know as a Scrum Master to better support your team.

We begin our series with : Automated tests

Think about the things we automate in our daily lives: washing machines, dishwashers, automatic doors, bill payments. Why? Do they provide efficiency? Consistency? Reduce the need for human effort and minimize errors? Yes, to all of those. When developers automate tests, it shortens the time it takes to create value for the customer.

Think about that in simple terms.

A developer begins work, and that work goes through a lifecycle like anything else. Automated tests help with that process by making it more efficient. If the process is more efficient, it means we can deliver what we are building in a shorter period of time.

Automated Tests Help with Efficiency: What Does That Actually Mean?

The longer it takes to find a defect, the more expensive it becomes!

Imagine you find a small hole in your shirt. If you fix it right away, it's quick and cheap to repair. But if you wait and the hole gets bigger, it takes more time, effort, and money to fix. The same thing happens with defects in software. If we find and fix them early, it's easy and cheap. But if we wait and the defects cause more problems, fixing them later becomes much more expensive and complicated.

Learning fast is important for efficiency. Automated tests can give a developer faster feedback on a defect very early on, right from the development stage.

So, Didn’t We Always Automate the Tests?

In the old days, all tests had to be done manually, and it wasn't uncommon for every change we made to result in a person having to run through a full regression test. This meant they had to test every single feature in the application to ensure that nothing had been broken in the development of this work item. Quick side step to give you an example of a regression test:

Imagine we own the Amazon website. We just added a new feature that allows customers to use voice commands to search for products. Now, we need to make sure this new feature doesn't cause any problems with the existing parts of the website. Explanation: Imagine you work for Amazon, and developers added a new voice search feature to our Amazon website. To make sure this new feature didn't accidentally break anything else, we need to do a full regression test. This means we have to check every single feature on the website to ensure everything still works perfectly.

For example, we need to make sure:

• Customers can still add items to their cart.

• The checkout process works smoothly.

• Product reviews are displayed correctly.

• The search bar still finds the right products.

• Payment options are functioning properly.

Back to the Article

Do you see what a pain in the ass it could be to manually do the above?

In most applications, this is a large undertaking and could take weeks. Since this process could take a long time, guess what the result was? It was slow and expensive! Releases were very expensive! Why? Because we would have to batch up as many changes into one release as we could before we kicked off the great manual regression test.

Slow, expensive... ohhh and wait for it!

Risky! Lots of changes in one release create risk, lots of things that could go wrong! And when something did inevitably go wrong, the more changes we had, the more difficult it was to find the cause of the defect - and so on it goes. So now we’re back to a lack of efficiency because we can’t stop things from being broken all the time. Shit happens, but we do want an easier way to spot the problems that do pop up, and a giant change is going to be harder to figure out where the problems came from versus a smaller change.

Automated Tests to the Rescue!

Automated tests came along to the rescue. The idea was that we should be able to make a change, and then the automated tests will quickly tell us whether everything is working properly or not. Then we should be able to release the change. What used to take weeks, we could ideally now do in minutes.

But - as with all things technology, there was a massive increase in automated testing tools. There were unit tests, integration tests, smoke tests, UI tests, mutation tests, API tests, contract tests; the list goes on. (Stay in touch we will be creating blogs to explain all of these things!)

As teams tend to do, many would pick up the shiny new tools that are available, and some invested a lot of time into them, only to find that the tests were not helping them speed up their releases. In fact, sometimes the automated tests were slowing them down!

A Sad Example

I recall many years ago when we worked with one team whose automated test suite took 5 hours to run. So, the team would have a change they wanted to release, but in order to release it, they needed the automated tests to pass. As they took so long, they would run the tests overnight. But then the tests would often either fail or fall over and not run properly. So the team would have to fix them up, run them again, and this process could go on for days, delaying the release.

We didn’t know it at the time, but this team was not following the test pyramid.

The test what? Ah my friends, that will be your next lesson. In our next blog you will learn about this mysterious pyramid and why it is vital to understand for any Scrum Master supporting & serving software developers.

The Mentor club for Scrum Masters opens back up in July

I love mentoring and have been doing this for a while, helping people from all walks of life get their first job, as well as fine-tuning skills for those who are already experienced.

It’s always a question of creating time, so due to popular demand, I’ll be opening the doors again on July 1st:

• Access to Real-Time Experts: You'll have access to real-time experts like myself.

• Support for Interviews: Learn how to secure an interview and develop the skills to excel in it.

• Situational Questions & Answers: Get guidance on situational questions, from team dynamics to product-related queries.

• Extensive Resource Archive: Gain access to a large archive of resources covering methods, frameworks, and techniques for Agile and technology teams.

• Career Growth Focus: Learn how to focus on skills rather than roles to ensure your career remains attractive in the industry.

If you’re interested in joining us, you can message me here to reserve your spot.

It’s the cost of buying us lunch once a month—we're a pretty cheap date at $15 :)

All the best,

Jem & Terrence