目錄
個人理解
測試經理大多數不實實在在執行測試，主要精力放在溝通、協調、團隊建設等方面，而其目標則需要建立一支強大的測試團隊
譯文內容
摘要
測試經理必須每天使用各種專業和人際交往能力，在多個方面進行測試。 面對所有這些職業方面，可能存在很多不同的領域。 這是測試經理通常會定期聽到的最常見（也是最煩人）的事情，以及一些如何處理它們的策略。
正文
測試經理必須在多個方面執行工作，每天使用不同的專業和人際交往技能。 他們必須給出準確的測試評估； 充分了解正在開發的功能和要求； 確定測試範圍； 應用適當的測試指標； 計劃，部署和管理測試工作； 甚至激勵和鼓勵測試人員，即使經理不是他們的團隊負責人。
面對所有這些職業方面，可能存在很多不同的領域。 這是我作爲測試經理聽到的最常見（也是最煩人）的事情，以及我爲如何處理這些問題而制定的策略。
僅僅測試主要的功能
問題：在更改了一小段但很重要的代碼之後，測試人員被要求測試“只是主要功能，爲了安全起見。” 此請求通常與可以理解的時間和精力限制相關，但仍然令人討厭。
解決方案：與負責此功能的開發人員一起分析更改通常會有所幫助。 我使用白盒技術，並根據這些結果和現有的迴歸測試用例構建測試套件。 良好的Pareto分析可以確定80％的時間使用了20％的應用程序，這也可以提供幫助。
指定必要的測試限制，就項目範圍和可能的後果與項目涉衆達成一致。 我經常爲此使用風險評估矩陣，並且在線上有相當不錯的模板。
從舊版本遷移到新版本
問題：每個公司都有一個很好的舊模塊或函數運行在已不再受支持的過時框架中。 必須在一個新的（可能是花哨的）框架中重寫它，但是它應該像以前一樣工作。
解決方案：從給定功能的深刻而徹底的映射開始，如果可能的話，與最初開發該功能的人員進行交談。 我一直嘗試與開發人員在實施本身上緊密合作。 重寫也是利用一些重新設計的好機會，不推薦使用未使用的數據表或UI元素。
它在本地是正常的
問題：發現嚴重的，可能是阻塞性的錯誤之後，您會從開發人員那裏獲得藉口：“但是它正在本地開發。”
解決方案：對錯誤進行非常精確的描述，然後讓開發人員進行處理。 不要陷入相互依賴的陷阱。 從長遠來看，在將要測試的項目交給質量檢查部門之前，嘗試強調需要進行單元測試。
一個月內準備好新的測試團隊
問題：儘管您沒有經驗豐富的測試人員，但管理層仍要求您迅速組建測試團隊進行新項目，並且他們希望所有人都瞭解產品的所有知識（儘管沒有可用的培訓）。
解決方案：花時間與管理層描述當前的勞動力市場。 同時，嘗試通過結合使用新廣告，社交媒體和教學實習生來尋找新同事時發揮創造力。 推薦程序也非常有用。 像Google這樣的大公司使用它們作爲尋找新同事的第一個策略並非偶然。
測試環境將是完美的
問題：儘管測試環境應該是生產環境的完美複製品，但是如果經常不能滿足需求的話。 對於數據庫和第三方工具，我已經經歷過這種情況。 爲他們設置質量檢查環境可能會很昂貴，並且需要大量管理。
解決方案：我發現絕對有必要對兩種環境之間的差異進行全面映射，併爲每種差異帶來風險。 我向我的團隊介紹了一個由我自己命名的“塞格迪法則”的概念：如果兩種環境之間存在n個差異，那麼測試結果中將有2n個問題。 這意味着即使大部分差異是錯誤警報，您也應分配大量時間進行調試。
無需測試管理工具
問題是：資助項目的利益相關者認爲沒有必要使用真正的測試管理工具。
在2017-18年度ISTQB報告中，測試指標和測試工作量估算僅對23.5％的被調查公司很重要，但其中62.5％的公司使用某種測試管理工具！ 我沒有其他經歷 除了阻止錯誤外，管理人員對其他測試報告並不十分感興趣，無論我花了多少個小時來製作報告。 而且，由於我們沒有使用任何專業的測試管理工具，因此我不得不手動製作它們。
解決方案：將購買這樣的工具與新的重大項目的開始聯繫起來，如果可能的話，強調使用案例的好處。 這樣獲得資源將容易得多。
我沒有時間閱讀測試報告
問題：在動手或其他會議上，您意識到利益相關者根本沒有瀏覽測試報告。 如果您花費大量時間進行準備，那就更煩人了。 責怪他們沒有用-他們每天只會獲得太多信息！
解決方案：假設利益相關者不閱讀您的報告，並準備會議，並在註釋中突出顯示最重要的問題和指標。
這些要求太複雜了
問題：需求過於複雜，無法檢查和驗證。 新功能應與舊功能良好配合，最先進的解決方案應涵蓋所有底座和角落情況，依此類推。
解決方案：在這些情況下，我切換到我的業務分析師身份，並通過良好的舊實地工作繪圖圖以及從開發人員，其他業務分析師和架構師那裏收集信息來映射新功能。
只需自動化所有測試用例
問題：由於一些關於測試自動化的好處的文章寫得很爛，利益相關者認爲自動化將解決所有問題並找到代碼中的所有錯誤。
解決方案：教育是這裏唯一的解決方案。 告訴利益相關者需要多少工作來維護自動化測試，評估結果以及爲新功能開發新工具。