典型測試錯誤（三）——人員問題

　　主題三：人員問題

　　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.)

　　但是不利之處超過了有利之處：新雇員迫不及待地要離開測試行業。這很難產生高質量的工作。你可能會爭辯說測試員為了“被釋放”，必定會好好工作。不幸的是，過程給人留下的印象常常像結果一樣深刻，嚴厲的活動——特別是為了證實具備程序員資格的活動——變得過時了。結果，缺乏經驗的測試員所做的事情就像一個局部可編程編輯器專家或是一個復雜的自由軟件工具專家所做的事情一樣。這些雖然與測試無關，但至少還有潛在的作用。更危險的是誤導了測試活動，即測試自動化。(參見最后一個主題)

　　Even if novice testers were well guided, having so much of the testing staff be transients could only work if testing is a shallow algorithmic discipline. In fact, good testers require deep knowledge and experience.

　　即使新測試員很好地獲得指導，除非測試是一個淺顯的算法學科，否則將這么多測試人員轉換工作也是不可行的。事實上，好的測試員需要深入的知識與經驗。

　　The second classic mistake is recruiting testers from the ranks of failed programmers. There are plenty of good testers who are not good programmers, but a bad programmer likely has some work habits that will make him a bad tester, too. For example, someone who makes lots of bugs because he's inattentive to detail will miss lots of bugs for the same reason.

　　第二個典型錯誤是從不合格的程序員中招募測試員。有很多好的測試員都不是好的程序員，但一個不好的程序員的一些工作習慣可能使他也會成為一個不好的測試員。例如，一個因為不注重細節的而產生很多 bug 的人也會因為同樣的原因而漏掉很多 bug 。

　　So how should the testing team be staffed? If you're willing to be part of the training department, go ahead and aclearcase/" target="_blank" >ccept new programmer hires. Accept as applicants programmers who you suspect are rejects (some fraction of them really have gotten tired of programming and want a change) but interview them as you would an outside hire. When interviewing, concentrate less on formal qualifications than on intelligence and the character of the candidate's thought. A good tester has these qualities:

　　那么應該如何招募測試團隊呢?如果你愿意成為一個培訓部門，可以繼續接受一些新程序員。接受一些你懷疑是被其他人舍棄的程序員申請人(他們之中確實有一些人是厭倦了編程而想有一些變化)，但是像從公司外面招人一樣面試他們。在面試的時候，重點集中于應聘者的智力和思想特征而不是表面的資歷。一個好測試員應該具備：

　　· methodical and systematic.

　　· 有條理、有計劃。

　　· tactful and diplomatic (but firm when necessary).

　　· 有策略、說話辦事得體(但在需要的時候要堅定)

　　· skeptical, especially about assumptions, and wants to see concrete evidence.

　　· 懷疑能力，特別是關于假設的，并要看到具體證明。

　　· able to notice and pursue odd details.

　　· 能夠注意并跟蹤奇怪的細節之處。

　　· good written and verbal skills (for explaining bugs clearly and concisely).

　　· 良好的書面和口頭表達技巧(可以清楚、簡潔地解釋 bug )。

　　· a knack for anticipating what others are likely to misunderstand. (This is useful both in finding bugs and writing bug reports.)

　　· 能夠預料到其他人可能會誤解什么的能力(這在發現 bug 和編寫 bug 報告時非常有用)

　　· a willingness to get one's hands dirty, to experiment, to try something to see what happens.

　　· 愿意不辭辛苦地進行實驗，嘗試一些事情來看看會發生什么。

　　Be especially careful to avoid the trap of testers who are not domain experts. Too often, the tester of an accounting package knows little about accounting. Consequently, she finds bugs that are unimportant to accountants and misses ones that are. Further, she writes bug reports that make serious bugs seem irrelevant. A programmer may not see past the unrepresentative test to the underlying important problem. (See the discussion of reporting bugs in the next theme.)

　　特別是要小心避免測試員不是領域專家的陷阱。經常地，會計軟件包的測試員對會計了解很少。結果是，她發現的 bug 對于會計師來說不重要，但又漏掉了很多對于會計師來說很重要的 bug 。而且，她編寫的 bug 報告將使嚴重的 bug 看起來無關緊要。程序員可能無法透過不具備代表性的測試來看到底層的重要問題(查看下一主題中的關于報告 bug 的討論。)

　　Domain experts may be hard to find. Try to find a few. And hire testers who are quick studies and are good at understanding other people's work patterns.

　　領域專家可能不太好找。嘗試去找幾個。聘用那些能夠快速學習并且善于理解他人工作方式的測試員。

　　Two groups of people are readily at hand and often have those skills. But testing teams often do not seek out applicants from the customer service staff or the technical writing staff. The people who field email or phone problem reports develop, if they're good, a sense of what matters to the customer (at least to the vocal customer) and the best are very quick on their mental feet.

　　有兩組人員比較容易找并且常常具備這些技能。但是測試小組經常不從客戶服務人員或技術文檔寫作人員中尋求申請人。通過郵件或電話解決問題報告的人，如果是稱職的，那么他們知道對于客戶(至少是電話中的客戶)來說什么是重要、最好的，這種感覺對他們將有所幫助。

　　Like testers, technical writers often also lack detailed domain knowledge. However, they're in the business of translating a product's behavior into terms that make sense to a user. Good technical writers develop a sense of what's important, what's confusing, and so on. Those areas that are hard to explain are often fruitful sources of bugs. (What confuses the user often also confuses the programmer.)

　　像測試員一樣，技術寫作人員常常也缺乏詳細的領域知識。但是，他們的工作是將產品的特性以對用戶有意義的方式轉換出來。一個好的技術寫作人員有培養出一種什么是重要的、什么是令人迷惑的感覺。那些難于解釋的領域經常包含了很多的測試錯誤。(使用戶感到迷惑的地方同樣也會使程序員感到迷惑。)

　　One reason these two groups are not tapped is an insistence that testers be able to program. Programming skill brings with it certain advantages in bug hunting. A programmer is more likely to find the number 2,147,483,648 interesting than an accountant will. (It overflows a signed integer on most machines.) But such tricks of the trade are easily learned by competent non-programmers, so not having them is a weak reason for turning someone down.

　　沒有選擇這兩組人員的一個原因是堅持認為測試員都應當會編程。編程技巧會給搜尋 bug 帶來一定的優勢。與財務人員相比，程序員更有可能發現數字2,147,483,648是有趣的(這個數字在大多數機器的有符號整數中溢出。)但是這種技巧很容易被有能力的非程序員掌握，所以這是不錄取他們的一個不充分的理由。

　　If you hire according to these guidelines, you will avoid a testing team that lacks diversity. All of the members will lack some skills, but the team as a whole will have them all. Over time, in a team with mutual respect, the non-programmers will pick up essential tidbits of programming knowledge, the programmers will pick up domain knowledge, and the people with a writing background will teach the others how to deconstruct documents.

　　如果你按照這些規則招聘員工，你就會避免一個缺乏多樣性的測試小組。所有的成員都會缺乏某些技能，但作為一個整體，小組應當具備這些所有的技能。隨著時間的推移，在一個互相尊重的的小組中，非程序員將獲取一些最基礎的編程知識，程序員將獲得專業領域知識，而具有寫作背景的人將教會其他人如何解構、拆析文檔。

　　All testers - but non-programmers especially - will be hampered by a physical separation between developers and testers. A smooth working relationship between developers and testers is essential to efficient testing. Too much valuable information is unwritten; the tester finds it by talking to developers. Developers and testers must often work together in debugging; that's much harder to do remotely. Developers often dismiss bug reports too readily, but it's harder to do that to a tester you eat lunch with.

　　所有的測試員——尤其是非程序員——會被開發人員和測試員在物理位置上的隔離所困擾。開發人員和測試員之間和諧的工作關系對于有效測試來說至關重要。太多有價值的信息沒有記錄下來;測試員在與開發人員交談時發現了它。開發人員與測試員必須在一起工作以排除 bug ，遠程實現是非常困難的。開發人員常常隨意關閉一個 bug 報告，但是對一個一起吃午餐的測試員的報告卻很難這樣做。

　　Remote testing can be made to work - I've done it - but you have to be careful. Budget money for frequent working visits, and pay attention to interpersonal issues.

　　遠程測試也能達到目的——我就這樣做過——但你必須很小心。經常進行工作訪問的資金預算，并且要注意人際關系問題。

　　Some believe that programmers can't test their own code. On the face of it, this is false: programmers test their code all the time, and they do find bugs. Just not enough of them, which is why we need independent testers.

　　有些人相信程序員不能測試他們自己的代碼。這顯然不對：程序員一直都在測試他們的代碼，而且他們也的確能夠發現 bug 。只是發現的 bug 還不夠多，這也是為什么我們需要獨立的測試員。

　　But if independent testers are testing, and programmers are testing (and inspecting), isn't there a potential duplication of effort? And isn't that wasteful? I think the answer is yes. Ideally, programmers would concentrate on the types of bugs they can find adequately well, and independent testers would concentrate on the rest.

　　但是如果獨立測試員也在測試，程序員也在測試(并且也在走查代碼)，其中不存在潛在的重復工作嗎?這不是一種浪費嗎?我想答案是肯定的。理想情況中，程序員應當集中于他們能夠充分發現的 bug 類型，而獨立測試員應集中于其他部分。

　　The bugs programmers can find well are those where their code does not do what they intended. For example, a reasonably trained, reasonably motivated programmer can do a perfectly fine job finding boundary conditions and checking whether each known equivalence class is handled. What programmers do poorly is discovering overlooked special cases (especially error cases), bugs due to the interaction of their code with other people's code (including system-wide properties like deadlocks and performance problems), and usability problems.

　　程序員能夠較好地發現的 bug 是那些與他們預期不符的代碼。例如，一個接受過一定培訓、有一定積極性的程序員可以很好地找到邊界條件，并且檢查每一個等價類是否都處理了。程序員做的不好的地方是不能發現被忽略的某些情況(尤其是錯誤情況)，不能發現由于他們的代碼與其他人的代碼交互作用而產生的 bug ，以及易用性問題。

　　Crudely put, good programmers do functional testing, and testers should do everything else. Recall that I earlier claimed an over-concentration on functional testing is a classic mistake. Decent programmer testing magnifies the damage it does.

　　大致來說，好的程序員進行功能測試，測試員應該完成其他所有工作?；貞浺幌挛仪懊嬖f過，過分集中于功能測試是一個典型錯誤。合格的程序員測試夸大了它產生的破壞。

　　Of course, decent programmer testing is relatively rare, because programmers are neither trained nor motivated to test. This is changing, gradually, as companies realize it's cheaper to have bugs found and fixed quickly by one person, instead of more slowly by two. Until then, testers must do both the testing that programmers can do and the testing only testers can do, but must take care not to let functional testing squeeze out the rest.

　　當然，合格的程序員測試相對較少，因為程序員既沒有接受過培訓，對測試也沒有熱情。但是隨著各個公司意識到由一個人發現并修復 bug 成本較低，這種情況也在逐步改變。在此之前，測試員不但必須完成程序員可以完成的測試，還要完成只有測試員才能完成的工作，還必須小心不要讓功能測試擠占了其他測試。

原文轉自：http://www.kjueaiud.com