Why Testing Is Fundamental to Any IT Project

By  Jacquie Webber, Test Manager at IT solutions provider KFA Connect

Avoid your online business failing you during critical times

“I have seen first-hand what can happen to businesses who haven’t tested their IT systems effectively”, says Jacquie Webber, Test Manager at KFA Connect. Jacquie is the company’s in-house Test Manager who is tasked with ensuring each system created by the leading IT specialist works effectively, following a rigorous process.

“Companies spend a lot of time and effort creating new websites and eCommerce systems but fail to test them. This can cause a business to lose sales and risk reputation. Websites that fail will convert less customers as they often lose confidence in the purchasing process. The impact of COVID-19 saw customers place a huge demand online and there were a lot of companies that had to quickly respond to fix websites and ensure they could cope with the demand – there will definitely be companies that will look back and wish they had full testing processes in place for their websites and systems.”

The role of a testing team            

There is no doubt that testers would like to test everything, but that is not possible. Much of the testing undertaken by Jacquie and her team is risk-based. For some projects, the team will have a list of business requirements that are determined by the customer in order of importance. Typically, the Business Analyst will start by writing a High-Level Design document, which then goes to the business for sign off. After the business requirements are agreed, Jacquie and her team write scripts to go through the process from the start and use the High-Level Design as their guide.

These scripts are uploaded to a testing tool that allows them to walk through the steps with each level stating what is expected from the system. The team capture test evidence at each step and check that what they see on the screen is correct, as well as what is being recorded in the background against the data base files. If the functionality does not work as expected, or if it fails, a defect is raised to the developer. The team then liaise with the developer to understand how it should work and once the issue has been fixed, they retest the scenario again. Once successful the defect can be closed.

Upon completion of all the scripts, a Test Completion Report is written detailing any issues or defects encountered during testing. This is part of the handover process to the client, who will then conduct their own testing – whether this be system integration or user acceptance testing.

The benefits of an in-house team

Jacquie Webber

Having an in-house Test Manager is a big USP for KFA Connect as most companies will use external testers. The benefit of having the developers in-house for immediate action, on the same time zone and avoiding delays in communication are huge. Being in-house means the testing team can be more responsive and dynamic, maintaining full control of the project. It also means they have direct access to the developers that created the system and can walk through test executions making any appropriate changes. Working in the same time zones means test progress is often quicker. If a defect is raised in the afternoon in the UK, it may be fixed overseas in the early hours of the morning. Often things get re-tested and so this process could end up taking several days going back and forth with the developer as opposed to raising, fixing, and re-testing it within the hour in-house. The test team at KFA Connect are also constantly building their knowledge of the system processes which is beneficial to clients as it allows for quick fixes and a better understanding.

Case study: Apple Device Enrolment Program (DEP)

KFA Connect worked on an Apple Device Enrolment Program (DEP) for a large telecommunications company. Apple DEP allows business customers to wirelessly pre-configure their devices with Mobile Device Management (MDM) software and profiles, so the user has an on-board device to use out of the box.

The changes involved having messages going between the source system and Apple itself. To assist with their system testing, these messages were built and spoofed to come back with the various responses that may be received via Apple, and the system functionality was built around this.

System testing included order processing, order returns and reporting, together with various messages between platforms and the source systems. For system testing, several test harnesses are used to simulate receiving orders and messages from these external systems.

A System Integration Testing (SIT) phase was also undertaken where the ‘real’ messages to Apple were initiated, ensuring Apple was able to receive and respond to them. For this phase, orders were placed on the individual test systems and the team liaised with the external companies that processed these, and where possible the use of test harnesses were avoided. This is an integral part of SIT testing; to make sure all the systems and interfaces are communicating with each other and achieving the correct outcomes from the test journeys.

Testing makes business sense.