The Ultimate Tester: Build Quality In

One of the most important aspects of agile working is the fast pace. In an ideal world, you can deliver to production constantly. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. We no longer want to give feedback about the product with a manual regression testset that takes days or even weeks. That’s simply too much time to waste. Let’s stop that nonsense, we’re better than that.

Before you start automating your regression test on GUI level, hold on a second. Think about what you want to achieve first. What do you want to test on which layer of your application? There are a couple of helpful concepts to help guide you: the testing pyramid, testing scales (to help you map out components of your application and think about how how heavily you want to test those)  and the agile testing quadrants (to see what types of testing you have used and what you are still lacking). Always consider your context and where the risk is, do not write tests without asking yourself what value they provide.

Usually, we want a lot of unit tests because they’re the fastest feedback we have. This is often something the developer does him/herself. Then the interesting part starts: on API level we usually have a lot of business logic so that’s where most of your automation effort should go (again: think of your own context, of course). On GUI level, you hopefully don’t have much business logic so you can use a smaller amount of automated checks there, or a tool that makes screenshots on many different screen sizes, browsers and operating systems so you can compare them and look for visual errors.  Think about when you want to test a component in isolation, and when you want to test integration. Research widely used programming patterns for test automation. Figure out if your infrastructure can handle all of your tests; can you easily do a set up and tear down as part of your test run? 

Common pitfalls

You also have to be aware of some common pitfalls when it comes to automation. As a rule of thumb: do not use record and playback to build your test suite, this will soon become a maintenance nightmare. Do not believe tool websites that claim “you don’t have to be able to program in order to use our tool”, because automation always involves programming. Do not believe that test automation will save you money; that is not the goal! If you properly integrate automated checks in your build pipeline, that is also code you have to maintain and keep clean. The time that you don’t have to spend on doing regression tests can be spent on doing useful testing yourself. Proper use of automated checks paves the way for a broader test coverage and test depth. When you find a defect this way, you can decide to write an automated check for it to make sure it doesn’t return again.

There are even more pitfalls, such as: believing that everything can be automated and that when all the tests are green you have built a quality product; that’s a false positive. Not having control over your test data setup and teardown when a test suite runs, so you have brittle tests. And there are probably many more. If you like, leave an example in the comments.

Looking at all the pitfalls, it is all to easy to get demotivated. So many things that can go wrong, so many things to consider. Do you have to personally know everything to be able to do this by yourself? No, as always, it is a team effort. This also begs the question: do you have to know how to program as a tester? I don’t think the answer is black and white, but I will say that it helps tremendously. If you don’t know how to program, however, there are still a couple of things you can do. You can help the team with deciding what you want to automate on which layer of the application, based on risk. You can help with creating the test data, the test types, the test ideas. You can also learn how to program; there are so many awesome (free) resources to help you with this: Coursera, Codecademy, Udacity, and many more. I think it is worth the effort and time. You don’t have to be as good as a developer, but your testing skills will also benefit from more technical knowledge.

Don’t forget the why

The end goal of all this is to speed up the feedback loop while still maintaining a good level of quality. The organisation you work for has to support this way of working. If there are still processes that go against this, like ‘acceptance test moments’, ‘QA sign-offs’, ‘GO/No-GO moments’, it is time to get rid of them. Some of you might wonder why it is bad to have acceptance testing. The concept in itself isn’t bad, but the fact that it slows your release cycle is bad. Think back at the second blog post in this series about creating value. If you can involve the business early and write acceptance tests up front, you have more confidence in that you’re building the right thing. You won’t need the official moment anymore and you can focus on also building quality in (building it right).

To summarise: automated checks at their appropriate system levels give you continuous feedback about the technical quality and possibly even the purpose of your software. This approach will truly flourish if the test code is treated like any other type of code. Clean coding principles apply to test code as well and it is a team effort. As the ultimate tester, you should have enough technical skills so you can add value in this area as well.

Information to explore:

• Clean Code (book)
• Test Driven Development (book)
• BDD In Action (book)

Qxperts. We empower companies to deliver reliable & high-quality software. Any questions? We are here to help! www.qxperts.io