Do programmer like test _ software test

Programmer and Software testing in the workflow is the upstream and downstream relationship, and work closely linked, the communication inevitably appear a variety of problems. As a programmer in the management software industry, I have been dealing with software testers for many years. Hope to be able to from the programmer's point of view, for software testers to make a little suggestion.

First, let's take a look at what the program workers are most reluctant to hear from software testers.

1, XX, and found a serious bug.

(Ni ma, copy error also calculate C-class bug?) NI, 1th bug and bug 2nd are the same problem, you mention two times C class. Do you want my brother to put your bug in Jira into Notabug?

2, I mentioned the bug how not clear. The last question I mentioned has not changed.

(Ni ma, you mention the bug inside, screenshots have wood.) The operating environment has wood. It's easy to write a text description without punctuation. There is wood there. I can only change according to my own understanding. ）

3, XX, you come to see me here, I have a problem to measure. XX, come here, there are problems. XX, there are problems again.

(Tears. Can let brother quietly write 2 hours of the program, programmers are taboo fragments of time, thinking Wood has ah. Think again. ）

Development and testing is a crucial part of the project process two, programmers and testers to love each other, must be the PM are most willing to see things. However, it is always challenging for people of different roles to achieve seamless cooperation in the process of accomplishing projects together. Admittedly, these challenges may be due to the capacity of the participants, which is unavoidable. But I am more willing to believe that communication is not smooth, poor habits, lack of transposition thinking and other factors are the most common. If the tester can pay attention to the following content in the actual work, it will certainly become the test that the programmer likes.

1, within the business to do professional

(1) Submit a bug to be described clearly. Note the operating procedures, test environment, describe the differences between normal and bug phenomena.

(2) Bug level setting do not rely on subjective opinion, should and product, development personnel after communication, determine a set of evaluation criteria, objective evaluation.

(3) As far as possible to avoid the proposed duplicate bug, two different pages of the same problem should be grouped into two occurrences of a bug. A deeper level of the same bug causes, can communicate with engineers to understand more.

2. Mutual understanding in communication

(1) The ultimate Programmer's way of working, do not find a problem to find the programmer, the coding process of thinking is interrupted to the programmer is very painful things. Can collect a number of issues after the unification of the programmer to deal with, or in the Instant Messaging tools, see the Programmer's schedule, give him a few minutes of time to buffer, at its convenient time to communicate.

(2) Testing the most fear of "Notabug", the programmer is afraid of "C-Class bugs" and "re-opened." Set C-Class and reset when the more cautious, uncertain can be first and the programmer ditch through to mention.

3. Kung Fu is outside the poem

(1) familiar with the business, understand the customer, for testers is also very important. Testers do not mechanically verify differences in functionality and requirements documents. Knowledge of the business and the customer can help you better design use cases, positioning problems.

(2) More communication with programmers to understand the development of ideas. Understanding development ideas can help testers find the blind spot of the test steps and make it easier to detect real problems. Such communication will also help developers verify the correctness of development ideas and improve the efficiency of the project team.

If one of these testers is in the project team, any programmer who leaves the project will miss him.

Of course, programmers can not be spoiled, blindly ask others how to cooperate with themselves. It's also a matter for programmers to think about and understand each other in the project. To be a loving family, to join hands and move forward together.

This article is reproduced from the 51Testing Software test network, see more: http://www.51testing.com/html/news.html