1个版本，Bug 100+ ，爽 ？
- 2019-10-23 14:31:00
- IDO老徐 原創
- 13728
今天，本不打算写东西的 。看到测试群，很多Tester在抱怨，一个版本，测了100多个Bug 等 。
有必要聊几句 。
首先，
1个版本，100多个Bug，肯定是不正常的 。
還記得，那套理論麽？Bug修复时间越晚，成本越高 。
如下，从搜索引擎随便搜了一张图（数据合理性暂且忽略，参考即可） 。
圖略，見原文
1个版本，提测后，100多个Bug，什么概念 ？（见如上图的第三阶段 ，自行对比下） 。
那怎么避免此类问题 ？（嗯，本文主要想寫這點，怎麽樣讓提測Bug少點 ）
（作者：老徐，http://isTester.com）
解決方案：
建立严格的准入标准 ，见之前文章：
准入標准、測試通過標准、上線標准
其实，文章里面写的挺详细的 ，包含 研发自测、冒烟测试、转测资料&说明&流程 等。
上面文章有的，今天就不重複闡述了（大周末的，避免浪費閱讀時間） 。
如果嚴格按這個邏輯執行，一個「兩周一叠代的版本」，Bug控制在30內，是沒問題的（具體還得看團隊的磨合情況，及項目的類型、項目複雜度等） 。
接下来，说点异常情况 ：
01
很多情况下，如上这套逻辑，是推行不下去的 。
理論很美好，現實很殘酷（很多團隊，那不是一般的亂；遇到问题，先不去想着解决本质问题，而是直接先来个996再说，如果还不能解决，997试试 …）。
如果实在无法推行研发自测、严格的准入标准 。
那麽，IDO老徐 的建議是：
提Bug時，先提主要Bug即可，先修複一輪；
待提交新版本后，再提细节Bug 。提太多Bug，浪费提交录入的时间，开发查阅，也费时间 。
02
（作者：老徐，http://isTester.com）
來自某同學的提問：“研發開發進度慢到吐，工期不能按時交工，測試該怎麽做？我如果要催，該怎麽催，關鍵人家也在工作，也沒在閑著，就是忙，工作進度是他們自己定的，腦子疼。”
如上，
很多时候，就是由于这种预估时间不准，最后上线时间定死，草草了事 。把未开发完成的半成品提交给测试，最后导致1个版本100+ Bug的情况 。
对于此种情况，普通测试能做啥 ？
“把现状，在项目群里，同步团队，说明没按时提测即可 。其他的，普通测试做不了 。”
如果在普通测试的基础上，想往前推进一步呢 ？
（作者：老徐，http://isTester.com）
1. 这种属于任务拆分不合理（或者过于乐观，亦或技术障碍没提前预研），导致工时评估不准。
第一步，先去把任務拆分到1D顆粒度（需研發老大來推動這個事）
2. 每日站会进度同步，遇到的阻塞性障碍，及时解决；设置项目关键节点 ，有问题，及时抛风险 。
如上，先玩这两点，再观察一下 。
End 。
先聊这些，周末了，文章尽量短点 。
最後 ，
這幾天，老徐花了十幾個小時，把之前的測試資料，進行分類調整、文章調整、格式調整，進入V2.0時代，閱讀體驗更佳、資料質量更佳，公號「簡尚」後台，回複“測試資料”閱讀之 。
文 / IDO老徐
2019.10.18 深圳
IDO老徐
全网同名，个人IP公衆號
日更10年，每天 1 分钟、解决 1 个问题
職場、副業、輕創業、寫作、個人IP
公衆號、視頻號、小红书、知乎
長按/掃碼，關注IDO老徐
關注回複 401 送你「十年原創资料包」
| 聯系人： | IDO老徐 |
|---|---|
| Email： | 957863300@qq.com |
| QQ： | 957863300 |
| 微信： | 957863300 |
| 微博： | isTester |
| 網址： | idoxu.com |
| 地址： | 中国 · 广东 · 深圳 |
來源備注：老徐博客