Apps break where you least expect them

Developing an app is anything but a static process. You can’t build a digital product once and wash your hands of it. Software without bugs just isn’t a thing, regular testing, retesting and updating is an ongoing process.

If you’re in the process of, or consider developing an app, we can’t stress enough the need to test, test, and test again. Both regularly and retrospectively.

So where do bugs occur?

Probably where you least expect them. We’ve come across many apps where their most important features didn’t work. We’ve seen an Android app where the signup and onboarding was broken.

Critical bugs occur as a natural part of software development. During active development the app is constantly tested by the developers, frequently seen by project managers and quality assurance people. Everyone sees the app, sees the new features and finds that everything works as expected. It's not the new features that break: it’s the old ones.

The old features are boring to look at for the developers and the tech team -- they worked on it in the previous sprint or milestone. Everyone already forgot about the corner cases that need special testing. And now, when some of the additions in the code may have broken those features, no one takes the time to go back and retest everything.

The take home?

Get into the habit of testing regularly and around every corner. 

QA is not a job for quitters

Quality assurance and testing is not a job for quitters. Continually testing the same thing week in week out can be laborious, boring, and requires a level of focus that most of us don’t possess. 

But even the best of QAs can miss bugs so we would always recommend keeping and using a checklist, in much the same way that pilots do before every take-off. 

Does login work? How about the forgotten password feature? How about signup? What if we tried signing up with an already existing email? 

Not only would we suggest keeping a checklist and use it to test your product once a week but keep a check on your checklist!

As problems and glitches occur, your checklist must also be amended. 

Qualities of a good QA   

QA rule 101 – don’t hire a developer to do your QA. Developers tend not to be lovers of routine tasks and have a completely different set of skills. If a developer writes bad code and they catch the bug, they will patch it and move on. 

A thorough and methodical QA will look for instances where else this kind of fault may occur. 

Your ideal QA will be someone who understands all the functions of the business, who can work across various teams, from your programmers and developers, to product designers.

But remember the words of Aristotle, “quality is not an act, it is a habit.”

We’d love to hear your experiences on successfully embedding a QA process or if you need any further advice. Get in touch on Twitter - Tech Eye (@beyourowncto) or email us here - office@beyourowncto.com.