foreword
Most of the small partners who have not yet stepped into the field of testing or have just stepped into the field of testing will experience a period of confusion, that is, what does testing do. Even some veterans who have entered the test for a long time will always question what they are doing. I feel that I am just looking for faults , and I even feel that what I do is meaningless. So let's babble today. I've had the privilege of going through the birth process of our company's most important project, and it's been there until now. So I use my experience as the background to discuss the QA industry with you. Of course, I also have a lot of bad things that you can use as a reference. I won't talk about these initial stages of test case design here, let's go directly to the core.
One of the QA competencies: focus on quality and efficiency, work divergently
In many companies, many small partners will be confused about what a QA should do. Some things you think are chores, and some things you think are too technical and should be developed and operated. So what is QA supposed to do? It can be summed up in one sentence that you can do any work that can improve the quality and efficiency. Of course, you don't have to do a lot of things yourself, but you have to be able to organize this thing and find the right people to do the details. You have to be the one who takes the lead, the one who tracks the progress, the one who controls the risks, and the one who collaborates with all departments to accomplish goals. To put it bluntly, you can do it yourself. If you are not arrogant, organize everyone to get it together. Everyone should understand the communication skills and influence in the project. I have a habit of asking myself before doing anything, will it increase my productivity? If you can, do it. No, then go to the side, and talk about it when the young master is busy. I suggest that everyone do the same, so as not to do a lot of useless work.
For example, when the project first started, all developers' configurations were scattered in many different files, and the configuration files for each module were also scattered in different locations. In addition, the system is very complex, so it is extremely difficult to deploy an environment. At the beginning, I wasted my strength to sort out all the key configurations in the project and write an automated deployment plan. This is a point to improve efficiency. My ability Shang Ke did it himself. But this also caused the dilemma that only I could build an environment by myself. I don't even dare to ask for a leave, because all the development environment and the lifeblood of the testing environment of the company are in my hands. And when it goes online in the future, it will be much more painful to enter and deploy. Therefore, the birth of a configuration management solution is imminent, and I am numb to this matter. Sir, I am a second-hand development and operation and maintenance, and I have very little experience in this field. It is basically nonsense to let me design a good configuration management structure by myself. Fortunately, some of the developers have done professional operation and maintenance, and have built ZK for configuration management before. So I called him directly to discuss a configuration management solution with all the module leaders. He writes the config server, and the other person writes the config client. Other module leaders do the overall migration configuration. Finally I have a deployment test. The plan is basically like this, and then everyone acts on their own. I make a unified schedule, track progress, expose problems in advance, and so on. You can see that I didn't do anything specific here except for the final test. Everything is done by everyone, I just take the lead and do errands. Like I said before, I'm good at automating deployment, so I do it. I'm not good at configuration management, so I beg others to do it.
QA Ability No. 2: Influence
Influence is the lifeblood of QA. QA must have enough influence in the team, so that when you implement any strategy and process, people will not ignore you as a piece of shit. To put it simply, you have to convince people to convince you that what you are promoting is reliable. Just like the above organization configuration management plan, if I didn't accumulate some influence before, do you think they will ignore me? So how to improve the influence of QA? My experience is to solve other people's most painful pain points, they will thank you and feel that you are competent . You will feel that there is an essential difference between you and the QA that they understand and only point at random.
For example, what are the most painful pain points in general development and products? The answer is the environment. The more complex the system, the more painful the environment is for development and product personnel. In our case, the system is more complicated. And it is developed in multiple languages. What NODE.JS, java, python, scala, c++. There must also be a set of hadoop2.0 clusters to run tasks. The cost of setting up an environment is outrageous. At that time, development, testing, and products all used the same environment. It is temporarily created by the developers of each module. The developers of each module build their own modules and then make up such an environment. The pain point of everyone using the same environment is to influence each other and trample. The QA is testing here, and the development restarts the server. The front-end developers over there are debugging, and the back-end has to restart the server again. In the internal demonstration of the product staff, the development of a module here said that the server needs to be restarted. So in every meeting at that time, everyone complained that stepping on each other in the environment affects the efficiency the most. Developers hope to have their own environment that will not be affected by others, products hope to have a stable environment for demonstration at any time, and QA also hopes that their test environment will not be affected by others. The development is free to restart and change. So at that time, I took over the task of automated deployment. Start to introduce docker, confirm the deployment details with the development of each module, agree on the deployment path, and also communicate and allocate special network segments, servers, etc. Then on a certain day, more than 10 sets of environments rose up on the server. Each development and test has a set of environments, the deployment is simple, and each environment retains the git directory, customized scripts for pulling code and restarting services, automatically opening ssh, mysql client, and so on. Developers can edit source files in their own environment at any time and develop directly on the environment. Since then, the development has been very happy, and QA will not have developers running to restart the environment during testing, and QA is also very happy. We have also created a stable environment for product personnel, in which functions are always available. So the product is also very happy. Until now, more than 20 environments have been launched on the docker server, and the developers report that the productivity has doubled. When chatting and joking, they say that whoever quits, you should not quit. What should you do if you leave the environment. Although it's a joke, this year, the earth is still spinning without anyone. But after hearing it, I was quite happy.
The third QA ability: control
QA should be the person who understands the project best, not only in business, but also in product architecture, the progress of the current iteration, possible risks and problems. Of course, it is enough to have breadth, not necessarily how deep. But you must be able to grasp the current rhythm, be responsible for pulling them back when the team is too divergent, inform or even inform the team members in advance when the team encounters problems and risks, and guide them when the team is not efficient. You are not the manager of the project, but you are the monitor of the project. You want to make sure that the project can bring the product online with quality and quantity on schedule. And most of the time, it is necessary to weigh the pros and cons and compromise with each other. There is always a compromise between development and production and QA. But if you wait until the release is about to let everyone know the problem, it is too late to compromise at this time. Be sure to have such a report on your list. It records all the features to be tested in this iteration, and who is the owner of the feature. When is the deadline for the test, is there any problem during the development process, is there any risk of delaying the test, what problems have been encountered after the test, who is the QA of the test, and how is the current test progress? And how many bugs are there currently, including how many are in p1 and p2, how many are in p3, 4, and 5, and is the current bug situation likely to endanger the release? There is also whether there are non-functional refactorings and optimizations in this round of iterations, and whether there are performance requirements. If so, the performance testing plans and use cases should also be tracked. There's also compatibility, deployment, and more. After you have all the information under control, you can make a judgment, make a risk analysis of the current situation, and list the priorities. Then discuss it with the development and the product, if it can be solved, of course it is the best. If you can't solve it all, start compromising with each other based on the data and priorities you list. Demand should be cut, and bugs should be compromised. Strictly define the severity level of the bug. The high-quality ones can be repaired, and the low-quality ones can be compromised, and we will talk about it in the next iteration.
Another example, two weeks before the first release of the project, I found too many bugs when I counted bugs, and there are still many features that have not been developed, and are expected to be developed in the week of release. I judge the current amount of unfinished features and bugs to be a serious risk to the release. So I found the leader of product and development to discuss the current priorities. One person from each module went into the small black house to fix bugs, and the number of bugs must be reduced before the next round of testing. So everyone ate and drank, and they all went into the little black house to fix bugs. Another time in the round of testing before acceptance testing. On the first day, QA found that there were many problems, which was likely to affect the acceptance results. If the acceptance fails, you need to fix the bug and re-accept. And we didn't give the buffer to run another round of tests at all in terms of time. So at this time, QA must stand up and speak out and put forward all risks, so a bunch of people entered the small dark room, and the features that were not developed were also cut off. QA is the one who is always questioning, it's our nature.
The example I gave is not to say that there is a risk to cut demand, but the result of trade-offs and compromises by all parties. If the release time is unshakable, those that cannot be resolved must be cut. And if the demand is uncompromising, then the release time has to be delayed. As I said above, everything is the result of three-way trade-offs and compromises.
QA Ability No. 4: Ability to Improve
QA is bound to improve product quality. Finding bugs in products is a direct way to improve. There are test plans, test case design, etc., which we won't go into details here. But we have some indirect ways, which generally fall into two categories. The first is to increase productivity, like the deployment automation above. Saving the time cost of engineers is to indirectly improve product quality. Generally, productivity is improved through engineering automation, or the development of some tools to improve efficiency. Like we have done CI, automated testing and other things are this set. The second is process improvement, by improving the various processes of the current iteration, standardizing the standard to reduce our unnecessary waste of personnel.
There are too many examples of improvement power. Just like what we just said, all kinds of automation we do are actually a kind of improvement. In entrepreneurial teams, process improvement is more common. At the beginning, everyone was a personal battle, and everyone in the small team could hold everything with their excellent personal ability. But the team is getting bigger and bigger, the product is getting bigger and bigger, not everyone is so good anymore, and even if everyone is excellent, they have a working habit. Individual differences have caused a lot of trouble for teams. At this time, everyone should start to compromise with each other and unify a same pace. This is no rules and no circles. When developing product QA, it is necessary to summarize frequently, agree on various processes, and carry it out with full force. Every team is different and I won't give an example.
QA Ability No. 5: Resilience
There is a famous saying in the software industry that the only constant is that requirements are always changing . Especially in the cusp of the Internet industry, changes are commonplace. The mantra of the agile development model is also embracing change. I remember that I talked about the strain in automated testing in the way of testing and development - spraying the mine, and arguing about the code , which relies on good design and rich experience. Check out the previous post if you are interested. In addition to the strain in automation, we actually have something else. For example, what if someone leaves the company, what if the key person for a certain event asks for leave. What should I do if the test is delayed, the test time is not enough, the server is down, and it cannot be restored in a short time. These must be thought of in advance, so as not to be busy with casters. QA is the one who questions everything and doubts everything. Don't assume that things will go your way, in my experience almost no project goes that smoothly. At least you need to keep a buffer when scheduling. When the project is carried out, the front and back are loose, and the personnel back up each other. If you rely on the cluster, remember to keep a single-machine version of the cluster just in case, and control all the information of the project. Get first-hand information and think about solutions right away. Okay, let's talk about this, these are all things of experience. I also lack a lot, and there are times when I am in a hurry.
QA Ability Six: Execution
Not to mention this, in your agile development team, execution is fundamental. One word, fast. It doesn't take so long for you to think about design slowly. As your work experience grows, you have to summarize a set of available methodologies, frameworks, and tools. It's important to keep an eye on the various open source projects in your language. As I wrote in my previous post, use open source if you can use open source, don't pretend to force yourself to write. By the time you write it, the daylilies are cold. Why do I like to use docker? Because it is fast, I will use it for the next official mirror of whatever service I use, and I will use mysql for 5 minutes (or when the network is slow). As long as you are not unfamiliar with these things, a set of basic services such as test link, Jenkins, jira, wiki, etc. will only be a matter of one afternoon. Abandon your heart that wants to study the details and the principles, wait for your spare time to study it, and remember that the quality of the project is the priority, it is always the most important.
QA Ability Seven: Technical Ability
Finally talking about this. I'm not going to say anything else. . . A lot of chatter again. technical skills. . . It is the basis of the above six points. Without technical ability, the above six points are nonsense. You can see that I listed technical ability as the last item, because it is true that when you are responsible for the quality of a project, you need to use less and less technical ability, because you need to focus on more and wider things. Many of the details, such as writing automation scripts and writing test frameworks, may have been left to your colleagues to do. But you must not think that you can be a pure manager without having technical ability. That's bullshit, bullshit within bullshit. For example, when did you hear that a CTO can't understand code? Although he no longer has to work hard to be a code farmer, how can he lead the technical department without superb technical ability? In the same way, if your skill is 0, the complete layman will lead the layman. How do you understand product architecture, how do you formulate testing strategies, how do you turn technical capabilities into productivity, and how do you discover and correct when colleagues go astray. Step back 10,000 steps, how can you convince the public without the technical ability, and how can you prevent others from fooling you. Anyway, if my leader is a complete technical idiot, I'll fool him the same way I fool my grandson.
Finally, a certain technical strength is the foundation. . . Really basic. . . Don't take technical knowledge as a noble thing. That is to say, the test circle thinks that the ability to write code and build an architecture is a big cow. You must know that there are masters in the software industry everywhere, and the technical people in your test circle simply don’t see it.
end
Okay, I've been rambling again, the above are all my personal opinions and do not represent the general public. Wrong or right, please lightly spray.