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?
The developer points his finger at the QA and says it was his fault that he never spotted the leak.
The QA looks at the developer telling him he built a shitty boat in the first place.
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.
Top comments (4)
I find weird when devs try to avoid testing, do they cook and serve without tasting the food?, they write without reading it after?, are their egos so huge they cannot conceive that their code may not do what they expect?, testing is not a separated thing, is just see if it works, instead of manually try different parameters, you automate them, is so weird to me avoid that, is like saying my job is not typing, is coding, bring me a typist!. QA has a different job, is Quality assurance, they also should make tests, just as they also type, and also turn on their computers. Are those prodigious devs that think they are perfect, picture a car designer just making a prototype and then send it to QA without even try it?, designing a circuit board, populating a breadboard and send it to QA without even turn it ON to check if is fine?.
Testing is annoying, I hate it, is boring, feels like solving the problem twice, but I don't like cleaning my house nor enjoy brushing my teeth. To those perfect godsend infallible programmers, even if your code is actually perfect, I have no reason to believe it, prove it, show me the code that says it works, testing is part of our job, deal with it.
Yes.
It is the responsibility of the developer to ship code that works as intended. Therefore the developer must do the testing necessary to ensure their code always works.
QA is an additional defense. Think of them as (constant) auditors of your work. In reality, if things always worked as expected, we would never need QA. Or at least they would be usability / design testers rather than functionality testers. But of course QA is needed because people make mistakes, miss or misunderstand requirements, etc.
Trick question. BOTH.