• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 21,  comments - 20,  trackbacks - 0

             

            當一個測試人員證實了程序里充滿bug的時候,他是一個好的還是一個糟糕的測試人員呢?在某些開發(fā)人員看來,這是一份糟糕的工作。看上去荒謬可笑,因為項目經理等人會因產品的延期交付而責備測試人員,而且開發(fā)人員會抱怨(通常是以玩笑的形式):“測試人員對于程序過于較真。”因此很明顯的,還有比計bug數更好的測試方法。這里是一些測試人員如何應對開發(fā)人員的小竅門。

            當我作為一個測試人員開始我的工作時,我意識到在開發(fā)人員和測試人員之間存在一種持久的對抗關系,而且我毫不費力的相信了:這太常見了!我接受開發(fā)人員不歡迎的態(tài)度,因此我認為所有的測試人員在他們工作的不同時刻都會有相同的經歷。從冷漠的不屑一顧到坦白的敵對相視(有時掩飾以同情的微笑),一個測試人員不得不忍受開發(fā)人員很多。這樣很難保持測試人員積極的態(tài)度。但我們測試人員積極的態(tài)度取決于我們保持的優(yōu)先權和保證項目質量的責任。我從Cem Kaner的《計算機軟件測試》一書中摘得一句優(yōu)美的話:“最好的測試人員不是發(fā)現了最多個bug或者使最多的開發(fā)人員感到不安的那個人,而是使開發(fā)人員fix最多bug的那個測試人員。”那么,我們從中能得到什么樣的啟發(fā)呢?

            態(tài)度誠懇,有耐心。

            作為一個測試人員,你也許發(fā)現說服一個開發(fā)人員修改你發(fā)現的缺陷比你發(fā)現缺陷本身更難。通常情況是,測試人員發(fā)現一個bug,開發(fā)人員會準備好十個理由來反駁。對于開發(fā)人員而言。有時很難接受自己的代碼有缺陷這一事實——即便是另外一些人已經查明確實如此。開發(fā)人員需要測試團隊的支持,他們能說服開發(fā)人員發(fā)現一個新的bug,對于盡可能使產品達到最好這一目的,是想望的、具有建設性的并且是非常重要的。采用一種人性化的方式,將更有利于測試人員了解開發(fā)人員。相信我,沒有這樣的一個人會和你坐在一起嘲笑他自己引出的bug。誠懇地態(tài)度常使開發(fā)人員說:“是嗎?多虧你的bug報告,我得到一個非常重要的進步!”

            要善用交際手段。

            試著機智圓滑的展示你發(fā)現的bug并不帶任何抱怨的解釋它:“我肯定這是一個很小的bug,你會馬上解決掉它。這是迄今為止非常完美的程序。”開發(fā)人員會非常歡迎解決它。

            要善于采取心理戰(zhàn)術,

            時不時地贊美開發(fā)人員的工作。大多數開發(fā)人員不喜歡我們的bug報告的原因很簡單:他們認為我們破壞了他們的辛勤勞動的成果。一些測試人員在只有發(fā)現問題的時候才與開發(fā)人員交流。對于開發(fā)人員而言,軟件就像自己的孩子,而你測試人員只是一個外來的干預者。我告訴我的開發(fā)人員因為他們我才能留在公司,并且因為我,他們工作上的失誤才能得以補救。這是在開發(fā)人員和測試人員之間的一種具有象征意義并且非常有益的關系。

            不要使開發(fā)人員不安。

            沒有人喜歡別人指出自己的錯誤,這是人的本性。試著解釋fix某個bug的具體辦法,譬如需要一個大的圖片,遠比自顧自的提一大堆bug報告好的多。一大堆的缺陷報告不僅不能使開發(fā)人員著急,還會使你的辛苦工作在他們看來毫無用處。就像測試人員不能對程序測試完全一樣,開發(fā)人員也不可能設計出沒有錯誤的程序。他們比需要其他事情更強烈的需要測試人員的理解。我們期望出現錯誤,因為他們是整個過程的一部分。

            有得必有失

            我知道測試人員盡可能的將bug報告提的很嚴格。他們甚至不去聽取開發(fā)人員關于這個bug不能fix或者是為了實現某個特性的解釋。試著讓自己放松下來,坐下來和開發(fā)人員一道分析這個bug的優(yōu)先級和嚴重程度,如果這個開發(fā)人員對于不樂意修改這個bug有合理的和明智的解釋的話,試著去理解他。只是要確保哪里是保證產品質量的底線。

            警惕心理

            外交手段和彈性應對并不能替換必需的警惕心理。開發(fā)人員經常找理由解釋他們拒絕fix一個bug時,說因為他們沒有意識到(或者你沒有告訴他們)這個問題有多嚴重。設計你的bug報告和測試文檔,使其能清楚地顯示出問題的風險和嚴重程度。甚至更好的辦法是召開一次會議,向開發(fā)人員解釋這個bug。一個聰明的測試人員是一個在聆聽與表達之間取得一個平衡的人。如果一個開發(fā)人員不能說服你不fix一個bug時,說服他fix這個bug就是你義不容辭的責任了。


            轉自 http://www.51testing.com/?59943/action_viewspace_itemid_86925.html
            posted on 2008-07-10 11:12 Niino 閱讀(229) 評論(0)  編輯 收藏 引用
            <2008年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            常用鏈接

            留言簿(2)

            隨筆檔案

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲国产欧洲综合997久久| 久久亚洲AV成人无码国产| 青青草原1769久久免费播放| 激情久久久久久久久久| 国产精品9999久久久久| 国产精品久久99| 91精品国产综合久久香蕉 | 国产高清美女一级a毛片久久w| 亚洲综合婷婷久久| 久久久亚洲裙底偷窥综合| 久久国产精品-国产精品| 久久成人小视频| 国产一区二区三精品久久久无广告 | 亚洲国产精品久久电影欧美| 国产午夜精品久久久久九九| 色欲综合久久躁天天躁蜜桃| 久久久久18| 中文字幕亚洲综合久久2| 国产亚洲精品久久久久秋霞| 久久国产精品偷99| 精品久久一区二区三区| 色婷婷久久综合中文久久蜜桃av| 很黄很污的网站久久mimi色| 久久久久久久亚洲Av无码| 狠狠色丁香久久婷婷综合蜜芽五月| 精品一区二区久久| 国产成人精品白浆久久69| 久久久久久国产精品无码下载| 激情伊人五月天久久综合| 99久久免费国产精品| 精品久久人人妻人人做精品| 国产精品欧美亚洲韩国日本久久| 色综合久久综合中文综合网| 99久久人妻无码精品系列| 久久久久人妻一区精品| 91精品国产高清久久久久久91| 久久伊人精品青青草原高清| 99精品久久精品一区二区| 精品久久久久久无码专区不卡| 少妇久久久久久被弄高潮| 国产91色综合久久免费|