前言
你好。
我是 QA 工程師 ふじ。
作為 QA 工程師參與實務工作，至今已經過了約 2 年。
我過去所屬的專案導入了離岸開發，
因此有機會負責審查海外供應商製作的測試方針與測試案例，以及品質改善相關工作。
透過這些工作，我學到了許多不同於國內開發的離岸開發特有難處，
以及為了確保品質而不可忽視的重要重點。
這次我也想藉由這篇內容，順便整理成自己的備忘錄並分享出來。
離岸開發中的測試審查課題
從網路上的調查與一般案例來看，離岸開發中的品質管理與測試現場，經常會出現以下這些課題。
• 「差不多就好」無法被理解，對 OK 的定義存在落差
依賴語氣與語境的說明不容易傳達，日本方與海外方對「以什麼作為測試完成」的標準也可能不同。
• 品質管理流程不足與黑箱化
測試案例的提交可能延遲，或是實際進行了哪些測試變得不易掌握，導致流程不透明。
• 文件說明不夠明確
由於缺乏清楚的需求定義與規格明文化，容易產生認知落差。
我在實際工作中進行測試方針與測試案例審查時，也有很多場面不得不意識到這些課題。
透過工作學到的 3 件事
基於這些課題，我在日常品質改善工作中特別感受到重要的學習有以下 3 點。
1. 徹底避免曖昧不清的文件撰寫
在與海外供應商往來時，依賴上下文的表達或「這種程度應該懂吧」的前提並不適用。
在審查測試方針與測試案例時，我學到了必須將「在什麼前提條件下操作，以及什麼作為預期結果」具體地、根據數值與畫面規格明文化的重要性。像是嚴格讓規格書的文字與測試案例的文字一致，打造出任何人閱讀都能做出唯一解讀的文件是必要的。
2. 品質檢查流程的標準化
如果品質管理的步驟與審查標準一直曖昧不清，就會造成測試案例的覆蓋率與粒度出現不一致。
為了讓交付成果的品質維持在一定水準，我切身感受到必須事先將測試案例的提交規則與審查流程標準化，並透過檢查清單等方式建立定期回饋的機制（流程）。
3. 事前對齊期望值（目標）
如果在測試開始後才發現認知有落差，返工成本會非常高。
我學到在測試開始前，就必須把要測到什麼程度的範圍，以及對交付成果所要求的品質基準（OK 的定義）明文化，並與供應商充分達成共識，這才是讓專案成功的基本。
總結
透過離岸開發中對海外供應商測試案例的審查與品質改善工作，
我深刻感受到，單純「指出測試案例的缺失」並無法帶來根本性的品質改善。
這也讓我學到，作為 QA 工程師，真正重要的是「如何標準化流程，並透過文件建立共同認知」這種本質性的做法。這次的經驗，我也希望能活用在未來的專案中。
感謝您閱讀到最後。
原文出處：https://qiita.com/fj_qaengineer/items/cabe6aea0be459f7d97b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
