What do you want? Speed or quality? The two are not mutually exclusive, however, they do have an impact on each other, so a balance must be struck. Ask yourself the following:
Often, for organisations, these two questions contradict each other. We want to get the product to market as quickly as possible, however, we also want it to be of the best possible quality.
The decision which needs to be taken is whether time or product is more important – do I want to get to market as quickly as possible or do I take the time to ensure my product is of high quality?
Why do we test?
There are two types of IT products/systems within organisations.
One where they can go live with a (reasonably) untested product and fix forward in live with little or no effect on its customer base e.g. Skyscanner, Facebook, Spotify. The effect of any ‘live’ faults or failures in these companies can be very quickly corrected and pushed back out given the speed at which change can be implemented and the social/cultural impact and issues would have.
Other businesses such as banks, air traffic control and the NHS face enormous customer impact from the failure of their systems. The effect of failures in these organisations can be catastrophic, even fatal.
Testing is about risk. Regardless of where you fall on the risk spectrum above, you can’t test everything. You have to make a call on the impact on your systems failing and this needs to include reputational damage.
We need to ensure what we have built is what we required
Fundamentally, testing ensures something works as it was intended. Functionally, speed of response, usability – all of these.
A failure of one of these measurements, renders any successful qualities pointless. If a mobile app is introduced to order taxis from your mobile – it could be feature rich, the quickest app on the market in terms of how it responds on your phone but if the user interface demands that you have to wade through 9 screens of questions to order your cab, nobody will want to use it.
You need to prove it delivers what you intended
By ensuring that functionality is tested against clearly defined business requirements, we ensure that the product released to the customer is the best possible product achievable.
Testing performed by a dedicated team also offers a degree of independence from the developers therefore giving some extra assurance on the level of quality.
Not testing your app, website or product does not prevent it going live. However, in the same way that you can dress yourself in the dark by blindly selecting clothes from your wardrobe, it wouldn’t be recommended!
Testing should not be seen as a task that prevents a product being released but instead should be thought of as ensuring that the right product goes live with an acceptable level of quality and with all of the risk understood and mitigated.
If you don’t test, then you’re really opening yourself up to all kinds of horrible possibilities;
Be it in resource or time, testing will add to your project budget. Larger organisations usually have internal test teams or engage with preferred test suppliers to perform this activity.
Start-up and early-stage companies don’t have this luxury and, as a result, can often fall into a trap of treating testing as something which can be diluted, skipped entirely or undertaken by people in their company with no testing understanding whatsoever.
This rarely works as effective testing relies on a very in-depth knowledge of the testing process and how this should be considered against the development and analysis stages of product development.
If you find yourself in a situation where a dedicated testing budget is simply impossible to find, then attempt to mitigate the likely problems described above and understand your risk. If you have the ability to consider testing in a more structured way, engage with a supplier that can help you design the best approach to take given your circumstances. The best suppliers will be able to help you come up with an approach that best suits your situation.
Contact us at:
Phone: 0845 643 5375
"Why we Test : Risk Management and Software Testing" First published on Company Connecting October 2017