成為測試主管第一步4

第第頁成為測試主管第一步[4]成為測試主管第一步[4]

發(fā)表于：2023-06-02來源：：點擊數(shù)：標簽：主管

成為測試主管第一步[4]軟件測試◆從我對測試主管工作的記事以來，就在印象中保留了這樣的一幕。記的剛進一家公司時，我團隊中的人員就開始經常會有下屬跟我說抱怨，公司的需求工程師讓我們太失望了。需求如何如何不好，然而，多少有些經驗的我，當時我

成為測試主管第一步[4]軟件測試

◆從我對測試主管工作的記事以來，就在印象中保留了這樣的一幕。記的剛進一家公司時，我團隊中的人員就開始經常會有下屬跟我說抱怨，公司的需求工程師讓我們太失望了。需求如何如何不好，然而，多少有些經驗的我，當時我是把幾家國內我服務過的頂尖公司情況作了一個簡單的對比，的需求跟公司的需求人員的需求做了比較這時才發(fā)現(xiàn)，發(fā)現(xiàn)，原來我們公司的需求人員還是做的得不錯的，。讓測試人員把心態(tài)調整過來是測試主管的另外一件事。試問，，如果是你做需求作為需求工程師，是否會比他們做的好嗎得更好??有了這樣的基調，就可以讓然后建議測試人員去總結不清楚的地方，給需求人員一個相對比較具體和明確的意見，這樣順利的了解了需求。

◆其實有時候不是流程不對流程在這其中并沒有太多值得指責的地方，而是相互的理解與支持,換位思考而對流程的執(zhí)行態(tài)度，卻是更加關鍵的。我們不得不學會如何換位思考，并更多地從他人的角度來看待這些問題。

◆同樣的問題還出現(xiàn)在還有需求變更上，很多測試人過不了這一關，?？偸撬麄冎肛熝邪l(fā)人員，讓研發(fā)那些本來就已經惱火的軟件工程師更加火冒三丈。換位思考一番，其實不難了解，，其實需求變更對研發(fā)工程師來說是更大的麻煩，。他們需要修改設計，、代碼，相較而測試只要需改測試用例，他們的工作確實更加麻煩。簡單來說，就ok了，其實大家要分析什么樣的需求變更最可怕，而不是眉毛胡子一把抓,其實測試對需求變更并不可怕，怕的是只有在提交時才發(fā)現(xiàn)，導致測試時間不夠，才會真正讓測試人員心慌。這時需要從研發(fā)流程上保證變更及時的通知到測試就可以了行，。也許有人會說你也需要說：，說的倒很容易，如果研發(fā)不按照你的要求做怎么辦!其實這里你只要用我所采用的方法是用數(shù)據(jù)說話，在項目進行時統(tǒng)計發(fā)生過多少次這樣的事情，讓研發(fā)管理層知道，讓項目組之間有一個比較，。一方面，如果是一家公司重視質量的公司，必然會引起重視;另一方面，從質量管理部門角度本身出發(fā)，也應該推動公司重視質量。，隨著時間的增加，需求變更給測試人員的反饋一定會有下降的趨勢，。關鍵是測試不能抓住雞毛就一直揪著不放寬容一些來看待身邊的同事，要允許別人他們犯錯，對于解決問題本身來說會大有裨益。只要趨勢是好的就可以了。同時如果出現(xiàn)這樣的情況并且極大影響到了測試進度，則要與研發(fā)部門溝通清楚,，如果研發(fā)不認可的情況下還可以請上級進行評估一下。

◆上面說的是不同態(tài)度在同樣流程下的實現(xiàn)不同結果,下面主要講一下關于自身資源是否勝任做流程上規(guī)定的事情，某些工作，也許并不一定是測試部門的優(yōu)勢，而另外一些，則需要根據(jù)測試團隊的基本能力和資源進行評估。比如像性能測試、SQL的trace、自動化功能測試、單元測試集成、游戲性測試。其實這些流程上的關鍵點，可能大多數(shù)從功能測試上來一路走來的測試人員是無法做的到，這時要善于利用資源，不一定要測試做，可以從通過流程上保正有人來做積極調動其它部門的同事。，或是找有能力的人來做，測試可以進行監(jiān)控。其實這種技術含量高一點的測試，對人的因素要求更大高，可以借助研發(fā)團隊一起來做會有更好的效果，。記的第一次做Oracle數(shù)據(jù)庫性能監(jiān)控時，就是請的Oracle的DBA專家?guī)椭O計了性能參數(shù)，成功的地進行了關于Oracle應用的性能測試。現(xiàn)在國內的測試人員普遍的技術水平不高，嚴重的限制了測試的發(fā)展，希望測試的同行能真正的提升測試技術水平，把這些高難度的測試做起來，而不是僅僅只是工具上玩玩，。只有真正提升測試團隊的技術含量，這樣別人才會更信賴你，這也是我這么多年來的一點經驗。如果你對開發(fā)很精通，、同時又精通對測試頗有研究，、善于診斷性能與架構上的問題，、經常會