In best practices
To test or not to test?
To test or not to test? This is not the question. If you want your app to be cost efficient, you'll test it from top to bottom.
"Well, I saw it performing, but I still need to test it"
(с) an average tester
"Well, I saw it performing, but I still need to test it"
(с) an average tester
Probably in the wild one can meet a team that doesn't test its products at all. Or, for example, having made some changes, the guys organize ritual dances around the compiler so that the new build works correctly. But this is not about you, is it?
The question is: whether you need to have a tester in your team or to make developers do self-testing?
Such a question makes a modern developer think more strongly than the famous Shakespeare's "to be or not to be".
The key differences between the tester and the developer are in the style of their work. A developer is a perfectionist and features creator, who loves to code and enjoys the process itself. Developers also like to implement the conceived functionality and create algorithms. A tester is a pedant who likes to automate what has been automated (hi there, Xzibit). Therefore, in the project, the developer knows what needs to be done, and the tester knows how to do it correctly.
Such a question makes a modern developer think more strongly than the famous Shakespeare's "to be or not to be".
The key differences between the tester and the developer are in the style of their work. A developer is a perfectionist and features creator, who loves to code and enjoys the process itself. Developers also like to implement the conceived functionality and create algorithms. A tester is a pedant who likes to automate what has been automated (hi there, Xzibit). Therefore, in the project, the developer knows what needs to be done, and the tester knows how to do it correctly.
To test or not to test? This is not the question. If you want your app to be cost efficient, you'll test it from top to bottom.
Let's consider two approaches to solving the testing issue.
Let's consider two approaches to solving the testing issue.
Option 1. Developers do self-testing.
Not a bad option.
Some teams practice an approach where a developer performs unit testing only; in other teams, the developer is engaged in test automation and integration testing. Thus, developers can provide significant test coverage of their code on their own. However, the entire code must then be further thoroughly tested.
Some developers prefer to independently test their code from beginning to end. They use tests to determine the code performance, the functionality of the application, as well as to check the new build after making changes. These developers consider testing their own code as a matter of principle.
They themselves try not to allow the situation when the bug is found by users. The developer, who is constantly testing the code, is confident that the product functions properly even after making all the changes. Of course, such an approach has its advantages.
Some teams practice an approach where a developer performs unit testing only; in other teams, the developer is engaged in test automation and integration testing. Thus, developers can provide significant test coverage of their code on their own. However, the entire code must then be further thoroughly tested.
Some developers prefer to independently test their code from beginning to end. They use tests to determine the code performance, the functionality of the application, as well as to check the new build after making changes. These developers consider testing their own code as a matter of principle.
They themselves try not to allow the situation when the bug is found by users. The developer, who is constantly testing the code, is confident that the product functions properly even after making all the changes. Of course, such an approach has its advantages.
Not a bad option.
Some teams practice an approach where a developer performs unit testing only; in other teams, the developer is engaged in test automation and integration testing. Thus, developers can provide significant test coverage of their code on their own. However, the entire code must then be further thoroughly tested.
Some developers prefer to independently test their code from beginning to end. They use tests to determine the code performance, the functionality of the application, as well as to check the new build after making changes. These developers consider testing their own code as a matter of principle.
They themselves try not to allow the situation when the bug is found by users. The developer, who is constantly testing the code, is confident that the product functions properly even after making all the changes. Of course, such an approach has its advantages.
Some teams practice an approach where a developer performs unit testing only; in other teams, the developer is engaged in test automation and integration testing. Thus, developers can provide significant test coverage of their code on their own. However, the entire code must then be further thoroughly tested.
Some developers prefer to independently test their code from beginning to end. They use tests to determine the code performance, the functionality of the application, as well as to check the new build after making changes. These developers consider testing their own code as a matter of principle.
They themselves try not to allow the situation when the bug is found by users. The developer, who is constantly testing the code, is confident that the product functions properly even after making all the changes. Of course, such an approach has its advantages.
- 1Firstly, creating tests takes time, which developers could spend on writing new code. That is why many developers do not want to test their own code, considering it to be boring and distracting from the main tasks.
- 2Secondly, sometimes the developer only works on one module of the application. In this case, it is difficult to understand how all parts of the application interact with each other. It is also much more difficult to perform any tests.
- 3Thirdly, there is the human factor, which can be briefly called "I am the lord of coding." Seriously, many developers are so sure that their code is flawless that they don't see any reason to test it at all.
- 1Firstly, creating tests takes time, which developers could spend on writing new code. That is why many developers do not want to test their own code, considering it to be boring and distracting from the main tasks.
- 2Secondly, sometimes the developer only works on one module of the application. In this case, it is difficult to understand how all parts of the application interact with each other. It is also much more difficult to perform any tests.
- 3Thirdly, there is the human factor, which can be briefly called "I am the lord of coding." Seriously, many developers are so sure that their code is flawless that they don't see any reason to test it at all.
Option 2. Testers do testing.
"Our new tester proved to be a real godsend to us. He catches bugs where no one can find them! That's why the whole developing team constantly want to punch him in the face" (с) an average developer.
Software testing requires a specific set of skills (psychological skills also) that are different from the skills of a successful developer. We recently observed several open vacancies for testers like: "We are looking for a perfect pedant, a pain in a neck, a wet blanket for the position of tester". Many teams now prefer to give testing tasks to dedicated specialists.
Testing is a continuous and multiple process. Such a process cannot frighten the tester at all, for whom monotonous work is a direct responsibility.
Software testing requires a specific set of skills (psychological skills also) that are different from the skills of a successful developer. We recently observed several open vacancies for testers like: "We are looking for a perfect pedant, a pain in a neck, a wet blanket for the position of tester". Many teams now prefer to give testing tasks to dedicated specialists.
Testing is a continuous and multiple process. Such a process cannot frighten the tester at all, for whom monotonous work is a direct responsibility.
Seriously, the importance of having a good tester in a team cannot be overrated. These guys will never admit that the absence of bugs proves the correct operation of the application.
Also, when a developer doesn't need to spend time on testing, he (or she) will spend much more time writing code, that is, the productivity will increase.
Also, when a developer doesn't need to spend time on testing, he (or she) will spend much more time writing code, that is, the productivity will increase.
This option has some drawbacks too.
Not all the testers are ready to be in the creative search for new ways to catch bugs. Here, the human factor "what has been tested, does not break for the second time" works. And we all know that it's not true.
This option has some drawbacks too.
Not all the testers are ready to be in the creative search for new ways to catch bugs. Here, the human factor "what has been tested, does not break for the second time" works. And we all know that it's not true.
Testing and development is a teamwork. A competent tester should work closely with the developer, constantly getting feedback on the found bugs, ask questions and have a good understanding of the application's workflow. Unfortunately, not all experts are so experienced and competent in matters of interaction.
Testing and development is a teamwork. A competent tester should work closely with the developer, constantly getting feedback on the found bugs, ask questions and have a good understanding of the application's workflow. Unfortunately, not all experts are so experienced and competent in matters of interaction.
So what would you prefer?
In the publishing industry, there is an established process of interaction between the writer and the editor. Sometimes the cases occur when the creator of the text is already physically unable to see all its flaws, being used to the look of what is written. Let us compare this with the coding process. No matter how experienced the developer is, there is always a chance of missing the issues that the tester's "fresh perspective" will light up. Whatever you may say, a professional publisher will never publish an article without editing. That's why, despite many teams giving preference to testing by developers, other organizations, after analyzing statistics, conclude that by refusing the services of testers, they receive more complaints from users.
Perhaps you have a team of hardcore, god-like (and hugely expensive) developers who release code without a single flaw. But this means that they spend their (hugely) expensive time testing their own products because somewhere on the product release line, testing should still be done. According to some reports, almost 26% of the project budget goes to the needs of QA. You can spend this piece of the budget in such a way as to give developers as much time as possible to write code, and assign testing tasks to completely different specialists.
Perhaps you have a team of hardcore, god-like (and hugely expensive) developers who release code without a single flaw. But this means that they spend their (hugely) expensive time testing their own products because somewhere on the product release line, testing should still be done. According to some reports, almost 26% of the project budget goes to the needs of QA. You can spend this piece of the budget in such a way as to give developers as much time as possible to write code, and assign testing tasks to completely different specialists.
We'll try to make our point and give an example.
So if there is nothing else to choose between, simply choose quality. And be sure you've assured it.
So if there is nothing else to choose between, simply choose quality. And be sure you've assured it.
We love what we do and do it with pleasure. Stay hungry. Stay tuned.
QA Camp team
You may also like: