What is software test automation?

Translator's Foreword: Probably at the end of 2008, I had an exchange with an engineer who had worked almost for a lifetime at Sun (when Sun was about to be acquired, he was very low), and he explained Sun's details in detail. The internal test architecture mentions that Sun has independently developed a large number of automated test tools over the decades, so I have a question: Is automated testing not a concept that has emerged in recent years? What is the status and role of automated testing? Can automated testing solve the problems faced by testing? In the past few years, my understanding of testing has improved, and I just saw James Bach's article "What is Test Automation?" ", I am similar to his point of view, translated for everyone to see, welcome to discuss.

Test automation is any test that is aided by tools. This test occurs on the first day of the computer industry. And there has never been a history of "test automation replaces the work of test engineers"; this happens unless you completely ignore the real work of the testers.

For the same reason, automatic space detectors have never been used to "replace the work of space scientists", they have only expanded the scope of scientists' exploration. Automated testing also means expanding the scope of the tester's exploration.

Test automation is simply not new (in the circle of consent — — translator Orz), the concept of independent test engineers is newer than it. A long time ago, around the end of the 1940s, independent test engineers did not appear at all. The developer tests the program himself. In the 1960s, papers on testing (such as those in the IFIPS conference) were all about how developers tested their own programs. The two concepts of test and debug are also not distinguished. As software systems grow in size, the concept of independent testing has become fashionable. In Chapel Hill, 1972, the first meeting on software testing was held, which led to the beginning of software testing as a technology independent of development.

But at this meeting, I think they made a mistake. It is they have a lot of expectations and enthusiasm for test automation. This expectation was not successfully achieved in the end, but not because of the lack of practice, but because of the lack of good understanding.

They don't understand, but also many contemporary programmers (I don't think many programmers today understand — — translator) does not understand: good software testing, natural, inevitable It is a kind of human activity, inevitable, not accidental. Testing is a social activity, a psychological activity. The more complex the software, the greater the role of people in using and identifying software problems. But the Chapel Hill conference was occupied by people trained as programmers and electronics engineers who lacked the knowledge of how to think.

(Who is this kind of person who thinks? Jerry Weinberg. His paper 1965 Ph.D. thesis on problem solving is awesome. He wrote computer programming psychology in 1970, including one A series of papers on software testing in the 1960s. In his 1961 book, Software Development Foundation, he devoted a chapter to discussing software testing. Unfortunately, Jerry did not attend the Chapel Hill conference, but he attended the CAST conference in Toronto.

The concept of trained independent testers is newer than the concept of automated testing, but compared to test automation, the concept is not acceptable enough, because the training of testers is really too bad! (Our domestic is not a —— translator)

So some people understand that testing is a simple technique, the test is to ensure that the call to the API does not make the program roll like an uncontrolled beast. I don't know where to go. This idea is still there, I mean Microsoft. My wife has to let me help her to locate the problem of Microsoft Office software. I was told that Microsoft Office, a software that is still inflated, was written by developers who have not systematically studied software testing, with the support of those "automated testing tools". (Fortunately, my colleague, Michael Bolton & mdash; & mdash; is this buddy singing good? Translator Orz—— recently opened a test class at Microsoft, so, maybe, there is hope)

Testing Automation does not reproduce the creative thinking of test engineers conceiving tests, controlling tests, modifying tests, observing and evaluating products. Test automation can't do those high quality tests. So, test automation never meant to: automate the services provided by those test engineers.

In a word, test automation means using test tools. Test automation is an old concept, and the concept of an independent test engineer is newer than this. The industry has not yet tried (except in a small internal scope) system training testers, they just named the position "Test Engineer" or "Development Test Engineer", and then some of them are not familiar with Test tools are thrown at them, and then wishful thinking that they can work hard! Fighting!

(Also, I am also a programmer. I use my Apple II computer to program, which is earlier than I heard about assemblers. In the early 1990s, I led the Borland C++ project. Borland Turbo Debugger test group ——Debugger is a debugging tool for developers, indicating that James knows the developer's work well. Translator —— Before that, I led the test tool development team at Apple. People's personnel testing, GUI-based automated testing, non-GUI-based automated testing, I have done these things.

These experiences have even brought me some new problems, when I face the new generation Testers —— refers to trained independent testers, translators—— and developers who have not used so-called automated test tools, I am a bit impatient)

Translator: James Bach means that it should be the life of an independent test engineer, not the reverse. Can the problem solved by automated testing 50 years ago be solved today? Welcome to the discussion.