War of the Worlds: Programmers vs. testers!

I used to be a tester. I remember how, in those days, sometimes I was extremely dissatisfied with programmers:

These eternal dubious arguments "is not a bug, it is a feature" or "if it is a bug, then it is insignificant, let it remain."

But how does it stay if the system gets up with a stake !?

Then I became a programmer. And everything changed - I began to terribly enrage these endless returns for revision:

Then they do not like it, it does not work here! Yes, it was generally in this window that the context menu calls and inserts unreadable characters!? How did they even think of this before !? Nonsense, in combat mode, so no user will do!

I will not rule, let it remain!

In general, the classic is the feud of programmers and testers.
')
And then I became a manager. And I realized that this hostility is detrimental to the common cause. Fortunately, I remembered myself well as a programmer and tester, which helped me realize the true essence of the problem and change the situation.

Process

In those days, we had a very simple and clear development process:

Tasks -> Programming <-> Testing -> Release

And

• Testers learn about tasks only at the moment they are passed to testing, i.e. they do not receive notifications about the beginning of the development of a new task.
• Programmers do not wait for the completion of testing tasks and start new tasks immediately.

Well, this is an example of perfect encapsulation!

Have programmers

• at the entrance: new tasks and returns from testing.
• at the exit: transferring tasks to testing.

Testers

• at the entrance: tasks from programmers.
• out: return tasks to programmers and the official release version.

Actually, the process is not bad in itself - everyone lives in his own world and does his favorite thing.

purpose

But after all, this process has a very specific ultimate goal - to produce high-quality software with the necessary functionality on time.

Actually, at this moment the problems begin.

Problems

Once the manager comes and begins to remind of the ultimate goal.

Typical situation:

The manager comes to the programmers and asks “when?”, And they answer “we don’t know, we did everything, ask the testers”.

The manager goes to the testers with the same question “when?”, And they answer him “the development issued an assembly only in the morning, we just started testing, and there will definitely be a return - there are a lot of bugs here, so we don’t know when there will be a release - ask at programmers ".

And the manager begins to walk in a circle back and forth, but there is still no release and no.

As a result, the manager's patience ends, he brings programmers and testers together and tries to somehow solve the problem. Actually, all decisions are reduced to the development of rules of interaction between programmers and testers. And all further efforts of the manager are aimed at monitoring compliance with these rules.

Here are some rules that have been formed in our department after several months of the manager’s exhausting work:

• Joint planning . The version is planned in advance. At planning there are both programmers and testers. Because of this, everyone knows in advance what they have to do. For example, it allows testers to begin to make test plans in advance and prepare the necessary test environment.
• Development in brunches . The developer does not inject new tasks into the main branch until all already poured tasks are tested. This avoids the "snowball", i.e. the effect of the accumulation of a large number of half-done tasks in the main branch. And it also does not allow programmers to idle - they can always do the next task in the brunch.
• Little versions . This is an attempt to reduce development in brunch, because it is the overhead of merge, updating the code and re-testing. If you make small versions, you can work immediately in the main branch.
• Doing nothing . Another attempt to reduce development in brunches. When many tasks are accumulated in the branches, and the development strongly runs away from testing, then programmers are allowed to simply do nothing so as not to run ahead anymore.
• Early notice . For example, the tester started testing the task. The task is big, but he immediately found the defect. He reports this to the programmer immediately upon detection, and not at the end, when all testing has been completed. Or vice versa, the programmer informs the tester about the implementation nuances during the development so that he prepares a test plan in advance. It seems to allow you to parallelize the work of a programmer and a tester.

All these rules, in fact, even though they helped to improve the situation, did not fundamentally change it. They seem to have shut up one small hole. It was felt that there was some other solution, that something was overlooked.

For example, as soon as the manager relaxed - almost immediately all the agreements between programmers and testers were forgotten, and everything returned to its original state.

Moreover, the relationship between programmers and testers did not improve - as there was hostility, so it remained.

Awareness

Many more days and nights have passed, when I thought a lot about the causes of what is happening, about the behavior of people, about their emotions, needs and motives.
And then suddenly everything became clear!
Why, the very structure of this approach, when “some people program, others test,” gives rise to a conflict between programmers and testers.

And the whole point of this conflict is that they have different goals !

Testers have a goal to “test”.
Developers have a goal to “develop”, i.e. "Pass into testing."
And the goal is to “release a release” only from the manager. And only while he puts efforts to it - is it achieved.
And when people have different goals - they are not on the way, they are not interesting to each other. As they do not attract, they will still go their own way, in different directions.

Decision

Actually, the solution of the problem lies in the fact that to put both a common goal for programmers and testers.

And the goal is obvious - to release a quality release on time.

Indeed, without achieving this goal, local goals “to develop” and “test” lose all meaning.
It is like the famous saying that for someone money is the goal, but for someone it is a means.
Those. programming and testing are means, even pleasant ones — it is even good, but still means. And the goal is the release.

It is clear that changing the goals was not an easy task. But since I was completely imbued with the logic of my thoughts, I was ready to break any resistance to change!

Here are the main things that have been done:

1. Changed the organizational structure of the department. Instead of the development and testing departments, teams are formed in which programmers and testers are assembled.
2. Moving The newly formed teams received a separate room. Now there was no situation when testers and programmers are sitting in separate rooms and live their own lives.
3. Propaganda . Naturally, I had to say a lot of fiery speeches about why and why we started reorganization. And most importantly - to convey to everyone a common goal, for which we all are here all gathered. Since people are all literate, and logical ideas - propaganda has turned out easy and successful.
4. Dismissal Alas, someone disagreed with new ideas. But it is for the better, they gave way to those who now brings much more good!

And all this effort was worth it! The effect was just amazing!

• Tensions between programmers and testers have disappeared, as if there was none.
• Mutual support appeared, the products became better.
• Programmers began to help testers, pointing out the bottlenecks that are worth further checking.
• The general attitude to the detected defects has changed. No one considers anyone guilty. On the contrary, the developer is grateful to the tester that he helped make the product better!
• All agreements on the interaction of programmers and testers began to be executed by themselves - because everyone understood their effectiveness.
• In general, everything worked like a clock - regular releases, high-quality product.

In the eyes of some six months, there was a real transformation!

Conclusion

Any conflict always has a true cause. In a typical conflict between programmers and testers, the true reason is different goals. It is necessary to put before them one common goal - and everything will change at once! Programmers and testers will become best friends, will always help each other, and everyone will benefit from this — programmers, testers, managers, products, and the company!