大家好，今天想分享幾個工作中遇到的問題，而這些問題又暴露出很多新的問題，讓我們一起想辦法解決吧。

因為我做過兩年的測試，所以即便轉崗後，對測試相關的事項也會經常關注，同時因為測試的工作經驗為我後續的工作提供了很多幫助，而且我所在的團隊，測試人員的價值也是遠超功能測試本身，所以當遇到下面這個問題時，會有很多話想說。

今天文章較長，但都是實戰總結，請各位耐心閱讀。

01 一些常見的問題

第一類：

前段時間和一個做測試的朋友聊天，他向我吐槽測試這個崗位的尷尬境地，比如在團隊內部話語權缺失，經常被開發“嫌棄”，提出的bug開發時常不願意改，甚至背後被吐槽等，這些可能在測試工作中常見的問題。然後問我可不可以轉崗需求或產品，轉崗之後會不會好一些。

第二類：

在專案中遇到的一些所謂“小錯誤”：

開發在上線過程中經常準備不充分，遺漏上線包；

缺少資料庫更新欄位，配置檔案 還是在用測試地址；

測試時加的“擋板”沒有撤掉就投產；

投產驗證準備工作不足，驗證環境層層受阻等問題。

這些問題相信很多專案組或多或少都會遇到，原本2小時能完成的上線任務，愣是搞到後半夜。

這些問題在表象上可能都是一些細節問題，或者態度問題，就像我們上學時習慣說的“我馬虎了，沒仔細檢查”。當年我也是這樣安慰自己。

但現在來看，每一個小問題的背後都反映出團隊管理、流程制度、工作意識或工作態度等方面的問題。

如果要解決這些問題，只針對表象處理，不僅無法根治，還可能會暴露出其他的更嚴重的問題。所謂“治標不治本”，“揚湯止沸，不如釜底抽薪”。

02 我的解法和想法

比如第一個測試話語權和認可度的問題，我當時的回覆如下：

之後我在想，如果這件事發生在自己的團隊要如何解決？大致有如下幾個思路：

1. 端正態度、提升意識

專案負責人首先要有質量意識，如果一個團隊自上都不注重測試與質量，那後面的結果一定是慘不忍睹。

同時專案負責人要提高團隊每個人的質量意識，透過宣導、舉例等客觀的方式闡述交付質量的重要性，順理成章的提升大家對測試工作的支援。這裡我強調的是質量的重要性，而不是測試的重要性。因為質量很重要，所以我們需要測試人員協助我們達成高目標。這個因果關係是需要注意的。

因為對於很多開發人員來說，可能對測試就是不重視，我們直接樹立測試重要的理念，對方也許會不認可。但是質量的重要性相信每一位從業者都會認可，只是在日復一日的工作中逐漸遺忘罷了。

2. 測試人員本身能力的提升

如果要解決上述問題，測試人員本身的能力提升一定是基礎，否則其他方式都會適得其反。

關於如何提升測試人員的綜合能力，展開說會有很多方式方法，在此僅羅列幾個關鍵點。相信大家都有自己的見解，希望我們能互通有無，共同探討。還可以檢視之前的一篇文章《如何提升測試階段的工作效率》

端正自己的態度，設立更高的目標。

我看到很多測試人員竟然只把自己定位為“點點點”，沒有更進一步的要求，無論從工作、團隊還是職業發展上都是不可取的。無論在哪個團隊、團隊是否有問題，首先要做的是我們自己不能放棄進步；

提升溝通能力，講究溝通方法和技巧。

去年我和一位測試同事專門分享了關於“測試與開發和諧相處”的技巧，後續我會整理出來。其實很多情緒的爆發都是源於溝通及態度，所以技巧很重要；

提升自身業務能力。

尤其是功能測試人員，對業務的理解能夠在設計階段為開發提供支援，在測試階段對交付質量提供更合理的建議與保障。如果能夠兼顧需求、或者協助需求，那證明業務能力已經獲得團隊的認可；

學會權衡和“抓大放小”。

其實這一點有些偏向於溝通技巧，但是因為比較重要所以單獨列出來。重要問題、原則問題要據理力爭，但是有些不重要的，或者可以妥協的也要適度妥協，給足對方面子，照顧對方情緒；

對技術和軟體工程有基礎的瞭解。

這樣在平日的工作中才能夠和開發平等溝通，不容易被開發踢皮球或者“忽悠”，而且能夠協助自身準確定位問題；

提bug要全面、有理有據。

如果能給出合理的修改建議或修改過程中需要注意的關聯功能，那開發一定會另眼相待；

對專案現狀足夠了解，對業務的處理邏輯足夠了解。

因為功能測試中大部分的缺陷都是業務理解不透徹、邏輯處理不嚴謹引起的。有時提出一個很難被發現的bug也會引得大家豎大拇指。

其他的一些工作之外、工作之餘的磨合、溝通。

其實大部分開發人員都是很單純的，所以有情緒就會表現出來，表現出來的情緒反而要比積壓的情緒更容易解決，關鍵在於我們是否願意多花心思來解決這些問題，從而讓自己的工作更順心呢？

3. 協作時細節隱患的及時處理

專案負責人要細心、留心，比如當發現開發與測試針對工作有情緒時，及時糾偏或打圓場。或者作為支持者一起進行問題討論與分析，對事不對人，客觀解決問題。

之後如果雙方仍有情緒，還需要單獨疏導。其實很多問題都是日積月累的，當我們在萌芽階段就能注意並解決時，不僅團隊會更加穩定，大家協同的效率也會更高。

尤其是當聽到開發吐槽測試，或測試吐槽開發時，不要做和事佬，一定要重視這些細節性問題，客觀及時解決。

因為大多數人說出來5分不滿，可能內心會有10分不滿。千萬不要因為聽到5分不滿，自認為只有3分不滿，從而為後期留下隱患。

4. 先入為主的小技巧

尋找一些團隊內部的小契機，讓測試人員“冒頭”（此技巧同樣適用於其他有類似訴求的崗位）。

比如新員工來了，可以安排測試人員為其講解業務，或介紹團隊、現狀等等。我相信這會是一個很有效的辦法，讓測試在新員工（尤其是開發人員）這裡有更好的印象。而且後續的一些疑問都會向測試人員請教，那之後再溝通缺陷時，就會更加容易認同。

基於這個角度，可以再看看團隊中還有哪些可以提供的機會，讓他們逐漸承接下來。

5. 管理流程及制度上的加強

比如加強測試用例評審過程，在評審用例時需要對應模組的開發人員一同參加，這樣開發會知道自己要做的功能需要考慮哪些異常情況，在提升開發質量的同時，也能對測試人員思維的全面性產生認可。

比如測試人員參與設計評審，在設計評審過程中，針對功能的實現邏輯，測試人員也可以在會上提出自己的想法。在前期針對一些可能產生分歧的內容達成一致，從而減少後續的爭執。

尤其測試人員作為對系統現狀最瞭解的人，在更新迭代過程中的很多建議，或者風險預知都是非常重要的，當我們能為開發或其他崗位提供幫助時，認可度自然會提升。

所以我們可以發現，雖然是解決測試的問題，但只有第二條和測試人員自身相關，其他的方法都需要領導、團隊、制度來配合。

這就是我想表達的方法2為治標，方法1-5為治本。

同理其他類似的問題也可以採用這些方式解決。

當然，現在的測試領域，很多測試人員尤其是功能測試人員在能力上確實有差距，尤其是很多半路轉行的人，選擇測試是因為門檻低，工作過程中也沒有確立持續進階的目標，因此無法真正為團隊賦予更多的價值，也使得大家對測試產生很多無謂的認知。這些現實情況確實讓人無力。

最後，我把這件事分享給了一位很有經驗的專案經理，他的回覆如下：

其實測試本是非常重要的崗位與角色，或者說每一個崗位都是非常重要的，做好了還能在其他層面發光發熱。所謂“XX崗不重要”之類的行業現狀也在逐漸糾正，過程很漫長，不僅需要領導層提高意識、建立規範，

更需要每位人員找到更好的進階方法，付出更多的努力，同時主動尋求解決而不是被動或等待、或抱怨，相信堅持的力量，逐漸展現崗位及自身的價值，

才能讓大家更加堅定，更加認可。

關於第二類問題，所有的現象都指向了

管理制度不規範，人員風險意識不夠強，負責人對制度規範的執行力不足。

其實會有很多人沒有真正重視這些，尤其是在工作壓力較大，加班較頻繁的時候，大家都在忙著工作、忙著解決突發性問題，沒有重視和推進相關管理規範的執行。最終造成我們後期會花費更多的精力來解決前期產生的隱患，從而形成惡性迴圈。

“緊急性的暴政”引發了優先權稀釋綜合症，優先權稀釋導致我們忽略了重要不緊急的事情。

——《時間管理的奇蹟》

我們正是這種總在處理緊急的事情，而忽略了重要的事情。

因為我本身專案管理經驗並不豐富，很多經驗也是在專案組和平時的交流覆盤中總結的，所以不展開討論，以免顯得“教條化、理論化”。

但是我始終堅信，忙不能成為持續不做改進的藉口，我們切勿變成“長期救火隊員”。每次總結大家都在說流程不規範，要加強各類評審、設計、風險排查、制度等等，但是真正到了執行層面，又有多少人能真正堅持呢？

比如：大家都知道設計評審很重要，設計完成評審透過再進行開發，但是真的專案進度很緊張時，還有人認真做設計、評設計嗎？其實回頭來看，很多後期的缺陷、風險又消耗了團隊10分的精力，我們提前拿出3分來時間提前設計好，真的不可以嗎？

像程式碼評審、走查可能需要花費較多的時間，但是我們在解決bug時，或者排查一些疑難雜症時，順手把對應的重點內容走查一遍是否可行呢？做一點、總比不做有效果吧。

而且這些評審不一定是要組織會議，佔用大家的時間來進行。現在遠端協同越來越規範，我們透過協作文件做好登記與同步，相關人員根據自己的時間進行安排，也是一種可嘗試的方法，只不過對負責人的跟蹤、執行能力又是一個新的考驗。

團隊內其他人員風險意識不夠強，是否也需要採取一定措施來提高呢？負責人沒有精力跟進的事項，是否可以從中選出可培養的人，藉此機會給予鍛鍊呢？同理作為想要更進一步、快速成長的小夥伴，是否可以主動請纓承擔更多的責任呢？一個擁有良好戰鬥力的團隊，一定是大家相互認同、相互扶持，目標一致又充滿能量。

03 還有很多其他常見的問題

工作交接不清楚，尤其是連續交接的情況（張三交接給李四，李四剛接手又交接給王五），沒有規範的產出，資訊同步不及時、不完整；

文件編寫不規範。這裡的文件泛指專案管理過程中各個階段的文件，尤其是非需求階段，由技術人員編寫的文件，從格式到內容再到排版、用詞，無法體現團隊的專業性；

諸如此類的問題，

單獨來看都是小問題，但聯合起來就是大問題，同時反映出管理上更大的問題。

04 寫在最後

理想很豐滿，現實很骨感，在我們解決這些問題時，雖然能想出很多方法，但在執行過程中勢必會困難重重，還極有可能被一些“不可抗因素”耽誤或者擱置。但是不能將這些問題視而不見不去著手處理，因為一旦此刻躺平，那後面等待你的可能會是暴風驟雨。

願我們每個人都有精力、有能力、有意願做一個

更優制度的創造者；

做一個更細心、更耐心、

更有恆心的執行者

；

做一個更平和、更溫婉、

更有決心的協作者

。

ps：後續將單獨整理產品工作中常見的問題及應對方式，比如優先順序排期總被變化、研發資源無法傾斜、交付週期緊張、功能設計不全面等等，敬請關注。

作者：不想延期了，公眾號：“不想延期了”

本文由 @不想延期了 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議。