"什麼叫你不知道這個功能要做什麼"

品管的過程其實就是與開發者、功能需求者的溝通技巧。
品管的關鍵約略是以下幾點

功能本身的目的

絕對不是單純把功能做出來有個東西塞著就叫做Feature
這種狀況只會有一堆BUG，然後等著被需求者罵一頓。
因此由品管與最終使用者或是需求提出者明確溝通出功能的來龍去脈很重要。

把握建議與開發者自我思考的平衡

通常做為一個潛在的使用者(畢竟東西要出去你自己要玩過一遍)，我們一定會有一堆建議想提出。
但若從頭到尾都由需求者與品管者向開發者提出建議，並完全照著建議做，按照經驗通常只會做出一個四不像。
因為開發者當下只想讓功能滿足每個人的需求，但沒有拿捏到平衡。
因此讓RD 自我重新思考功能目的本身是很重要的。
當你覺得有異常，就說你自己在用有沒有覺得這裡怪怪的，通常他自己就會有修正的答案與方向了

你是一個無情地找出問題的機器

或許作為一個有經驗的產品測試者，腦袋裡一定有一百種聲音想告訴對方說你就這樣改。
照經驗，沒有好下場，除非你自己就是需求者。否則回歸到需求本身的重分析才是解決問題的主要方式。
核心來自於你怎麼把問題找出來，將心思放在如何找到潛在的問題就是重中之重

Pass/Fail 的界線判斷

當我們開始進到如何判斷一個功能是否有問題大概就分為幾點來進行判斷

• UI
• UX
• 穩定性
  你一定會想，效能呢，效能哪去了?
  說實話，當你的使用體驗不好，你也不想管他跑得快不快了，
  若當你的車子方向盤往左打車卻往右跑，
  你也會不想管車子跑得快不快了。
  讓我們照順序來逐一確認個別怎麼檢查以及有哪些重點

UI

錯別字

沒錯人生到了現在，你終於可以抓錯別字並且自信地告訴對方，你打錯字了

語意不清

通常我們在產品設計時很難去期待最終使用者會乖乖看說明書，老實說你自己上次看說明書是什麼時候?
所以當我們在UI 設計什通常會考慮塞入一點說明文字，此時語意清楚就是很重要的部分
至少要是一句，可以清晰解釋要做什麼的文字

跑版

有時候你會痛恨自己，看到了一個歪掉一點點的排版，然後就無法忽視它了，
沒有錯、接下來就是讓所有人無法忽視它。

不一致

這個比較麻煩，要從設計面考慮怎樣的預設行為叫做正常，因此這部分其實就是與開發者溝通預設的版面與設計規劃

UX

流程繁瑣度

當一個東西你重複三次就會覺得麻煩，那可能就要討論是否可以簡化部分資訊
尤其是這個項目進到使用者手中它的使用頻率會比你在測試時還高

使用條件清晰度

這取決於功能本身是否有前置條件
要考慮以下幾點

• 是否有引導完成前置架設
• 是否有清晰表達條件的細節
  如果這兩個都有表達 但你還是常常忘記，那就還要考量一點
• 提醒本身顯目與否
  當這幾點完成基本上就難以出現，不清楚為何功能無法用的狀況

穩定性

長時間待機

這是有時候我們會忽略的一個狀態，我們都知道燒機很重要。
但是若機器待機的反應是我們完全沒考慮過的，是否就要思考，如果我開機後什麼都不做，放一天機器會怎樣?
有時會有意想不到的狀況。

重複操作單一動作

這基本上就是挑戰你的操作能力...開玩笑地，寫一隻小程式去滿足測試需求吧，並不是每個動作都要你手動點個一百次

紀錄Issue 從寫清楚開始

當我們在方方面面找到許許多多的問題時接下來就是紀錄問題重點了。
一個問題紀錄很重要的點在於
別人看著你的紀錄是否可重現問題
一個Issue 至少要有以下幾點

• 操作環境紀錄 (包含的你的OS 版本，有時會有意外收穫，
• 操作流程 (最基本的，逐步列出你作了什麼操作，
• 事後討論 (與開發者在分析問題的初步討論內容也可以保留
• Debug LOG (有最好啦，但是更重要的，LOG 內容是否完整清晰，也是一個可以留意的問題
  當我們可以清楚地重複作出問題，你的Issue 紀錄就是夠完整的。
  因此Issue 比起數量，可複製度，是最重要的指標

品質保證的重要特質

品質管理，其實單純就是你想要從客戶身上收穫哪些對產品的想法，因此當我們從自己可以從產品上收穫那些感受
就是客戶基本會體驗到的，嚴謹的做出判斷與分析，清楚的看見功能本身要達成的效果，這些都是我們在產品設計的終點上，要回頭考量的就是是否為一開始要做的功能
看見原始功能的出發點，就是你做為產品開發終站的最重要的功課