測試關鍵風險指的是在測試活動中發生的對測試程序和測試結果又重大影響的阻礙性問題和突發事件。
這一輪的轉測試版本，有新的測試需求。需要所有的測試員都學會搭建乙個比較複雜的測試工具。而且這個步驟是整輪測試的關鍵點。如果沒有正確配置，整個測試程序都會停滯。
在配置方式完全正確的情況下，配置好此工具的時間需要2-3個小時。然而目前要驗證工具是否配置正確的唯一方式就是執行基礎測試用例，此用例執行完成下來需要花費1-2個小時。也就是說一次的配置不正確，花費的代價就是4到5個小時。一天的工作時間包括加班也就10個小時。如果兩次都出現錯誤，一整天的時間就浪費了。而且此工具的配置還因為測試場景不同配置方式也有部分差異，所以每個測試員所需要面對的問題都會不一樣。
目前手頭上有的資源就是乙份配置說明（不包含每個場景的細節配置），乙個有過成功配置經驗的老員工。下班後測試經理組織培訓，叫乙個有此工具配置經驗的老員工給大家講解配置步驟，要求大家必須在2天內都能上手。測試員培訓完以後發現這個任務存在很大的風險，並且不可控。整個的轉測試時間只有6個工作日，按照正常的版本測試週期，5天再加上每天加班3個小時，基本可以按時完成任務，突然冒出這麼個複雜的東西，根本無法完成任務。因為多個場景可以同時配置，有測試員提議：找專人來負責。測試經理答曰：「找你你願意幹嘛？要是找我，我肯定不幹，我付不起責任。」
碰見這問題，測試經理關注的是不可控風險對整個測試進度和測試質量的影響，測試員關注的則是對自己任務進度的影響，延時以後可能會有更多的加班，原本有10個功能點要驗證，應為趕進度只驗證了9個，發生漏測！
測試經理站在全域性角度可以要求測試員必須在2天之內學會配置，但是真的在2天之內所有測試員都能學會嗎？在轉測試之前，測試經理和tse沒有對新的測試需求進行詳細分析，沒有評估新的測試需求包含的風險，沒有詳細的了解員工對新測試需求的理解和掌握程度，沒有參考測試員對技能的掌握來設定任務時間。
個人認為，在以後的轉測試之前，測試經理一定要詳細的分析每一項新的測試需求，及時的將新需求達到每個測試員，務必要詳盡的羅列此齣存在的風險項，結合測試員對新需求的掌握和理解程度來確定風險的大小，再根據風險的可控性來適當的延長測試時間，並且及時的對薄弱環節進行加強培訓。當風險發生以後要及時的做出評估和分析，分析風險發生的原因找出解決方案，評估風險對測試進度和質量的影響，結合實際情況確認是否需要調整測試方案。
風險發生後，測試員需要積極的面對，參與分析給出自己的意見，不能推卸責任。測試經理不能盲目的施加壓力，測試員壓力的大小也會直接影響到測試質量。還有一點，作為乙個測試經理，必須要擔負起責任，對於風險，測試員有責任，但更大的責任在於測試經理，是你沒有事先沒有充分分析，才導致風險發生。你付不起責任誰負責任？大家共同的在做同一件事情，測試經理在帶頭，大家走錯路了，最大的責任肯定在測試經理。大家團結一條心才能順利的度過各種難關，達到零漏測的目標。
如何應對不明需求做好測試
在日常需求的 測試過程中，因為時間和資源的相對緊張，往往會遇到prd不夠細緻，而uc描述也過於簡單的情況，這個時候會讓經驗不夠豐富的 測試人員有種無從入手的感覺。其實由於思考方式 對 需求的理解程度 開發和編寫uc的經驗 以及文字描述的習慣不同，開發人員首次提交的uc，並不一定能立即指導 測試人員 ...
如何應對沒有需求的測試
軟體測試 時候發現根本沒有需求，一問開發和需求，發現原來是我們的專案經理口口相傳，告訴開發要怎麼怎麼做。可想而之，這個過程是沒有設計的，開發過程當中遇到問題，就會問，專案經理即時馬上給出答覆。而到了測試，測試人員在完全不了解狀況的時候，在介面上點了點，也不知道要點多少東西，反正一會告訴我說版本測試完...
風險管理計畫中的BUG應對方案
bug就像軟體的影子一樣，其生命週期和軟體的生命週期同步持續進行。產品是想bug的，研發是寫bug的，測試是找bug的。在軟體開發這場戰役中，幾乎所有的專案人員都在不停的與bug做鬥爭，直到被打敗。在風險管理中，軟體產品的風險被認為是不可避免的，只能設定相對完全的應對方案來降低風險度。就是說，bug...