Dealing with “We are used to working like that, so don`t touch it”-kind of projects

Here is the situation: I came to the project as a QA lead, trying to optimize processes.

What I saw:

• Some of the tasks submitted by developers for testing don`t have any description: they just do something, change the status to “development completed” and send it to testers. Testers, in turn, see no documentation, no links to user history, no description of the task either. Of course, they blow up, mess with the developers, who start messing back and so on.

What I did:

• In the requests for submitting a task into the devbranch (requests pull), I added a template that automatically inserted the following text into the description:

For the convenience of the reviewers: “Summarize the changes in the code so that the reviewers would know what to check.”

Whats the purpose? Heres a simplest example. The backender doesnt want to look at the front code: he has plenty of his own problems. Therefore, we write whats been changed in the backend, and the reviewer immediately looks at this part, without wading through the jungle of changes.

For the convenience of QA: “If there is no documentation or requirements, summarize what needs to be tested and where the tester should look.”

It seems that everything is simple - you create a request for submitting, the reminder pops up automatically, you remember that you forgot to describe the changes and write them.

At the beginning, it worked perfectly… to certain point. Soon enough, people just dropped it or even tried to sabotage (“What do I write here, everything`s clear: just read the user story”). The template text was being deleted, distorted to one letter and so on.

What I changed:

I decided to take another approach. I gathered the main saboteurs, who were too lazy to write a lot of text, listened to their indignation and came up with a solution that was brilliant in its simplicity.

I added just one phrase for the tester to the text of the template message: “Test according to the user history of the task, unless otherwise specified.”

Thus, if the developer has attached a user story to his task, then they don`t need to write anything, as the robot has already written everything for them. The developer clicks of the “Publish” button and keeps on coding. The tester, in turn, sees what to test in the attached user history, clicks there, and there is a description. Everyone is happy and satisfied.

That`s all.

Short and to the point, as they say. You got similar stories out there? Submit them in the comment section!