SQA TW

12/02/2026

原本是為了 App 測試而打造的工具，結果竟然被客戶當成了「皮克敏 GPS 穩定器」在用！
​
全家人的手機都用上了Qaptly Auto，不管是Android/iOS，只因為用它跑 Fake GPS 在玩 Pikmin 比其他 App 更穩不亂跳，連平常設定 Accessibility、開發者模式的麻煩也忍下來了 😆
​
Qaptly Auto for iOS那個工具，我們沒有代理進台灣，目前只有英文版，台灣用戶還是能用subscription plan裡附屬的device quota來啟用完整功能，或者直接走原廠的standalone license。
​
這種不一定要靠系統標籤，靠模式辨別也能知道在作弊，在不知道規則的情況下還是要保守一點比較好，哪天被遊戲營運方禁了帳號就得不償失。

https://sqa.tw/blog/pikmin-with-fake-gps

#科技與生活 #工具也有第二人生 #皮克敏日常 #測試步數中

我們為什麼願意開放「跳過 Accessibility 檢查」的能力、這個設計背後的工程與產品思考，以及 Qaptly Auto for Android 如何在「正式測試」與「非典型使用場景」之間，保持工具的彈性與邊界。

21/12/2025

最近輔導幾個產品團隊，轉型往AI協同開發的過程中，發現有些行之有年的開發規範/流程，在新的開發者教育當中好像比較少提及。

後遺症就是AI coder會放大這些問題，不只是管理者對整體狀況的掌握度不高，團隊彼此之間的信任感也偏弱。

所以，還是抽空把一些一但有了就會比較清楚狀況的事或指標拿出來分享，希望對當前產品或系統困惑的管理者有幫助。

Error Code 不只是錯誤處理工具，而是判斷軟體品質成熟度的重要指標。從 SQA 角度解析 Error Code 如何影響判斷效率、團隊協作與使用者體驗。

13/11/2025

Qaptly v0.13.0 released！

Qaptly本來是我們內部用來加速SQA服務的工具。

這個內部系統與工具矩陣的組合，終於要對外開放了，那些繁瑣又重複的SQA步驟終於可以慢慢放下，享受動動嘴就可以寫完測試案例，又有AI幫你跑測試案例，幫你寫issue。

Qaptly 是我們打造智慧 QA 工具過程中的一個重要里程碑，v0.13.0這個版本大概又能幫SQA省下不少生命，執行的事交給我們，你可以放開雙手，去做點更有意義的事。

30/10/2025

早上開會，被合作夥伴問起來我們內部AI的使用情況，心有所感寫下了這篇，希望對遲疑中的團隊有幫助。

AI 正改變開發團隊的工作節奏與協作方式。能有效整合 AI 的團隊，通常能在更短時間內完成更多、更穩定的產出，而不是單純加班換效率。真正的差距不在技術本身，而在思維與習慣的轉變——懂得與 AI 合作的人，將重新定義....

29/10/2025

一篇文章從七月寫到十月，每個月剛好寫一段，好長...

沒時間的看底下這一小段就好
---------------------------------------------------
電商系統這件事，
不管是自己組建團隊開發，或是委外開發，都有非常多需要考量的點，
預算只是其中一個，甚至都不是最重要的那一個，
沒個上千萬預算，別隨便跳進去。

真的想省事，找個好夥伴陪你一起走很重要。

我們不接專案開發，只幫忙孵化產品，但是大型專案有需要可以找我們幫忙把關。
---------------------------------------------------
原文不建議大家點來看，真的是寫太長

開發一個自有電商網站，比起被平台抽成，好像更划算，這篇告訴你，為什麼不建議你這麼做。

22/09/2025

每隔一段時間，總會想把最近常遇到的場景拿出來分享。

我們最近有點忙，能去現場的時間不多，但客戶希望我們可以快速評估一下問題在哪裡，談的次數多了，我們大概就累積一個簡單的清單，問完這些問題後，不用看產品也能大概知道會有哪些問題，幾乎一問一個準...

這些可以分成五大類跟20幾個小問題，今天要分享的是無研發背景的人員也可以自己拿去評估的，當然，有需要還是可以找我們，時間嘛，擠一擠總是會有的。

https://forms.gle/NQWWr4AiwPb2uLGQ7

如果不是軟體研發人員，我們其實很難評估目前專案跟產品的品質，我們這次不談太專業的內容，就從一般非研發人員也能簡單操作的方法，讓大家能夠評估自己的專案或產品

03/09/2025

最近這一季的新客戶，有超過一半都是因為內部測試達不到預期效果才找到我們，有兩家還透過我們幫忙面試找到合適的QA，其實有時候就是隔行如隔山，外面看起來都懂，也覺得很容易，自己上手才發現沒那麼簡單。

有個最核心也是最難發現的原因，就是可測試性，之所以難發現，是因為就算可測試性低好像也可以進行，就像身體器官或肌肉的代償一樣，不調整回來，只會越來越嚴重。

軟體型態多樣化，實作方式也各有千秋，在SQA上，各種方法論也都是層出不窮，其實，怎麼測一直都只是術，關鍵的是測試的道，而如果要在所有原則中挑一個最重要的，那可測試性(Testability)應該會是當仁不讓的那一個，偏偏.....

21/08/2025

Alice & Bob 是密碼學中很常用的角色，這次請兩位扮演一個案例中的兩個團隊，講了一個故事。
​
https://sqa.tw/blog/information-security-is-quite-important
​
話說，雖然已經很多人知道資訊要加密，甚至認為資訊安全就是要加密，但...還是會把對稱加密的密鑰放在前端網頁裡，然後告訴老闆說所有traffic都加密了，非常安全，每次看到這種做法，總能會心一笑。
​
這與SQA有關係嗎？
​
不能說有，也不能說沒有，只是這算是bug/defect嗎？
​
我們會盡量寫在報告裡，不過開發團隊有沒有能力修改，真的不好說，
​
自以為安全是很常見的現象，各位老闆們如果有需要，還是要找外部團隊好好評估一下(我們沒有這個業務...)。

所有看似完整且自洽的邏輯，一但來了一個必要的第三者，就得重新思考資訊完整性的問題

28/07/2025

在台灣正式嘗試相關業務應該也算上一年了，悶頭跑的一年。
​
本來規劃每個月至少要一篇跟SQA與AI相關文章的，結果跟SQA相關的屈指可數，跟AI相關的就更別提了。
​
乾脆把粉絲頁弄起來，看能不能逼自己好好寫點東西來分享，在AI寫程式的這個時代，SQA該如何理解跟參與到這個時代的巨變裡。
​
節錄一段我在23年底寫給一間VC的研究報告，裡面提到軟體開發角色中，工程師能力七種中的第一種 —— 寫程式的能ㄌ。
​
"這裡所謂的寫程式的能力，專指會撰寫程式語言，了解程式語言特性，並知道程式語言在執行過程中與執行主體間的限制與能力，通常這三者，大部分的工程師都不會需要知道太多，也不用知道太細節就能完成自己的工作，短時間內，這會發展成區分工程師與AI Programmer重要的分水嶺，要知道AI Programmer給出的程式碼適不適合現在這個需求與場景，並且給出明確的指示去調整，需要對原理跟細節有更深刻的理解，如果只是單純的根據需求寫程式，基本上，已經可以確定是會完全被AI Programmer取代了。"
​
雖然那個時候寫起來有點武斷，但現在看起來好像也差不多，那篇報告裡面也有提到有關SQA的部分，剛好就是創立這間公司的初衷。
​
當前有不少所謂的AI自動化測試平台，好不好用見仁見智，但能不能解決自己團隊的問題，這一年下來，我比較少聽到正面的答案，不過，我們的服務是一直新的增長與訂閱，老王賣瓜，還是要自己推薦一下自己，關於我們的服務，請看這篇介紹。

https://sqa.tw/blog/sqa_tw_service_introduction