I also turn to my article on software testing.

Advantages of Microsoft Testing Technology

Http://www.51testing.com /? Uid-88979-action-viewspace-itemid-86696

1.1 Test-driven development, early and uninterrupted software testing. Establish a powerful automated testing system supporting daily build and daily test. Establish a defect management platform, statistical analysis, and project management platform centered around the bug data. Decision-making changes from empirical models to scientific models. Data is used to talk about both macro and micro details of the entire software development process. Through data managers, they can focus on what is not yet done.
1.2 establish a balance system and culture to prevent problems Code Check in to ensure that the code library is sacred. Reduces various bugs.
1.3 improve various checklist or templates (documents, use cases), development and testing tools (white box ...), This allows the ability to instantly transfer to the team, fully apply the results of existing members, and improve the team level. Avoid the disadvantages of manual testing (no knowledge inheritance, low confidence level, relatively continuous at a level)
1.4 automated testing is not only a technology, but also an idea. Automated testing is a quality assurance means instead of looking for bugs. The essence of automation is to introduce one kind of pain to solve another kind of pain. Insufficient infrastructure is the root cause of the problem. Scripts are the lowest form of automation. The framework fully adopts re-use and encapsulation complexity to improve the adaptability of the framework. Automated testing should be carefully verified at the unit level. Establish an automated Square Environment
1.5 detailed and strict requirements in each stage, such as bug submission specifications to reduce human communication. Every QA Team makes their tasks well and professionally.
1.6 release standard: 95% case pass rate and 85% code coverage rate. <5% is not an important case bug.
1.7 emphasize the value of documents (capability conversion form, support for management) and requirements for defining high-quality documents
1.8 reliability and scalability tests are designed to be tested as early as possible. Otherwise, even if the results are not satisfactory, the cost will be high.
1.9 select the latter between work around und and thorough solution. Breakthrough
1.10 Test Engineer performance assessment indicators: increase check in before the prevention of bugs, find other module bug, development automation tools such as the proportion of the contribution of large items tester misunderstanding: Scientific automation http://www.51testing.com /? Uid-88979-action-viewspace-itemid-109900 finally has time to summarize the testing experience in Microsoft over the past few years and talk about the Views on testing automation.
Let's talk about why testers prefer automation.
First, self-esteem. People from computer science and technology are fond of Development (Dev ). Testing is often self-help, But testing does not require programming for a long time, so the testers try to write Program To show that you are programming. The result is often unable to stop. The more the test automation program writes, the more complex it writes. I will talk about the complicated cost of testing the automation framework later.
Second, in order to score. In order to present scores to the management, many test groups often need to take measures such as testing automation to reach 80% and program coverage to reach 90%. I want to say that these are all bull shit. As Comrade Xiaoping said, "practice is the only criterion for truth testing." In my opinion, "no problems for users are the only criterion for quality testing ". Automation is nothing more than making users fail. In addition, automation usually requires two or three tests that one person can perform. It is a good solution to employment.
My understanding of test automation is also changing. Just now, I believe in automation. I tried to write some automated frameworks from the beginning to the end, and I felt that automatic testing was quite enjoyable. After arriving at the Microsoft portal media center group, they also performed an automatic test on a very complex user interface with the other two people. As a matter of fact, the problems discovered by automated testing can basically be completed by one person by manual testing. You can simply write some simple test auxiliary tools. Some may say that automation can save testing time for the next version of the product. In fact, when the next version of portal Media Center is released, all user interfaces are completely changed, and more than 80% of automatic testing programs need to be changed. After the first version was completed, all three of us went away. People who come later often prefer to write another set of programs by themselves, and they are too reluctant to change their previous programs. This is the result of automation waste. It is very difficult to persuade others to use the self-developed automated testing framework. Everyone wants to build another one.
The following describes why we should discard the illusion of automated testing and how to conduct effective tests at a low cost. If you still cannot agree with my opinion on test automation, go to Microsoft employee's blog to see why the WTT test framework used by the Windows test group is called "waste of tester time ". My most basic point is not to say that testing automation cannot detect bugs, but to ask: is the waste of manpower caused by a complicated testing automation framework worth the final result? Can the same effect be achieved without automated testing. Based on my personal experience, two people in my test group correspond to five developers in the Development Group last year, with three project managers working on several release tasks last year and only two or three hotfix tasks. There are five or six developers in the test group. They are both automated, program coverage, and Hotfix. The labor cost for one person is USD 0.12 million, and the cost for at least three people in our province is USD 0.36 million.
First, do not expect automation to help you find bugs. Software bugs are similar to biological bugs. The test rule is that the fewer bugs there are, the more bugs there are. Automated Testing often discovers bugs when developing automation. After the automated development is completed, it is difficult to find more bugs. No matter how you run your automation, you won't find any new bugs.
Second, do not count on the contribution of automation to regression test testing. The software features that, if it is done right at a time, it will never make mistakes in the future. When the program changes, you only need to test the changed part. The items that have been tested before will not go wrong if they are not associated with the change. On the contrary, automation may be useless if the program changes significantly.
Third, automation is not as good as testing tools and manual testing. I do not recommend that testers perform full automation. On the contrary, I suggest testers use more small and flexible testing tools. Automation usually requires automatic pass or fail determination. If you test the product used to generate a page at http://www.microsoft.com/, what is the correct page framework? Many things are generated dynamically, and it is hard to confirm the correctness of all the content. If you use this product to create a page manually, you can easily identify the correctness of all related and irrelevant content with the naked eye. I used this method to find a bug that no one on the Web page could think of at work. If I used automation, it would be hard to find this bug in the test phase.
Fourth, the life cycle of software projects is automated and useless. At present, many network application projects have a very short life cycle. A project can only be born for two or three years. The dead definition is that the project enters the sustain engineering maintenance state. One major purpose of automation is to make software testing easier and cheaper in the future. But when a project dies, what is the purpose of automation. Moreover, the latest agile development, software requirements, programs, interfaces, and interfaces are constantly changing. How can automation keep up with changes. Instead of automating, it is better to understand changes and test changes directly.
How to conduct a valid test?
First, the tester's self-confidence can establish the ability to read programs. In a project, developers work to study new technologies and write the best program. Testers should better understand new technologies and understand programs based on developers' research. Understanding the program can make the test work very efficient. People who do not understand internal programs may design thirty test cases to find a bug. Each test case may find one or more bugs. I have read 30% of bugs. Due to a deep understanding of the Developer Program, even if a problem occurs after release, the developer can quickly understand what the problem is and whether it is a bug.
Second, the tester should spend as little time writing the test program as possible. The time allocation for testing should be: 30% read programs, 20% write test programs, 50% write test cases and run test cases. Good testers should focus on understanding requirements, understanding customer needs, and thinking about the conditions under which the program will go wrong, rather than thinking about how to automate. If the time is put on design automation, testing will inevitably be affected and testing resources will be dispersed. The tester should read the program and test the program to help find a good test case and test to help verify understanding and speculation.
Third, testers must learn to bargain. In many cases, the Project Manager or developer may never get what the customer needs. The tester can study with the project manager what to test first, what to test later, and what to test. For example, for a project I made, I found that 30% of the features are currently of little use, so I directly told the project manager what I would not test. It turns out that this saves a lot of manpower.
Fourth, testers need to spend more time on design. Testers must keep up with the changes and designs required by the project manager and developers. Understand the impact of each requirement. Compare all program changes of the current and previous versions in each project cycle. Key test changes.
In short, less automation, more gadgets, and more understanding of programs are efficient and cost-effective testing methods, unless you have a lot of money to spend. Who would suggest testing the automated architecture next time and tell him "that is bullshit ". Next, another person criticized the person above: http://www.ltesting.net/html/66/n-155966.html today saw this article about Automated Testing Article And has a very misleading effect. I also want to talk about my views on automated testing. First, the author is a tester who has worked at Microsoft for several years and summarizes the testing experience at Microsoft. However, what he summarized is not a typical test opinion of Microsoft, but his own test opinion. Therefore, his point of view is actually not very relevant to Microsoft. We should not be misled about this. As we all know, Microsoft made a big change in testing a few years ago. In the past, Microsoft had two positions: STE and SDET. The former was a manual test, and the latter was an automated test. Microsoft basically cut ste down, So ste should not leave, or switch SDET. In the past, manual tests were used to generate great resistance to automated tests. Team lead is reluctant to see this sentiment. Therefore, Ste is difficult. There is also a large number of testers working in Microsoft for several years. Due to capability problems, the level cannot be improved. Therefore, Junior is used for several years. Therefore, a few years of testing at Microsoft does not mean a very high level of people. In addition, we can see from the title of this article that this article is intended for scientific and automated testers. In the past, the author was a scientific and automated tester, but then he began to believe in automated tests. It can be seen that the author is a person who is easy to go to extremes and does not use a fair and rational attitude to face automated testing from start to end. In addition, this article is of some significance if it is for scientific and scientific automated testing personnel. But how many of us are superstitious about automation as the author did before? Most of them may think it is for the whole automation, and the author indeed deviated from his title, so I also need to clarify. I think the author missed the most important aspect, that is, automation can solve our testing problems. In two aspects, automation can complete tasks that cannot be completed manually, and automation can replace manual repetitive work. This is the most important reason for automation. There are some questions about self-esteem. However, the author does not seem to have explained it. Do people from computer science and technology like to develop? Where does this opinion come from? People born from computers can develop, test, DBA, support, sales, marketing, and start their own businesses. All kinds of work are possible. How can I say that I like development? In my personal experience, there are only a few developers who like development. I often cannot help myself in testing? I think many developers cannot help themselves. Does the test work a lot of time without programming? Developers do not need programming for a long time. I won't talk about it later. In short, the feeling is the author's psychology. It seems that the author prefers to do development and can't help but perform tests. He finds that no programming is needed, and then tries to write programs to show that he can program the program as well. The result is a big problem. Here, we can provide two pieces of information. First, the author wants to do development without making it. It can be seen that the author's development capabilities are limited, and the boss does not provide this opportunity, because the boss is responsible for the product. Another thing is, if I have been working on a program for several years and want to turn it into development, I can't really suppose how high it is. In addition, it is not very reasonable to extend your own psychology and mentality to the whole. What is the only standard for users? You can think of it as a standard, but how do you measure it? Users, with no problem within six months, no problem within one year, or no problem within five years, never a problem? Also, can the quality of a software be measured only when users use it? The primary purpose of our testing is to ensure the quality of the product before the user obtains the product. Isn't it a solution to achieve this goal for automated testing and program coverage? Two or three automated tests performed by one person. Where did this come from? In my experience, three or four tests can be automated by myself. My recent job achievement was that it would have taken three weeks to manually test it. After my automation, it would have been completed in one week. That is to say, three manual testers are needed, and now only one automated tester is needed. In addition, our software needs to be tested in different platforms and environments. How can this problem be solved without automation? For example, we want to go to 2000, XP, XP + SP1, XP + SP2, 2003,200 3 + SP1, 2003 + SP2, and Vista. This does not include the CPU or different Windows versions. How many people are required for manual testing? I 'd like to give a simple explanation of the problem during the second part. In my opinion, functional testing can be divided into three types based on the tested objects: Ui testing, command line testing, and API testing. I think the last two parts are very suitable for testing with automation as the main method. The author just mentioned UI automation and then promoted it to the whole automation. I think this is not a reasonable. If anyone thinks that API and command line tests are not suitable for automation, we can discuss them separately. However, we need to remove the topic nail. We only talk about UI automation. If we want to talk about automation, the author's point of view will suddenly be wrong and there is no need to continue talking about it. The problems and errors discovered by the author during the automation process are very easy for beginners. At the beginning, many people wanted to set their own automation as fancy and 100% automation. The goal was very high, and the results were quite different. Therefore, the confidence in automation is shaken. I always emphasize that "How to automate it properly ?". What should be automated, what should not be automated, and how to automate it are all learned and basic capabilities that a senior tester should possess. Because of the capabilities of the author, the later testers did not want to use their code, rather they would like to build a new one. This does not mean that automation is not good. You can think about it. If you design and implement a very good and flexible automation system, and later people can easily get started, why should they come over again? In my personal experience, the most fundamental reason for getting started is that the Code left by people is too abuse. This is not only a test, but also common in development. The automation framework I designed has not appeared as a substitute one year after I resigned. On my foundation, everyone has made new development, utilization, and expansion. What does this mean? I have never tried to persuade others to use my resources. Good things will certainly be seen by others.