Test the battle with developers-I am not fighting alone

By Ouyang Chen

 

 

As a test veteran, I often hear complaints from new testers,Need to have a heated discussion with developers and feel like fighting. In fact, the battle between testers and developers is not only for small companies, but also for large software companies. This "battle" not only occurs in the early stages of the development cycle, but also in the development process. Even after the product is released, many product quality problems will be held accountable and a new "battle" will be introduced ".

 

 

As an old test engineer, I also talked about the battles between developers and testers and my own experiences.

 

 

First, let's talk about the types of battles.

1) Bug attribute battle:
Developers and testers have different opinions on a defect. For example, developers say "suggestion" and testers say "code defect". Developers say that priority is 3, the tester said it was of priority 1; the developer said it could not reproduce the problem, and the tester said it had appeared and had to be investigated.

 

2) product Indicator goals: 
What are the required indicators for a product? It is also a hot topic discussed by testers and developers. For example, testers say the performance must reach 200 milliseconds, but developers often argue that 500 milliseconds is a reasonable target. Although the product manager specifies large product indicators in the requirement specification, the detailed objectives of implementation are not carefully defined, which is often the battlefield for developers and testers.

 

3) Battle of quality tasks:
There are many types of quality assurance tasks, including writing unit tests, collecting test data, building environments, functional tests, and security checks .... How are these tasks arranged? Are they done by testers or developers? Different companies have different cultures and proportions of developers and testers, which leads to different division of labor. Sometimes, development and testing have different opinions on the owners of some tasks, which often becomes the battle focus.

 

4) Battle of code Quality
The quality of the Code is often discussed during code review. For example, the handling of some exceptions is reasonable and the coverage is comprehensive.

 

 

Testing strategy and tactics
Many testers cannot take the initiative in these battles. The following is a veteran's experience, hoping to help the testers win the initiative better in the battle and win the victory for high-quality software products. In general, it is intended for testers to protect the user experience, so they have the opportunity to get support from more people. In other words, testers are "not alone". In addition, "Multi-calculation wins, less calculation wins", try to prepare as much as possible before the discussion.

 

1) multiple references to user experience, and multiple references to competitor data as arguments 
During the discussion, if the tester's argument is "I think .....", This argument is often convincing to others, because developers can also say, "I think... Not like this ..''. Therefore, in the discussion, we should introduce user experience data as support arguments. In addition, it is convincing to list more competitor data.

For example, a user login interface requires three seconds to log on to the product. The tester thinks it is slow and the developer thinks it is acceptable. The tester can point out that, in this design, the user experience is poor and the user needs better performance. At the same time, you can list the logon time of some competitors as a reference. Not to mention "I think .....", Let's talk about the specific data of poor user experience.

 

2) win support from the project manager or product manager 
Product managers are also a strong supporter of product quality, so product managers are usually on the side of testers. If the views of developers and testers are deadlocked in terms of user experience, you can consider introducing the product manager for discussion. Generally, the product manager will support a better user experience, and stand on the side of the tester. Obtain the support from the product manager. Pay attention to the number and frequency of introductions. If too many introductions are made, developers may be dissatisfied.

 

3) same storage and exception
For non-critical arguments, such as decisions that have no essential impact on product quality, testers can maintain different opinions with developers. These different ideas will not affect the project progress and product quality.

 

4) Fast-paced

Sun Tzu said, "the soldiers are expensive, not expensive for a long time". Testers usually have a lot of work to do. If they spend a lot of time fighting with developers, they will often lose the candle. In fact, in most of the discussions, the two sides have clearly expressed their views and listed most of the arguments in the previous five minutes. Therefore5 minutesMost of the subsequent discussions are repeated arguments and arguments, which usually cannot be used to persuade others. Therefore, I advocate that the discussion of a single issue should not exceed5 minutesThe tester should control the pace and end the discussion within 5 minutes. If there is still no conclusion within five minutes, the tester can take the initiative to end the discussion:For Principle issues, consider collecting more arguments (data) and gaining support from more people. Find another time to continue discussions with developers. for trade-offs, mutual concessions can be considered to achieve a win-win situation. For some small problems, you can consider making small moves.

 

All right, so many of them are on paper. In fact, combat techniques mainly come from practice. I hope that you can maintain a good mood after the battle. In addition, you can reduce the energy spent on intense discussions and improve the effectiveness.