測試管理：百人團隊質(zhì)量保障演進：從0到1三步走
來源：軟件質(zhì)量報道
本文是根據(jù)演講嘉賓朱媛媛（汽車之家經(jīng)銷商BU質(zhì)保負責(zé)人） 2021年8月21日在 Q&E meetup online 分享整理而成。
公號作者寄語：文章中提到的團隊質(zhì)量問題，相信在大部分研發(fā)團隊中都出現(xiàn)過，請讀者細細品味。
團隊背景：質(zhì)量內(nèi)建三個階段，從開始嘗試到推廣到整個技術(shù)團隊，變成常態(tài)化，每個階段大概都是1年時間。團隊規(guī)模是150左右，分7、8個業(yè)務(wù)開發(fā)團隊，推廣過程中在試點團隊觀察3個月，每個月都會總結(jié)復(fù)盤，3個月試點結(jié)束，然后一個業(yè)務(wù)組一個業(yè)務(wù)組的推廣。每階段定好一個建設(shè)目標(biāo)，然后：試點--->效果--->推廣--->常態(tài)化。
一、困境?
1.1 傳統(tǒng)開發(fā)模式的困境
這種模式下，測試作為上線前最后一個環(huán)節(jié)，整個產(chǎn)品的質(zhì)量都壓在測試環(huán)節(jié)，沒有充分的測試時間，通常情況是bug能被測出來就會被提前發(fā)現(xiàn)，測不出來就會留到線上，變成線上問題，再靠團隊“救火” ，而且這階段Bug發(fā)現(xiàn)成本也很高。這種模式下，測試人員是最痛的角色。?
二、第一步：破局，小步初試
2.1 從測試團隊開始推進，搭建質(zhì)量體系三步
破局三步：
造成問題的原因，抓關(guān)鍵點環(huán)節(jié)。 共識理念、尋找方法的指導(dǎo)原則，引入必要的外部力量，比如培訓(xùn)，建立測試左移，Google的質(zhì)量觀等思想。 尋找試點團隊，把握關(guān)鍵原則，找到最合適的團隊，提供必要的保姆式服務(wù)。
整理測試用例覆蓋的bug數(shù)據(jù)，每個迭代關(guān)注數(shù)據(jù)督促開發(fā)執(zhí)行。 將測試用例覆蓋出現(xiàn)的bug數(shù)作為考核指標(biāo)引起重視。
統(tǒng)一到測試環(huán)境，開發(fā)完成后部署完先自測，完成后在進入測試階段。 數(shù)據(jù)保證從業(yè)務(wù)層面構(gòu)造，不能通過修改數(shù)據(jù)庫等方式略過業(yè)務(wù)場景，無法發(fā)現(xiàn)問題。 開發(fā)對測試數(shù)據(jù)有疑問的，測試同學(xué)幫助構(gòu)造業(yè)務(wù)數(shù)據(jù)，熟悉業(yè)務(wù)的數(shù)據(jù)流程。
明確組長或某個角色負責(zé)有交叉的業(yè)務(wù)自測驗證。
進入測試前，測試與開發(fā)溝通測試用例（一對一）+測試用例評審。
短期改善期是會比之前更忙，是不可避免的，過渡期。 逐步來，提供用例的需求覆蓋度，從20%開始，逐步增加到80%。 優(yōu)化簡單的需求開發(fā)自測保證，大家共同努力。 跟開發(fā)溝通需求和測試點后，先提供能覆蓋各種場景的測試點和粗略的預(yù)期結(jié)果，在開發(fā)完成代碼時提供全部的測 試用例。
測試用例評審。
和開發(fā)團隊約定一個大家都可接受、理解的程度。
測試給出需求規(guī)約，由產(chǎn)品針對規(guī)約進行細化補充確定需求規(guī)范，并按照規(guī)范執(zhí)行。 流程上約定測試同學(xué)先過一遍需求文檔，符合評審要求才進迭代。
約定給出時間。
約定需求變更截止點+要求同步到測試。
通過測試用例的輸出，提高開發(fā)提測質(zhì)量，開發(fā)自測完成功能初驗和修復(fù)的工作，減少測試同學(xué)發(fā) 現(xiàn)bug后的回歸，縮短交付周期。
測試環(huán)節(jié)前置到開發(fā)，由測試同學(xué)串行測試任務(wù)到開發(fā)并行執(zhí)行，縮短交付周期。
三、第二步：鞏固，自動化
四、第三步：推動，聚焦價值
五、經(jīng)驗心得
不為了工具而工具，不為了自動化而自動化，從實際問題出發(fā)解決問題。 容易出效果，建立信心。
靜態(tài)代碼掃描等措施并不能直觀的減少bug提高開發(fā)提測質(zhì)量，更重要的作用是代碼的可維 護性好，不易出問題，形成好的編碼習(xí)慣。 接口自動化開展到一定程度，也會遇到瓶頸困難，需要變通。
自己和自己比，建立基線，看趨勢變好還是變差。 根據(jù)不同階段選擇關(guān)鍵度量數(shù)據(jù)，并不斷迭代。
END
長按二維碼/微信掃碼? 添加作者
閱讀原文
評論
圖片
表情