典型的測試錯誤有哪些？(8)

　　向每一個能夠找到的人征詢意見。從開發人員、市場人員、技術寫作人員、客戶支持人員和你能找到的每一個客戶代表那里收集意見。查看[Kaner96a]以獲得關于這種協同測試計劃的描述。

　　2. Use historical data. Analyzing bug reports from past products (especially those from customers, but also internal bug reports) helps tell you what areas to explore in this project.

　　使用歷史數據。分析以前產品的 bug 報告(特別是來自客戶的，但也要包含內部 bug 報告)可以幫助你辨別在這個項目中還需要探索哪些領域。

　　"So, winter's early this year. We're still going to invade Russia."

　　“今年冬天來得很早。但我們還是要入侵俄國。”

　　Good testers are systematic and organized, yet they are exposed to all the chaos and twists and turns and changes of plan typical of a software development project. In fact, the chaos is magnified by the time it gets to testers, because of their position at the end of the food chain and typically low status. One unfortunate reaction is sticking stubbornly to the test plan. Emotionally, this can be very satisfying: "They can flail around however they like, but I'm going to hunker down and do my job." The problem is that your job is not to write tests. It's to find the bugs that matter in the areas of greatest uncertainty and risk, and ignoring changes in the reality of the product and project can mean that your testing becomes irrelevant.

　　好的測試員是有計劃、有組織的，但他們受到計劃，特別是軟件開發項目計劃的各種混亂、各種意外轉折的影響，因為他們處于食物鏈的最后一環，而且通常地位比較低。一個不幸的反應是固執地堅持測試計劃。從感情上講，這會令人很滿意：“他們可以隨意胡亂擺弄，但我要坐下來做我的工作。”但問題是你的工作不是編寫測試。而是在最不確定和危險的領域發現 bug 。忽略產品和項目的實際變化可能意味著你的測試變得無關緊要。

　　That's not to say that testers should jump to readjust all their plans whenever there's a shift in the wind, but my experience is that more testers let their plans fossilize than overreact to project change.

　　這不是說測試員在有任何變化時都應該匆忙地重新調節他們的計劃，但我的經驗是很多的測試員都讓計劃僵化而不是對項目變化起過度的反應。

　　主題三：人員問題

　　Fresh out of college, I got my first job as a tester. I had been hired as a developer, and knew nothing about testing, but, as they said, "we don't know enough about you yet, so we'll put you somewhere where you can't do too much damage". In due course, I "graduated" to development.

　　剛走出大學校門的時候，我得到了第一份工作：測試員。我是做為開發人員被錄用的，對測試一無所知，但是他們說：“我們對你還不太了解，所以要把你放到一個你不能做太多破壞的地方。”在這個課程結束后，我“畢業”并加入到開發部門。

　　Using testing as a transitional job for new programmers is one of the two classic mistaken ways to staff a testing organization. It has some virtues. One is that you really can keep bad hires away from the code. A bozo in testing is often less dangerous than a bozo in development. Another is that the developer may learn something about testing that will be useful later. (In my case, it founded a career.) And it's a way for the new hire to learn the product while still doing some useful work.

　　將測試作為新程序員的過渡工作是組織測試人員架構的兩個典型錯誤中的一個。這樣做有一些可取之處。一是你的確可以使一些不合格的雇員遠離代碼。一個測試行業的笨蛋常常比一個開發行業的笨蛋的危險性要小。再有就是開發人員可能學習到一些以后有用的測試知識(就我而言，測試開創了我的職業生涯)。還有就是一個新手在了解產品的同時還能做一些有用的工作。

　　The advantages are outweighed by the disadvantage: the new hire can't wait to get out of testing. That's hardly conducive to good work. You could argue that the testers have to do good work to get "paroled". Unfortunately, because people tend to be as impressed by effort as by results, vigorous activity - especially activity that establishes credentials as a programmer - becomes the way out. As a result, the fledgling tester does things like become the expert in the local programmable editor or complicated freeware tool. That, at least, is a potentially useful role, though it has nothing to do with testing. More dangerous is vigorous but misdirected testing activity; namely, test automation. (See the last theme.)

原文轉自：http://www.uml.org.cn/Test/200709289.asp