QA for Startups
Quality Assurance, or QA for short, is an important part of any app development process. QA helps identify potential issues before your app gets in front of users, which results in happy customers, more revenue, and lower development costs in the long run.
However, QA can also be a significant cost for a startup, depending on how much confidence in a product stakeholders require. QA can involve anything from just having someone open the app before you hit the final publish button all the way through a full-on QA Engineer writing extensive amounts of code that verifies the functionality of other code.
What it should not include, however, is developers spending cycles attempting to find bugs in the application they wrote. There are a few reasons for this.
First, developers are often one of the largest expenses in creating an app. Having your most expensive worker doing things that others are just as qualified to do is a recipe for going over budget.
Second, developers are notoriously bad at finding bugs in their own work – and it’s not because they’re stubborn, as tempting as that is to believe. The issue is that, as the architects of what actually appears on the screen, they have internalized the ‘proper’ way to do things. They know the way the system is meant to be used on an almost innate level, making thinking outside of that box difficult to say the least.
Third, developers think deeply about all the things that could go wrong in an application. Unfortunately, if they spent all their time preventing each of those things, the app would never be finished. Without a sense of how to prioritize various problems, developers will inevitably try to fix the wrong things – resulting in higher costs for the client.
As a result, LithoByte recommends one of two things: either including QA engineers explicitly in the project from the beginning, or have startup-internal contributors do some amount of testing themselves. If the former, startups should prepare for additional costs (though not as much as if they had no QA at all – you’ll pay for it now, or later, when your users report the bugs to you).
The latter (having a someone internal to the startup do testing), often means that the founder or a co-founder is testing out the application themselves. This is a good thing on several levels. As we’ve previously discussed in our article on bugs, founders often have a vision in their head of how an app should behave, but, through the process of reducing that vision to the imperfect medium of words, an incomplete version of that vision is communicated to the developers (not to mention the further translation into code). Having the founder frequently review the product has huge advantages, and allows the team to resolve discrepancies earlier in the process. This is often the cheapest, most effective way to accomplish QA.
Luckily, both Apple and Google have built in ways to test apps out before they get to live users. We highly recommend that, even if you have external QA consultants checking over the product, you also make use of the these tools to do internal testing by at least one stakeholder before releasing the application.
