What happens if you don't know whose responsibility is to do mobile app testing? QA or Developer.

Consider this scenario:

You send a developer, QA, and the customer on a boat that your team had built. What happens if the boat suddenly starts taking in water in the middle of the river?

1. The developer points his finger at the QA and says it was his fault that he never spotted the leak.

2. The QA looks at the developer telling him he built a shitty boat in the first place.

3. The customer has his head wrapped in his hands, knowing for certain that he is going to drown.

This is not some warped way of looking at App development these days. In this age of Agile, where iterations are made on the fly, and the code is constantly evolving (thanks to changing customer's needs), it is next to impossible to deliver a production-ready application that is error-free.

In fact, according to this research by Coralogix, a developer creates 70 bugs per 1000 lines of code.

So the importance of testing the code, be it Unit Testing, Behaviour Driven Development (BDD) or Exploratory Testing, is paramount.

But whose baby is testing anyways?

Isn't QA responsible for catching the bugs, since that is their job?

Aren't developers supposed to run at least a Unit Test on their code, to make everyone's life easier?

In this article, we try to answer these questions, trying to put to rest the age-old debate between QA and Development - whose line is it anyway?

Let's identify whose job is to do mobile app testing- QA vs Developer-

QA-based App testing - The "doers" approach

One of the fundamental qualities of a Tester is that he or she " Thinks different."

The mantra for any testing team should be the now-famous Facebook motto, "Move fast and break things."

A tester can look at the code from different angles, use it in ways that the developer would never have imagined, and put the application through its paces.

That's why we like to call it the "doers" approach.

While testing might seem a repetitive and time-consuming job, in reality, the testing requires a whole different level of skill sets that a developer generally lacks.

According to Nataliya Hordiy, a QA analyst at LYONSCG -

Testers are disciplined, like repetition, and have a broader knowledge of the application's regression history than any developer.

What makes a tester invaluable is the way they quickly grasp the functionalities of an application, and then try and find a way to break it. Testers can be compared to little kids who have been handed a set of LEGO toys.

We have thousands of ways to put together those LEGO blocks. Similarly, customers might have thousands of ways to use the app. So, the testers have to identify each way the customer might want to use the app.

Developers might consider testing as an "added management hassle." Hence, having good QA teams for larger applications and a single tester per team can save thousands of man-hours and dollars. This way you may avoid sticky issues when the code goes into production.

Testing also helps in providing a rich depository of knowledge in the form of documentation that can be used to guide customers and newer recruits. Developers can refer to this documentation and learn how the application performs as a whole.

In summary, testing helps the team to get a helicopter's view of the application, and having a good tester in your team is as big an asset as having a really talented developer.

Developer-based App testing - The "thinkers" approach

While it may not be possible to find a great developer like Bertram Gilfoyle from the hit HBO show Silicon Valley, there is a huge number of quality developers out there.

But do these developers also don the hat of testers, if needed, and perform a minimum automated Unit tests on their code? The jury is still out.

On the one hand, most of the developers feel that testing is repetitive and they can invest that time in building new features for the app instead. But there is also a school of developers who feel that their code is perfect and would be bug-free.

Developers often take what we call the "thinkers" approach. They know that they are building an application. Also, they know how their code is supposed to function.

And, they may miss out on whether their code might mess up the other functions written by other developers when it goes into production.

In other words, developers are good at thinking up solutions to problems and then converting it into code. Still, they don't want to be bothered if the problem they solved aligns with the bigger picture, which is the entire application working smoothly.

But, like exceptions to every group, there is still a small army of developers who feel that the code they ship should be perfect. They are constantly trying to avoid painful emails from the QA team by using coded tests to see if a new fix they just wrote breaks existing code.

These developers see their code as a piece of art. They are easily put off when they find lengthy bug reports from the testing team, or worse, customers complaining about the app crashing when they use a feature that was built by the said developer.

So whose line is it anyway?

Now coming to answering this big question - who should take the blame when the code breaks?

In our opinion, every line of code, and every piece of software that you put out, there is a team effort. There should be no name-calling and finger-pointing when something doesn't work according to the way it was supposed to.

A developer should test the code that he or she writes since he/she knows it better than anyone else. Writing test cases and carrying out repetitive tests should not be seen as a waste of time since a poorly written piece of code can play havoc when it goes into production.

A software tester should look at the application as a whole, and report errors that may arise in the customer workflow that the developers may have missed.

Testing should be a shared responsibility and should be seen as the natural progression from development, rather than an add-on responsibility.

A good developer knows the basics of testing and can do some of the things that a tester does. In the same vein, a good tester knows the basics of development, and the pain points that a developer faces.

Any points that you feel we have missed? Do write to us and, if it resonates with us, we will include it in the article.