What is the charm of software testing?

Problem:Software TestingWhat is the charm? Why do you choose to test a row without development?

　Wonderful answer:

Chen fuyun:

Although I switched to development now, after all, I have been in this line for six years. It seems that I still have the opportunity to speak here. At first, my contact test was purely accidental,MicrosoftTo our schoolInterviewI am only willing to do the test. However, after a while, I gradually liked this location. Let's talk about some of my past experiences.

As I have mentioned in many replies, the test and development focus is different.Work. The development goal is to achieve the function, and the purpose of the test is to determine whether the function can operate normally. So where is its pleasure? In short, there are two keywords: "discovery" and "analysis ".

One or two sentences are hard to tell. Let's give an example.

Suppose you want to write a VoIP program, how can you test its effect? An inexperienced test may tell you That I can connect two machines by phone, and an experienced test may list a lot of combinations for you:

1. Does your scenario support laptops and headphones? What headphones do you support? Bluetooth or 5mm plug-in headphones?

2. Does your scenario support using a laptop microphone? Or do I only support microphones?

3. Support for use in your scenarioMobile phoneDevice?AndroidOr iOS?

Why list so many things? Someone may sneer at this: just to ensure that everything can be tested. However, every scenario here makes sense:

1. Bluetooth headsets generally have hardware-supported echo cancellation modules, while general 5mm headphones generally do not have a simple structure. For general headphones without echo elimination, we must provide our own software for ECHO elimination to avoid impact on the answer performance.

2. We cannot use the same logic to process voice input from headphones and laptops. Because the headset microphone has a much stronger orientation than the notebook microphone, it can only obtain the sound from when the sound source is very close, the laptop microphone is designed to sound in a large range before the screen. If the voice detection algorithm of the headset microphone is used for the notebook microphone, a large amount of peripheral noises will be generated due to high sensitivity, affecting the call effect. In addition, some scenarios are exclusive to the laptop microphone, such as the user's typing sound and fan noise.

3. Both Android and IOS have built-in call modules. IOS even provides highly efficient echo cancellation and gain control modules, but does not have a mute detection module. Therefore, if the desktop program is transplanted to a mobile phone, you can use these functions to simplify your code. The echo elimination module of Android is unstable and requires many adjustments to achieve better results.

This is what we call "discovery". We found that the development did not pay attention to it, found that the project manager did not define the scenario, and proposed the corresponding test scenario. This requires a wide range of knowledge. Inexperienced tests tend to arrange all the tested platforms, but do not ignore any scenario. This is certainly okay when resources are infinite, but in real projects, testing resources are often the most limited, so we have to learn how to do the most effective test, instead of opening your eyes completely.

So what is "analysis "? For example, if an internal test Customer complains that the voice of your VoIP program is intermittent, How do you identify the cause of the problem? There are many scenarios with intermittent sound, including network latency andOperating SystemIf the processing is too busy and the execution time of the program is stolen by the high-priority program, the processing interruption occurs. How can we analyze the reasons? Inexperienced tests may directly require customers to go to the site for a look. But what if the user's environment does not repeat every time? An experienced test will propose: we can give the customer a debugging version, which requires that the data packet collection time point and the start time and CPU usage of each data segment be recorded. We can use the previous one to measure the user's network conditions, and the next data segment can be used to find out if it is caused by an OS swap. In turn, people who are not familiar with the product may not be able to see any usage of the data.

Some people say that this can be done by developers without testing. Completely correct. But is there time for development? In a company like Microsoft, all projects have strict development progress. When the development department is busy implementing functions, I think few product managers will agree to frequently interrupt the development progress and ask to stop for Bug Analysis.

Another point is that we do not need to clearly differentiate the development and testing boundaries. In fact, most of today's multinational IT companies rarely divide development and testing jobs (about only Microsoft has strictly divided them into two positions, and even so, searching has begun to explore and change ), however, there is still so much work to be done, but the title is changed, so there is no need to tangle.

=== I am the dividing line for Switching topics ===

Another question is how testing works. Like development, experienced and inexperienced tests play different roles in the team. From the actions taken when a problem occurs during the test, I have observed that the testing personnel can reach the following levels:

1. Open a bug;

2. Search for additional materials, such as design documents and history, identify this as a problem, and then provide detailed bug reproduction steps;

3. Refine the reproduction steps to identify the minimum steps to reproduce bugs. If possible, automate the reproduction steps;

4. Try to confirm the problem by studying the Code;

5. Try to give a fix;

6. analyze the cause of the error and propose some standardized methods to detect similar problems, such as stress and fuzzing;

7. The ability to define the corresponding data analysis methods for standardized test procedures can ensure that the development and project supervisors can obtain the required information to control the quality status.

So what is our goal as a tester? My goal for myself is to be able to control all bugs from 1 to 4, and I can even achieve level 6 in at least two examples. I have been in Microsoft for more than six years. I have seen tests in many departments that can always perform level 7 and can perform such tests. No one dares to say that their technology is not good. For developers, if one of you can test most bugs at level 4, I believe the development work will be much easier.

There are many bugs. It is also a test to catch a group of monkeys and click twice on the keyboard. It is also a test to earnestly and step by step through various technical means (code coverage, stress testing, security analysis, etc. Which one do you trust as a technician? I think most people will select the latter, but what I want to say is that in practice, many test teams will become the former one without knowing it. Why? Because the tests do not understand the design of the product, they instinctively choose the easiest way to do it. Ask them: How much have you tested? How confident? They are all stupid. I am not saying that the monkey test is meaningless: on the contrary, it can catch many blind spots in our thinking. However, if your entire team is completely dependent on monkey testing, it is absolutely impossible to give you a trustworthy result.

Then the officers will inevitably ask, how many such big bull testing teams and big bull teams are there? Unfortunately, in my personal experience, the fact is that among the testers I met, it is not uncommon for testers who can only achieve level 1 at most, many people think that the testing staff who can achieve 3 is quite good. As for the team that has multiple big bull testing teams, it is really rare (a large proportion of the Microsoft headquarters ). Yes, don't be surprised. This is what I encountered at work. However, please note that this is not to say that the company is spending money to raise waste, but that the status quo will inevitably result in the early stages of entry without professional test education. All of us start from this state and it takes time to make progress.

Some people may ask: Isn't this a task for development? Yes, that's right. But why not? What is our purpose? Is it a bug or a better product? If all your goals are to open more bugs, it's really easy. Real examples: I have seen the bug of testing automated code turning into a product bug. I know it is impolite to ask a colleague to do this, but the style of doing things is delaying the work of all colleagues. As a part of the team, testing takes more time on the product. Sometimes it can save a few days of development work, because testing is the person most familiar with this bug, and development needs to be analyzed from the beginning.

-- Of course, in turn, the development should also try to bring testing into the development process so that everyone can know the details of various functional progress. Such cooperation can also greatly reduce the time required for re-designing test cases during product design changes.

Some may ask: Why do I save time for development? Well, good question. But I think everyone knows how to answer this question ".

Now, do you know why I have to perform six years of testing?

Zhu Shan:

It's an accident with software testing. The story is a little long. If you are free, let's take a look at it. I used to develop financial software in a state-owned enterprise. When I started Vi, I wrote C, and occasionally went to VB. At last, I had to spend more than 200 business days a year on a business trip and had to work overtime all night without having to take off my work, in a rage, I switched back to school to make a adjustment. In order to earn some tuition and living expenses, the company where the university students are located will try the software test with something they have never done. During the postgraduate course, the school offered two software testing courses. Due to the practice, I found that I had a good experience in learning. Due to the strict requirements of the teachers and the small number of students selected in the second semester, a major course became a small focus for a few people. The time and resources instantly became abundant, which benefited me a lot. Some of its own advantages in observation, analysis, understanding, and imagination are gradually reflected in this learning + practice process. At the same time, at the internship company, I started to follow up on a new function development that has been prohibitive to everyone so far, and met the biggest challenge since I started the test, it was definitely a miserable time, but it was this time that allowed me to grow rapidly and gain everyone's approval. After graduation, I naturally stayed in this company and officially joined the software testing team. It seems that there is no choice.

The charm of software testing, in fact, before you have this question, I did not deliberately Think About It. Moreover, in the eyes of one hundred million people, the itch of one hundred million people may not be in the same place. As a result, I thought of it temporarily. I said that my personal colors are thick and may be difficult to answer:

First, I like to play puzzle games and find that I usually get started quickly with these games. Although I cannot tell you how this is related to the test, some of them feel the same. Observation, deduction, attempt, induction, and discovery are a fascinating process. The test itself is also a comprehensive test of this ability. When getting a problem, the feeling of worrying and itching is really similar to playing a game. The testing process is a process of further learning and divergent thinking. It has always led people to explore and become very attractive.

Second, freshness. I did function tests and accessibility tests. The exploration and discovery of new functions are the main reason why I personally love new functions better than regression. Discovering and learning new tools and technologies is an interesting process. Testing is actually a purpose-driven thing. Based on this, no one will ask you to create a wheel from the ground up, and you have to learn how to use it. Otherwise, everything should be written from the main, lily is all cold. Cutting novel tools and learning new technologies are all interesting things.

Furthermore, a sense of accomplishment. As the QA owner of an application and a dev team have long-term cooperation, although there will be debates and complaints from each other when the time is short, the cooperation is smooth. Only when Dev and QA take releasing a healthy product as their common goal and work closely together is a benign development ecosystem. A successfully released product is the result of the joint efforts of everyone, it is both the pride of dev team and the pride of QA. Even if Dev is more praised at the front-end, you are confident and full of achievements because of your contribution. Think about potential design defects during design discussions, and provide suggestions before function development to avoid function misunderstanding and error risk assessment, A defect with clear descriptions and accurate root mining is delivered to Dev and is removed from the root cleanly. When the support
When the Team asks questions about product functions and users seek solutions, is there a sense of accomplishment in their hearts.

Finally, when you quarrel with the most fierce development, carrying you to praise others, you are the best QA, that kind of feeling will never be forgotten.