缺陷修改引發問題的思考

 

在2013年5月版需求測試過程當中，我遇到「缺陷修改引發需求變動」和「其餘條線的缺陷修改引發另外一條線的出問題」的兩種狀況，對於這兩種狀況，處理方法具體以下：

一、缺陷修改引發需求變動

原需求：當天到期或已過時的票，銀承自動解付任務流經中心崗後，沒有直接提交主機記帳成功，還要手工解付後才提交主機記帳。此作法讓操做人員重複工做，效率很差。

後來通過開發人員和業務人員溝通，程序須要修改成：當天到期或已過時的票，銀承自動解付任務流經中心崗後，直接提交主機記帳成功。

出現此種狀況，開發人員沒有提供最新需求說明書，而且沒有郵件通知測試人員。

此修改，將會涉及到：需求變動、測試用例修改、工做量增長等狀況。

 

咱們測試人員具體處理方法以下：

一、           需求變動：提醒開發人員或需求分析人員須要修改需求說明書。要郵件通知測試人員、業務人員等相關人員，而且提供最新的需求說明書。

二、           測試用例修改：測試人員要根據需求變動內容進行測試用例修改，評估工做量，若是工做量太大，則要上報組長。

三、           工做量評估：若是工做量超過3天以上，那應該上報，要走需求變動審批流程。

 

面對這種狀況，我以爲測試人員須要多思考多分析，及時上報。

面對這種狀況，建議開發人員可以有意識地修改相關需求說明書及通知相關人員。

 

二、其餘條線的缺陷修改引發另外一條線的出問題

在5月版需求測試過程當中，遇到一個問題：同城需求的缺陷修改，把銀承的掛起任務程序改錯了，形成銀承自動解付的任務不能掛起。此問題涉及到平臺公共部分的程序。

這種狀況，開發人員不知道本身改錯了。

同城對這個缺陷驗證的測試人員也分析不到此問題會影響到其餘條線。

 

咱們測試人員的處理方法有以下幾種方法：

一、 若是缺陷涉及到平臺公共部分的程序，則缺陷驗證的測試人員要思考下或是驗證缺陷之外涉及的其餘條線交易。若是缺陷驗證的測試人員對其餘條線的交易不熟悉，那能夠郵件通知其餘條線的組長安排人員驗證。

二、 測試人員多學習平臺各條線的交易。這樣測試人員在測試平臺公共部分，就會全方面思考啦。

三、 各條線派出表明人對平臺的測試人員作培訓。

 

面對這種狀況，我以爲測試人員須要多思考、多分析、多學習。

面對這種狀況，建議開發人員在修改缺陷時多分析缺陷的修改涉及面，特別是平臺公共部分程序，若是涉及到多條線的程序修改，那請在缺陷修改說明中描述出來告知測試人員。