iT邦幫忙

鐵人檔案

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

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

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

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

假資料,真臭蟲:給 QA 的測試環境

身為 QA 工程師,我的工作有很大一部分圍繞著理解軟體如何安全地從開發走向真實使用者的手中,而這段旅程建立在彼此分離的環境之上。對我的日常工作而言,第一個也最重...

2026-09-25 ‧ 由 shanen 分享
DAY 12

一份好的 Bug 報告,即使沒有作者也能被理解與重現

找到缺陷只是工作的一半。當另一個人——開發者、QA 工程師、產品負責人,或幾週後回來查看該問題的人——能夠理解發生了什麼並獨立重現它時,這個缺陷才真正變得有用。...

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

錯誤的答案就代表助理壞了嗎?

AI 助理給出錯誤的答案,不一定代表模型有問題。它的回應可能只是整條服務鏈的最後一步——資訊先被檢索、結構化並傳遞給模型,最後才被轉譯成自然語言。 當 Auro...

2026-09-27 ‧ 由 shanen 分享
DAY 14

拆解測試套件,重新打造得更好:新增、合併或刪除測試

一個回歸測試套件可以在每一步都事出有因的情況下,逐漸變得難以信任。在期限壓力下,這個模式再熟悉不過:重現一個缺陷、加一個測試、確認修復,然後繼續趕工。 多年各自...

2026-09-28 ‧ 由 shanen 分享
DAY 15

放寬措辭,絕不放寬紅線:定義可接受的範圍

我們撐過了兩個星期!! 在進入主要內容之前,先來一道電路題:如果一顆標示 1 kΩ ±5% 的電阻,在你的三用電表上量到 1,030 Ω,你會拒收嗎?又如果妳...

2026-09-29 ‧ 由 shanen 分享
DAY 16

先打造直尺,再開始測量:建立黃金集

在沒有固定評測集的情況下,每一次提示詞修改都是一場新的遊戲。我可以用幾段看起來很有說服力的對話來測試新版本,並宣稱這是一項改良;而另一位 QA 工程師可以挑選另...

2026-09-30 ‧ 由 shanen 分享
DAY 17

兩個人都給 4 分,不代表同一件事

主觀品質之所以難以測試,是因為 good、helpful、professional 這類詞,把好幾種不同的判斷壓縮進單一一個分數裡。兩位審閱者可以閱讀同一段 A...

2026-10-01 ‧ 由 shanen 分享
DAY 18

在信任 LLM 評審之前,先測試這位評審:它有多「像人」?

人工審閱是評估 AI 回覆時有用的參考基準,但它的成本很快就會失控。幾位審閱者可以仔細檢查幾十、上百段對話;要他們評一萬段,就完全是另一回事了。用另一個 LLM...

2026-10-02 ‧ 由 shanen 分享
DAY 19

提示詞改變行為。把它當程式碼一樣追蹤。

身為一位接觸不到原始碼的 QA 工程師,我從能夠觀察到的行為著手——透過前端與後端。這通常給了我足夠的證據去重現缺陷、檢查請求與回應、比對環境、驗證修復。但 A...

2026-10-03 ‧ 由 shanen 分享
DAY 20

別再等 AI 自己出狀況

快樂路徑(happy path)測試告訴我:當對話停留在我們為它設計的路徑內時,AI 功能如何表現。它們回答了有用的問題,卻很少揭示:當指示互相衝突、使用者要求...

2026-10-04 ‧ 由 shanen 分享