Many organisations rely on standard or customised ERP software to run their operations more efficiently. But if a solution doesn’t operate correctly or meet the business requirements of the enterprise, it could mean lost customers, frustrated employees or even catastrophic business failure. In any case, the organisation will incur higher costs to correct a problem that need not have occurred.

By thoroughly testing software before it goes live, companies can avoid unwanted overheads and headaches. So it’s no surprise that software testing plays a key role in application development, implementation and configuration. “More organisations than ever acknowledge that they cannot deploy systems effectively without a robust testing process,” says Menzi Tshabalala, director at Onpro Consulting.

However, several assumptions persist that can short-circuit their efforts:

Testing is isolated
“Software testing has become a scientific process with touch points across the application lifecycle,” affirms Tshabalala. Although software testers play a key role, they are only part of the equation. For example, many programmers use test-driven development and create unit tests before ever writing code. The testing process must accommodate all the moving parts to avoid “rogue” testing.

Testing is the tester’s job
The test team is responsible for the bulk of testing, including defect finding, test automation and performance testing. “However,” says Tshabalala, “it’s vital that all stakeholders buy in to the idea that testing is everyone’s job.” Developers, business analysts, users and all other stakeholders should see themselves as the extended testing team.

Testing comes later
If an organisation determines that an application will help them achieve a specific goal - the project business purpose - the test team should be involved from the start. How testing will be approached and executed must also be planned in advance and run in parallel with development and implementation. Yet testing is often seen as a downstream function rather than a management process.

Testing is bug-finding 
There’s more to testing than finding bugs and improving performance. A test plan must identify all points of risk, design meaningful tests, identify appropriate test data, consolidate testing activities of all stakeholders, develop a clear feedback loop, and more.

Testing is self-guided
“Whenever I ask for an organisation’s test policy, they either don’t have one or it’s outdated,” reports Tshabalala. Unlike the project-specific test plan, the test policy is a set of guiding principles that standardise testing methodology, management, KPIs and reporting across the enterprise. A well-defined policy coordinates the efforts of all stakeholders, prevents silos, can baseline any project’s velocity, and simplifies future planning and estimation.

Testing is easy
While testing is everyone’s job, planning and managing the testing process is a highly specialised field. “Not just any IT person can do it,” says Tshabalala. Only qualified test managers and testers should be employed or contracted. They should also be equipped with an appropriate testing platform to help them perform their duties effectively.

Testing is slow
Testing is dictated by needs and risk profile. For example, high-risk banking and medical systems demand rigorous testing to achieve minimal failure rates regardless of time restrictions. In such cases, testing can be accelerated while maintaining quality and robustness. Tshabalala advises employing advanced testing techniques such as state transitioning, equivalence class partitioning, or path testing, depending on the nature of the requirement or condition under test.

As organisations seek greater performance and reliability from their software, testing has become a critical component in the development and implementation processes. “By reconsidering these seven incorrect assumptions,” says Tshabalala, “they can achieve far better results from their testing efforts.”