The quality of testing. Who is responsible for that? For so many years the only answer that I had in the back of my mind was “QA”. And let me tell you — I’m a QA Engineer myself.
I know how important is to test the quality of the software that is planned to be released to public. However, I’ve noticed some patterns along the way that sometimes made me wonder about the whole testing process and how it might be improved.
Should developers test their own code?
Thank you for asking. If you are a developer, you know all the hidden paths that you code does, or at least more than a QA Engineer does. You know your code from top to bottom and where a problem might exist.
If you know where the problematic area might be — give a hint to a QA Engineer. Yes, they will discover those at some point, but you know more about the architecture of the application. We would appreciate if you tell us beforehand where the problem might be.
We’ll take it from there and write a test coverage that takes away your worry. But it definitely won’t hurt if there is some additional information provided by developers.
Few words about testing of your own code. My opinion is that developers should at least make a smoke test of their code. There is no need to run extensive tests. Just check that it works on the first pass and give it to testing team to investigate further.
If it doesn’t work on the first pass, why even bother giving it to QA? There would be dozens of bug reports and you already know that there are problems — it will only slow down the development process.
We missed a bug. It’s a QA fault, right?
Yes, and no. Each time there is a bug discovered, especially in production, there is something to discuss with your team. There are several possible reasons the bug reached the production:
1. The failed area was never a priority.
Frequently, the bug that was discovered in production was never thought of. There was not enough communication between QA and Development team. There was no mutual understanding of how important it was. Classic examples are performance and security issues. If you know that those areas are vital for your application — communicate it within a team.
2. QA doesn’t have a necessary knowledge of that area.
It’s also a common problem. Developers created a feature and automatically assumed that QA understands all aspects of it. Well, assuming is never a good approach and especially for a quality of a serious project. If you know that this is super important — let a QA manager and QA team be aware of that. There is no way around it.
3. Software Developers don’t really care.
We are all humans. We all have our schedule outside of work. Some developers might work long hours to make sure they ship the product of a highest quality — they talk to QA team; they make them aware of possible problems and things like that. And then there are developers who simply don’t care. They don’t really use the product daily, nor they understand the importance of it. For them it’s just a side gig, they want to finish and forget about it. To put it simple: they don’t care if the final product is not up to a quality standard.
4. Quality Engineers don’t really care.
Here is a flip side of the coin. Not all QA Engineers care. Some of them want to finish testing, make a beautiful report and forget about it. Proper test coverage doesn’t bother them. Communication with developers is not a priority for them. Bugs might be discussed, but they either think those are not important or don’t even want to bother filing those.
5. Test Engineers are not qualified enough.
Other problem is that QA doesn’t have enough qualification to test your application. For example, it needs penetration testing and all you have is a Manual QA test team. In that case, they don’t even understand how to properly test it. You should either rely on developers in that case or have qualified engineers within your team who know how to properly test that specific area.
6. Lack of user studies.
Engineers think how to build the app, QA thinks how to break the app. And what about users? Users are actual people who will use your app in a real-world scenario. They don’t intend to break it. They are just different personalities that have different goals and they want to achieve those by using your application. QA people might get used to a bug and understand that it’s not always repeatable and hence — not a big deal. User won’t tolerate that. If it breaks the next their step would be wiping your app and finding an alternative. That’s the reality. User studies and/or having a test user group are very important strategies.
7. Bad communication process
Ideally, there should be a straightforward bug triage process that makes QA bugs being appreciated (and at least properly prioritized) and Developers who understand their workload. When there is a misunderstanding, QA or Developer could approach each other and resolve that problem within a few minutes or hours. If there is no process and both sides try to hide underlying problem of miscommunication, then nothing good comes out of it. Both sides pretend that something is going on while in reality both sides are stuck and wait for someone else to resolve the mess. That’s not a proper solution.
8. There are not enough Test Engineers.
This might be a complex application and multiple platforms and browsers to test. Just a few engineers might be not enough for that task. Consider hiring more people or finding a solution of how to focus all your resources on testing.
9. Developers are overloaded.
There might be a perfect engineers all around you, but they are stressed out and have no one to assist them. Yes, they are stressed out and they have no time to communicate with the QA. They have a lot of tasks to do and not enough time to actually make a quality product. It’s a very common issue and one of the main reasons the software lacks quality.
10. Quality was never a focus.
Take that common scenario into account. There were some minor bugs there and there. None of them were really that bad. But users don’t like the app. Reviews are bad. User experience is below average. Why? It’s because making a polished product was never a focus. Developers were doing their job, testers were doing theirs, but there was nobody to coordinate the fact that quality product is a priority. That application must feel as a whole for everyone. If there was no mood like that within the team it means that quality was never a real priority.
Conclusion
Applications these days are getting more and more complex day after day. If there is a need to find a culprit of a failed project, it’s always an easy task. It might be a QA or Developers or Management. Or all parties involved. The main question is why should we look for someone to blame if all of us could take responsibility for the project? It might be anyone who did not notice an importance of testing for a particular feature. The only question should be “Are we making a good product?”. If the answer to that question is “Yes” then there would be no doubt that all teams are doing a great job.
There would be nobody to blame and everyone would be happy. Quality is a collaborative effort.
Original arcticle: https://medium.com/swlh/who-is-responsible-for-the-quality-of-application-testing-cef91db32f74