War of the worlds: programmers vs. testers!


I used to be a tester. I remember how in those days it was sometimes extremely dissatisfied with programmers:
These eternal dubious arguments "this is not a bug, this is a feature" or "if this is a bug, then it is insignificant, let it remain."

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

Then I became a programmer. And everything changed - they began to terribly enrage me with these endless returns for revision:
They don’t like it, it doesn’t work here! Yes, what for there was generally a context menu in this window to call and insert unreadable characters !? How did they even think of that !? Bullshit, in combat mode no user will do that!

I will not rule, let it remain!

In general, the classics are the enmity of programmers and testers.

And then I became a manager. And I realized that this enmity was fatal to the common cause. Fortunately, I well remembered myself 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 understandable development process:

Tasks -> Programming <--> Testing -> Release

Moreover
  • Testers learn about tasks only at the time of their transfer 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!

At programmers
  • Entrance: new tasks and returns from testing.
  • exit: transfer tasks to testing.

At testers
  • input: tasks from programmers.
  • exit: returning tasks to programmers and the official release of the version.

Actually, the process is not bad in itself - everyone lives in his own world and does what he loves.

goal


But 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 a manager arrives and begins to remind about 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: “development only issued the assembly in the morning, we just started testing, and there will definitely be a return - there have already been a lot of bugs, so we don’t know when the release will be - ask with programmers. "

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

As a result, the manager’s patience ends, he brings together programmers and testers together and tries to somehow solve the problem. Actually, all decisions come down to the development of rules for 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 formed in our department after several months of exhausting work of the manager:
  • Joint planning . The version is planned in advance. The planning is attended by both programmers and testers. Thanks to this, everyone knows in advance what they have to do. For example, this allows testers to start drawing up test plans in advance and to 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", ie the effect of the accumulation of a large number of half-completed tasks in the main branch. And it also prevents programmers from messing around - they can always do the next task in brunch.
  • Small versions . This is an attempt to reduce development in brunches, because this is the overhead of merge, updating the code and re-testing. If you make small versions, then you can work right away in the main branch.
  • Doing nothing . Another attempt to reduce development in brunches. When a lot of tasks accumulate in brunches, and development runs far ahead of testing, programmers are allowed to just do nothing so as not to run forward even more.
  • Early informing . For example, the tester began to test the task. The task is big, but he immediately found a defect. He reports this to the programmer immediately upon discovery, and not at the end, when all testing is complete. Or vice versa, the programmer, even during development, informs the tester about the nuances of implementation so that he prepares a test plan in advance. This kind of allows you to parallelize the work of the programmer and tester.

All these rules actually helped to improve the situation, but they did not fundamentally change it. They seemed to plug 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 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 animosity, so it remained.

Awareness


Many more days and nights 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!
But the very structure of such an approach, when “some 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 the goal of "testing."
Developers have a goal to “develop”, i.e. "Pass to testing."
And the goal is to “release a release” only with the manager. And only while he puts effort into it - is it achieved.
And when people have different goals - they are not on the way, they are not interested in each other. As they are not attracted, they will still go their own way, in different directions.

Decision


Actually, the solution to the problem is to set one common goal both for programmers and testers.

Moreover, the goal is obvious - the release of a quality release on time.

Indeed, not reaching this goal, the local goals of “develop” and “test” lose all meaning.
It’s like a famous saying that for some people money is a goal, but for someone it’s a means.
Those. programming and testing are means, albeit pleasant ones - it’s even good, but still means. And the goal is release.

Clearly, changing goals was not easy. But since I was completely imbued with the logic of my thoughts, I was ready to break any resistance to change!

Here is the main thing that has been done:
  1. Changed the organizational structure of the department. Instead of development and testing departments, teams have been formed in which both programmers and testers are assembled.
  2. Relocation . The newly formed teams received a separate room. Now there was no situation where testers and programmers are sitting in separate rooms and living their own lives.
  3. Propaganda . Naturally, I had to say a lot of fiery speeches about why and why we started a reorganization. And the main thing is to convey to everyone a common goal, for which reason we all gathered here. Since people are all literate, and ideas are logical, propaganda turned out to be easy and successful.
  4. Dismissal . Alas, someone disagreed with the new ideas. But it’s for the better, they have given way to those who now do much more good!

And all these efforts were worth it! The effect was simply amazing!
  • The tensions between programmers and testers disappeared, as if they weren't.
  • Mutual support appeared, products became better.
  • Programmers began to help testers, pointing out bottlenecks that should be further checked.
  • The general attitude towards 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 implemented by themselves - because everyone understood their effectiveness.
  • In general, it worked like a clock - regular releases, a quality product.

Before our eyes, for some six months, a real transformation has taken place!

Conclusion


Any conflict always has a true reason. In a typical conflict between programmers and testers, the true reason is different goals. It is worth setting one common goal before them - and everything will immediately change! Programmers and testers will become best friends, they will always help each other, and everyone will benefit from it - programmers, testers, managers, products, the company!

Also popular now: