The pressure to produce a product quickly and efficiently has created a level of stress unseen in the development world before.
In the recent past, we’ve seen some damaging (and potentially life-threatening) situations unfold.
QA and Testing Blunders everywhere
While it might seem like each product and their bugs would have it’s own unique cause, at a top level the problem (and risk) begins at the same place, a lack of a proper testing strategy. Their products were released to the public too early causing, at the minimum, billing a much higher technical debt to the product than originally anticipated.
Would any of these companies have discovered the flaw or flaws that put users at risk if they had spent more time working out the bugs? In a 2012 study from Namcook Analytics, normal software testing methods only identified twenty-five to fifty percent of issues that needed to be resolved.
If the point of beta tests and other testing structures is to crowdsource feedback from real users to create real use fixes, how did these companies fail?
No one can be certain, but chances are there are a few things each company could have done better to prevent these issues. There are steps you can take to prevent these kinds of QA and testing blunders with your own products.
The right programmer mentality
We’ve spoken at length about where automated testing should be in your testing strategy and the difference between testing and checking. Our founder, Ka Wai, writes, “The real question we should ask is, how do we pragmatically make the introduction of bugs as improbable as possible?”.
While there’s tried and true ways of getting from point A to point B, the nuances of your development team make a unique solution necessary. Be sure to read Ka Wai’s article on testing strategies to make sure your human processes still play a major role.
Quality > quantity
It’s an old saying, but we know the words and refuse to follow them. Many companies make similar mistakes in pushing products and services out too early with no regard for quality.
Deadlines make this hard. Is your client demanding a quick turnaround? Weigh the risks of following their lead for a fast product and request extra time to release a high-quality product instead. It’s likely worth taking the extra time to prevent QA and testing blunders.
Sing the praises of what extra time could do for the client and you may even position your development team for more work in the future.
Become the user
While you’ll need to provide customer service to your client, think a step further, and discover the user and their behaviors with your product. Ka Wai wrote it very simply, use the software you write.
With all of your manpower and working hours going towards writing code and fixing issues with written code, what percentage of time do you spend using the code?
Using the software as a customer gives you direct insight into what they would see, feel, and do with your product.
You might even find a few bugs, too.
Fix and repeat
Learning when to take extra time to build a better product can be risky itself. You can’t expect to bring the idea to a mature and stable place without time and again providing a proof of concept.
Yevgeniy Brikman, co-founder of Gruntwork, a DevOps service company, says “speed wins”. Kent Beck calls this “Agile”.
Whatever philosophy you subscribe to, a major portion of development time is spent in trial and error. Discovering which of your assumptions are incorrect as quickly as possible, while not interfering with the customers’ perspective of your product, is the key.
Create a test environment that works for your development team and stick with the process on every project.
What is your current test environment like? Have you seen any major successes? What QA and testing blunders have you had? Send us an email or tweet us about your development team and the testing environment you have in place.