[Reprint] Talk about test management

Reprinted from the "Test road of the Hills": Talk about test management (steward)

Management: Tube person + steward.

When it comes to management, it's actually a team, no team, no management. Personal understanding, more to the individual, should be planning, not management. Management time is not long, or very short, there may be a lot of local understanding of the problem. This article is also written in order to be able to communicate more with you, but also recorded under the current stage of my understanding. (This article is in the entrepreneurial company's work as the background), the entire chapter is divided into the steward and the management of the person.

The work flow of the test of the steward.

About this point, in fact, the network on a search a lot of, roughly the same, demand analysis, test planning, design test cases, review use cases, execution testing, defect management, fixed version, release. But, I think as a test leader, in an entrepreneurial company, it is not a process that is so simple. I think more should be considered suitable for the company. When I set up our team's testing process, we had a long communication with our project managers, architects and even product managers, and the testing activities were inseparable from the product and development, so in the testing workflow, we should include how to go to the product and develop more efficient collaboration. Let's talk about the test workflow I've compiled.

1. Demand Analysis

Black box testing is inseparable from demand analysis, all tests are based on demand, if the needs of the understanding is not thorough, the quality of testing can be imagined. So at this stage, I'm going to spend a lot of time doing it. My team's needs analysis mainly includes: two diagrams a document.

Two graphs: Business flowchart, Mind map.

A document: A Requirements Analysis document.

The business process diagram is to understand the requirements from the flow (overall). Mind map is to understand the function points that need to be included. The requirement analysis document is a test point for the function points in the mind map. In this way, the content expressed by a demand will not be missed. And the higher level of hidden demand, need to have a deep understanding of the business, this can be in the work of slowly to guide team members to do. The process is difficult to control.

2. Test Plan

The test plan on the network, is a document, a lot of formal things, it may be for large companies, it is necessary, I now see, basic is not necessary.

I think the test plan mainly gives the following points:

(1), Test Type: Black box test, interface test, UI Automation test, Interface Automation test, performance test, etc.

(2), Test time: Demand analysis start and end time, design test case start and end time, perform test start and end time

(3), Test executor: Entrepreneurial company due to the situation of less personnel, it is possible to project (module) Division of the test head, but also according to design and implementation to divide the test leader

A test plan, with these three points, I personally think is feasible.

3. Test Cases

With regard to designing test cases, many of the small partners who worked in startups say that time is tight and there is no time to do this.

This, I used two months to do a survey, the first one months do not write test cases, everyone in accordance with their own ideas to test; after one months, strictly write test cases, execute test set to test. The results are: the first one months at the beginning of the test, the test speed slightly faster, in the test in the later stage, the test speed is very slow, because the common point has been tested, test engineers themselves do not know what has been tested, which has not? What's the problem and what's the problem? Can not be very intuitive to control. At the beginning of the one months, the speed of writing test cases was slightly slower, but in the mid-to-late period, the test efficiency was significantly better than the previous one months, and the test engineer was more aware of the project. The two spend almost the same time. The quality is not to mention, certainly the latter is more assured.

Exploratory testing, I think in the case of business capability and testing experience is sufficient, can be combined with writing test cases, to perform the test. The pursuit of exploratory testing blindly, in fact, for most test engineers, it is difficult.

At present, my team is, test engineers write good test cases, first group review, then import to QC, the tester to perform the test according to the QC test set, and I can be very intuitive to control the progress of the test, and of course, the problem exists.

4. Test Case Review

Use case review is very important, after all, the test engineer is also a person, there will be many points is unexpected, so the use case review is a leak check the link. Use case review is not the stubble, but in the process, the supplementary test ideas, improve the quality of testing.

Years ago, this one, we did not do, because at that time our test engineers wrote the use cases are not up to the level of the review, so it is only within the group review. A use case review has been initiated. The effect is still under observation.

Test Case Review Method:

(1), Advance email alert review related personnel (development leader, product owner, test leader, project manager, etc.), attached to the test case.

(2), 1-2 days later, the organization of Use-case review meetings, due to the prior to see the needs and use cases, so the meeting time is not recommended long, as long as the leak, everyone will have some test ideas, will also find that the existing test case deficiencies.

(3), according to the minutes of the meeting, the non-considered points are maintained into test cases. Fixed edition.

The test case after the revision can be used to perform the test.

5. Defect Management

Defects, and above all, a clear explanation of the problem, the steps to reproduce, and how to resolve it.

The improvement of efficiency lies in the details, the Defect management tool is not written on the unknown, but also through real-time communication to solve, but the communication will take time, if the defect management tools, write very clear, this communication time cost savings.

A flaw is a use case, the idea is very important, I went through the company, for the defects are placed in the management tool, the defect resolved, closed, then no. In fact, each flaw is a good use case, these use cases you may have written, or may not, and not, you need to maintain into the test cases, the next time you execute, you will be more prevention of a point.

6. Acceptance Test

Typically, the functionality that passes the test is ready to go online. But before you go online, you need products or operations to check the requirements. Does the feature implementation meet the requirements, there are no features that are not considered, and so on. Product or operation to do the acceptance test, I will give an Excel document as a list of their records, daily with my feedback on progress and results. If there is a defect, then arrange the time to solve it. If there is a need for defects, will be scheduled to review the conference, the release of the changes, or the next release of changes. Finally, on-line or not, need their determination.

Second, test time 1, to fight for testing time

Entrepreneurial company, product version iteration fast, tight cycle, often compression is the test time. and the test quality to a certain extent, and the test time is proportional, so this is very contradictory.

Test time needs to fight, because the project time is very tight, more resources for development, on-line time to determine, basically off-line time only 2 days before the development end, only delivery test. And such a short test time, to ensure that the test quality is very large, and may require a lot of overtime. And the test time of the fight, but also need to test the quality as a basis. So how do you fight for test time? I think this is the case:

(1), as far as possible at the beginning, even if overtime to do a good quality assurance, and then in the time to buy, you can try to take the quality as a reason;

(2), usually more with the project manager, architects and other talk about product quality, transport quality awareness, and more talk about the importance of testing, not every development or the person responsible for the test, although the test industry in rapid development.

(3), is in the test time, resolutely do not give in. On-line, product problems, many times, will let the test back pot, of course, there are reasons for development, but everyone's idea is: How did the problem not tested? This time, you say the test time is not enough, the meaning is not big.

2. Schedule Test Time

The timing of the test should be based on the ability of the testers themselves. The ability to be strong, of course, takes a short time. In general, my schedule for testing is as follows:

(1), within the module (less interaction between modules), the requirement analysis time and design test case time is 1 days, the time to execute the test is 2 days (mainly the defect repair time), the final acceptance time is half a day.

(2), multi-module interaction between the function, requirements analysis and design test cases each 1-2 days, the implementation of the test time 4-5 days, the final acceptance time of 1 days.

(3), system-level functional requirements, demand analysis of 3 days and above, design test case time 2-3 days, the implementation of testing time more than one week, the final acceptance time of 2-3 days

The main strategy is that the time required for analysis is guaranteed, this time can not be squeezed, after all, this is the most important part of testing. The time to design test cases can be slightly squeezed, the most important time is to write documents. Test time to consider the defect repair time, testing a round may be very fast, but the time for the repair of defects may be long. Final acceptance time, product or operation of the function for the acceptance, to see if the product needs to meet.

Third, test progress and quality 1, test progress

After the test plan is determined, the next step is to control the progress of the test. The progress of the grasp is not real-time requirements of the test engineer feedback, nor do you want to know the time to ask. There is a need for an intuitive query to the current test progress and to receive feedback from the test engineer. And the rules of our team are as follows:

1, the use of project management tools: Teambiton, the task board has every Test engineer before the release of the task, each task has a detailed test time, can understand the visual view of the implementation of the task.

2, the implementation of QC Test set: QC Test set, is based on the execution of test cases, every step of each use case has a state of execution, so that during the testing process, you can see the progress of the current test in real time. This is the most accurate. There is no laziness, or whether it is a coping type of work can be seen.

3, every day before work, will be today's test situation feedback to me. This is prepared for improvement, which is scheduled to take 5-10 minutes each morning to the station. Everyone needs to talk about what they did yesterday and what they are going to do today. For a long time, standing can improve the efficiency of the whole team.

4, every morning and every day before work, you need to check the defect management tool, to see if the defect has been resolved today has been processed.

If the test progress is very slow, with the expected serious discrepancy, will be discussed with the relevant test engineer, is not expected time, or test the engineer itself, or the development engineer's problem. This is the time to test leader to solve the problem. Find the appropriate problem and fix it.

If the test progress is too fast, also need to confirm, to prevent in order to catch up with the quality of the situation.

2. Test quality

There is a sentence in the industry: testing does not guarantee software quality. I think, although we can't guarantee the quality of software, but we can guarantee the quality of testing, as far as possible to improve software quality.

The quality of the test is the most important part of the test activity, all of which are based on improving the quality of the test. So how to improve the quality of testing?

(1), adequate testing time. It's not as long as the time is better.

(2), comprehensive test requirements analysis.

(3), full test case design.

(4), the ability of testers (detailed talk of the person in control)

(5), do the acceptance test.

(6), Risk control

Wait a minute.

Four, online tracking

I always thought that no matter how precise the test was, there would be problems after the line. Just say the test can be as far as possible to reduce the occurrence of such situations.

If there is a problem after the product is online, how to deal with it?

The first time, in a test environment, is reproduced. Can reproduce, then find the appropriate development engineer to solve, and then evaluate the time of the line. If they cannot reproduce, look directly at the project manager and evaluate the solution.

In general, after the problem, I will bear the responsibility (this is a popular method), after the incident with the relevant test engineer to explore the cause of the problem, because he caused, summed up why, strive to not fall in the same place two times, for him, is a kind of growth and progress.

Conclusion

The above is only a personal understanding. I hope we can discuss more.

[Reprint] Talk about test management