小螞蟻  
          風雨過后才見彩虹
          公告

          • —————————————
            李麗君
            軟件測試工作者
            廣東籍貫的海南人
            北京生活12年
            目前在深圳

            郵箱:
            llj2003hbdd@163.com
            —————————————
            說明:本Blog中的內容均為本人原創或轉載,本人依法保留Blog內原創文章的所有權利,如需轉載,請注明作者及出處。未經許可,不得將本Blog內文章用于任何盈利性用途。
            —————————————
          日歷
          <2010年6月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          導航

          常用鏈接

          留言簿(174)

          隨筆分類(189)

          0--感興趣的網站

          1--國內測試網站

          2--測試同行的blog

          3--開發好友的blog

          最新評論

           
           

          編寫背景:

          這兩天郵箱中有同行問我關于測試工具及需求變更相關的問題,這類問題聽過很多、有的自己曾經遇到過,心里有些感想、同時覺的有必要總結,在此進行記錄希望對大家有幫助。



          同行在來信中提到的問題現象是:

          問題現象1:測試完成后,出現需求變更(如:增加、修改、刪除),此時的測試該如何做(如:測試執行該如何做、測試文檔該如何寫)?

          問題現象2:開發人員和用戶直接交互,出現需求變更,開發修改后沒有經過QA測試,直接提交用戶,導致用戶發現很多bug,因此開發人員說測試組發現不了bug,要求引入自動化測試工具。

          問題現象3:開發人員理解的自動化測試工具,就是能夠自動發現BUG,并且能發現所有BUG的工具,讓測試人員引入這類的自動化測試工具;如何讓他們開發人員明白自動化測試工具的局限性,似乎不是一個簡單的問題。

          站在測試管理角度看上面的問題現象,我總結為三點問題:測試工作流程、測試工作技能、團隊協作溝通,現在一一對這些現象進行分析和探討。

          現象1和現象2都遇到了需求變更

          由于缺少需求變更處理流程,問題1的測試人員不知道該怎么辦;問題2的測試人員很冤枉的背負漏出去的bug,被開發強求引入自動化測試工具。

          老中醫的一個觀點我很認同:最終目標是要治本而不是治標;公司一位大牛的一句話我很認同:要用科學的態度看問題。

          當需求發生變更后,測試該怎么辦?我給的建議是:

          1)        需求變更,不光牽扯到的是測試、里面還有開發和后期負責維護的相關部門;需求變更時,需求負責部門(或產品部門)、開發部門、測試部門、技術支持維護部門之間要對這個情況進行溝通協調,通過一個合適的工作流程讓團隊之間的工作效率和質量能有效的得到保障和提升。

          2)        需求變更出現時,我認為測試能做的、應該做好的是:

          a)         測試管理者對待需求變更等同于測試一個版本的流程一樣,需要進行版本控制和資源協調;也要相應的對變更需求做分析(如:需求變更的影響范圍、緊急程度、資源能否相應、工期的影響和風險),制定相應計劃、評審相應測試用例;

          b)        測試人員需要根據變更的需求以及開發設計文檔,編寫用例、執行測試、測試日報。。。。。等等執行相應的測試工作流程。

          有的人會說,但現實情況是,有的團隊就沒有這么個變更處理流程、有的團隊有了這個流程會要求特殊情況給予特殊處理,測試能怎么辦

          1)        沒有變更處理流程的,需要各個相關部門的管理者給予重視并商討建立一個合適的,大家好才能是真的好!

          2)        有了流程,需要考慮特殊情況特殊處理:

          a)         例如:時間緊任務重,可否跳過QA?可以跳過QA,但QA不承擔這種情況出現的質量問題,由決策者來承擔。

          b)        例如:時間緊任務重,QA資源緊,但必須要QA測試,測試管理者要讓相關兄弟部門老大知道,在這樣的情況下,QA能保障的也是必須要保障的是主要業務和功能的測試,其它的無法保障,同時要讓相關兄弟部門做好這個任務的風險評估及應對配合工作。

          c)        在特殊情況下的測試任務,測試有權力說出自己當前的版本質量情況及是否上線的建議。

          現象2和現象3都遇到了團隊協作溝通的問題

          這是測試工作中最難、也是最累的;有過測試工作經驗的人都有體會,測試和開發配合的好壞直接影響工作的進度、質量和團隊發展。

          要想解決這個問題,最終取決于這整個團隊的管理者及整個團隊工作的氛圍。

          曾記得在某一本書上看到這么一個觀點:要想看一個公司管理者的能力、整個團隊的管理水平及氛圍;可以從問題角度去觀察。

          當出現問題時,整個團隊是互相推卸,還是積極反饋、查找原因和解決辦法;整個團隊是否愿意去發現和尋找工作中的問題,能否有正確的方法去面對問題;這就要求管理者在組建和管理一個團隊時,對團隊成員的要求;工作流程很重要,執行工作流程的人更重要。

          沒有做過測試工作的人,會不知道測試工作過程中的困難和難度;沒有做過開發工作的人,會不知道開發工作過程中的困難和難度;沒有做過管理工作的人,會不知道管理工作過程中的困難和難度;前不久有位同事說過:有些東西你沒有做過就你沒有發言權。

          當某些工作需要大家配合去完成時,只有足夠的尊重(學會換位思考、學會溝通)、責任心才會讓事情做起來比較順利。

          上面這些牽扯出另一個問題:工作技能,應該說是綜合技能

          做技術的,大家都知道,牛人通常不會推卸責任;牛人知道自己會哪些,不會哪些,不會瞎指揮;牛人會根據實際情況結合自身的經驗給予對方建議和幫助,而不是刁難和嘲笑;牛人會用你能接受的方式讓你知道自己在哪個地方出問題了。

          關于現象3中的自動化測試工具的局限性,如何讓開發明白,我給的建議如下:

          1)        讓一部分開發人員來干干測試的工作,讓他做過后,就會明白了;這個方法耗費的成本代價較大,屬于內耗

          2)        如果公司還有其它團隊,讓其它團隊測試工作有影響力的人給開發團隊管理者進行引導

          3)        收集數據,準備材料,用足夠的數據(自動化測試提升了XXXX測試執行工作效率;自動化發現的bug數據;手工測試發現的bug數據XXXX等等)來說服對方,當然在說服的過程中,要得到更上一層管理者的支持和理解。

          上面3點是治標不治本,最終還是要把工作流程整理順暢,要有個合適的人在合適的位置上選擇一堆合適的人,然后帶這堆合適的人一起做事。

          在我測試工作的7個年頭里,經過在不同公司和不同團隊配合做事后,讓我感觸最深的是:測試工作要做好很不容易。

          posted on 2010-06-24 20:54 lijun 閱讀(1182) 評論(0)  編輯  收藏 所屬分類: 軟件測試職場話題
           
          Copyright © lijun Powered by: 博客園 模板提供:滬江博客
          主站蜘蛛池模板: 会同县| 天气| 长宁县| 那坡县| 嘉定区| 江都市| 汨罗市| 资源县| 渝北区| 石首市| 淳安县| 虎林市| 汉沽区| 平昌县| 博兴县| 松江区| 黔西| 郓城县| 阿拉善右旗| 友谊县| 平泉县| 永川市| 调兵山市| 丽江市| 武乡县| 柘城县| 子洲县| 盐山县| 宣城市| 手游| 松原市| 蒙阴县| 西平县| 易门县| 墨竹工卡县| 元朗区| 大姚县| 肇庆市| 莲花县| 苏州市| 莎车县|