軟體測試人員，如何保證緊急任務來臨時的任務質量

        某專案組正工作得熱火朝天的時候，突然接到一個緊急任務：兩天後領導要給客戶演示一項新功能，必須要兩天內高質量上線。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

　　專案組全部成員就開始集中火力全力支撐此緊急任務，除了趕工外，還把原本計劃的功能很大部分挪到下一個階段。

　　最後這種頂著壓力上線的任務質量堪憂，甚至可能成為一個惡性迴圈。

　　相信類似的經歷，很多專案組都會遇到，並且在敏捷文化盛行的今日，需求快速變化，快速佔領市場幾乎是軟體行業的家常便飯。

　　而作為軟體測試人員來說，如何能夠保證緊急任務來臨時，避免成為交付的最大的瓶頸是一個較大的考驗。測試人員在完成任務的同時更應該去思考如何形成處理這種緊急任務的操作流程。

       心理準備工作

　　所謂修行先修心，首先我們需要端正態度，平心靜氣，做好自己的心理建設。站在一個較高的角度去看問題，可能就不會再看到一地雞毛蒜皮了。

       接納計劃外的任務

　　任何人都不希望做一些計劃外的任務，一般情況下有緊急任務出現都是比較影響業務的。要試著站在對方的角度，以同理心的角度去換位思考。

　　與其焦躁不安，怨天尤人，倒不如主動去接納這些意料之外的任務，也許事情就會變得更簡單。

       相信沒有解決不了的事

　　要相信每個人都是解決問題的專家，當困難和挑戰來臨時，迎難而上，終會柳暗花明。不管是透過流程還是工具或者適當的外援，終逃脫不了“一物降一物”的法則。

        應對策略

　　從時間管理四象限法則中可以看到，緊急任務不外乎有兩種型別，一種是緊急且重要的事，另一種是緊急但不重要的事，不同的緊急任務處理方式是不一樣的，但總體的處理方式是要事第一。

　　對於緊急且重要的事情需要高度關注，優先解決，對於緊急不重要的事情則可以根據情況授權別人做。

　　比如你可以根據專案實際情況來定義必須在XX時間內完成的任務為緊急任務，在這之外的為非緊急任務。

　　重要性呢可以針對當前的事務和我們已經設定的目標是否相吻合，吻合度越高就代表越重要，而吻合度如何確定則靠自己的個人價值觀以及經驗值來確定。

　　對於一個測試負責人來說，一方面需要很清楚的明確緊急和重要的邊界，另一方面需要從管理和流程層面全面的來預防和應對緊急任務，建立適合自己專案組的測試策略。

        以管理促發展

　　測試負責人的主要工作就是在不同的階段把人、事、物等要素綜合考慮和運用，使各方資源發揮合力，讓有限的資源產生最好的組合效能。

　　如果效能提上去了，就能預留相對較多的時間給到緊急任務的覆蓋。提高效能和質量的有很多不同型別的測試策略，本文主要討論測試分工的策略。

       1、基於風險預警的測試分工

　　保證每個測試人員手裡應該只有80%飽和度的需求，除非特殊情況不排到100%。

　　首先個人精力有限，一直忙碌的話工作效率不高，也不利於個人身心健康和有效地思考。

　　其次，需求測試的不確定因素較多，一般情況下80%的需求可能已經花費了100%的精力和時間；最後20%的時間預警給緊急任務，以保證接到緊急任務有人可以接手。

       2、基於AB角的測試分工

　　一個功能最好有兩個以上的同學熟悉。

　　功能AB角有很多好處，一方面可以相互評審測試用例，另一方面可以降低對人員的依賴性，當熟悉這一模組的同學請假或者離職時，有備份人員可以快速接手介入測試，避免測試空檔期。

       3、基於人員能力層級的測試分工策略

　　在安排測試需求的時候，需要結合測試人員的個人發展計劃和意願以及個人能力有傾向性地去分配對應的模組，保證每個人至少要有一個最擅長的模組，同時又不能只接觸這一個模組的內容。

　　專案組人員在提到某個模組的時候自動關聯到對應的測試人員，當有緊急重要的任務來臨時，會優先這個測試人員來負責，同時在別的模組有緊急但是不重要的任務的時候，可以協助處理。

　　總之在進行需求分工時不能只顧著將需求安排下去，要了解這個需求是做什麼的，然後分析最佳人選，既能確保需求的交付質量和效率，又要能讓測試同學有提升。

        以流程促質效

　　無論何時何地，需求只有在保障質量的情況下才能上線，所以，無論任務是否緊急都要盡最大可能去進行測試覆蓋，盡大可能去暴露風險。對於緊急任務呢，會受限於資源和時間，所以需要綜觀全域性制定一個合理的流程。

       1、任務評審

　　緊急任務發起人員組織研發、測試、版本等相關人員進行評審：

　　任務發起人說明此次任務的背景，預期目標；

　　開發人員闡述修改方案，影響範圍；

　　測試負責人根據評審的情況可以判斷出這個任務是屬於緊急重要還是緊急非重要的任務，以例採取合適的測試策；

　　相關模組的測試專家根據評審內容，評估大概的測試要點。

       2、工作量評估

　　測試負責人或者測試專家根據評審內容來評估任務的測試難度，並且根據以往的測試經驗來估算出當前的測試功能點數需要多久時間才能測試完成。

　　拿我們專案組來舉例：

　　大概可能涉及到X個場景，涉及Y個測試省份，最後評估出最樂觀的測試時長A：X*Y*0.5天，最悲觀的測試時長為X*Y*1.5天；最可能時長為:X*Y*0.8; 所以按照三點估演算法最可能測試時長為(X*Y*0.87)/50 (天)。

　　對於一些特別簡單的或者比較特殊的情況，可以根據實際情況來進行調整。

        3、工作分工

　　測試負責人要根據目前測試人員剩餘資源情況來進行分工。

　　首先要了解當前大家手上的需求和進度，評估當前可額外支撐的任務數，按照測試任務的輕重緩急，盡最大努力完成測試任務。

　　在時間不足的情況下，我們應該對測試任務按照優先順序來劃分，重要緊急的任務先完成，且對於每個任務，優先測試主要功能，次要功能優先順序放低，優先測試的功能需要與產品開發確認。

　　緊急重要和緊急非重要任務可以採取8:2時間投入，具體可以參考下面的測試策略。

      （1）80%投入緊急重要的任務

　　如果是緊急重要的任務，從目前可以額外支撐的任務的測試人員裡面選擇對該模組相對最熟悉的人員來測試。

　　前面我們講到一個模組都有AB角，所以至少會有兩個人對這個任務比較熟悉，原則上如果管理得當的話，是可以抽出一個人來進行此類緊急重要的任務來進行測試，如果由於特殊情況沒有一人可以分身，則可以考慮把熟悉該模組的人手中的相對不重要且不緊急的任務分給其他人員來幫忙，從而騰出時間來進行緊急任務的測試。

　　或者由較熟悉的同學帶著不熟悉的同學測，關鍵的地方把控下即可。

      （2）20%時間投入緊急非重要的任務

　　對於緊急非重要的任務，則分兩種情況：

　　如果測試資源足夠，則按照正常的分工進行即可。

　　如果測試資源不足，則可以根據測試任務的簡單複雜程度來區分，測試人員評估後場景較簡單，且開發自測和測試人員驗收場景基本上無區別外，則可以考慮直接開發自測而無需再流轉到測試人員。

　　如果評估後仍然需要有測試人員跟進，則可以考慮增加外援，比如自動化測試人員、需求方、使用者，或者是透過版本灰度方式等來進行。

     （3）巧用工具

　　如果公司完備的CI/CD流程，有較完善的敏捷開發流程，那基本上處理緊急任務就非常的輕鬆了，透過自動化測試加上版本的灰度等功能可以實現在風險最低的情況下來保障質量。

　　當然大多數公司的CI/CD還未達到理想的情況，但是一般都會具備最核心功能的自動化測試，這個時候，如果緊急任務涉及的面較廣，則可以採用自動化+手工的方式來聯合進行測試。

　　另外，還可以採用灰度發版的方式，一部分使用者直接線上上進行試用和驗收，無問題後直接拉齊全部使用者。

        4、如有困難，及時向上反饋

　　如果在這個過程中有任務的困難自己無法推動解決，請一定及時的向上反饋。

總結

　　確定緊急和重要的邊界，對緊急重要的任務優先關注，對緊急非重要的任務可以申請援助，投入度可參照8:2。

　　測試負責人要從管理和流程方面制定合適的測試策略來應對緊急測試流程。

　　測試任務緊急來不及寫用例的情況下，一定要列測試點並進行review，避免無序測試、思路混亂、丟三落四。

　　如果只有一個測試環境，則需要確認當前的緊急任務部署會不會影響到正常排期的任務，如果影響的任務較多，則建議走灰度進行測試。

　　緊急任務上線前回歸測試建議採用自動化，如果任務過程中有突發情況第一時間丟擲問題。

       最後：

       可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

       這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！