ソフトウェアのテスタビリティ（テスト容易性）に関してまとまった書籍「Team Guide to Software Testability」を読んだ📕

本書の特徴は「テスタビリティ」を重要視してソフトウェアの品質・デリバリーの予測可能性を高めていくために「どのようにチームで取り組んでいくか」というチーム目線で技術的な施策と組織的な施策が紹介されている点かなと💡後述するエクササイズも充実していて，読んで良かったな〜と思える一冊だった．テスタビリティに含まれる品質特性に関しては優れたテスト容易性を実現するためのポイント | PrAhaENGINEERLAB に詳しくまとまっていて，あわせて読むと相乗効果があると思う📝

Team Guide to Software Testability: Better software through greater testability (Team Guides for Software Book 3) (English Edition)

作者:Winter, Ash,Meaney, Rob
Conflux Books

Amazon

本書は Team Guide というシリーズで計4種類出版されていて，他のテーマも気になるぞー＼( 'ω')／ちなみに Leanpub だと4冊セットで安く買えたりもする👌

Team Guide to Software Operability
Team Guide to Metrics for Business Decisions
Team Guide to Software Testability
Team Guide to Software Releasability

leanpub.com

最近ソフトウェアのテスト全般に課題のあるプロダクトを支援していて，参考になる情報をインプットする中で Team Guide to Software Testability が良さそうだったので読むことにしたという経緯がある💡ちなみに Team Guide to Software Testability は「Web API テスト技法」を読んでいたら第7章で紹介されていて知った．

Web APIテスト技法

作者:Mark Winteringham
翔泳社

Amazon

Exercises
Introduction
1: Set a pragmatic direction for improving testability using trade-off sliders
2: Create testability targets to improve interactions with dependencies
3: Adopt testability mapping to expose hard-to-test architectures
4: Apply the CODS model to increase architectural testability for faster feedback
5: Adopt ephemeral development environments for fast feedback
6: Use production data to enhance your testing strategy
7: Use team testing reviews to enable sustainable delivery
Appendix - Notes on 10 P’s of Testability

テスタビリティの重要さ

Introduction ではテスタビリティの重要さがコンパクトにまとまっていた．テスタビリティの価値を再確認できて良かった👌

Team dynamics（チームのダイナミクス）
Predictability（予測可能性）
Supporting your business and customers（ビジネスと顧客のサポート）
Fast feedback（迅速なフィードバック）
Data, not opinion（意見ではなくデータ）

本書は TDD (Test-Driven Development) と直接的な関係があるわけではないけど，TDD はテスタビリティを意識する機会になると思うし，Fast feedback に関しては fukabori.fm #114 で話題に出ていたフィードバックの話にもつながるな〜と思いながら読んでいた📻

fukabori.fm

エクササイズ

本書の良いところは，テスタビリティに関する解説だけでなく，各章に「エクササイズ」というチームで取り組むイベントが紹介されていること❗️エクササイズの内容以外に「準備すること・ファシリテーションのコツ・FAQ・ゴール・アウトプット」などもまとまっていて，取り組みやすいようになっていた．

特にエクササイズに取り組むことを考えると「ファシリテーションの良し悪し」で効果が全然変わってきそうで重要だと感じた．

Chapter 1 exercises
- Team Test for Testability
  - 1.2 Exercise: do the Team Test for Testability for a quick testability health check
- Trade Off Sliders
  - 1.3 Exercise: use Trade-Off Sliders to guide your testability focus
Chapter 2 exercises
- Testability Dependency Targets
  - 2.2 Exercise: employ Testability Dependency Targets to improve interactions with dependent teams and systems
Chapter 3 exercises
- Testing Smells
  - 3.3 Exercise: Use testing smells to diagnose poor architectural testability
- Testability Mapping
  - 3.4 Exercise: adopt testability mapping to measure testing feedback and waste
Chapter 4 exercises
- CODS model
  - 4.3 Exercise: Use ‘CODS’ to increase architectural testability
Chapter 5 exercises
- Agile Test Quadrants
  - 5.3 Exercise: Use the Agile Test Quadrants to extend testing in your development environment
Chapter 6 exercises
- Data from Production
  - 6.2 Exercise: employ data from production to keep your test strategy relevant
Chapter 7 exercises
- 10 P’s of Testability
  - 7.3 Exercise: use the 10 P’s of Testability to track team testing culture
- Incident Reviews
  - 7.4 Exercise: adopt incident reviews to target testability improvement actions

どのエクササイズも良かったけど，特に良くてすぐに取り組んでみようと思った2つを紹介する👏

Testing Smells

このエクササイズでは以下の「15項目の課題」に対して，どれがテスタビリティの非効率さに影響を与えているのかを洗い出す．

Too many production issues（運用上の問題が多すぎる）
Pre-release regression cycles（リリース前に行う回帰テストのサイクル）
Lack of automation & exploratory testing（自動化と探索的テストが不足している）
Hesitance to change code（コード変更に対する躊躇）
Testing not considered during architectural design（アーキテクチャ設計時にテストが考慮されていない）
Team constantly seeking more testers（チームが常にテスト担当者を探している）
Too many slow user interface tests（UI テストが遅すぎる）
Important scenarios not tested（重要なシナリオがテストされていない）
Ineffective unit and integration tests（非効率な単体テストと統合テスト）
Cluttered, ineffective logging（適当で非効率なログ）
Flaky nondeterministic automation（不安定な自動化）
Tests that contain duplication & irrelevant detail（重複しているテストと不要なテスト）
Issues are difficult to reproduce（再現できない問題）
Issues are difficult to isolate & debug（問題を切り分けてデバッグできない問題）
Too much effort spent writing, maintaining and debugging automation（自動化のメンテナンスとデバッグが大変すぎる）

そして，それぞれの項目に対して以下の 1-5 のスコアを付ける．最終的にチームで優先的に取り組むべき（取り除くべき）課題のトップ3を洗い出して，ディスカッションをする❗️

1: No impact on team effectiveness（チームの効率さに影響なし）
2: Small impact on team effectiveness（チームの効率さに少し影響がある）
3: Moderate impact but rarely impacts team effectiveness（ある程度の影響はあるがチームの効率さにはほとんど影響なし）
4: Moderate impact but often impacts team effectiveness（ある程度の影響がありチームの効率さにも頻繁に影響がある）
5: Large impact, almost always impacts team effectiveness（影響が大きく常にチームの効率さに影響がある）

10 P’s of Testability

このエクササイズでは以下の「10項目の観点」に対して，どれがテスタビリティに悪い影響を与えているのかを洗い出す．

People（人々）
Philosophy（行動指針）
Product（プロダクト）
Process（プロセス）
Problem（問題）
Project（プロジェクト）
Pipeline（パイプライン）
Productivity（生産性）
Production Issues（本番環境の課題）
Proactivity（積極性）

そして，それぞれの項目に対して以下の3種類から投票する．最終的にテスタビリティに悪い影響を与えている項目を洗い出して，改善策をディスカッションする❗️

happy（満足）
unhappy（不満）
no opinion（意見なし）

「テスタビリティに課題がある」と言っても，チームによって原因は違っていて，さらにメンバー間の価値観の違いなどもあるため，テスタビリティに対する認識合わせができることは重要だと思う．よって，このエクササイズはすぐにでも取り組みたいと思った💪例えば四半期ごとに実施すればテスタビリティの変化を計測できるというメリットもあると思う．

まとめ

「Team Guide to Software Testability」を読んだ📕読んで終わりではなく，実際にチームでエクササイズに取り組むことでさらに効果が得られる一冊だった．ソフトウェアのテスタビリティ（テスト容易性）に課題を感じていたら読んでみると良いのではないでしょうか〜＼( 'ω')／

Team Guide to Software Testability: Better software through greater testability (Team Guides for Software Book 3) (English Edition)