Identifying bugs through different scenarios

Let’s start with one of the more common yet critical aspects of testing; finding, logging and fixing bugs. Testers will need to take a solution through all known use-cases to check if the code breaks or the user experience is impacted at all. Sometimes a particular order of screens or steps together can create a bug that crashes or impedes the solution. It’s this level of detail that testing will get to, and these scenarios will be captured in a backlog to be worked through. Bugs are simply part of every piece of software. So much so that, in general, end users (both inside an organisation and external customers) have been conditioned to somewhat accept bugs periodically, provided they’re not fundamentally preventing desired activities from being completed. A well-performing solution isn’t perfected out of the gate, but is continually refined and improved upon as more bugs are identified and fixed.

Consider the combination of user journeys, operating systems, devices, and so on – a digital solution may be perfect on a select number of variables, but demonstrate issues on others. It’s up to a testing and QA team to validate reported bugs from end users as well as proactively find these prior to releases.

Keeping the business and its users safe from data security flaws and threats

Testing and QA goes far beyond fixing bugs that impact a smooth UX. For systems that work with sensitive or personal data, the testing function needs to be even more stringent. Data security is a fast-growing discipline with specialist expertise involved that often have their own testing methodologies and penetration/stress tests to ensure the best possible security. A project’s testing team will typically take a platform through its paces from a security standpoint, although this should be overseen by the organisation’s security team and leadership.

In the QA and testing environment, testers will check things like password security, brute force, backdoor entry points and a myriad of other common cybersecurity vulnerabilities. Where data is retrieved from other repositories within the infrastructure, there should be careful testing performed to ensure that this is done securely.

Bugs that represent vulnerabilities will typically attract the highest priority from a development and/or security team to address before release.

Determining any speed / performance issues to be addressed

In a world where our attention spans are ever-decreasing, the performance of a platform, even that which is only used by an organisation’s internal team, matters a great deal. As a starting point, slow performance can make teams less efficient in their work, impacting both individual job satisfaction and the business’ bottom line. Beyond this, slow systems can create other unwanted outcomes like users finding workarounds, or simply avoiding using the solution entirely. If the solution is used by a team whilst serving an external customer, slow speed can create a poor customer experience.

Testing phases within a project and beyond the need to identify performance issues and determine where and why these are occurring. With the right experience and testing tools, testers can document the issues in detail, helping those responsible for development to work on the right part of the solution. Consider issues such as slow retrieval of data (may require changes to how this information is requested or even infrastructure updates) or slow rendering of a front-end system due to bloated code.

We’re now spoilt by fast, almost instantaneous internet usage – that translates into the business world too, and first impressions really do count. Testers should make sure that when a solution is first released to its end user, that they come away feeling like the system is responsive.

Testing integrations with other systems

One of the challenges that technology product development faces is the integration with other platforms – commonly those that the project team has no control over beyond an application programming interface (API), if available. What this means is that a development team must ensure that their solution is compatible with the required systems by adjusting things on their side – known as System Integration Testing. Again, if an API exists then developers have more control over the data and features they can access that helps systems talk to each other.

During the QA/testing phase, the team will need to take the solution through all the scenarios in which it needs to integrate with other platforms and re-create those common use cases. Close attention will be paid to how quickly this integration works, whether or not it completes the task accurately and any situations in which a bug occurs. The more integrations and functions that are performed, the more complex this process can be. But if the solution relies upon this, then testing simply must be done in as much detail as possible.

Simulating the solution’s daily usage

Where modern-day testing provides the most value is taking the system through its typical and heavy use cases. Testing will happen according to a framework (or combination of) and be led by testing experts. But organisations understand that the way to surface issues that may not be found by the project team is through the practice of user acceptance testing (UAT). Here, the typical users are brought into the project and conduct tests based on their requirements from the platform. Those who’ll eventually be the end user of the tool can apply real-world situations to the solution and report on how well it operates/functions. Through a managed process, testers can build up a backlog of issues discovered through UAT and work with the project team to address these before release.

It’s crucial for this kind of testing to happen alongside the more formulaic code and security testing as it can uncover user experience issues before a larger group of users are exposed to the solution. It’s far easier to tackle issues through a UAT approach than releasing an incomplete or problematic system and fielding feedback at scale.

Satisfying project completion acceptance criteria

At the start of the project, there will be acceptance criteria outlined, directly correlating to the functionality of the solution that meets the business requirements. These requirements will be informed by a strategic outcome that is to be met; this may include providing a more efficient customer experience, reducing operational costs long term, improving security or anything else deemed important. Acceptance criteria may be fed into by various stakeholders including leadership and those in the business units that will ultimately make use of the solution.

Testing needs to take careful note of the acceptance criteria and translate them into testing requirements. How these requirements are tested for and confirmed may be down to various approaches, including those we’ve discussed in this article.

Acceptance criteria is often illustrated through the concept of ‘stories’ that reflect each unique user type who’ll interact with the developed solution. For example, a financial system may have users including CFO, accountants, security and so on. Acceptance criteria will typically consider all of these unique requirements, which the testing phase will need to satisfy before being considered ready for release.

Protecting the business from poor user experiences

Cost and time savings enabled through good testing

Need guidance on your IT project?

IQANZ provides specialist assurance services for technology projects across the private and public sectors. We apply proven assurance methodologies along with a high level of technical expertise to help guide projects and programmes to success. If you’re interested in getting independent, expert help on your technology project, get in touch with our team.