Expert Testing Advice: 10 Industry Leaders Share Their Top Tips

Learning and Improvement Ideas Testing Starting in Testing

Introduction

Over the past 10 years I’ve interviewed some fantastic software testing experts in our industry. In this blog post, I will 10 tips that these experts have shared, along with a link to the original blog post so you can read more.

1. Changing Your Mind About Certain Things by Lena Nyström

I used to LOVE waterfall projects. I felt I could only do good testing if I could plan forever. A horrible project around 2014 forced me to try something different and the results amazed me. I guess Agile wasn’t so bad after all :-D

I didn’t trust developers with testing. A few amazing people showed me how much more powerful you become when you work as a team. And I guess I improved my soft skills enough to stop treating them in a way that alienated me so today I work much more through nudging and suggestions and less through “Stop doing the same stupid mistakes CHILD”

I thought testing in production was a mirage. I have seen first hand how amazing it can be to let go of control and trust in the fact that someone will actually notice, prioritize and fix when something goes wrong.

Being able to deploy many many times a day even in a non-microservice environment is not impossible and it is bloody cool!

It is easy to convince people through facts. It isn’t. Emotions are so much stronger. It is impossible to convince management to prioritize big projects/improvements. It isn’t. You just need to figure out what motivates them.

Initial interview with Lena Nyström

2. Challenges You May Face as a Tester by Aaron Hodder

One, is the constant learning you must do as a tester. Every project has something unique about it which requires you to upskill quickly. Even having to rapidly learning about a new client, and what’s important to them, what they value, all about the problem that this software is supposed to solve, through tot he technical solution before you’ve even considered how you’re going to test it can be very challenging.

The second challenge, and the one most difficult is communicating that the way I test may be different t how you’ve seen others test before. There can be resistance when you suggest that pre-scripting tests upfront may not be the best use of your time, and it’s easy to displace your frustration at those asking for test scripts, rather than those that make money perpetuating the folklore that testing is merely the writing and execution of testing scripts.

Initial Interview with Aaron Hodder

3. Lesser-Known Useful Browser Extensions by Ajay Balamurugadas

You can find more at Ultimate Productivity Toolkit.

Initial Interview with Ajay Balamurugadas

4. When to do Exploratory Testing vs Test Cases by Callum Akehurst-Ryan

Test cases and scripts are for when we want to confirm what we already know to be true, so they’re great for regression or in an environment where things are highly designed by specification. Generally on my projects, these get automated so test scripts are an awesome candidate for automation.

Then we use planned and structured exploration to investigate what we don’t know about. This is really powerful in times of uncertainty where things are not strongly specified, or when we’ve used user stories to specify the what and not the how. We can explore to find out how something can be done and then playback quality narratives about how that works.

Although I think exploratory testing is something we can always use, we might not want to always use it. It’s something that some organisations, teams and testers are not familiar or comfortable with and you have to be able to advocate for its use in an organisation.

I’ve written about sharing exploratory testing with developers and there are resources out there if you’d like to do the same. However, if you or your team / organisation don’t want to push for this style of testing then it may not be a good fit for you.

I’d recommend trying it though: it’s a good skill to have, helps build rapport with your team and is fun to do.

Initial Interview with Callum Akehurst-Ryan

5.Express Uncertainty As a Software Tester by Elizabeth Zagroba

You don’t have to literally say “I don’t know.” My advice is: Show your work. Noticing when you’re not sure about something, decide to seek an additional reference point or do more exploratory testing, and share the information you’ve gathered so your peers can be involved in the decision.

It’s the difference between “204 responses don’t have a response body” and “it says here on httpstatuses.com that 204 responses don’t have a response body." It’s the difference between reporting “I finished testing, we can release it.” and “I looked at Sjoerd’s branch on the test environment with an admin user.” at standup.

Telling the slightly deeper story lets your team ask “Was Sjoerd’s branch the right one, should we look at the rebased version on the development branch?” or “Did you try a regular user in addition to the admin user?”

I’m also curious if someone who struggles to say “I don’t know” is in an environment where it’s possible (or even better, rewarded) to admit doubt. If their environment doesn’t foster this kind of thinking, I’d begin to wonder why that is and dig in there instead.

Initial Interview with Elizabeth Zagroba

6. Example of a misconception of Software Testing by Kim Engel

The biggest misconception I hear about testing is that it’s boring. If you find testing boring, you’re doing it wrong.

Try researching a new approach; learn more about your product; use some competing products; chat to your customers in online forums; read a free online testing magazine; find or start a tester meetup in your area; read\\write a blog about testing; chat to other testing folk on Twitter.

I’m sorry to say that I’ve met many testers who do none of these things, and they complain to me that testing is boring.

Initial Interview with Kim Engel

7. Starting with Accessibility Testing by Laveena Ramchandani

I started accessibility in a very odd situation, I was rushed into a meeting and asked have we done accessibility testing once the banking app went live! I was so confused and started thinking what is accessibility testing.

That experience really pushed me to learn about it all and make sure wherever I go I keep sharing the knowledge. I got told once we shouldn’t do accessibility as we are delivering a b to b project and not a b to c. That really shock me and I started moving things forward regardless of what I was told. YOU will face this at some stage in your lives, if you see someone who lacks knowledge, go ahead and share that knowledge as you never know you may save a firm from a juicy fine!

Resources I would recommend:

Difficult parts within accessibility for me were to understand what particular things meant, specially the errors such as ARIA, page formatting errors which were straight forward for a front end developer. What I started to do then was to pair up with them and learn. As I always say “Pairing is caring”.

Initial Interview with Laveena Ramchandani

8. Biggest Misconception of Agile Testing by Lisa Crispin

One thing I see a lot is that agile teams will have a tester or two embedded on the team, yet, they still practice mini-waterfall. They hand off everything to the tester(s) to validate. They don’t embrace the whole-team approach, they don’t focus on bug prevention instead of bug detection. This doesn’t scale, one or two testers cannot keep up with the output of three, four, ten coders. Managers who are often ignorant about testing think they just need to hire more testers, and that is usually not the solution to quality problems.

I’m still often asked “what is the correct ratio of coders to testers?”

There’s no correct answer to this.

I’ve worked on high-performing agile teams where we needed as many or more testers as coders, even with the team practicing TDD, ATDD and everyone pitching in on testing tasks. The code wasn’t hard to write, but the business domain was quite high-risk - production failures could cause both customers and the company to lose money, or violate laws that would make the business fail. We had to be sure the product behaved perfectly.

I’ve worked on a product - a project tracking tool - where it was ok to have two or three testers for 30 programmers, because the programmers also used the product and understood it well, the risk was low (it’s inconvenient to have your online project tracking tool go down, but generally does not a huge financial loss or loss of life), and the team were expert at TDD, pair programming, exploratory testing, continuous integration, and automation.

As testers, we acted more as testing consultants and coaches, to help everyone learn the testing skills they needed.

Initial Interview with Lisa Crispin

9. Embarking on a Testing Tour by Lisi Hocke

My testing tour was yet another challenge I had, pairing with lots of different people on lots of different topics. I really relate to the difficulty of approaching strangers and setting out on such tour, especially publicly. Well, it was meant to be scary and get me out of my comfort zone so I could also really grow with it!

What really helped me was to make use of relationships I already had built and start with them. My very first tour sessions were with people I met at conferences and colleagues - this way I could also gain experience on how to prepare for these sessions, run them and follow-up to get the most out of it for everyone. The more sessions I did, the more confident I grew, and the more it enabled me to ask further people to join me.

At some point, I did not even have to ask myself anymore, strangers approached me directly or just booked a session! That made it easier regarding getting connected, yet came with different challenges to get us started on the right track.

Why to embark on such a journey? Whatever it is that makes you set out on a tour, it should fit with your personal goals. For me it was the fact that I always was the lone tester, or the most experienced one - and I was very unsure about my own testing skills. I was eager to see how others approached testing challenges, get to know different specialties like security or accessibility testing, and more.

What I gained was a lot more knowledge, skills, tools, and a lot more awesome human connections as well. Doing these sessions for ten months was one of the best things I ever did during my testing career and granted me lots of opportunities later on.

Initial Interview with Lisi Hocke

10. Learn About Strong-Style Pairing by Maaret Pyhäjärvi

Strong-style pairing is an approach to pairing framed on the idea that we can keep the pair more engaged on the shared work by choosing how we split the work in the pair. In strong-style pairing, the idea of what to do starts with the person off keyboard as voicing out the idea. So if you have the idea, you say, take the keyboard. In traditional pairing it is the other way around, you pass the keyboard to the person with the idea.

For years I paired traditional style, and felt particularly disconnected with people I did not have a strong relationship with, or where our skills were either on different things (programming vs. testing) or we were on significantly different levels of skill. Strong style distributes the work and allows the person off keyboard to do more than review. And it solves the problem of how hard it is to talk while you write by not forcing you to carry both in the pair. Rules help with pairing with new people, and the same rules allow for growing from pair to an ensemble – more than two people sharing the task.

Also, a complete newbie to testing or programming would have hard time pairing any other way. Pairing is so important for new people, but to learn effective they need control over the pace, with their hands (and their working computer) on that control of keyboard. New people – well, established people too – don’t know how to ask for things they don’t know they are missing out on. Pairing reveals so much of that unknown unknown in tools, techniques, approaches and thinking.

Any style of pairing won’t be suitable if people are unwilling to pair. And when pairing, I have a personal preference towards strong-style pairing.

Initial Interview with Maaret Pyhäjärvi

Will publish another blog post soon with 10 more tips - stay tuned!

Learning and Improvement Ideas Testing Starting in Testing