Software testing must be aware of 10 key points

The software testing industry needs Daniel

I remember when I graduated 2 years ago, I heard the software testing this industry, at that time also went to Baidu carefully conducted a search, evaluation of the basic uniformity of the optimistic. The reason is that, experts believe that the future of the Internet market user experience is supreme, and product quality and user experience have a close connection, since the Product manager post fire, everyone is the concept of product managers rooted in people, but in fact everyone has to have quality concept, excellent product quality can provide a better user experience.

Said by the expert words moved some far-fetched, at that time is because of their own development skills insufficient, back to the second choice of Hangzhou software testing a company to make a living. And many things in life to know exactly how it is-in fact, the domestic software testing industry does not have the book and the media described so well, norms, processes need to be developed by each company. Whether the process is standardized, the ability to test, and whether automation and interface testing is complete or not, many tool platforms or software can be reused, all of which demonstrate the company's accumulation of software testing.

Anyone who has ever contacted a software company should know that, from the company's ecological chain, software testing belongs to the downstream, which also determines that many situations must be passively accepted. Even if a test siege lion theory is rich in knowledge, the ability to identify risk, in the test of the discerning, but a product needs change can let him dumbfounded, and then very hard to adapt to the rhythm. Maybe he complains, maybe he spit groove, behind the product, Operation scold n many times, but useless, product operation is the trend, the test lead is not good products.

There is one point that has indeed been debated for a long time, that is, the question of assuming responsibility for the problem. If the product is on-line no problem that is happy, if there is a problem, almost everyone will put the test together to cushion back. They would think that even if the upstream links to a variety of problems, but to the test here should be "reasonable control" all kinds of risk points listed and inform the responsible person, sometimes a "why not measured out" unexpectedly let the test classmate speechless.

Read the above content, you crossing will feel the hostility is too heavy, indeed, the status of testing is often very awkward, a kind of "others carnival has my hair, out of the problem I am very sad urge" feeling. But undeniably, a good tester is very rare, understand the business code, write the interface test, do the performance optimization, but also to coordinate a variety of contradictions. So good test can become good development, can become a good product, can become good operation and maintenance ...

　　One, what does software testing do?

In each software enterprise, the needs of testers are mainly from the following three aspects:

1, Product Manager--for the product itself, perhaps the function optimization, perhaps the module added

2, product operation-to expand the product with the operation activities to expand new users and enhance user activity

3, Technician (development LED)--technical transformation or code refactoring

So, for testers, need to understand how the product wants to play, how users will play, how to play the operation wants the user, development how to implement, test how to do, what is the technical difficulties. I'll go! This is the rhythm of PD, operation and Development!

I believe that in many companies the best understanding of the product must be testing, because as soon as the testers participate in the entire process, they will be exposed to all roles. So summing up basically is the test than product understanding development, more than the development of understanding the operation, than the operation of understanding the product, but also the best understanding of testing and product quality.

　　Second, several stages of software Test engineer

Members of all walks of life have different stages of competency, and software testing is no exception. Depending on the ability of each person, there is a clear distinction between what is being done, and here are a few common types of analysis.

1, manual testing (Pure black box test), even if the ability to detect defects is very strong, will soon encounter development bottlenecks, because any manual testing is high risk, and input-output ratio is not satisfactory. Once the project is changed, only personal experience can be reused, which is hardly helpful for team building and knowledge settling. (Experience can be shared?) Who can guarantee that everyone will apply? ）

2, black box Automation test, slightly advanced some, improve the efficiency, can be timed automatic execution, but maintenance automation script is also very painful, even if some code can be abstracted as a public module, but cannot avoid the front-end changes. At present, the product function Automation testing is based on a relatively shallow level, so whether to carry out, with a wide range of development is worth careful weighing point.

3, interface testing (including interface Automation), this is more in-depth, sometimes feel when a test really left the front-end page, from the interface level began to intervene in the test, he really became a qualified test siege lion. At this time can do content such as the Sky Stars, imagination space is endless.

4, performance testing, whether for the app or the backend server, performance is very important point, professional performance test the Siege lion for a single direction is very high, the smell of performance problems will be more sensitive.

5, white box test, this direction is very advanced, the real white box test is to be able to verify the correctness and effectiveness of the code, these siege Lions level should be higher than many development.

Good testing is really a dick, not so often because it is not found. Oneself Once "coding ability is not enough, so into the test this line" idea really is the pattern Tucson broken AH.

　　Third, the position of software Test engineer

As mentioned in the beginning of the article, good software Testing industry development test engineer can not only continue to be in the test position, but also have the ability to work in some other positions, to cite the common, of course, a large span of the job transfer will certainly exist, but this greater extent depends on personal ability and preferences, it is difficult to general.

1, Product Manager: I always think that testing the transfer product is very normal, but the limitation is that the test can be high-minded, the original attention to every detail, and now to consider the overall and have a choice. Familiarity with the product is standard, but the ability to pass on a person's ideas to your leader and team also requires a great amount of effort.

2, Project Manager: Test to project manager The difficulty should be minimal, many capabilities are universal, the understanding of technology can be supported to a certain extent, but in today's Internet enterprises have weakened the concept of project managers, need to respond to change more quickly, to a gradually market-eliminated post really good?

3, test experts: This automatically expands to the above software testing several stages, today's market demand for expert level is too urgent, software testing in the domestic development of a long time, can think of an expert is how sought-after.

4, Operations Engineer: This transfer has a certain degree of difficulty, but if its own contact is the server testing work, and the server of various operations are very familiar with the transfer is still very hopeful.

　　Four, some misunderstandings of software testing engineers

1, the problem of discovery rests on the surface, and does not continue to dig deep

2, no macro concept for the entire product, and the key to each detail

3, test execution for quality assurance of the role of not more than 50%, really want to do well, should start from the upstream slowly standardize 4, blindly believe that automated testing

5, do not assume that the test Engineer's task is only to test

6, do not differentiate the test focus, think the test to do chatty is always right

　　Five, the good habit suggestion of software test engineer

1, analysis First, then execute, this will be more effective

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

3, believe that the test engineer is also a status, for the product, operation of the abnormal needs of the society reasonable refusal, test work of course, their own decisions

4,mindmanager, flowcharts and other software often used, will help you expand your thinking

But not to do the above five links can represent themselves very good, because you must have heard that "bug is not finished" such a prophecy.

So the question is, what the software test is going to do!

This problem is a bit tangled, because open the book, will first the software engineering large space to describe again, and then tell you a set of standardized software enterprise process, how to use, hardly involved. When you understand, into the company, found that "I X, completely different", said the specification is not executed, the company is not a reliable AH.

The answer is no, of course, leader know that changes in demand, development delays will be a risk to the quality of software, but for the current market, according to the process is certainly not in line with the overall situation. So how can the test engineer properly reduce the risk? Share some small experience, for Daniel to skip it directly.

　　Seven, familiar with the various modules of the product

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

For example, the demand for products was originally implemented using a scheme, but because of the need to fine-tune the use of the B scheme will be more appropriate. For inexperienced product managers, often from the development there to obtain solutions, when the development process has begun, the adjustment program will increase the workload, the risk is inevitable, then the test, how to give advice?

If the product logic is not known, of course, is allowed to develop "at the mercy of", the late two changes also need to work. However, if you are familiar with the product logic, you can compare the two implementations, list the pros and cons to evaluate, and finally adopt a more rational approach to solving the problem.

Therefore, familiarity with the various modules of the product is a very necessary ability for testers.

　　Eight, the priority for test cases is clearly divided

When testing, you always ignore the importance of test cases. A product with thousands of use cases is really a headache. However, good test cases can help test engineers improve test efficiency when time is critical.

Test engineers must not be unfamiliar with test cases, but choosing the use cases to be executed is often more casual, with a very good word, "almost on the line". But this is almost always the pit of their own, the workload becomes larger, the effectiveness may be reduced, but the outweigh the cost.

　　Nine, can be automated testing to work hard

If you have an idea to make some of the features of the product automated testing, then congratulations, at least for yourself to reduce the workload to improve efficiency to find a good idea. But, automation is not as simple as it is imagined.

First, you need to study different automated test frameworks and find out what the current product is for

Second, distinguish between good product modules, where appropriate, where not suitable, such as UI Automation and functional automation may choose a different framework

Third, prioritize, in general, the use of high-frequency modules is preferred

In addition, the implementation must consider whether the program is perfect, a semi-finished automation test code more deceptive.

　　Ten, must be early to intervene in demand

Don't assume that testing begins at the start of development, and that understanding the requirements is too important for testing work. Work, the product manager will often appear to describe the needs of unclear, or product, development, testing three-party understanding inconsistent, advance the united front must be conducive to reduce risk.

At the same time, when discussing the assessment requirements, the test engineer can analyze from the source of the demand, and ask whether this requirement should be done, although there is not much work, but it is good for the quality and usability of the product.

Software testing must be aware of 10 key points