iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
自我挑戰組

踏入品質保證工程之路:QA 新手如何善用 AI 與開發者工具 系列

我是一名電子工程師,專長偏向數學、電路與網路領域。近期我在台北一家科技公司轉任品質保證工程師,希望藉此機會學習並分享更多相關領域的知識。我將分享 QA 相關主題,內容包含但不限於:測試類型、測試模型、測試技巧與測試管理。由於我目前負責的產品皆屬於客服與行銷產業,因此我的分享方向也會較偏向這兩個領域。此外,我先前曾從事專案管理工作,服務過來自美國、英國與澳洲的多個客戶,這樣的背景也為我踏入 QA 工程領域奠定了更有利的基礎。

參賽天數 28 天 | 共 28 篇文章 | 0 人訂閱 訂閱系列文 RSS系列文
DAY 21

快、便宜、準確:真的只能三選二嗎?

對一個 AI 功能來說,「正確」並不是品質議題的終點。一個在 20 秒後才給出正確答案的支援助理,可能仍然會失去那位兩秒內就需要答案的客戶。一個 AI 工作流可...

2026-10-05 ‧ 由 shanen 分享
DAY 22

如果人人都能通行,就別稱之為關卡:讓 CI/CD 成為品質關卡

團隊一直說我們有品質關卡。紙面上聽起來令人安心:測試必須通過,評估必須達到預期,發佈必須在往前推進之前滿足某些檢查。但當我回顧一整季的紀錄時,一個更令人不安的問...

2026-10-06 ‧ 由 shanen 分享
DAY 23

偵測、隔離、決定:用值得信任的 CI pipeline 修正不穩定測試(flaky tests)

品質關卡寫好之後,下一個實務問題是它們應該在什麼時候執行。所有測試都跑在每次 push 上,聽起來很嚴謹——直到開發者開始在漫長的 pipeline 中苦等,並...

2026-10-07 ‧ 由 shanen 分享
DAY 24

別再亂點了:有目的的探索性測試(Exploratory Testing)

在這第二十四天,我想再次談談另一種測試類型。到目前為止我建立的所有東西,都依賴於事先知道要檢查什麼:測試案例、API 契約、評估集、迴歸套件,以及品質關卡——每...

2026-10-08 ‧ 由 shanen 分享
DAY 25

影響 × 可能性:更好的缺陷排序方法

當我在管理缺陷時,最難的問題往往不是如何重現一個 bug 或找出它的根本原因。有時候難的是:當好幾個問題都真實存在、而時間與資源有限時,要決定哪一個缺陷值得先被...

2026-10-09 ‧ 由 shanen 分享
DAY 26

每一格都勾、每一項主張都有證據:發佈檢查清單與 Canary 驗證

「可以發佈了」聽起來很直接——直到有人追問:實際上是什麼證明了這件事? 迴歸套件跑過了,但它通過了嗎?效能檢查過了,是對照哪一個預算?團隊說可以 rollbac...

2026-10-10 ‧ 由 shanen 分享
DAY 27

線上監控的好壞取決於它的樣本:抽樣與壞案例回饋

線上儀表板可以看起來很健康,與此同時客戶正默默地過著糟糕的體驗。如果我只收集使用者自願提交的回饋,我看到的大多是有動力抱怨的人。那些放棄對話的使用者、因第一個答...

2026-10-11 ‧ 由 shanen 分享
DAY 28

QA Essentials:交接手冊

一套 QA 流程可以看起來很有條理,同時卻把大量依賴寄託在建立它的那個人身上。我可能知道要跑哪一個評估、為什麼存在那個特定門檻、哪一個結果值得調查,以及發生意外...

2026-10-12 ‧ 由 shanen 分享