The role of the test team is to make sure that the software developed does what it’s supposed to, doesn’t do what it isn’t supposed to do, and meets the client’s business and technical requirements. Our Test Analysts will confirm functionality, find defects and build confidence in the functionality of the software so that we can deliver the best quality product possible.
Software can be complicated and in the real world it’s not possible to check everything it can do. For instance, consider a health insurance company that might have thousands of clients across dozens of different policies claiming for any one of a hundred different injuries; then you need to consider previous conditions, other injuries, different payment types, whether they have dependents. Testing the claim processing system thoroughly for this system would take years, if it was even possible to do at all.
This is why test planning is the most important part of what we do; testing is a process of planning our efforts efficiently to maximise coverage and build confidence in the system, rather than proving every bit of it works.
What is the process of testing?
A project, whether run in waterfall or Agile, is broken down into user stories and tickets, and each ticket is worked on in isolation. Depending on the size of the project there could be hundreds of tickets! When a developer finishes working on a ticket, they check it works and then merge it in to be deployed with other completed tickets. Once a build is deployed to system test, we put all of the pieces of work together, looking at them in the context of the whole product, and asking…
Does the software do what we want it to and importantly, does it fulfil what the client initially requested?
In a more traditional style project, it might be that the Business Analyst (BA) team would initially gather the client’s requirements. Then follows a long period where the developers develop the all of software and eventually the whole product is given to testers to examine in one go. This can be risky as sometimes you’ll find something that works fine for the developers when it’s on its own, but as soon as it’s deployed with everything else, it goes wrong and that’s a key part of system testing, known as integration testing.
With an agile approach, which we tend to adopt at Software Solved, the project is divided into sprints. As the tickets assigned to the sprint are being worked on, we can simultaneously plan our testing based on the expected functionality. We don’t need to know how the developer is implementing the functionality, because we know what it should look like at the end. This is known as ‘black box’ testing; we know that when thing A goes in, we should get output B. We don’t need to know how the software (or rabbit) is made! This speeds things up because we can plan testing without needing development to be finished.
Find out more about a day in the life of a Test Analyst at Software Solved.
If you like the look of how we work and are thinking of having a piece of software developed then Get in contact with us today.