※ 引述《ledia (下班後才下棋)》之铭言： : 1. unit test 不是各处都适用 : 2. unit test 不是万灵丹, 他只是用来取代人类重覆同一个动作容易出错的特性 : 3. unit test 视需求再配合其他的 QA 机制 列举一些个人经验 * 高品质、短时程、低成本，无法兼顾 这是定律；与税、死亡一样确实 * 资产与债务的共通点: 利滚利 上述三者之中，被舍弃的那一个迟早要还的 是故，不能总是舍弃同一样东西, 要适度地平衡一下 * 微软的例子 (注1) * 成本: 聘请 SDE 与 SDET SDE (software development engineer) 的主要责职是完成 shipping code SDET (software development engineer in test) 的主要责职是监测品质 function, integration, security, performance, scalability, i18n & l10n 有的没的通通要测 SDE 与 SDET 的人数比约在 2:1 到 3:1 之间 以年资、能力为基准，SDE 与 SDET 的待遇福利完全相同 SDE 与 SDET 在工程能力的 proficiency 要求相同 易言之，有能力受雇为 SDET 者，原本是可以拿来当 SDE 战力用的 * 时程 只要你的提案方式骚到痒处 (high ROI + low initial cost) 管理阶层多半愿意拿原本可以用来制造 shipping code 的时间拿来 修正 engineering system & process 的 pain points * 品质 如开头所述，对於 engineering system & process 的投资会利滚利 以微软这个 product unit team 为例, 现在他们有 * automated gated check-in 把 build break 的机会降到最低 * automated continous integration + P0 functional test coverage 在 commit 後约 2 hr, 一分自动产生的测试报告让 commit owner 及 test owner 知道有没有任何 P0 scenario regression * automated continous integration + P1 functional test coverage 在 commit 後约 8 hr, 一分自动产生的测试报告让 commit owner 及 test owner 知道有没有任何 P1 scenario regression * automated daily integration test coverage * automated daily performance test coverage etc... 只要是 automation 能带来 high ROI 的，大概都被 automated 了 security, scalability, i18n, l10n, UI test 方面 除了 security, scalability 有 tool-assisted testing 其他部分事实上用人来测试比较有效 SDET 有花时间对整个 test execution stack 的改善 让 SDE 也能随时跑任何 automated test case SDE 也花时间 refactor product code 使得 test case 有更好的测试方法 这样造成的结果，就是完善的 regression detection 可以让 (大部分的) SDE 全力往前冲而无後顾之忧 结论 * 在品质上不能让步，所以在时程与成本这两边得要有那个胆识作长远的投资 * 如果想要好的 SDET 支援，那就得花钱请有能力的人来作 SDET * 想要好的 engineering system & practice ，那就得实质奖励并支持 那些愿意花时间精神去改善 engineering system & practice 的员工 * 多积德，冲人品 XD 本文讲述的这个 product unit team 就是作微软 ALM solution 旗舰产品 Team Foundation Server (TFS) 的 team 天天 dogfood 他们自己的 TFS 来作 ALM, 有用不顺手的地方就修正 用得顺手的地方就 refactor 後拿出来卖, 听了顾客 feedback 後再修正 一般来说很少有机会作“能 bootstrap + dogfood 软体本身的软体”这样的工作 所以要多积德，冲人品… 注1: “微软”是一个很大的集合体，这里指的是 server & tools business 下 developer division 下某个约 200 人的 product unit team windows / office / xbox / bing 那边是怎麽作我不知道 这篇是挑着一些重点讲，虽然会偏颇些 但实在也没那个时间从头到尾谈一遍 orz --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 98.26.14.35 一些补述… Q: 常常 product code 一动， test code 就要大改，怎麽办? A: 在本文这个例子里，解决方式是 * 聘请有能力的人来作 SDET, 所以 SDET 有能力去 refactor test code 使用适量的 abstraction 使得 test code 与 product code 的连接点 不会牵一发而动全身 * 让 SDE 知道 SDET 是像後勤部队一样的友军 奖励两边合作让 product code interface 更乾净, 稳定 Q: 为什麽不 100% 专注在於把 product code 写好? A: 列举两个理由 * 一个 SDE 再强，总有一天他会赢乐透几百万美金去退休 与其把重点放在单个 SDE 强者上， 一个 reliable, performant, independent, isolated, transparent 的 engineering systerm & process 比较有价值 * SDE 本身还是会作 code review + unit test 配合 SDET 从不同的角度监测品质, 那还不飞上天? Q: 花钱请能当 SDE 战力的人来作 SDET，有没搞错? A: 如果你想要一个好用的 engineering system & process 你就得花钱请有能力建立+运作 engineering system & process 的人来为你工作... Q: 这样子的安排不会让 SDE 松懈下来，随便乱写吗? A: 松懈多少一定会有，但如果老是写出一些乱七八糟的东西， 出那种“应注意而未注意”的包, 该 SDE 自然会被钉到墙上去 Q: 结果 test case 到底是有没有用? A: ledia 与 NDark 那两篇 #1FmZXhcL #1FmZ-6x- 解释过了: “看情形” 如果你的团队里没人能回答这问题 花钱去请 consultant 回来，买他的时间帮你找答案。 Q: 我们小公司没那个资本，句点。 A: 这里是一张端士银行的本票，价值三千万美金… Q: 我们小公司没那个资本，怎麽办? A: 投资跟债务都是利滚利， 找出 high ROI + low initial cost 的部分一点一点作吧。 Q: 微软品质就是烂，句点。 A: http://www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY12/Q3/default.aspx REDMOND, Wash. — Apr. 19, 2012 — Microsoft Corp. today announced quarterly revenue of $17.41 billion for the quarter ended Mar. 31, 2012, a 6% increase from the prior year period. Operating income was $6.37 billion, up 12% from the prior year period. 哭哭哦? :D Q: 作到文中所述那样子，就 GG 破关了吗? A: 非也, 举两个例子 以 CI+P1 test 为例，跑一轮 1000 多个 test 要 8hr, 太慢了 接下来是要让 test execution 也能 scale out 另外，还有许多 static / compile time / runtime 的 test technique, 都可以想办法在现有的自动化系统加进去来试试看有没有实质上的效益 ※ 编辑: AmosYang 来自: 98.26.14.35 (05/29 06:01) ※ 编辑: AmosYang 来自: 98.26.14.35 (05/29 06:17) 补两个在 derekhsu #1FmwBE2i 这篇看到的重点 Q: 如何让 automated test 保持稳定? A: 这是 SDET 的责任 1. 让 test execution (从 setup 到 analysis) 变得很简单 2. 执行这些 automated test as often as possible 3. 把 #2 所找到的 test defect & flakiness 视作 product bug a. 迅速、确实地修正这些 test bug b. 找出方法来避免、减少 test regression Q: 如何让 automated GUI test 保持 high ROI? A: You tell me. XD 这得从个别案例的方式来讨论了，很难给一个通用的答案 ※ 编辑: AmosYang 来自: 98.26.14.35 (05/29 12:48) 是的，该 product unit team 老大 PUM (product unit manager) 手下 三巨头 manager 分别管 PM, SDE, SDET SDET 整支後勤部队拿的待遇, 在决策过程中的分量， 是与 PM 及 SDE 平起平坐的; 相对的，SDET 要负的责任也一样重 ※ 编辑: AmosYang 来自: 98.26.14.35 (05/29 13:36) 重新申明一点: 这个 team 可以这样玩成这样算是一个特例 别的 team 要导入 ALM solution and/or practice, 都要背上投资的风险 这个 team 要对 ALM solution / practice 作实验则是“产品研发” * 觉得 Visual SourceSafe 太烂 -> 开发 TFS 自己的 version control solution * 觉得 TFS version control 无法承受微软整个 developer division 的用量 实在太烂 -> 将 TFS version control 提昇到 enterprise 等级 * 觉得 Product Studio 太烂 -> 开发 TFS 自己的 work item / issue tracking 系统 * 觉得市面上 version control 与 issue tracking 之间 out-of-box 整合度太差 -> 让 TFS version control 与 issue tracking 有 out-of-box integration * 觉得一天到晚老是 build break ，实在太烂 -> 开发 gated check-in * 觉得从 CI build 完成还要手动去跑 automated tests, 实在太烂 -> 开发 integrated build testing * 觉得传统 issue tracking 介面 (像 Excel 一样的列表) 实在太烂 -> 开发 web-UI based task board (像 post-it note 的介面) * 觉得 TFS 2005/2008 一定要配 MS SQL enterprise，实在太烂 -> 在 TFS 2010 支援 SQL Express, 适合 home office / small teams 使用 ... etc ... 不及列举 在这样的环境下，把 SDET 视为正规的後勤部队 (而非外包的佣兵) 有许多好处, 除了能有效地改善 engineering system & process 也增加了各种 ALM solution 的实验使用者, 更能第一手体验到顾客的 pain points 易言之，要复制这个 team 的经验并不是件很简单的事 不是把“搞测试的”一夜之间变成一等公民，品质考试就会100分 这个 team 从 2002 开始，历经了 TFS 2005 / 2008 / 2010 三个 major release 到现在正在作的第四个 major release 及线上版的 tfspreview.com 才有这样的成绩; 最後还是得看决策管理阶层对品质时程成本的取舍 ※ 编辑: AmosYang 来自: 98.26.14.35 (05/29 14:23)