The Quality of Software
/
When Oneplus co-founder Carl Pei appeared in a video with American Tech guru Marcus Brownlee, he showed off the prototype of the Oneplus Nord design, spoke honestly about the choices they made and broke kind of a fourth wall between the accessory makers and the consumers of the brand. Among the many aspects they discussed one hit me home, the fact that they are cutting about forty dollars’ worth of testing to get the ip68. This seems to have become the norm in the outsourcing industry. The customers want an Airbnb looking site and they can get it affordably. It is a good deal. But just like the Logo, homepage or product catalog is important to the business, similarly important quality aspects which may make or break the business remain less understood and not well communicated from the provider’s part. It is because the frugal entrepreneurial handbook guides the business to be economically lean from the beginning and the provider is in a competitive market that often prioritizes agreement over proper counseling. There is a case to be made for quick business solution but as an engineer concerned with quality nearly half a decade it is incumbent upon me to try to inform both the solution provider and the valued customer about the pitfalls of the treaded path.
Sacrificial Testability
The first victim of removing the quality concern is the architecture is then designed with testability in lower priority. Even for the moderately tech savvy customer it will seem like a matter of no concern and it will therefore be reflected in the quotation. But what they should know is that it is the first step for the application is taking towards failure in case of success. It means for them that the application while look as pretty as any of the best looking sites but will not preempt failure in case the business application is as successful as it hopes it would be. Succinctly said, software written with non-testable code means that, failures/bugs will be an ever increasing problem and will reach the threshold only when you know enough to rue the problem.
The Performance Quicksand
A successful delivery of a Share market live information site, a betting app or a simple e-commerce site is something the valued customer would accept, applaud and give a glowing recommendation too. It certainly checks all the boxes of the SRS. But then it might be outdone by the competition, failing to retain users or get user reviews concerning slowness that they can’t seem to put a finger on. A performance engineer would point out the fact that the average response time is of the Share Market info is way slower than the competition, or the betting app is becoming unresponsive at a certain peak time or the e-commerce sites various modules are performing inconsistently. He might plan out a way to identify these issues before the development phase and help the dev team solve the issue when they arrive. It might not seem like a good investment to the entrepreneur looking to cut development cost but it would be incumbent upon the solution provider to inform the hidden costs to actually performance tune after it has been launched. Which, I have to add, is a lot more than addressing them in the first phase.
The Tested Software Fallacy
Again with the idea that software development should be in tuned with the business, I will propose that not all of the features have critical business aspects. For example a E-commerce site can live without the Wish list feature but will sure face huge losses if the purchase feature is broken or the search is not returning the right results. Yes, the manual tester might be expected to catch these errors but at the time the product is in production it might be too costly to handle. This is particularly important when a live product is under maintenance or is getting enhancement. So an experienced QA would suggest a business critical (risk factor driven) UI automation process to be integrated in the software development cycle which basically ensures that the new toy doesn’t choke the baby.
Hypothetical usability
Those with better accumulated focus group data could easily identify the core desire of the customer and use it against the next competing product. User Acceptance Testing does something similar; it gives a reaction from the end users about the site. In the book “Hooked”, Nir Eyal points out the importance of returning customers. Plenty of Software with technological advantages are failing because of the lack of emotional response from the user. Even in the case of blue ocean market ideas every business not getting the edge by collecting real user based data will be outdone by someone who is going to use it. But the customer often overlooks the fact that this kind of testing might be way cheaper than to hire a focus group while the business is running. What they don’t know might just hurt them in this case.
In the end Oneplus did what they do best to break into a saturated market, they did it not by doling out fancy new technology but assuring quality where it mattered. The part Pei was mentioning was actually a smart move considering they prioritized the software experience over durability which makes the device popular. It took some time but they edged out their place in the pantheon of high end smart phones. By making informed decision of assuring quality of the business critical aspects of any solution both the software solution providers and the potential solution seekers will be benefited with better business outcome. That I think is the writing on the wall we finally need to see.
