If we directly ask ourselves the following question – who is responsible for the software quality, the first thing that comes to our mind will be – a tester, of course! But it’s not so easy as it seems.
IT field has several peculiarities that always happen at the final stage of software testing, right before it has been released. They make us think about testing not only in terms of technical quality assurance of software but also, as a part of a particular stage of software development and implementation.
Software Quality
Should the developers test their code?
A developer knows all the details and pitfalls in his/her code functioning. This knowledge is bigger and more important than the one of a tester who starts studying the tested environment.
If a developer knows where is the product’s weak spot and a tester doesn’t see this – he/she should definitely mention this. As a result, a QA engineer will appreciate this and a developer doesn’t need to additionally fix already developed and ready code. A tester will cover everything with the tests and a developer will have nothing to worry about.
In turn, developers should give a list if created unit tests, which help to avoid unnecessary tests and help to structure the parts of software testing.
As for the process of manual testing of code performed by developers, here you should use the practice of smoke testing. It’s not crucial to perform extensive testing, you just need to check that software code works on a certain list of data and pass it to the testing department where they will thoroughly work with the software.
If the code doesn’t work at this stage, you don’t need to pass it to testers. You’ll just receive in return a huge bug report with numerous defects which you are familiar with. This will just delay the software release.
Is it a tester’s fault if a bug is missed in production?
Fifty-fifty. The testing department has always things to talk about when a defect is found in production.
In fact, there are several reasons why some bugs appear exceptionally in production:
- This part of the software was never given a priority for testing. Sometimes it happens that one can never think about the bug found in production. It’s the result of incorrect communication between developer and tester. There was not a good understanding of the ways of testing this or that part of the software. If you are sure that a few core parts of the software have not been covered with tests, you should tell developers about this;
- A tester has not enough knowledge to test a particular part. It’s also an important issue of both departments. A developer has created a function but forgot to tell a tester about the peculiarities of its testing. If you as a developer see an important peculiarity of software, you should primarily inform the main QA engineer about this. You can’t miss this stage;
- A developer doesn’t care about this. Developers are the same humans as we. And each of them has his/her own life outside the office. There are developers who value not only his/her work but also care that a tester checks a high-quality software: they help to find a bug, inform about the testing peculiarities, etc. and there are some people who don’t care about this. They may not use this software every day and they don’t care what will happen with it. In other words, they don’t really care about how a product will work in production;
- Testers don’t care about this. This is the other side of the coin. Not all testers are interested in the projects they are working on. Some of them want just to rapidly finish this, create a readable report and make a point. They are not really interested in the quality of test coverage and they don’t want to communicate with developers. Developers and QAs should consistently discuss the bug nature but such a type of testers will not care about such meetings and other things;
- Low-skilled testers work on the project. One more reason for such a problem is that unqualified testers work on the project. For example, penetration testing must be performed but a manager has only a group of manual testers. In this case, they will simply not understand what they must do. You should choose more qualified testers or pass this work to developers.
- The complete absence of studying user behavior. A developer knows how to develop software and a tester – how to test it. But what should we do with users? Since they are real humans who will interfere with software from time to time. They won’t break it. And all people are different, have different goals and all of them wish to reach this with the help of the developed software. A tester can simply get used to the bug and understand that it appears occasionally and so is not critical. A user won’t stand this. If software breaks, a user will delete it or forget and use another one. It’s real life. User testing and engaging a test group to a project is crucial during the development and testing of multifunctional web product;
- Improperly built communication process. Ideally, a trivial process of defect sorting should be on the project and this process can help the developers to properly evaluate the bugs found by testers (and simply prioritize them after they have been fixed). If there is a technical misunderstanding, a tester and a developer should start the discussion, to fix the issue in the bud (ideally). If a manager has not built such communication, both sides will just simulate serious work and a problem won’t be fixed. And finally, a bug will appear in production;
- Lack of testers. The software can be complex and should be checked on several platforms and browsers at once. And few testers may be not enough. You should engage more people or find ways to distribute human resources, to be sure that everything is thoroughly tested;
- Developers are “up to their ears” in work. A company may have only 4 developers but they are very technically skillful and are ready to solve even the most complex tasks. But there are only 4 of them and there are too many projects, there is a deadline and they don’t simply have time to discuss the software with the QA department. It’s a very important and common reason why the released product has so many bugs;
- Quality is not the main thing. The software has a few bugs. One of them is visible, another one – not. But a user doesn’t like the software. And the reviews are completely negative. Why does this happen? None was really interested to create an exceptionally qualitative product. Developers wrote their code, testers performed testing but none of them paid enough attention to the process of quality assurance. Web product development should unite the departments, make them a single whole. If the company doesn’t work in such a way, then they don’t care about the software quality at all.
Conclusion
In today’s IT field, software becomes more and more complex. It’s very easy to find the responsible one. It may be the fault of a tester, manager or developer. Or all of them are guilty. The thing is that you shouldn’t search for the responsible one if you may be responsible for the quality yourself from the beginning.
Quality assurance is a mutual activity and every member should take the initiative in maintaining the highest quality of developed/tested software.
Leave A Comment