“溝通”成了最重要的技能之一
敏捷宣言里講：個體和交互勝過過程和工具，客戶合作勝過合同談判。在內(nèi)部需求上，開發(fā)人員就是我們的客戶。而我在加入團(tuán)隊后所做的第一件事，就是搬位子到開發(fā)人員旁。當(dāng)然，是被要求這么做的。一開始還有點不適應(yīng)，畢竟我們被分離開了曾引以為豪的獨立的測試團(tuán)隊，這和傳統(tǒng)的觀念是相悖的。不過在經(jīng)歷過幾個測試階段后，這么做的好處就體現(xiàn)了出來。
以往我們總要等到一個正式的版本，才可以開始測試，否則過多的介入會打亂開發(fā)計劃。而現(xiàn)在，程序員就坐在我對面的隔間，他一抬頭就說：“嘿，X功能做好了，我跑了一遍沒問題，你來試試看？”結(jié)果我過去試了試，bug出來了。程序員的反應(yīng)則是：“好，我馬上改”。——這樣一個bug從發(fā)現(xiàn)到修正，最多不超過半個小時。而以往，我要等到版本正式提交，再build好，再up好，發(fā)現(xiàn)bug后還要通過提交bug管理系統(tǒng)，等待系統(tǒng)發(fā)郵件給程序員。如果恰好程序員忘記開郵箱了，那就可能要更多的時間。
事實上這里面還有更多的細(xì)節(jié)。我相信大多數(shù)測試人員會和我有同樣的經(jīng)歷，在發(fā)現(xiàn)并提交一個bug時，我們寫了大量的文字來描述bug的環(huán)境，bug的重現(xiàn)步驟；程序員修正bug時，也自信滿滿的說，該bug已修正。但當(dāng)你一復(fù)查時，卻發(fā)現(xiàn)你所認(rèn)識的那個bug還在，而程序員完全理解錯了你所說的bug。而現(xiàn)在，你所需要做的，只是抬一下頭，把問題說出來，直接和程序員進(jìn)行溝通，讓他能夠準(zhǔn)確的理解你的意思，甚至包括你對于該bug的分析。接下來一切就十分好辦了。
此外，有時有些bug確實不是那么容易重現(xiàn)的，你需要和程序員配合操作，才能發(fā)現(xiàn)其中的蛛絲馬跡。我們現(xiàn)在最常做的一種合作就是，由我來制造環(huán)境，按重現(xiàn)步驟操作，由程序員在另一端跟蹤調(diào)試代碼，一邊溝通，一邊進(jìn)行，這樣就能很準(zhǔn)確的發(fā)現(xiàn)問題，并且能很快的得到修正。
僅僅是幾句話的溝通，就能將一個bug在最短的時間內(nèi)修正，這節(jié)省了多少時間？這皆得益于比以往更便捷的溝通。而我們所做的，不過是移動了一下位子，減少了我們之間的溝通成本，卻大大的提高了開發(fā)效率——我已經(jīng)記不清有多少bug在還沒提交之前就被消滅掉了。但這也對我們測試提出了更高的要求，雖然之前的我們也很強(qiáng)調(diào)溝通能力，但現(xiàn)在由于需要更頻繁的溝通，我們對溝通能力的提高也變得也越來越重要，成為了最重要的技能之一。
說到這里，其實我們已經(jīng)能感受到，測試的角色定位已經(jīng)變了。因為敏捷開發(fā)中，要對質(zhì)量負(fù)責(zé)的是整個團(tuán)隊，這一目標(biāo)就要求測試人員不再是一個獨立的質(zhì)量監(jiān)督部門，而是要融入到整個團(tuán)隊中，成為開發(fā)中不可分割的一部分。
調(diào)整測試用例的粒度
敏捷宣言里還說，可以工作的軟件勝過面面俱到的文檔，響應(yīng)變化勝過遵循計劃。那么我們是不是可以都不要文檔，不用寫用例了呢。我想，如果你的項目是一個“Hello world多國語言版”，大可以如此。但如果是面對一個大型的，多人的，在線的，角色扮演游戲，還是算了吧。
此文章共有3頁 1 2 3 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
