原文出處：https://www.stickyminds.com/article/problem-solving-software-testing-conversation
前言： 你經歷過多少次從開始解決一個特殊問題，過程中才發現實際的問題並不是你所想的呢？Ajay Balamurugads敘述了自己與一個同事關於在軟件測試中的測試用例問題以及他從問題解決過程中學到的經驗。現在來看看你應該考慮的方面吧。
我朋友打電話給我說他在工作中遇到的情況。他曾經是這個項目唯一的測試人員，他描述當他得到一個想法時是怎樣寫下測試用例的。隨着團隊逐漸增大，項目增加更多的功能特性，測試用例的數量猛增到上千。
隨着用例的增多，用例的細節部分不會給予太多關注，因爲每個人都理解測試用例的意思，所以要求及時關注用例細節變得不是那麼重要。
然而隨着自動化用例的計劃開始後，很多問題就浮出水面。自動化工程師不理解用例因爲用例裏面沒有太多細節。用於寫用例的工具不支持大量的導入，用例組件有很多冗餘的用例。最後的問題來自於管理層人員，他想知道是什麼阻礙了測試用例的自動化。我朋友問我是否知道解決他所有問題的工具。
我在電話裏抑制住我的衝動打斷他，這時我就問了他一個問題“你們現在試圖想解決什麼問題呢？”
他又開始提工具。這時我打斷並問他，自動化工程師使用現有的腳本是待解決的問題嗎? 他很肯定的回答而且想加一些細節到已有的測試用例中。
從第一個問題開始，我們討論自動化工程師關心的事應該怎樣合理解決。我們可能先給他們一部分有充足信息的測試用例，而不需要等所有用例都補充完詳細信息後再給他們。我們先解決一小部分，看看有沒有新的問題出現，把這種方法看成是一種練習。
下一個問題就是丟失細節的完整測試集。我告訴他列檢查點和思維導圖可以替代測試用例。 我們也考慮過如果人們抱怨信息的缺失，我的朋友可以告訴他們通過保持用例的簡潔可以節省多長時間，這些時間可以很好的利用在於探索和了解產品上。
如果他的團隊中有人擔心一些測試點會測不到， 我說他們應該花一些精力培訓測試人員而不是把這些精力花在龐大的測試用例上。除非你環境需求需要帶有數據的詳細用例，否則列檢查點和思維導圖是一個很好的替代，因爲他們很容易審查和更新。
這時候我們創建了兩個問題：自動化工程師需要詳細的測試用例以及上千的測試用例需要維護。我們決定當自動化工程師正在處理腳本是，我朋友團隊就可以花時間講測試用例轉化成思維導圖或者測試清單。 這通電話從一我朋友想找一個工具來解決問題開始，到我們意識一個工具是沒有必要而結束。
你經歷過多少次從開始想解決一個特殊問題到中途才意識到實際問題不是你所想的那個？當我在等待我朋友嘗試使用我們所討論的策略時，我開始思考我們的討論。下面是一些我總結的重點：
問題是相對的
當談到軟件測試時，bug不是絕對的；它是產品和某些人之間的關係。同樣地，一個問題也是一種場景和一個人之間的某種關係。如果你改變這個人的期望或環境，原來的問題可能就消失了。
問題和解決方法不是永久的
當我朋友的測試團隊很小時，測試用例是相當靈活的，她不是一個問題。當自動化工程師加入進來後同樣的測試用例就成了一個問題。解決一個問題的方案可能會造成另一個問題。這時你可以決定哪個問題是可管理的。
考慮成本，價值，風險
當我們思考解決一個問題的可能方案時，問問自己：
- 這個活動的成本是什麼？
- 執行這個活動有什麼價值？
- 不執行這個活動會有什麼風險？
在你開始花大量時間，金錢或者精力時，做一個小嚐試去測試一下你的理論是否可行。
不是所有工具都能解決問題
只要你遇到一個問題，很多人都會想到用工具座位一種解決方案，但是有些時候，短期內工具能解決一些問題，但未來可能會帶來更多問題。在選擇一個工具時徹底想清楚它有哪些風險。
如果你在嘗試解決一個問題時卡住了，找一些不在當前這個環境中的人去獲取不同觀點，是很有幫助的。觀點差異不可能保證都是好的，但是它可以幫助你想到一些你以前從沒有想到過的點。