前言

會來參加這場活動其實是被同事推坑，一開始其實還在猶豫，不過實際來參加之後，收穫倒是出乎預料的多。這次的活動共分三軌並行，所以我就針對我所參與的三場來做心得分享。

持續測試：如果我可以重來一次

我們都知道測試很重要，因此現在有越多公司/團隊導入測試。持續整合測試更能讓團隊知道目前產品整體的狀態，而自動測試會讓測試的執行成本降低，進而讓團隊更願意頻繁的測試產品。但當市面上大神的那些導入方法在公司環境裡不 Work 時，要怎麼辦呢？

對於一個產品重要的是要拿到回饋改進產品，不論是交與測試團隊，或是放上正式環境讓使用者使用，都是一種方式，而持續測試就是一種安全又快速可以拿到回饋的方式。

但是既有的程式(系統)越是龐大複雜，regression test 的工就越大，執行起來越耗時，也會讓團隊對於執行測試感到不耐。甚至到後來會因為測試耗時，導致新功能上正式的時間被影響到。

將測試的範圍往產品設計，開發與上線這兩端推

test_to_each_phase

在產品設計階段：

使用實例化規格，將需求轉化為具體的 Case

  • 這可以幫助團隊對於需求的理解更好達成一致性。
  • 減少溝通成本

在開發階段：

使用單元測試與靜態分析

  • 單元測試是所有測試的類型中，執行負擔最小的一種
  • 能提供最基本的品質保證

在測試階段：

使用 E2E test

  • 模擬使用者在使用產品時一般的操作流程
  • 確保整個流程是符合預期的行為
  • 測試一整個 user story

在上線階段：

使用即時監控

  • 讓使用者協助做 corner case 的測試
    • 畢竟 QA 也只能代表少部份的使用者
  • 藉由各項觀測值來觀察使用者的使用情況

Git Branch Pattern

Trunk base development：

  • 頻繁交付到主線
  • Feature toggle
  • 需要每個 commit 都足夠乾淨，讓 release 時可以方便將 commit 撿入 release branch 中
  • 需要有較為完整的測試在 trunk branch，確保目前是可以發布的狀態

從工程角度，引領團隊持續挖掘產品風險

瞭解商業邏輯中的重點數據

這些數據會是重點監控指標

Prometheus + Grafana

資料的呈現與數據的監控

Prometheus

監控數據與發布警告

Grafana

畫出美美的圖表

issue2

雪崩效應

組織過於依賴明星，而明星離開時的效應。

要避免英雄主義。

團隊文化

  • Ownership
  • Commitement trust

willing

monitor

當 SCRUM 遇上 PATTERN

scrummaster

每一個概念的興起都是為了要解決一個既有問題，在跑 Scrum 時，思索謂何要有 Scrum Master 這個角色的存在。

例：每日站立到底要解決什麼問題？

Scrum Master要解決什麼問題？

ANS: Scrum是否能被順利進行

Quality without a name

Name Magic

  • 呼名大法
    • 只懂名詞，卻不知其精神與內涵是沒有意義的
  • 小心成為老司機
    • 很姆湯的那種

技近乎藝，藝近乎道

quality