其次，很多優秀的黑盒測試人員并沒有編程經驗。他們能提供緊要問題的意見，以及其它大多數程序員無法提供的與客戶溝通方面的經驗。他們是完成大型測試工作所不可缺少的。但是，你不能指望這些人編寫自動化代碼。因此，你需要一個不要求每個人都編寫測試代碼的崗位安排和開發策略。你還需要避免產生一種帶有歧視性的想法，認為測試編程人員要高于測試非編程人員。這是一種在使用自動化工具的測試組中普遍存在的偏見，但在我看來，這是不理智的和降低生產率的。它會排擠你的高級非編程測試人員，并且會使你把大量精力投入在與實際客戶需求無關的程序測試中。
Non-programmers can be well served by data-driven approaches that let them develop test cases simply by entering test planning ideas into a spreadsheet.
數據驅動方法使非程序員能很好的工作，因為它使他們能通過簡單地把測試規劃放入電子表格中來開發測試用例。
Third, be cautious about using contractors to implement automation. Develop these skills in-house, using contractors as trainers or to do the more routine work.
第三，在把自動化外包給承包者時要特別謹慎。最好是在內部開發，把承包者視為培訓者或讓他們處理更多的常規事務。
Finally, you must educate management that it takes time to automate, and you don’t gain back much of that time during the Release in which you do the initial automation programming. If you are going to achieve your usual level of testing, you have to add staff. If a project would normally take ten testers one year for manual testing, and you are going to add two programmer-years of automation work, you will have to keep the ten testers and add two programmers. In the next Release, you might be able to cut down on tester time. In this Release, you’ll save some time on some tasks (such as configuration testing) but you’ll lost some time on additional training and administrative overhead. By the very end of the project, you might have improved your ability to quickly regression test the program in the face of late fixes, but at this last-minute point in the schedule, this probably helps you test less inadequately, rather than giving you an opportunity to cut staffing expense.
最后，你必須讓你的管理者知道，自動化是要花費時間的，而且在做初始自動化編程工作的發行版中你也無法趕回這段時間。如果你要達到你通常的測試級別，你必須增加人力。例如，如果某項目通常需要十個測試人員手工測試一年，而你想要為自動化工作投入兩個人年，那你就需要保持這十個測試人員，并增加兩個程序員。在下一個發行版中，你才會縮短測試時間。在這一版中，你會在某些任務上節省時間(比如配置測試)，而在額外的培訓和行政管理上付出更多時間。到項目結束時，你可能已經改進了面對今后困難時快速回歸測試的能力，但是在進度的最后時刻，它很可能反而使你缺乏足夠的測試，而并非讓你有機會削減人力開支。
6. Consider using other types of automation
6.考慮使用其他類型的自動化
The LAWST meeting focused on GUI-level regression tools and so I have focused on them in this article. Near the start of the LAWST meeting, we each described our experiences with test automation. Several of us had dramatic successes to report, but most of the biggest successes involved extensive collaboration with programmers who were writing the application under test. The types of tools used in these success stories varied widely, reflecting the many different kinds of benefits available from many different kinds of testing tools.
LAWST會議的重點在GUI級回歸測試工具，所以本文的重點也是這個內容。在LAWST會議召開前夕，我們每人都介紹了我們在測試自動化方面的經驗。其中的一些人報告了大量的成功案例，但大多數案例都涉及到那些編寫測試應用程序的程序員的協作。這些成功案例中用到的工具各式各樣，說明不同的測試工具能帶來不同的收益。
There is too much hype, mythology, and wishful thinking surrounding GUI-based regression automation. They can create an illusion of testing coverage where no significant coverage exists, they can cause serious staff turnover, and they can focus your most skilled staff into designing and maintaining test cases that yield relatively few bugs.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
