原則上我認為這是個專案團隊在專案初始規劃時的一個嚴重錯誤。規劃人員礙於經費相當有限,於是只安排一個階段的測試工作,並未安排第二階段的驗證、回歸測試。
其實原本開發人員本來就應該針對自己交付的成品的品質負責(程式開發階段的單元測試,以及錯誤改正的基本驗證),例如嘗試重製該錯誤,確認錯誤不會再發生,才能結束該項錯誤修正的工作。但品管人員應再一次的為之前所記錄的產品瑕疵再次驗證,做最後把關動作。
當第二次的回歸測試被取消了,其實即使開發人員有做基本的驗證,但畢竟開發人員不是專業的品管測試人員,產品經理或是產品團隊甚至是開發人員在最後要將成品交付客戶時,為了為品管把關,結果還是要多花一些時間再次驗證產品品質,那麼事實上不做第二次的回歸測試,只是把成本轉嫁到產品團隊身上,而當產品團隊本身不具備品管與測試專業時,可能會花更多時間在做最後把關,這樣弄到最後,看似成本省了,但實際上團隊超時工作的成本卻被忽略了。
各行各業都有各自的專精,開發人員善於開發,不見得善於測試;同樣的,有擅長於測試的人員與團隊,通常當開發流程成熟後,將測試工作轉交給專業的測試團隊,對於整個專案來說是最省開銷的做法,同時又可兼顧品管。試想,讓你做你所不熟悉的領域的工作,例如讓一個程式開發人員來作測試,是不是通常會花費更多的時間,甚或是得不到理想預期的結果?
不用寫程式的瀏覽器自動化:Codex for Chrome 幫我操作 Google 地圖、Evernote、 Gemini、社群
-
上個禮拜撰寫了「一般人如何快速上手 Codex 超完整圖文教學:讓 AI 助理整理文件表格,建立自動化流程」一文,分享新手如何快速掌握 OpenAI
的 AI Agent 軟體:「 Codex 」。因為這幾個月的使用經驗,讓我認為 Codex 已經不只是一個程式開發 AI 工具, *Codex
更可以當作...
8 小時前
0 Comments:
張貼留言