QA & BugFixing – Step IV of interexy Development Process

Step by step we’re moving to the ending of the description of our work process – and we are already at step 4!

What the first thing to do after the completion of the intensive development plan with lots of sprints, planning, check-ins & quality assurance processes tied up with it? Check out the work done! QA is our guy here.

We have a certain checklist we follow within this process – after the completion of the development stage within the kick-off of testing one there should definitely be a process in place on how to test, which parts of the product to start with when to do regression & stress testing.
There are different approaches to test for iOS & Android, the main difference is in the number of devices – for Android it’s obviously higher. There are also different approaches to test in connection to what development methodology you are using, what architecture you’re writing code with – but that’s a whole different discussion for about 10 more articles.

The thing that helps the most with UI tests for mobile apps is Automated Testing. In some cases, you’ll be able to manually test the UI of the application for iOS devices, but in the case of Android – there are just too many of them to test everything using a manual approach. With UI tests we can provide rules for certain behaviours for our UI within different screen size & screen ratios. It speeds ups the process vastly and frees a bunch of free time to write automated tests for certain parts of complex logic, API communication, models communication, etc.

Speaking of Automated Tested as itself there is also a number of approaches (TDD (test-driven development), BDD (behaviour-driven testing), DDT (data-driven testing) KDT (keyword-driven testing). But that’s also a topic for at least 5 more articles ?

So, what the most important thing in testing within our space – startup mobile development?

Well, it depends on the goal you’re trying to reach with MVP – if it’s just a first initial version built with web-based technology and you have plans to rewrite the whole thing from scratch once proving initial traction & fundraising – manual testing should work fine. It will speed up the launching process and you won’t meet any critical performance issues in the default case.

If you already have a certain version of the application, have funds and a clear business plan for new functionalities & future releases, as well as constant feedback loop setup with your target audience – that’s the point you need to look through all the available testing methodologies and pick one for yourself.
Whether it’s the approach to write tests before you add any logic into the product and only after that be writing the functional code or manual testing with certain checkmarks to follow just to meet next sprint deadline – testing is an essential part of any mobile product development. The market has high expectations right now and users expect perfect performance, UX/UI even from MVPs nowadays – in reality, AppStore won’t even approve buggy MVP on their platform. (Google Play started to follow the same rules recently).

UI design check, UX performance check (with the test group & internal design team), performance testing using native development environments (if you are using cross-platform development solutions), regression tests, stress backend testing (to make sure system will handle more users once you kick off marketing) and you should be all good.

Stay tuned!