Testing has evolved quite a bit over the last few years - particularly with the evolution of Agile and DevOps methodologies. If you’re looking for ways to improve testing outcomes in your organisation, take a look at the tips below for some ideas of places you can start.

Some of them will be more and some less appropriate for your team or context; just have a read and see what sticks (the tips aren’t in any particular order). The list is meant to stimulate ideas – it’s not a panacea!

1. Encourage better requirements capture and documentation

Good testing doesn’t depend on requirements, but having good requirements certainly doesn’t hurt. Working more closely with analysts and product managers to ensure requirements are captured and documented in ways that will better inform the test effort won’t only help the QA team - it’ll help the analysts and PM’s get better at their jobs, and the developers will likely thank you too!

2. Collaborate closely with the development team

On the subject of developers, the days of siloed working are long gone for most organisations. Even if you’re in the unfortunate position of working on a project where direct contact with developers is discouraged, I’d strongly recommend building relationships with them wherever possible to do so. Even if test and developer discussions have to take place over lunch in the canteen, or drinks outside of work - consider it the start of something which will pay dividends in the future, when you need some support with a tricky bug, or assistance with some environment configuration.

3. Code and Application Focused Testing

In days gone by, I would have referred to white and black box testing instead; but these seem like somewhat loaded terms in 2020! Anyway, if you’re only doing one or the other - consider switching or increasing your coverage by combining approaches. There’s nothing inherently wrong with either technique, but testing will always benefit from the combination of lots of different styles, techniques and perspectives. You can grow your skillset and knowledge whichever direction you move in - for blackbox testing you can grow more business domain knowledge and interact with BA’s & PM’s some more. For whitebox testing, it’s an opportunity for more interactions with developers and code knowledge.

4. Control your test environment tightly

With containerisation, testers can have more control over the environments used for their testing than ever before. Using a Docker environment for your testing for example, means that you can spin up a fresh environment with a preconfigured state for each new build of the code; preventing issues with data or other environment configuration problems that may invalidate the approach to or results for your tests.

5. Reduce cost

Use of on demand environments that are spun up by the tester that needs them, and maintained for only as long as they are needed can help to reduce the amount of money that needs spending on provisioning and supporting more complex requirements. Clearly this may not always be possible, but maybe there are cost savings to be made elsewhere? The test manager should always have an eye on costs and be looking for optimisations.

6. Cover the entire software delivery lifecycle (SDLC)

Continuous testing by any other name; you should be looking to test throughout the entire process. Again, this may not always be possible, since testers aren’t always involved in the earliest stages of a project. But to the extent you are able to do so, seek to add value by closely scrutinising requirements, implementing rigorous quality processes such as unit and automated integration & regression testing during development, and exploratory testing before and after release (in production – see below).

7. Keep improving quality – one step at a time

Stay focused on implementing improvements to quality wherever they can be made. Small wins are fine and accumulate over time. Implement the necessary changes to increase quality in the desired area, and protect them with process improvements such as quality gateways, acceptance criteria or test automation.

8. Test as early in the process as you can

Often referred to as shift-left, introduce testing and quality processes as early in the SDLC lifecycle as you can. I mentioned requirements above; you can implement testing at the requirements stage by ensuring each requirement is documented with acceptance criteria, and/or is written three-amigos style, as a Given, Then, When Gherkin scenario, that can be used to clearly communicate the expected behaviour of the finished solution. BDD’s can be used to subsequently automate testing of the finished product.

9. Decompose tests into small parts

Running smaller tests more frequently throughout the entire SDLC can help to save time and resources. It forces design considerations also, and helps developers and testers alike think about how to develop efficient tests. Small tests take less time to debug, as well as to run.

10. Continuous testing equals continuous monitoring

It’s wise to monitor your application code throughout the development lifecycle. Consider what measurements are useful and relevant for your team, introduce and monitor them as your maturity increases. Taking measurements such as unit test coverage for example, may result in some unpleasant surprises – but Rome wasn’t built in a day. When starting out with monitoring you can just seek to ensure things at least aren’t getting worse, and save improvement battles for another day.

11. Test in production

Don’t be afraid to carry on testing in after your code has been released. It’s not unusual to face time-constraints when carrying out pre-release testing. Testing after release can be a good way of mopping up remaining areas for which coverage wasn’t as good as you would have liked. You can get some additional testing carried out by your customers too!

12. Keep the customer or end user mindset

On the subject of customers, never forget that one of the key roles of the tester is to be an advocate for the customer or the end user of the product. Make sure you carry out at least some of the testing from this perspective.

13. Stay (relatively) neutral

While advocating for the end user, watch your language and try not to upset anyone! Testing reports and bugs should be relatively neutral and unbiased. As sergeant Joe Friday from Dragnet used to say – “Just the facts.” Your reports should focus mainly on the facts. It’s no bad thing to have an opinion; just be careful about how and where you voice it. Ultimately, it’s not usually the testers job to decide what actually gets fixed.

14. Learn and apply effective testing methodologies

Staying abreast of and applying relevant testing methodologies for the context in which you are working is kind of stating the obvious, but I’ll say it anyway. By way of an example, carrying out a lengthy manual regression test at the end of a sprint if your team is attempting to be agile, probably won’t go down very well. In this situation, you should be looking to automate a lot of your testing, so the code can be tested using the automation framework throughout the development iteration.

15. Cultural transformation

It’s not usually within the testers direct remit to implement organisational (cultural) change, but that doesn’t mean it’s impossible either. In organisations where I’ve been the first or only dedicated tester, I’ve often seen some cultural changes take place as a direct result of an increased focus on quality. You can take this further by implementing further processes, documentation, systems etc that serve to support ongoing cultural change.

16. Software development methodology

Following on from 15, part of that change may be to review the software development approach (or methodology). Again, this is unlikely to be under the direct control of the tester (or test manager), but they can certainly influence it. And in my experience, having a suitably qualified tester progress into a delivery or product manager role isn’t an unusual occurrence, which can result in even further influence in this regard.

17. Accumulate highly skilled testers

In my experience, testers have influence over culture and organisational policy to the extent that they are respected. And respect comes from demonstrating the requisite skills and behaviours. To that end, you should try to ensure your team has testers with the necessary proficiencies; something I’ve written about at length elsewhere.

18. Have a mix of skills and personalities

While you’re accumulating your testers, remember what I said above: as a general rule, testing benefits from lots of different approaches. Different approaches can be a function of different personality types and mindsets, so you should be aiming for a team full of the same kinds of people.

19. Document all your testing

Keep a record of all your testing activities. I like to use a test management system to capture my test ideas, and ensure they can be repeated in the future if needed. The use of a test management system ensures that testing progress and outcomes can be reported on quickly and easily also.

20. Bug free products don’t exist

And to conclude, don’t beat yourself up too hard if your product ships with bugs every now and then. Testing doesn’t prove the absence of bugs, only their presence - and we all miss a bug or two now and then. Remember the 80/20 rule, and ensure you invest effort in places where you’ll see maximum returns.