測試左移和開發賦能

從事測試開發那麼長一段時間，一直不知道怎麼去評價和衡量這個職業的目標是什麼，超高的自動化測試覆蓋率？或者超穩定超包容的自動化測試框架？

怎麼纔算得上是一個優秀的測試開發人員？上週有機會去聽了阿里2天的公開課，好像明白了一些，拿來跟你們分享一下。

內建質量

在微軟有一句名言：「質量是設計出來，而不是測出來的。」 固然，這是理想狀況，若是產品經理都這麼優秀，這個世界早就和平了。

今天咱們不說產品經理，咱們從測試和開發的角度看，怎麼內建質量。

讓測試內建質量

爲了內建質量，測試同窗就要儘量早地干預開發寫bug，讓bug死在搖籃裏。換句話說就是讓開發不要寫出能夠避免的bug：

1. 產品，開發，測試應該同時參與需求評審會議，澄清需求，達成共識
2. 將關鍵測試點做爲需求的一部分，讓開發同窗交付需求時完成自測

讓開發內建質量

從開發的角度看，要提升代碼的質量能夠有不少種方式：

1. 提升自測意識，藉助單元測試或者質量分析工具
2. 真正理解需求和技術架構，進行Code Review或者結對編程
3. 評估代碼質量或者bug數量，跟績效掛鉤

排除開發的自身能力問題，80%的bug都是需求理解不許確的問題，若是開發不肯背這個鍋，那就甩給產品經理吧。

因而可知，若是測試不想看見這些bug，那麼你就要幫產品表達需求，幫開發理解需求。

測試左移

上面咱們說內建質量其實已經涉及到了測試左移，例如讓QA在參與需求研討時提出問題，列出測試點其實已經開始在進行測試了。

爲何咱們要測試左移呢？由於發現問題的時間越晚，修復的成本就越高。

圖中橙色線條表明了傳統測試發現缺陷的時間，大多數bug都是在功能測試和集成測試時發現的，最後致使的結果就是發佈前加班加點，祈禱不要有bug漏到生產環境。

若是咱們能把測試活動向左移動，那麼就意味着修復成本大幅降低。

可是談何容易？想要把大部分測試點放在單元測試環境完成，很是依賴成熟的開發環境和極其資深的開發人員。

在阿里是這樣實踐的，讓測試給開發賦能。

開發賦能

從字面上解釋就是，測試同窗給開發賦於必定的能力，讓他們有能力去完成測試，好比：

1. 下降測試門檻
2. 使用測試工具（自動化）
3. 獲取測試數據
4. 培養測試意識

舉個例子，開發同窗在完成需求代碼後，能夠點擊一個按鈕獲得測試數據，再點擊一個按鈕驗證測試覆蓋點，喝杯咖啡後就能夠看到測試報告。

從上面這個例子看，開發同窗其實他並不須要懂測試數據的設計，自動化測試的開發，測試報告的編排，可是他依然能夠快速完成需求測試（門檻低），只要他養成習慣（培養意識）。

那麼你就會說，這對測試的同窗要求是否是很高啊？對啊，回到開篇的問題，如何評判一個測試人員的能力？在我看來就是評判他給開發和團隊賦能的能力。在阿里是這樣，在微軟和谷歌也是這樣。

一個優秀的測試人員將測試左移時，並不會將負擔轉移給開發。相反地，而是幫開發寫出更高質量的代碼，更高效率地交付需求。

那麼測試能左移到什麼程度呢？好比讓開發在Coding時就發現問題，或者還沒Coding就發現問題，那應該是極好的。

怎麼作到呢？剛纔已經說過了，測試即需求，把bug扼殺在搖籃裏。

實踐方法

想實踐測試左移能夠有不少種方法，每一個組織須要根據實踐狀況進行裁剪和調整。

1. 參與需求評審，幫助開發理解需求
2. 參與架構、設計分析，提前預防問題
3. 踐行BDD，TDD
4. 單元測試提案，接口測試提案
5. 提供模擬數據能力，測試工具
6. 制定提測標準，拒絕低質量代碼
7. 迴歸測試自動化
8. 靜態代碼分析，單元測試覆蓋率

測試左移的概念給整個測試角色帶來了巨大的轉變。軟件測試不單單是「發現bug」，而是致力於「儘量早的檢測和預防bug」。

參考資料

• 培訓課件： 阿里Devops體系和實踐.svg
• 參考文章：What is shift-left testing?

關於做者：

Toby Qin, Python 技術愛好者，目前從事測試開發相關工做，轉載請註明原文出處。

歡迎關注個人博客 https://betacat.online，你能夠到個人公衆號中去當吃瓜羣衆。