Wind writer-coming out of the software Workshop: how to become a regular army for the development of million people)

Our company was not tested at the beginning.

The company is a startup company. When I fell empty, I couldn't even sell anything. The start-up of a company is just out of the boss's breath to the original company. I think it is better to be happy with myself. I may think a lot about what company the company wants to become. Consultation? Training? Authentication? Communication? Data mining? I found these books on my boss's shelf. But what do they really sell? It's not easy to sell, it's hard to sell. By mistake, I entered the software line, but whether the software line can continue or not, and the boss is not sure. if the product is not sold well, I will not do the software, now is the stage of survival, so we can't take much care of it. If there is a project, we can connect it. There is a boss relationship on it, and there are honest workers working hard to work overtime, so the project will pass through.

Unexpectedly, I went down the road to software and got a big job. There were a lot of installation points, involving many users, from Hainan to Xinjiang, from Shenzhen to Zaozhuang, Shandong.

The company launched all the implementation consultants for testing. Only when they pass the test can they implement it.

Most of the implementation consultants come from recent graduates who have just graduated and have no idea about enterprise management, software, or industry. I am not familiar with testing.

There is no division of labor for testing. Everyone tests the software. There is no test method, no test plan, and no test plan. If you do not know the software, you should study the software in depth.

There was no test report at the beginning. If you find any problem, you can send the problem to developers by phone or QQ or email. If you don't know the developer, send it to the developer. If you don't know the developer, send it to the boss. All words in the report are useless. However, what functions are not easy to use, how they are operated, and how they are not easy to use.

The boss is anxious. Why are there so many problems.

I said there are five reasons:
1. Many problems are reflected by everyone. In fact, there is only one problem, but there is no division of labor, and all tests are conducted. Therefore, all reports are reported.
2 many people see a problem and send an email, so it looks a lot better.
3. Some people just randomly entered the test, and our software has not been compatible with this destructive operation.
4 many people do not understand the functions, the industry, and the business. They are right. According to his understanding, they are wrong.
5. Some people are lazy. Today these questions are reported, and the day after tomorrow they are the same.

I said, based on the status quo, I will give you a test method:
1. Division test. Several people test a function.
2 not all tests, only test the key functions that are commonly used
3. Do not report data by phone, QQ, or email to individual developers. Just send it to me. I will judge the measurement arrangement. Do not report any time. Send the messages in a unified manner every day after work. The persons in charge of each test team will summarize the tests in their own groups and merge the repeated questions.
4. The daily test reports of each test team should be continuous. Do not send the test Excel today. Tomorrow is the test Excel tomorrow, so there is no consistency.
5. Each problem should be marked with a functional module, a tester, a test version number, a test time, a test operation process, test input data, and an error.
6 first, test the normal data input, normal operation process, whether all the processes can be passed, whether the data is saved normally, and whether the stored data can be retrieved correctly. Do not perform those critical condition tests first. Do not mention the need for difficult functions, poor UI, proper title of the window, and bold font. The focus of our current phase is to test the problem. Do not mix the requirement with the problem finding.

The method is executed, and the problem is much less.

A few days ago, people complained that such software was a bad software. If they were given to the customer, they would be killed by the customer.

Now, it takes only a few days for the Implementation consultant to think that the implementation can be done.

This is the difference between method and method.

The implementation of the first batch of customers finally started, and the Implementation consultant rushed to the whole country.

When we get to the real customers, we find out how superficial our testing, software, and business processes are. The problems found in the past were all pediatrics, and the real complicated problems were not tested at all. After explaining to the customer, the customer found that many functions were not understood and did not know how to explain them to the customer. So I called to ask. I am the only one who can answer this question.

Of course, I cannot be an operator. On the one hand, I still asked them to report problems found at the implementation site according to the previous test problem report procedures and methods, and on the other hand I wrote a faq TO THE IMPLEMENTATION consultant. However, the implementation consultant still asked a duplicate question. I will show you the XX line of the FAQ. He said that he had read but did not understand (in fact, he did not understand the customer's business, so he did not understand the function ). I will explain it to him again. After many explanations, I also learned the understanding ideas and layers of the implementation consultant. As a result, I kept revising the FAQ so that faq1.0 and faq1.1.1 were continuously released almost every day. Now I want to go back and think about whether the Help file is good or not. You can't say that you have already understood what a fool can't understand. Don't think so. This doesn't solve the problem at all. The only way to do this is to make the user understand how low the user is. You need to make the help low so that the user can understand the purpose. Otherwise, what else can you do, the problem must be solved.

With the implementation of the project, the company has gradually recovered a lot of money, but it is faced with a bottleneck. This big project is almost finished. What will it do to support so many people now. Therefore, the best practice is to change the software generated in this project into a product and sell it to other customers. The more you sell, the better. However, we do not have many relationships with other customers. Therefore, to sell to other customers, we must talk about products. As a result, the R & D department has successively joined full-time testers, copywriters, and artists to improve product quality and packaging, hoping to sell well.

Therefore, this is the case for full-time testers.

Many software companies do not have testers. The reason is that the boss has a good relationship with each other. Programmers work honestly. Although the project quality is not good, the money can be settled. Now that we can make money, why do we need testers. Unless you cannot sign the order due to quality issues. Unless the customer does not accept the payment due to quality issues. Unless everyone in the company tests, the quality of customer satisfaction cannot be achieved. Only in this way will full-time professional testers be recruited.

The tester started to work. But how can we conduct the test? Where is the document?

There are only very old design documents, and the software and documents are no longer relevant. Why? There are two reasons:

1. They are all programmers who write special documents. For the survival of the company, I have a number of roles. I have meetings and project managers or pre-sales staff, developers, and implementers call me to ask what is going on with a function in the software, I have no skills.
2. All changes are made based on the requirements and bugs reflected by implementers, customers, sales personnel, and the boss. There are some bugs and requirements in Excel tables, but they cannot be used as the basis for writing test cases.

Testers start to learn the software.

Where is the help? No?

Yes, no, because the person who did not write the Help file. Only the PPT that is explained during the order.

The tester fainted.

When you finish learning the software, the tester does not know what is correct and what is incorrect. Of course, the tester does not know what the bug is. The software quality has not been improved.

The boss asked: Is this tester incapable? Do you want to cut it off?

I said: It's not that he is not competent, but that we owe too much to survive. We will be completing the course. Now the copywriter is assisting. With help, there is a correct standard. But now the problem is that the copywriter doesn't know the software either. She also wrote her own guesses, so I have already assigned a developer as the project manager, he is currently responsible for setting up help documents, but his developer is not good at writing documents, but he is familiar with software, so only two of them can work together. However, this kind of Running-in takes time.

In this way, the project manager and the copywriter continuously explain and write the program continuously for review and revision.

Testers can finally write test cases. But he also had a preliminary understanding of the software. Due to years of development, software has been added to the needs of a large number of customers, and many details have not been seen in help. Testers do not know this function. Therefore, the test results are not much different from those of the implementers.

The boss began to get down again. As a side-by-side hacker, he wanted to cut off the tester and thought that his existence was meaningless. It was better for the implementer to test. However, because I proposed the recruitment of full-time testers, I am also a direct employee, and this tester is also honest and diligent, the boss can't find any handle to open this one.

I said: He is from a famous outsourcing company and is dedicated to testing. I believe he is professional. However, we were missing too much in the past, so he wanted to test it. Let's continue.

Sure enough, testers have their own unique software testing methods and software understanding methods. Soon, the testers understood the software as much as those implementation consultants who had been working for years and as much as programmers. More and more accurate and in-depth problems are found.

Of course, this is also because of the growth of this team, a full-time project manager began to write the design documents for changes to existing functional requirements. If there is no in the past, let it pass. If there is no in the past, let it be missing. But in the future, do not become the past. There are also dedicated text files, which are constantly being modified to help, which has deepened a lot. Testers now have more detailed and in-depth functions than copywriters. They often remind copywriters to write a sentence into help; otherwise, they will be easily ignored by users, it is a pitfall that will be tripped accidentally.

To enable the tester to quickly understand the customer's application operation methods and the specific features in more detail, I asked the tester to also serve as the technical support of the R & D department. If the problem cannot be solved by a girl with a service department, go to you to solve it. Otherwise, in the past, the little girl in the Service Department always transferred the phone number to the developers. There were just a few shots in the past, and the customer's phone number was so loud that they could not develop it with peace of mind. In addition, the customer finds that it is more effective for developers to answer phone calls. Therefore, many customers call developers directly, and the service department becomes a virtual shelf, and the development progress of developers is dragged down. Now we have testers and technical support, which frees developers. The development quality and speed have improved a lot.

However, the tester did not have any technical support experience. After a while, he complained to me, saying that the little girl in the service department had nothing to do and directly transferred the call to him, therefore, he is no longer able to test and has become a full-time service support staff. In this case, the software quality cannot be guaranteed, and the Development Department will become the development + service department due to the heavy pressure on technical support in the future.

I gave the tester three methods:
1. if you encounter problems frequently, create a FAQ. The next time I asked the little girl, she directly asked her to read the FAQ and refused to answer the question.
2. Give them methods and ideas instead of doing it for them. Look at her and let her serve the customer. No. If you continue to do this for the second time, you have to let her know for herself.
3. provides regular training and answers to questions every Saturday. And take the test. If you have said that you will not take the test, you will be charged for the fee.

In addition, I also made an assessment for the Service Department (the service department that I managed at the time): How many customer problems did you receive, how long it took to solve, and how many problems were transferred to the Technical Support Department of the Development Department, how difficult are these problems. These indicators are used to measure the technical problem-solving capabilities of the girls in the service department. If the capability is poor, the employee will be dismissed.

After these moves, the technical support capability of the service department has been greatly improved. I really don't need to work without a whip. It is easier for testers to serve as technical support personnel.

I also handed over version management, packaging, and publishing to testers. The reason is that sometimes the customer reports a bug, and the programmer directly changes it when optimistic about the change. After the change, the programmer directly contacts the customer for updates, but does not change the software version number, there is no new packaging. As a result, the functionality of the software with the same version number is different. In addition, due to the large number of project teams, each project team lead has its own reasons. Sometimes a package is provided to the customer, and any version number can be customized, which is odd, some are called Beta and some are called 6.0.20050203. This caused the tester to make the test, the developer said it was changed, and the tester said it was not changed. The developer said there is no problem, and the tester said I can repeat it here. So it took two days for two people to check out the inconsistency between the tester and the developer.

I made a few more moves:
1. Developers cannot contact customers, answer customer calls, solve customer problems, or update customers.
2. Developers cannot modify the software without assigning tasks or designing documents.
3. You must use version management tools, Bug management tools, requirement management tools, and task management tools. Use tools to bind project managers, developers, testers, and copywriters, and push the flow according to the curing process.
4. The package and release should be handed over to the testing personnel. The testing personnel can control whether the release can be made and the release version number should be named. If the quality is not met, you have the right not to publish it.

Now, our tests have been capable of border testing, version compatibility testing, system compatibility testing, stress testing, security testing, integration testing, and destructive testing. It has also been applied throughout the project. testers are mainly involved in requirement verification, design verification, code verification, document verification, and packaging verification.

However, we have not yet implemented unit tests, but there are many projects for developers. In addition, testers are not capable of programming. We didn't do more regression tests. After all, there were too few testers and there were too many projects in parallel.

See the opportunity. The more he makes money from the software, the more he is willing to invest in the software. The cost is always too high, and the profit is always too small.

If you are a development director, your boss has not made any money from the software you are responsible for, and it is very happy to make a large amount of money, instead of relying on his interpersonal relationships and gifts to eat, I think he will not give you a dime. It is useless to complain, because you have no value, so investment is meaningless.

Prove your value first.