Shulou(Shulou.com)06/03 Report--

Software testing industry is in urgent need of Daniel

I remember that when I first graduated two years ago, I heard about the software testing industry. At that time, I also went to Baidu to conduct a careful search, and the evaluation was basically stereotyped. The reason for being optimistic is that experts believe that the future Internet market user experience is paramount, and product quality is closely related to user experience. Since the post of product manager has become popular in recent years, the concept that everyone is a product manager is deeply rooted in the hearts of the people. but in fact, everyone should have the concept of quality, excellent product quality can provide a better user experience.

It was a bit far-fetched to say that I was moved by the words of the experts. At that time, because of my lack of development skills, I chose a software testing company to make a living. In fact, the domestic software testing industry is not as good as that described in the books and media, and the norms and processes need to be developed by various companies. Whether the process is standardized, the ability of testing requirements, automation and interface testing is perfect or not, many tool platforms or software can be reused, which shows the company's accumulation in software testing.

Anyone who has come into contact with a software company should know that software testing is downstream from the company's ecological chain, which determines that many situations must be passively accepted. Even if a test engineer has rich theoretical knowledge, strong risk identification ability, and a discerning eye in the test, he can be dumbfounded by a change in product requirements, and then try very hard to adapt to this rhythm. Maybe he complains, maybe he complains that he scolds the product and operation for many times, but it is useless. Product operation leading is bound to be a trend, and testing leading is unable to make a good product.

There is another point that has been debated for a long time, that is, the question of responsibility for problems. If there is no problem with the product launch, then everyone will be happy, if there is a problem, almost everyone will pull the test together. They will think that even if there are all kinds of problems in the upstream link, they should "reasonably control" all kinds of problems when it comes to the test, list the risk points and inform the responsible persons, and sometimes the sentence "why not tested" leaves the test students speechless.

After reading the above, you will feel that hostility is too serious. indeed, the status of the test is often very awkward, and there is a feeling that "there is something wrong with me in the carnival of others, and I am very sad when something goes wrong". But it is undeniable that a good tester is very rare, understand business and code, write interface tests, do performance optimization, and coordinate various contradictions. So good testing can be a good development, a good product, a good operation and maintenance.

First, what should software testing do?

In every software company, the requirements for testers to participate mainly come from the following three aspects:

1, product manager-for the product itself, it may be the function optimization, or the module addition.

2, product operation-launch products with operational activities to expand new users and improve user activity

3, technical staff (developer-led)-technical transformation or code refactoring

Therefore, for testers, they need to understand how the product wants to play, how users will play, how the operator wants users to play, how to implement development, how to test, and what is the technical difficulty. WTF! This is the rhythm of integrating PD, operation and development.

I believe that in many companies, the best understanding of the product must be testing, because as testers participate in the whole process as early as possible, they will come into contact with all the roles. So to sum up, basically, testing is better than product understanding of development, than development of understanding of operation, than operation of understanding of products, but also the best understanding of testing and product quality.

Second, several stages of software test engineer

Members of various industries have different stages of competence, and software testing is no exception. There is a clear distinction between what is done according to each person's ability, and here are several common ones for analysis.

1. Manual testing (pure black box testing), even if the ability to find defects is very strong, it will soon encounter development bottlenecks, because the risk of any manual testing is high, and the input-output ratio is not satisfactory. After the project changes, only personal experience can be reused, which is of little help to team building and knowledge precipitation. Experience can be shared? Who can guarantee that it will work for everyone? )

2, black box automated testing, slightly advanced, improved efficiency, can be timed automatic execution, but the maintenance of automated scripts is also quite painful, even if some code can be abstracted into common modules, but can not avoid front-end changes. At present, product function automation testing is based on a relatively shallow level, so whether to carry out and how wide to carry out is a point worthy of careful consideration.

3, interface testing (including interface automation), which is quite in-depth. Sometimes it feels that when a test really puts aside the front-end page and starts to intervene in the test from the interface level, he will really become a qualified test engineer. What can be done at this time, such as the sky full of stars, imagination space is endless.

4. Performance testing is a very important point for both App and backend servers. Professional performance test engineers have high requirements for a single direction and will be more sensitive to performance problems.

5, white-box testing, this direction is very advanced, the real white-box testing is to be able to verify the correctness and validity of the code, the level of these engineers should be higher than many developers.

A good test is really cool, and it's often because you don't find it. I used to think that I was too young and too simple to enter the testing industry because I didn't have the ability to coding.

Third, the position of software test engineer

As mentioned at the beginning of the article, a good software testing industry development test engineer can not only continue to have attainments in the testing position, but also have the ability to work in some other positions. Here is a list of common ones. Of course, large-span job transfers will certainly exist, but it depends more on personal abilities and preferences, and it is difficult to be universal.

1, Product Manager: I have always thought that it is normal to test a transferred product, but the limitation lies in whether the test can focus on every detail, but now we have to consider the overall situation and have a choice. Familiarity with the product is up to standard, but it takes a lot of effort to pass on a person's ideas to your leader and team.

2, project manager: the difficulty of transferring test to project manager should be the least, many abilities are universal, and the understanding of technology can also be supported to a certain extent, but in today's Internet enterprises, the concept of project manager has been weakened. Need to respond to changes more quickly, is it really good to move to a position that is gradually eliminated by the market?

3, testing experts: this automatically extends to the above several stages of software testing. Today's market is too eager for expert-level needs. Software testing has not been developed in China for a long time, but imagine how popular an expert is.

4, operation and maintenance engineer: this transfer is difficult to a certain extent, but if you are exposed to the testing work of the server and are very familiar with the various operations of the server, the transfer is still very promising.

Fourth, some misunderstandings of software test engineers.

1. The problems found stay on the surface and do not continue to dig deep

2, there is no macro concept of the whole product, but cling to every detail

3. The effect of test execution on quality assurance is no more than 50%. If you really want to do well, you should slowly standardize 4 from the upstream and blindly believe in automated testing.

Don't think that the task of a test engineer is just to test

6. Regardless of the key points of the test, it is right to think that the test is big and the whole association is right.

Fifth, the good habit advice of software test engineers.

1. Analyze it first and then execute it, which will get twice the result with half the effort.

2, the ultimate goal of the test is to control the purpose, do not want to find all the bug

3, firmly believe that test engineers also have a status, learn to reasonably refuse abnormal needs of products and operators, and of course make their own decisions in testing.

4 MindManager, flowchart and other software are often used, which will help you to expand your thinking.

But by no means doing the above five links means that you are excellent, because you must have heard the prophecy that "bug is endless".

So the question is, what exactly is software testing to do?

This problem is somewhat tangled, because when you open a book, you will first describe software engineering at length, and then tell you a whole set of standardized software business processes, which are hardly involved in how to use them. When you understand, enter the company, found that "I X, completely different", said how these norms are not implemented, this company is not reliable ah.

Of course, the answer is no. Leader certainly knows that changes in requirements and delays in development will bring risks to software quality, but for the current market, following the process step by step is certainly not in line with the overall situation. So how can test engineers reduce the risk appropriately? Share a little experience and skip it for Daniel.

Seventh, be familiar with each module of the product

For any product, it is not a bad thing to increase familiarity with the product. When you know what the development logic of the product is, you can respond to changes in requirements very well.

For example, the requirements of the product were originally implemented in scheme A, but because the requirements have been fine-tuned, it would be more appropriate to use scheme B. For inexperienced product managers, they often get solutions from developers, and when the development process has begun, adjusting the solution will increase the workload and bring risks, so how to give suggestions for testing?

If you don't know the logic of the product, of course you are at the mercy of the developer, and the second change at a later stage also requires a lot of work. However, if you are familiar with the product logic, you can compare the two implementation schemes, list the advantages and disadvantages, and finally solve the problem in a more reasonable way.

Therefore, familiarity with each module of the product is a very necessary ability for testers.

Eighth, the priority of test cases is clearly defined.

When testing, people always ignore the importance of test cases. The thousands of use cases of a product are really a headache. However, good test cases can help test engineers improve their testing efficiency when time is urgent.

Test engineers must be familiar with test cases, but they tend to pick use cases to be executed casually, with a particularly good saying, "pretty much." But this almost often deceives oneself, the workload increases, the effectiveness may be reduced, on the contrary, the loss outweighs the gain.

Ninth, it takes efforts to make automated testing.

If you have an idea to automate some of the functions of your product, congratulations, at least find a good idea for yourself to reduce your workload and improve your productivity. But, automation is not as simple as you think.

First of all, you have to study different automated testing frameworks and find out what the current product is suitable for.

Second, distinguish between product modules, where they are suitable and where they are not. For example, UI automation and functional automation may choose different frameworks.

Third, prioritize. Generally speaking, modules with high frequency of use are preferred.

In addition, the implementation must consider whether the scheme is perfect or not, and a semi-finished automated test code is even more deceptive.

Ten, the demand for intervention must be early.

Never think that testing starts with the start of development, and understanding requirements is too important for testing. In the work, it often occurs that the product manager describes the requirements are not clear, or the product, development, testing understanding of the three parties are not consistent, the United front in advance will certainly help to reduce the risk.

At the same time, when discussing and evaluating the requirements, the test engineer can analyze the source of the requirements and ask whether the requirements should be done or not. Although there is not much work, it is good for the quality and usability of the products.

Programmer Hangzhou Software Test Hangzhou APP Development Hangzhou PHP engineer

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.