Beyond Bugs: Testing IRL Part 4

Reading Time: 5 minutes

 

This is part four (the final part) in a mini-series – Testing in Real Life – that aims to share practical information about testing, based on real life examples.  It’s born from the observation that a lot of resources I’ve seen appear to concentrate mostly on theory, or how to advance existing experience, but there’s not a lot about how to actually do these things in real life, or get started with them.  The information I’ll share in this mini-series is based on my recent experience of helping someone test their mobile app for the first time, as an example of how to test in real life.

 

In this post, I’ll be talking about some things that testers should get involved in, other than finding bugs.

 

 

Misconception of Misconceptions?

 

As I sit down to write this post, I’m thinking of what I deem to be some common misconceptions about testing and testers.  I’m also thinking about some behaviour and attitudes that I’ve observed from real testers, which actually seem to match these “misconceptions”.  This leads me to wonder: are they actually misconceptions, or does popular opinion just heavily lean towards a way of testing that is completely different to the way I do things, and what I admire in other testers?

 

Here are some of the “misconceptions” I’m referring to:

• Testers just click around, following scripted test cases
• Testers only exist to be gatekeepers
• Testers shouldn’t be involved in anything until there’s fully developed software to test
• Testing is a phase / stage
• Everything that testers do can be automated

 

All of these notions hurt my feelings; professionally and personally.  I take a lot of pride in my work as a tester, and to think that these statements might be true of me makes me feel really uncomfortable.  The fact that I’ve observed these to be true in other testers is almost as bad.  And yes, a tester like this can absolutely have all their work automated away, but I think that good testers do much more than this, and it’s the work of testers that can’t be automated which can sometimes be the most valuable.

 

Please don’t let the statements above describe your testing.  Go beyond bugs to add more value to your project and team.

 

 

Going Beyond Bugs

 

I’ll briefly cover some things I’d strongly recommend that testers do, other than just bug hunting.  I tend to waffle on a bit, but I’m going to try not to go into too much detail here, and encourage you to research each aspect on your own instead.  Being able to research and learn independently is a very important skill for a tester!  However, I will refer to some further reading of my previous posts.  Not ashamed.

 

Alright, let’s go.

 

 

 

Use PQIP (or similar)

 

PQIP stands for problems, questions, ideas, praise.  I’ve talked about it a couple of times already, most recently in part two of the mini-series – How to Document Testing with SBTM.

 

The point here actually isn’t to use this particular structure (so the heading is a little misleading), but to look for things other than bugs.  Don’t just look for issues or deviate from the documented requirements. Keep your eyes open for opportunities for improvement, and things that already work really well or improve the user experience.

 

 

Identify Risks

 

Look for risks too!  This might be a bit of an adjustment if you’re used to following scripted test cases, because they probably don’t refer to any particular risk that they’re trying to cover or mitigate.

 

Being aware of product and project risks is really important for a few things, including: generating test ideas, prioritising what to test, and developing a robust and appropriate test strategy.

 

 

Get Involved in Every Part of the SDLC

 

If you follow a Waterfall / faux-Agile approach, then you might be used to only testing once a product or feature has been fully developed and is ready to “touch”.  Get involved earlier and insert yourself into every part of the software development life cycle to maximise your value as a tester.

 

Gather all the information you can and ask questions about everything.  Review the purpose or goal of the software; get involved in refinement (three amigos) meetings; review the design proposals; evaluate the branching and release strategies; get involved in code reviews; find out what the development pipeline does; think about what monitoring and logging would be useful; etc.  All the while, think about risks, potential issues, etc., as stated above.  You don’t need a developed product or feature to be able to test.

 

Be warned – some people who hold the views mentioned at the start of this post might not like or see the value in a tester getting involved in different parts of software production, and you might face a lot of resistance.  Do it anyway.  As a tester, you need to get used to that uncomfortable feeling of saying or doing things that people won’t like – as long as it helps to improve the quality of the product.

 

This can be very difficult to do without severing important relationships.  If you’d like to read tips on how to get involved in more of the SDLC without alienating yourself, let me know in the comments.

 

 

Communicate

 

I write about communication quite often because it’s so important.  Good communication is the foundation of a successful team and can really help you in difficult situations.

 

• Tell your team what you’re doing
• Speak up when you need help or don’t understand something
• Make all your test notes easily available to the whole team
• Conduct debriefs after testing
• Learn how everyone on the team prefers to communicate and receive communication
• Ask for feedback on your own communication

 

 

Educate

 

A lot of good testing is education.  Educate the team not only about the product and associated risks, issues, etc., but also about testing itself.  In my last few projects, I’ve gotten into the habit of giving the team a presentation on exploratory testing and SBTM because most of them have never come across them in real life; some not at all.

 

It’s hard for people to see direct value in what you do if they don’t know what it is you’re doing, so teach them about it.  This includes sharing helpful resources, pairing, and coaching.

 

 

Test (and Shape) the Ways of Working

 

When most people think about testing, they think about testing a product itself.  However, it’s important to test the way in which the product is developed as well.  Test, and help shape, the way the team works, including: development methodologies; WIP limits; strategy; communication and documentation procedures; meetings (those held and the structure), etc.

 

For the app this mini-series is based on, I did a lot of this when I first came on board, and worked on it as things progressed.  I started with a “model to be wrong” so we’d have something to get started with, then reviewed and improved it as time went on and we saw how well it was actually working.  You can do that too!

 

 

Do What Makes Sense

 

Requirements and processes are only useful to a point – and they’re not set in stone.  Ditch the gatekeeper reputation and take a step back to take context into account.  Weigh the pros and cons, get input from others, consult the data, and don’t be afraid to throw out the rule books when necessary.  If there’s frequently a good reason to go off-protocol, change the protocol to something better suited to the challenges you face in real life.

 

 

Think for Yourself

 

Above all, think for yourself.  Don’t just mindlessly follow scripts or procedures or instructions…  Or advice from people like me!  Think critically: question, experiment, analyse, discover.  Do what machines can’t, and really think.

 

Always Be Curious.

 

---

 

I hope you enjoyed the Testing IRL mini-series.  If you’d like to see more posts like this, or have any other ideas about what you’d like me to write about, let me know.