Test it fast? It won't work.
Sometimes you really want to test something "in a hurry." Most of the time this works poorly, unless you know exactly what you are doing and why.
You lead product development in a small company. The development process is based on two-week iterations; demo of ready-made snacks for the customer are periodically held. The developers are quite strong and experienced, the product didn’t look too complicated, so there wasn’t any testers on the project, and now there aren’t either.
During the half a year that has already passed from the start, you have done a good job, the customer as a whole is pleased with the progress of the work, although, of course, the drops and the inadequate behavior of the product during the demonstrations confuse him. The last demonstration was especially successful - due to technical problems that arose, it was not possible to show new features. The customer demanded more attention to be paid to the stability and quality of the product.
According to the plans, three and a half iterations are left until the project is completed, the developers' time has already been planned, and you decide to hire testers - so that they can quickly test everything, scoop at least the main problems and thereby help to produce a fairly good product.
Hey, that won't work!
Even assuming that at the moment when you decided to hire testers, the house attendant put a list of suitable candidates on your desk - you need to contact each of them and call to your place. Those need to retire from the current place of work, and coming to you - spend the day setting up the workplace. In short, there will be two and a half weeks between the decision making and the appearance of testers on the project. There are two iterations left.
The first iteration of the testers will take to get acquainted with the product and understanding - and what are we doing here at all? Well, even if half of the iteration is a week, it’s still quite a lot.
That is, in the allotted time, testers will be able to bring at least some benefit only in the last three weeks. And it will be a rather chaotic use, because you can hardly give them time to analyze the situation and clarify expectations. It's good if you can decide on priorities.
So, three weeks. But testers only find problems and tell others about them. Problems will have to be fixed by developers, whose time, as we remember, was planned a month ago.
Some of the problems found will be caused by a misunderstanding of the product’s work - you don’t expect that the nuances of logic developed in half a year will become clear to the new person in a week? And there are certain nuances, otherwise there would be no problems at the product demonstrations to the customer. In short, some of the problems are rubbish. But someone has to spend time and understand whether there is a bug or not.
And by the way, you are not going to repair everything that testers dig up? Someone must also prioritize the found bugs.
Again, due to a weak acquaintance with the product, there is a chance to find a bunch of small things, but not to find a serious problem that the customer comes on the second day.
In general, too many questions and fuss for the sake of a three-week work of unknown people with an unknown result.
')
The initial data is the same, the difference is only one: you decide to hire experienced testers who are familiar with the subject area: they will be able to quickly get involved in the work and bring more benefits.
No, it will not work.
This time I’ll ask you: where will you find them, so experienced and useful? And when you find - how will you invite to yourself?
In testing, as well as in programming (and any other profession), experienced, adequate professionals are appreciated. Most likely, they are well at the current place of work. In the labor market (especially open), these specialists appear less frequently.
What can you offer them that they will go to you? A month and a half of work on a burning project and a vague perspective, what then, they say, will still be working? Turning into the head of the testing department (for the same month and a half)? By the way, do you yourself need an inexperienced leader, who yesterday was the former, let him lead, but an engineer?
But this is only the beginning: under the hired testers will have to rebuild the development process, to establish communication between testers and programmers, to look for hardware for working machines and test labs.
No, not for a month and a half :).
Another situation.
Testers are already there and working. Processes are debugged (well, more or less), there is a separate test environment, etc. Basic needs are met, so to speak.
The work is in full swing, the project goes on as usual, everything is in order in general.
I just really want another feature. Well, she needed this, and only one. And the completion of the project - it is already seen, and it seems to fit. Well, let's do this too.
Programmers promise to do in the penultimate iteration. And - we will test quickly.
Do not! It will not work!
In any case, not in the form of "everything will be exactly the same, just another plus is this feature." It will not be the same.
There will be - a little ambiguity in the requirements. Programmers will work a little longer. A pair of unrecorded dependencies in the product will pop up. The testing area will increase slightly, the available testing time will decrease. Junior tester sick. Everyone will hurry and miss something.
Classic.
And a very good result is if your little feature has not taken root deeply into the product. Otherwise (almost always) problems will appear somewhere else, a little aside, where they will be forgotten and look.
Good autotests with decent coverage will help, but, I'm afraid, they won't save: they started testing at the last moment, there is not enough time to repair, but you also need to check the fix later ...
In general, be prepared that the quality of the product will eventually subside. And well, if the feature was worth it. And even better, decide in advance what you are willing to sacrifice for such a wonderful feature, and - cut it off in advance.
And then the deception of some kind of themselves will turn out differently.
In general, yes, although in this case there are many questions and nuances, of course.
Even testing “in a hurry” can be a very reasonable solution - it all depends on priorities and tasks in reality.
But it is better not to introduce instability into this already chaotic system.
And last but not the least it’s worth remembering that testing alone will not help anyone. Testers may find a problem, but other people will have to fix it. Attracting testers will not change anything if they live in their vacuum spherical world. Strength comes from the effective interaction of all participants in the process - programmers, testers, managers and other analysts.
one.
You lead product development in a small company. The development process is based on two-week iterations; demo of ready-made snacks for the customer are periodically held. The developers are quite strong and experienced, the product didn’t look too complicated, so there wasn’t any testers on the project, and now there aren’t either.
During the half a year that has already passed from the start, you have done a good job, the customer as a whole is pleased with the progress of the work, although, of course, the drops and the inadequate behavior of the product during the demonstrations confuse him. The last demonstration was especially successful - due to technical problems that arose, it was not possible to show new features. The customer demanded more attention to be paid to the stability and quality of the product.
According to the plans, three and a half iterations are left until the project is completed, the developers' time has already been planned, and you decide to hire testers - so that they can quickly test everything, scoop at least the main problems and thereby help to produce a fairly good product.
Hey, that won't work!
Even assuming that at the moment when you decided to hire testers, the house attendant put a list of suitable candidates on your desk - you need to contact each of them and call to your place. Those need to retire from the current place of work, and coming to you - spend the day setting up the workplace. In short, there will be two and a half weeks between the decision making and the appearance of testers on the project. There are two iterations left.
The first iteration of the testers will take to get acquainted with the product and understanding - and what are we doing here at all? Well, even if half of the iteration is a week, it’s still quite a lot.
That is, in the allotted time, testers will be able to bring at least some benefit only in the last three weeks. And it will be a rather chaotic use, because you can hardly give them time to analyze the situation and clarify expectations. It's good if you can decide on priorities.
So, three weeks. But testers only find problems and tell others about them. Problems will have to be fixed by developers, whose time, as we remember, was planned a month ago.
Some of the problems found will be caused by a misunderstanding of the product’s work - you don’t expect that the nuances of logic developed in half a year will become clear to the new person in a week? And there are certain nuances, otherwise there would be no problems at the product demonstrations to the customer. In short, some of the problems are rubbish. But someone has to spend time and understand whether there is a bug or not.
And by the way, you are not going to repair everything that testers dig up? Someone must also prioritize the found bugs.
Again, due to a weak acquaintance with the product, there is a chance to find a bunch of small things, but not to find a serious problem that the customer comes on the second day.
In general, too many questions and fuss for the sake of a three-week work of unknown people with an unknown result.
')
2
The initial data is the same, the difference is only one: you decide to hire experienced testers who are familiar with the subject area: they will be able to quickly get involved in the work and bring more benefits.
No, it will not work.
This time I’ll ask you: where will you find them, so experienced and useful? And when you find - how will you invite to yourself?
In testing, as well as in programming (and any other profession), experienced, adequate professionals are appreciated. Most likely, they are well at the current place of work. In the labor market (especially open), these specialists appear less frequently.
What can you offer them that they will go to you? A month and a half of work on a burning project and a vague perspective, what then, they say, will still be working? Turning into the head of the testing department (for the same month and a half)? By the way, do you yourself need an inexperienced leader, who yesterday was the former, let him lead, but an engineer?
But this is only the beginning: under the hired testers will have to rebuild the development process, to establish communication between testers and programmers, to look for hardware for working machines and test labs.
No, not for a month and a half :).
3
Another situation.
Testers are already there and working. Processes are debugged (well, more or less), there is a separate test environment, etc. Basic needs are met, so to speak.
The work is in full swing, the project goes on as usual, everything is in order in general.
I just really want another feature. Well, she needed this, and only one. And the completion of the project - it is already seen, and it seems to fit. Well, let's do this too.
Programmers promise to do in the penultimate iteration. And - we will test quickly.
Do not! It will not work!
In any case, not in the form of "everything will be exactly the same, just another plus is this feature." It will not be the same.
There will be - a little ambiguity in the requirements. Programmers will work a little longer. A pair of unrecorded dependencies in the product will pop up. The testing area will increase slightly, the available testing time will decrease. Junior tester sick. Everyone will hurry and miss something.
Classic.
And a very good result is if your little feature has not taken root deeply into the product. Otherwise (almost always) problems will appear somewhere else, a little aside, where they will be forgotten and look.
Good autotests with decent coverage will help, but, I'm afraid, they won't save: they started testing at the last moment, there is not enough time to repair, but you also need to check the fix later ...
In general, be prepared that the quality of the product will eventually subside. And well, if the feature was worth it. And even better, decide in advance what you are willing to sacrifice for such a wonderful feature, and - cut it off in advance.
And then the deception of some kind of themselves will turn out differently.
Um But in general - at least sometime testing will work?
In general, yes, although in this case there are many questions and nuances, of course.
Even testing “in a hurry” can be a very reasonable solution - it all depends on priorities and tasks in reality.
But it is better not to introduce instability into this already chaotic system.
And last but not the least it’s worth remembering that testing alone will not help anyone. Testers may find a problem, but other people will have to fix it. Attracting testers will not change anything if they live in their vacuum spherical world. Strength comes from the effective interaction of all participants in the process - programmers, testers, managers and other analysts.
Source: https://habr.com/ru/post/138313/
All Articles