An Insight Into Why Software Testing is Necessary

Testing is a systematic process to determine whether a product or service meets specified requirements. It’s a process which if executed well, builds confidence & mitigates critical & high-level risks.

Software testing helps to ensure effective performance of an application or product. It’s a process used to fulfil the primary objective of verifying a product is correct before being deployed for general use.

Ultimately, we test for quality assurance.

Imagine signing a contract with a company to develop software for you, only for it to come back incomplete and inadequate, and you’re unable to deploy it. As a result, not only have you missed your deadline, but you find yourself returning the software to the developers, or end up sending it to a new developer to fix, costing more time and money.

By testing the quality and functionality of a product or service, bugs can be caught early enough before release, saving a lot of embarrassment, time, money, and possible legal ramifications. There have been historic incidents of software failure as a result of little or no testing. We take a look at two major incidents that could have been prevented if better testing had taken place.

Some of us are old enough to remember the Y2K bug where billions were invested to prevent any disasters, yet still a few things managed to slip through the net. Just ask an Australian about what it did to the bus ticketing system...but thankfully no nuclear Armageddon.

However, did you ever hear of the failure of the patriot missile system in Dhahran Saudi Arabia during the Gulf War? 28 soldiers died and 110 more were injured inside the patriot missile defence zone. Why? Well, the missile system failed to track and destroy an incoming missile because of a hard-coded bug that caused it to think that the missile was 600m outside of its detection zone. Read more about it here.

After this devastating event, it would be reassuring to report that many now consider testing important; unfortunately, it’s still not always the case.

This year TSB tried to push through their new IT system far too quickly, thinking that it could be delivered under budget and earlier than planned. TSB naively thought that the new software could work right out of the box despite having to integrate with multiple complex middleware systems.

The result was a spectacular failure that should never have happened. So, why did it?

TSB sought the expertise of industry experts; IBM. It’s important to mention that IBM was brought in at a considerable cost to consult with TSB to fix their new banking system, but the most notable comment from IBM’s initial assessment was “[the system] has not seen evidence of the application of a rigorous set of go-live criteria to prove production readiness”. Read the full article here.

That was not the end of TSB’s problems either. TSB had been under investigation by the FCA since the debacle, and consequently, their Executive Chairman, Paul Pester, stepped down on the 4th September this year, making the entire event a very costly affair for the company. If more consideration had been given to the importance of qualifying the software from the very beginning of the project, risks to TSB’s customers, jobs & reputation would have been avoided. Read more here.

Testing should commence at the beginning of the project. As soon as requirements have been specified these should be reviewed, & risks identified. Only then can tests be documented based on a blend of the two elements. The later testing occurs in the process, the more expensive the fixing of the defects become.

There are many tools available to help with the testing process. These tools can accommodate test management, automated & performance testing as well as multiple mobile device & browser version testing. Most teams will incorporate the use of at least one of these tools if not many to ensure improved efficiency with their process.

The types of testing will ultimately depend on the requirements of an individual project. But, the primary focus for software is functional, usability and browser / mobile device compatibility testing.

• Unit testing tests an individual unit, or a group of related units of code, to validate how each performs. These tests are generally carried out by developers.
• Integration testing is used to expose faults in the interaction between integrated units, i.e. software and hardware.
• Functional testing tests the system against the functional requirements and specification. By feeding the system an input, the functions can be tested to ensure requirements are properly satisfied, by comparing the actual output against the expected.
• Regression testing is used to ensure that any enhancements or defect fixes to existing software, do not have an adverse effect. It’s the process of checking that fixing one problem does not create another problem.
• Usability testing is a test from the customer’s perspective to determine if a system is convenient and practical, making it easily usable. Things the test will evaluate are:
  • Is it user-friendly?
  • Does it work in a logical way?
  • Is it easy to navigate?
  • Is the design aspect good & consistent?

• Performance testing is a type of software testing that can determine the performance of a system, in terms of responsiveness and stability, under different workload patterns. There are four basic types of performance testing:
• Load testing evaluates the behaviour of a system at increasing workload.
• Stress testing evaluates the behaviour of a system at or beyond the limits of its anticipated workload.
• Endurance testing evaluates the behaviour of a system when a significant workload is given continuously over a period of time.
• Spike testing evaluates the behaviour of a system when the load is suddenly and substantially increased.
• Acceptance testing is a form of testing to evaluate a system’s compliance with the customer and business requirements, and meets the user’s needs. It’s a pre-acceptance/pre-delivery test that is usually completed by the end user.

The ultimate goal of testing is to ensure that the final product meets the requirements agreed between a development company and their customer. It is common for projects to change over time and requirements may need to be adjusted and/or revised, so it’s important to document results as they may need to be referred to later.




What happens after testing?

 

A test analyst or software developer’s responsibility doesn’t necessarily end once a product is initially deployed. In fact, their support can continue throughout the life cycle of the software all the way through to its retirement. Regular releases are common to resolve defects & to enhance & modify the product.




Conclusion

 

Many misunderstand the importance of testing and can easily ignore the implications of not qualifying a product. While the efforts applied during the test process may not be as tangible as a piece of code, the risks it mitigates along with the confidence it builds for end users cannot be denied. Failure to test can have costly and damaging effects to your business and your brand.