Whether a long-time testing professional, new to the world of software testing, or a business user looking to learn more about processes, understanding the methods behind managing a software testing operation is handy.
The three test management questions you need to answer
Everything you need to think about when it comes to figuring out your test management process can be boiled down to three questions: what do you need to test? How are you going to test it? When are you going to test it?
Considering testing from those three angles will help you build a comprehensive plan that covers all the bases. Best of all, it doesn’t matter whether your IT team uses Agile, Waterfall, Hybrid or any other methodology. Testing happens in all forms of the software development lifecycle – organizations might just have to run test management processes frequently and on a small scale if using a methodology like Agile, or more infrequently but for a larger volume of testing for something like Waterfall.
What needs to be tested?
To deliver on the ultimate objective of any testing program, a checklist of tests needs to be created to ensure that a business can still operate while undergoing a tech integration.
The ways that the list can be built might depend on the source of the testing need a firm is dealing with. Generally speaking, testing will be needed because a piece of software has updated, or because a process has changed. In each instance, organizations need to make sure that the software enables business users to do their work. There are a few things that business leaders need to consider before jumping headfirst into testing procedures.
Which processes need testing?
If an application is being updated, it’s important to work out which processes rely on that application and will be affected by the update. Remember, in today’s IT landscape, where cloud platforms, API-driven integrations and third-party applications are the norm, a change in one application can affect quite a large number of business processes.
Remember; If a process is being changed, it might have knock-on consequences for other processes (for instance, if an order is now being stored in a system in a different format, can processes that rely on that order data still function?)
Testing purists would say you need to test absolutely every change to any piece of software, but the truth is that it’s a judgement call each time. The only way to properly make that call is to read the documentation for every update. Automating some smaller-scale changes can also be a way to lighten the testing burden.
How will the testing happen?
Most organizations build up a library of test cases over time, each testing a different process (or aspect of a process). That library can exist in different states, though. Some organizations have highly detailed documentation. Others have their test cases stored in the head of their testing people (or person).
Test automation can be a valuable tool for getting high volumes of testing done. But there are some reasons to stick to manual testing, depending on the update.
For example, If the update changes the software significantly, it can disrupt automated processes. Most automation tools are logic-based and won’t cope if buttons move, form fields change or the workflow in the software changes.
If processes are changing, or even if the UI has adjusted, users may struggle to adapt. By staying devoted to manual testing, firms can ensure at least some of the business users who know how to use the updated software can guide the rest of the team and help reduce and update disruption. Typically, regression testing will stick to automated scripts, and UAT will rely on manual testing.
When are you going to test it?
Ideally, testing processes shouldn’t be reactive, but something that can be put in the diary ahead of time. A sufficiently-prepared workforce will make it easier to get users to commit to testing times and devs will be waiting to squash bugs as soon as they appear.
Getting to this proactive planning state works a bit differently depending on the source of the testing need – the business changing processes, or a vendor updating their software.
When it comes to software updates, most of the time major updates are done on a regular schedule. Infor, for instance, undergoes two large updates per year. And then, of course, there’s the famous Patch Tuesday. With these events in the diary, you can at least have some resources on call ahead of time, in case you need to kick off a round of testing.
When testing software to make sure it can support a revised business process, being proactive will determine how involved IT is in the decision-making process. Ideally, IT is consulted at the very start of the process and therefore has sight of any necessary testing with plenty of time.
Whether testing proactively or reactively, the details of ‘when’ remain largely the same. It’s imperative that firms understand exactly what resource is needed to undergo the testing procedures, and also to book the necessary time in their diaries.
Doing the testing
Once a clear view has been obtained about what’s being tested, how it’s being tested, when it’s going to be tested – it’s finally ready to test it! It’s time for one last checklist before you do, however. Have tests been allocated to business users? And will the progress be tracked and chased up for anything that’s falling behind? Is the feedback system clear and succinct enough to quickly identify failures and pass them on to devs?
As with the management of any process, when things are in motion, organizations need to be ready to handle unexpected setbacks. What will happen if a business user is sick, for instance? Can the test wait until they are better, or will the task need to be reallocated to someone else to keep things moving? The large of a scale testing is undergone, the more complex the process can become.
Once a testing cycle has finished, it’s always worth taking a moment to evaluate what happened and try to improve on it for the next cycle. The more insight that can be gained into what happened during the testing process, the easier and more useful this will become. The testing procedure altogether can’t happen in an efficient manner unless organizations leverage the right tools.
Choose your tools wisely
One thing that’s been clear throughout this piece is that data and insights are vital to manage the testing process properly. A comprehensive library of test cases, both manual and automated, is a much-needed resource to guarantee firms have enough test coverage. Knowing the exact schedule of testing will make sure resources are allocated correctly, and the resource allocation and progress of the testing needs to be monitored easily – enabling quick reactions to anything unexpected. A comprehensive report at the end of the testing procedure can contribute to optimizing future testing processes.
The usual way organizations manage tests isn’t designed to make the management process easy. Most organizations make do with a combination of testing software, spreadsheets, emails and screenshots of test results to make everything work. As testing volumes increase, the cracks are starting to show.
The best way to solve the problem is to invest in built-for-purpose test management tools. The Original Software testing platform, for example, can give one place to manage and control all testing, which is tightly integrated with test automation and manual testing software. As a result, test managers can get a much richer level of data and insights when managing testing.
With everything in one place, the test management process becomes much easier to run and optimize, ultimately helping deliver better results for organizations.
