Talking about the standard construction of software Test team

A number of friends who have been in the testing business for 3-5 years are actively transitioning to the QA Manager role, and they are consistent in the direction of future development, most of which is to build an excellent and efficient Test team . Recently I also think of some team norms and become a good team title of the necessary conditions, their own testing work is nearly four years, some of which I met and summed up in the original work, wrote I think there is no comprehensive later will gradually complete.

Conditions:

Defect Management

First, the formal Test team will have at least one defect management system, whether bugzilla or mantis or other systems, because the software testing process itself is around the defect, which is an important part of the test work. Personally, I prefer to use open source tools.

Test Cases who will write

I don't advocate testing new people to write test cases, which should be assigned to experienced testers. New people write test cases have a certain amount of risk, such as poorly considered to reach the expected coverage, delay the test cycle and the time of launch.

Bug has owner

For bugs, the bug that the tester opened should be closed by me. You have to be a master to do bugs.

Test Workload Assessment

The test workload should be estimated by the testers themselves, from bottom to top to estimate the amount of work, rather than from the top to the bottom of the workload, if the duration of the fixed can simplify the test case, test the severity of the

Bug Description

The bug must be described concise and clear strive to achieve PD a look to understand, reduce unnecessary communication. For bugs that are not easy to reproduce, you can clearly describe what type of error is generated by the operation steps and the specific operating time. Through past work experience, individuals think that there are no non-reproducible bugs.

The developer has doubts about the test results of the testers. If the tester determines that it is a bug based on his or her own test experience, you can first organize a defect discussion within the tester. Determine the severity level of the bug before processing it accordingly. It's normal to have different views, but don't compromise easily.

Don't waste testers ' time. The tester receives the test task to test the product to find the number of low-level errors and the incompleteness of the function and is entitled to return. This is a waste of time for testers.

Testers should not rely too much on test tools

Testers are completely dependent on the test tool is a bad practice, do not forget that the most powerful is your test ideas, in the necessary circumstances to use the tool does give the testers an unexpected harvest but this is only a test means not all of the test, if you need to use tools, I suggest to the open source side.

let testers understand the business meaning behind the product

What functional modules are most important throughout the project, and why the new feature is being developed, and what is the meaning of this feature throughout the project, which allows testers to create an inner level of importance for the function. It is very helpful for test cases and later regression.

creating a test atmosphere

Developers need to self-test after the development of the function, and then handed over to the testers, together to good quality. Development may say what I write and I have to test what else I want you to do. If the development of the product even the normal process can not run through the test is sent back once, so that not only affect the project progress, but also may lead to the tester you open the product has emotional conflict, quality is difficult to be guaranteed.

Test Technology Learning

The test team can regularly come up with a topic for the study by some people, and then regularly share research results to organize team members research and discussion, promote work learning two not mistaken.

Not enough testers .

If a time-tight task is encountered the re-test cycle is shortened. I do not recommend omitting write test plans, test cases, test reports to the bulkhead test. The test can be divided into the weight, can apply for the development of auxiliary testing. It is also not possible to omit those written words. Not formality. Testers are fully aware of the value of these things and can protect you in due course.

Writing test cases before testing is not a rule of death. This is actually the workflow, but sometimes when there is no test case thinking, you can run the function manually, think what to write, and finally form a complete specification test case. Do flexible testing.

Testers are obliged to explain to PM their own ideas on the flow of functionality and ease of use. If it is for the scalability of functionality it is not just the testers who need to participate in the discussion, but also the PD OP DB, and so on. The initial goal was to facilitate automation in the future. Allow automation to cover more and more comprehensively.

In order to ensure product quality testing earlier, the better. It is not just functional testing , it also includes performance.

Understanding Current Product quality

Each of the testers should be aware of the current product quality, know which piece is weak, know what to do, and advocate that everyone can make constructive comments.

The developer tells the tester how you should test it.

This phenomenon can be understood in many ways:

1, as testers you do not good enough, for a long time to you as a shout the role of the microphone, from your previous submission of the bug to see no depth. Want to be respected by people or to rely on their own steadfast fight.

2, the test team is not standardized, or there is no Test team. Let development lead the work themselves and not write code psychology is not good to be complained about a lot.

More time still need their own efforts, knowledge to rely on little bit of accumulation. Difficult to reproduce the bug you can reproduce, can tell the development of which feature may cause problems in the future, pointing out that the system bottlenecks and so on a lot of similar. These are the needs of experience accumulation. Gradually you will find yourself in the team to be worthy of the recognition of colleagues and superiors.

test Environment Maintenance

Test environment by WHO to maintain in fact, I think it is not important, here refers to who can be operations can be a research and development can be QA, but it is best to ensure that someone to maintain, not everyone can intervene. It is not advisable to release new features or modifications without saying hello. It is important to ensure that the version is unified. To do this, the OP can crawl the entire package of items in a test environment before releasing the feature. Of course, small changes to minimal functionality can be exceptional.

Collect requirements Documents

Testers gather information around the testcase in order to write a fairly complete list of the people. Develop documentation and product requirements documents after the first time sent to the QA in hand, to ensure that QA work carried out.

Talking about the standard construction of software Test team