一些已經(jīng)從事測試工作三到五年的朋友正在積極的向QA Manager 角色轉(zhuǎn)型，他們對于將來的發(fā)展方向也很一致，普遍觀點(diǎn)大都是組建一支出色高效的測試團(tuán)隊(duì)。最近我也想了一些團(tuán)隊(duì)規(guī)范和成為具有出色團(tuán)隊(duì)稱號的必要條件，自己從事測試工作也接近四年了，有些是我在原先工作中遇見并且總結(jié)出來的，寫的我認(rèn)為還談不上全面以后還會(huì)逐漸補(bǔ)全。
條件：
缺陷管理
首先正規(guī)測試團(tuán)隊(duì)至少會(huì)有一個(gè)缺陷管理系統(tǒng)，不管是Bugzilla還是Mantis 或是其它系統(tǒng)，因?yàn)?a target="_self" style="word-break: break-all; color: #202859; text-decoration: none; line-height: normal !important; ">軟件測試過程本身就是圍繞著缺陷進(jìn)行的，這也是測試工作的一個(gè)重要組成部分。我個(gè)人還是比較青睞于使用開源工具。
測試用例誰來寫
我不提倡測試新人去寫測試用例，這些工作應(yīng)該分配給那些經(jīng)驗(yàn)豐富的測試人員去做。新人寫測試用例存在一定量的風(fēng)險(xiǎn)性，例如考慮不周達(dá)不到預(yù)期覆蓋率，延緩測試周期和上線時(shí)間。
Bug有owner
對于Bug來說，測試人員開啟的Bug應(yīng)該由本人來關(guān)閉。做到Bug也要有屬主
測試工作量評估
測試工作量應(yīng)該由測試人員本人估算，從下到上估算工作量，而不是從上到下分派工作量，如果遇到工期固定可以簡化測試用例，測試分輕重
Bug描述
Bug一定要做到描述簡潔清晰爭取做到PD 一看就懂，減少不必要的交流。對于不容易重現(xiàn)的Bug可以清晰的描述操作步驟和具體操作時(shí)間產(chǎn)生什么類型的錯(cuò)誤。通過以往工作經(jīng)驗(yàn)個(gè)人認(rèn)為沒有不能重現(xiàn)的Bug。
開發(fā)人員對測試人員的測試結(jié)果產(chǎn)生疑議。如果測試人員根據(jù)自己的測試經(jīng)驗(yàn)判定是個(gè)Bug，可以先組織測試人員內(nèi)部進(jìn)行缺陷討論。判定Bug的嚴(yán)重級別后再進(jìn)行相應(yīng)處理。有不同看法是正常的，但是不要輕易妥協(xié)。
不要浪費(fèi)測試人員時(shí)間。測試人員接到測試任務(wù)拿到需測試產(chǎn)品發(fā)現(xiàn)低級錯(cuò)誤的數(shù)量以及功能的不完整性，有權(quán)退回。這是在浪費(fèi)測試人員時(shí)間。
測試人員不要過于依賴測試工具
測試人員對測試工具的完全依賴是一種不好的做法，不要忘了最強(qiáng)大的是你的測試思想，在必要的場合采用工具確實(shí)能給測試人員帶了意想不到的收獲但是這只是一種測試手段不能代表測試的全部，如果需要使用工具，我建議往開源方面靠攏。
讓測試人員了解產(chǎn)品背后的商業(yè)意義
整個(gè)項(xiàng)目中什么功能模塊是最重要的，為什么要開發(fā)這個(gè)新功能，這個(gè)功能在整個(gè)項(xiàng)目中有何種意義，這可以讓測試人員對該功能產(chǎn)生一個(gè)內(nèi)心重要級別。對測試用例和以后的回歸都起到很大幫助。
營造測試氣氛
開發(fā)人員開發(fā)完功能后需要自測，然后再交送給測試人員，共同把好質(zhì)量關(guān)。開發(fā)可能會(huì)說我寫出來的東西我自己還要測試那還要你做什么。如果開發(fā)的產(chǎn)品連正常流程都無法跑通就交給測試被一次一次的打回，這樣不光影響項(xiàng)目進(jìn)度，還可能會(huì)導(dǎo)致該測試人員會(huì)你開發(fā)出的產(chǎn)品有情緒抵觸，質(zhì)量很難得到保證。
測試技術(shù)學(xué)習(xí)
測試團(tuán)隊(duì)可以定期拿出一個(gè)課題由部分專人負(fù)責(zé)研究，然后定期Share研究成果組織團(tuán)隊(duì)人員研究討論，促進(jìn)工作學(xué)習(xí)兩不誤。
測試人員不夠
如果碰到時(shí)間緊任務(wù)重測試周期被縮短的情況。我不建議省略寫測試計(jì)劃，測試用例，測試報(bào)告去悶頭測試。測試可以分輕重，可以申請安排開發(fā)做輔助測試。也不能省略那些書面文字。不是走形式。測試人員要徹底認(rèn)識到這些東西是非常有價(jià)值的，在適當(dāng)時(shí)候可以保護(hù)你。
先寫測試用例再測試不是死規(guī)矩。事實(shí)上應(yīng)該是這種工作流程，但是有些時(shí)候當(dāng)沒有測試用例思路時(shí)，可以先手工運(yùn)行一遍功能，想到什么寫什么，最后形成完整規(guī)范測試用例。做到靈活測試。
測試人員有義務(wù)向PM闡述對功能的流程以及易用性方面自己的想法。如果是為了功能的可伸縮性那就不僅僅是測試人員需要參與討論有可能還有PD OP DB等等。最初目的是為了以后如何更方便的開展自動(dòng)化。讓自動(dòng)化能覆蓋的更多更全面。
為了保證產(chǎn)品質(zhì)量測試越早進(jìn)行越好。不僅是功能測試，其中也包含性能。
了解當(dāng)前產(chǎn)品質(zhì)量
測試人員每個(gè)人都應(yīng)該了解當(dāng)前產(chǎn)品質(zhì)量，知道哪塊薄弱，知道自己該干什么，提倡每個(gè)人都可以提出建設(shè)性意見。
開發(fā)人員告訴測試人員你應(yīng)該如何測試。
這種現(xiàn)象可以從多方面理解：
1、作為測試人員你做的不夠好，長時(shí)間來你充當(dāng)一個(gè)喊話筒的角色，從你以往提交的Bug來看沒有任何深度。想受人尊敬受人重視還是要靠自己踏實(shí)爭取。
2、測試團(tuán)隊(duì)不規(guī)范，或者說根本就沒有測試團(tuán)隊(duì)。讓開發(fā)領(lǐng)著干活自己又不會(huì)寫代碼心理不好受抱怨多多。
更多時(shí)候還是需要自己多努力，知識要靠一點(diǎn)一滴的積累。很難重現(xiàn)的Bug你能重現(xiàn)，能告訴開發(fā)哪塊功能將來可能產(chǎn)生問題，指出系統(tǒng)瓶頸等等類似很多。這些都是需要經(jīng)驗(yàn)積累。漸漸的你會(huì)發(fā)現(xiàn)自己在團(tuán)隊(duì)中起到了應(yīng)有的價(jià)值得到同事以及上司的認(rèn)可。
測試環(huán)境維護(hù)
測試環(huán)境由誰來維護(hù)其實(shí)我覺得并不重要，這里指的誰可以是運(yùn)維可以是研發(fā)可以是QA，但是最好要保證專人來維護(hù)，不要誰都可以插手。再?zèng)]有打招呼的前提下擅自發(fā)布新功能或者修改是不可取的。保證版本的統(tǒng)一性很重要。要做到正式發(fā)布功能之前OP可以在測試環(huán)境下抓取項(xiàng)目整包進(jìn)行發(fā)布。當(dāng)然對于極小功能小修改可以例外。
收集需求文檔
測試人員為了寫出一份還算完整的TestCase東奔西跑到處收集信息。開發(fā)文檔和產(chǎn)品需求文檔出爐后請第一時(shí)間送交的QA 手里，保證QA的工作開展。