最近在測試某個項目，測試用例評審以及整個測試周期中，該項目的研發負責人有事不在，不過也不影響，因為項目代碼反正也不是負責人寫的。昨天測試完成了，今天研發負責人回來了，然后準備上線。
上線前他跑過來找我，說有一個重大功能不能用。我也很震驚，所以看他演示了一遍之后，著手查這個問題。
印象中這個功能是可以用的，雖然具體測試工作由我的另一位同事完成，但是我也是過了一遍的。為什么今天突然壞了呢？第一時間想到是不是開發動過什么東西，所以先通知開發去查一下，自己也同時查問題。
突然間我意識到，這個功能，研發負責人剛才演示說不能用的時候，用的是admin賬號。我們都知道，系統中admin賬號是比較特殊的，所以有些時候要和普通用戶區別對待。也正是因為這個原因，普通用戶用起來正常的一個功能，admin賬號會有一些差異，而這個差異在某些情況下的表現就是，某個重要功能不能用。
于是我和測試這個模塊的同事確認了一下，他表示當初也提出了這個問題給開發，得到的口頭解釋是，根據xxx邏輯，這是正常的。當然從這個角度解釋也是通順的。同時他考慮到admin賬號，普通用戶不會使用，表示接受這種解釋。于是并沒有提bug。
我便和研發負責人說了這個事情，他想了一下，說，雖然解釋的通，但是這樣卻導致admin在很多情況下無法正常使用這個功能，也是不合理的。所以本期就這樣上線，提醒一下使用admin賬號的人，目前存在的問題。之后提一個需求，下期徹底解決這個問題。
虛驚一場，本來以為是自己的測試工作不到位，會影響上線。但是這也反映了很多問題，值得深思。
研發負責人表示，測試用例評審的時候，為什么沒有人提出這個問題？仔細想想，如果深入思考了，是可以提出這個疑問的。從我的角度，為什么我沒想到，可能有以下幾點：
a. 負責具體開發的人員一再表示這期功能簡單，所以我們也沒有太花時間去細思考。
b. 我們就直覺認為admin賬號只是用來管理一下用戶，主要功能還是用普通用戶賬號來執行，所以并沒有過多的考慮，本期需求更改后，admin賬號在執行主要功能方面，是否有問題。
c. 同時并行三個項目，這個項目是最簡單的，所以主觀上也降低了對他的關注度。負責具體測試該模塊的同事提出了這個疑問，卻沒有在那個時候得到把關，這方面我也有責任。
首先，對于任何疑問，都應該有一個確定的書面的回答。這次他只是得到并非研發負責人的口頭答復，并不正式，覺得解釋的通就放過了。
第二，對于暫時無法得到有話語權的人的回復的疑問，都應該提bug來跟蹤，有記錄。比如這次其實是需求未澄清的問題，研發負責人不在，并不能說明我們達成了一致，就應該書面記錄跟蹤。
以上兩點，我并未和這位同事說清楚，讓他去做記錄，我的責任。回歸測試自己沒有特別留意。本來測試完成之后，唯恐遺漏，我是整體又看過一遍的。看到這里的時候，只是簡單的想到了同事之前所說的解釋，就放過了，沒有再去做確認或者記錄。
那么對以后的工作有什么啟發呢？
首先，用例評審的時候，要多思考，及時澄清需求。
第二，任何問題盡量在jira做記錄，溝通結果不能只是口頭，一定要有文字記錄，不管是郵件還是企業微信聊天，否則對方不承認或者忘記，導致自己背鍋。
第三，和同事傳達清楚上面兩層意思，并在以后的工作中，對他的工作及時做監督和檢查，避免疏漏。
PS：
這次和研發負責人溝通，還發現一個在需求中并未提到的點：某個表示狀態的標志（完全看不出來能點）是可以點擊的，點進去里面還有內容展示。目前這里展示的內容有缺失，但不是什么大問題。
因為需求沒說，所以測試過程中完全忽略了這塊展示的內容，以后要留意這類問題，多思考，包括需求沒有的地方也要多提問。
順帶繼續記錄一下，這個項目前期遇到的和需求相關的坑。
這個項目中有個功能是做配置。就是key-value這樣的配置，然后會根據界面key-value的設置，同步轉換成yaml、properties格式。
講需求的時候并沒有特別說明這里可能的配置數據將會是怎樣的，當然我也有責任，也沒有特別問明白這個配置用于哪里，考慮到是對內項目所以也沒有對字符串的長度特別做驗證，心想正常來說key和value都不會太長。 于是測試的時候就是用簡單的數據進行了測試，并且測試通過。
后來發現問題如下：
- 配置項非常多，同時key、value值超級長的時候，頁面展示會有問題。
- 配置項中出現特殊字符串組合的時候，切換到yaml、properties格式，編輯會出問題。
這個問題主要是對需求中的數據定義不夠明確。雙方都有責任。
