[Notes] 2022 不確定時代下的敏捷測試

一段時間沒充電了，報名了三叔公（David老師）的課程來好好了解敏捷測試。 上課內容很豐富也有分組討論，我自己非常喜歡有和老師及學員互動及經驗分享的課程，除了可以站在巨人的肩膀上，也可以了解一下其他團隊的做法和面臨的問題。

以下就記錄一下自己比較缺乏和未來需要加強的部分 😊

 

Agile Testing Manifest (By ThoughtWorks)

• Agile Testing Manifest
• Quality Manifesto

1.     測試人員的價值在於早期協助團隊釐清需求和建立系統，而非只是嘗試破壞系統和找出臭蟲。

2.     產品和團隊的質量由團隊所有人負責，並非只由測試人員負責。

3.     精準的自動化測試：應做到可選擇「只執行調整到的範圍」，自動化測試不在於多，而是必須準和穩定，而且必須做有效分層（種類和Priority）。

4.     實例化需求 （Spec By Example）。

5.     從產品的正式環境建立觀測、收集數據，作為開發和測試的參考。

6.     Living document: 持續性更新的文件。

7.     預防defect，而不是追求找到defect的數量。

8.     專案或產品Milestone前期，建立測試計畫，原則以簡單、易維護為主：

     a. 測試目標、項目、風險、策略及環境

     b. Resource and delivery.

快速交付產品

1.     團隊不要刻意分角色別（即多職能團隊）

2.     擔任QA角色的核心價值不僅於進行測試，而是要建立團隊的mindset，讓開發人員也可以做測試，而更複雜的測試再讓QA進行（因為自動化測試絕對無法覆蓋所有範圍，更不用說更複雜的測試可能無法自動化）。

3.     需要有對應的CI/CD流程。

敏捷產品需求處理

1.     Impact Mapping -> Story Maps  -> Spec By Example

2.     SBE (Spec By Example)

     a. User story

     b. Rule

     c. Example

     d. Questions

3.     SBE is like User Story Mapping, that are helping the Team to understand the requirement and give the feedback, we can create the actual test cases after it.

4.     測試左移

      a. Review requirement design

      b. SBE

      c. Code review

      d. Increase Testability (Observability + Controllability)

Automation Testing

1.     自動化測試程式視為軟體開發，需要做版控、Code review及安排重構。

2.     價值導向，重於做好做滿。

3.     及早開始就可以及早收到回饋。

4.     因為重要性通常會被產品功能開發壓低，所以建立初期就要讓資深的人先打底（架構），避免未來難以擴展或因為不穩定（false alert）導致不信任感。

測試右移

1.     開發後期的測試工作，通常在佈署後進行。

2.     Testing and Monitoring production

3.     Why

a.     Collect feedback from real users

b.     Improve product

4.     How

a.     Release: Feature flag, Blue-Green deployment, Canary deployment.

b.     Post release: Chaos test, A/B test, monitoring.

5.     Key of testing in production

a.     Distinguish from test data and real data.

b.     Controllable scope or isolation.

c.     Fast recoverable plan.

d.     Not only focus on the AP, but the statics of BI or Reporting must exclude the test data.

6.     Chaos testing

a.     Progressive

b.     Automation flow on testing and recovering

c.     Focus on few customers and regions.

d.     You do have a PLAN.

e.     Tools: Chaos Monkey

Q & A

1.     Production上發生的Edge case的測試策略？

Ans. 可以從兩方面思考：1. Hotfix後多久可以發佈上線？如果足夠快的話就不需要害怕edge case。 2. 要考慮該edge case的impact和severity，如果團隊覺得高的話，就需要放入regression test，但因為是edge case，也許不一定要以非常高的頻率去執行它。

2.     壓測/負載測試相當耗費人力及機器資源，安排的時機點？

Ans. 依據需求，在Sprint planning時確認是否排入Sprint backlog，建議自動化並讓它在機器不繁忙的時間測試。 實務上我們通常會排一個Hardening Sprint 來進行。
另外可先預估loading並在日常開發的CI做小規模測試，來快速檢視是否這一次的調整有Performance issue。

3.     DoD由誰去review真的有做到位？

Ans. 所謂上有政策，下有對策。 由管理層去看不是好的解決方式，重點是團隊有mindset。 DoD初期先訂寬鬆，再逐漸refine成團隊的文化；也可以透過Scrum master幫忙看和建立規則。

4.   當QA建立了完整的流程和自動化測試，如何展現自己的價值？

      Ans. QA最高的價值在於初期即協助團隊和PO/PM確認真實（或未發現）的需求，以建立更正確的設計；QA應該以指導團隊同仁測試觀念和架構為核心，一同改善團隊推動業務的資訊流程。 當老闆看到團隊邁向正軌，自然而然會看到團隊的每個人的價值。