When is 200 x 1 ≠ 1 x 200?
When you’re running a frickin test case that’s what! 😫
“How could that failure at the National Air Traffic System (Nats) happen?”
ÜberHub was incredulous.
Infrastructure and seamless DR (disaster recovery) is his world where he dreams in technical jargon such as clustering and failover services.
On Monday, just as we were leaving Gatwick Airport in London for Turkiye, we were told that an issue with the Air Traffic Controller System was causing a failure and there would be delays for all UK inbound and outbound flights.
I suspected an edge case involving an issue external to the clustered environment.
My suspicions were validated when the BBC reported that the head of Nats called it a “incredibly rare occurrence” due to bad data.
Just like the TSB IT meltdown in 2018 when attempting to migrate to a new system, I believe that both situations were caused because the importance of QA has been ignored.
“Umm do we need so much testing time? Surely your team is highly competent and you’ll be able to produce defect-free software?”
😵😵😵
That’s usually what I hear when we present the client with the project implementation plan (and cost).
The topic for QA and testing is something I put front and centre during project kickoff.
We need strong QA skills to make sure the system is fit for purpose. And no, we shouldn’t use our devs to test each other’s work. 😐
An outstanding QA can be incredibly creative, and they can come up with all sorts of ways the system can be broken, by any means one can think of.
And when they tell us about those edge cases, we don’t fob them off.
We listen carefully and assess probability and impact of those edge cases, and when the stakes are high, for example if you’re a bank or if you’re in charge of handling up to 6000 flights an hour in the UK, we’d better have a damn good reason for not testing these edge cases.
I get so frustrated that people only pay attention when things go wrong.
In fact, we should be paying attention from the start.
Testing is not as sexy as building the next shiny new functionality on #salesforce. 🙄 … but neither is the hard work of building the foundation for Rock-Solid ANYTHING.
It absolutely pays to pay attention to the details and the best QA bods I know excel at this.
They also know that 200 x 1 ≠ 1 x 200, especially when talking about load testing or performance and volume test scenarios! 😁
Regardless of the tools that you might use, for example like Provar, we need to lead all software projects with this question:
What’s your testing strategy for producing a solid system that performs robustly against spec and is also resilient in the long term?
That is the only way we can highlight the importance of this topic.
Anyway, I might try to make it my mission to make QA as sexy as #BusinessAnalysis! 😉
Tag your favourite QA bods below 👇🏻
