「自動テスト」の勘所を聞いてきました！～JaSST’23 Hokuriku 参加レポート～

こんにちは！よしみつです。
現在、E2Eテスト自動化の推進や、アジャイルQAとして、日々業務を行っています。

1/20に開催されたJaSST’23 Hokurikuでは、「自動テスト」「アジャイル開発における品質確保」「仕様書が無い現場で開発と一緒にテスト成果物を作成した事例」等、個人的に関心のあるテーマがあり、オンラインで参加してきました。
どの講演も非常に学びの多い内容でしたが、今回は「基調講演」をピックアップさせていただき、講演から得た「学び」をお伝えしていきたいと思います。

基調講演
まとめ

基調講演

基調講演は、〚組織に自動テストを書く文化を根付かせる戦略（2023新春版）〛と題して、（テスト駆動開発のスペシャリスト！）和田卓人さん （タワーズ・クエスト）が登壇されました。講演内容から得た「３つの学び」を以下にまとめます。

学びその１：自動テストを書く「意義」

講演の冒頭では、「ITは事業のコアとなった」「企業における開発能力と業績との因果関係」「不確実性の時代における開発力の指標」という、サーベイデータに基づいた世界の状況を説明。

ソフトウェアデリバリーのパフォーマンスを示す4つの指標（4keys）、そして「テスト容易性」と「デプロイ容易性」の重要性を示唆され、その「テスト容易性」と「デプロイ容易性」を実現するために、自動テストを書く「意義」がある、と本題に入っていきました。

4keysとは「ソフトウェアデリバリーのパフォーマンスを示す」4つのキーメトリクスのことです。

リードタイム
デプロイ頻度
MTTR（平均修復時間）
変更失敗率

講演では、State of DevOps(*1)のサーベイに基づき「4つのメトリクスによって組織が備えているソフトウェアの開発力を測ることができる、また、その企業の開発力が、企業の業績、競争力に繋がっているという結果が、データとしてはっきり出ている」という話を伺い、「4keys」の重要性を理解することができました。

ソフトウェアデリバリーのパフォーマンスを向上させるうえでキーとなるのは、コードの「テスト容易性」と「デプロイ容易性」です。
「テスト容易性」とは、テストの大半を、統合環境を必要とせずに実施できること。
「デプロイ容易性」とは、アプリケーションを、それが依存する他のアプリケーションサービスからは独立した形でデプロイまたはリリースできることです。

それらを実現するためには、設計やコードでの工夫が求められます。例えば、結合度を低くし、凝集度を高くすることなどです。そのために「自動テストを書くこと」「自動テストを書く文化を根付かせることが大切だ」という本質的な話に繋がり、非常に納得することできました！

当日の講演資料はこちらから閲覧できますので、ぜひご覧ください。

(*1) State of DevOps Report： 年1回DORA（Google Cloud内のチーム）が発表しているソフトウェアのデリバリーパフォーマンスに関する調査結果レポート

学びその２：テスト自動化の「アンチパターン」

テスト自動化のアンチパターンについては、４点あげられていました。

私自身がE2Eの自動化推進に携わっているため共感もあり、また、新たな気づきもありました。

信頼性の低い自動テスト
- 信頼不能性（flakness）が高いと、チームがテストを信頼しなくなる
  - どうせまた失敗でしょ？　→テストの失敗に反応することをやめてしまう
- 信頼不能性が全テストの1％を占めると、テストは価値を失い始める
買ってきた自動テスト
- 自動テストの量を増やしたい→　リソースが足りない→　外部委託を活用
  - 結果、納入後のテストコードはメンテナンスされずに朽ち果てる
- 内部でテストコードを書く能力を育てることが重要！
アイスクリームコーン型
- E2Eテスト自動化を重視してしまうケース
- 実行速度は遅く、保守コストがかかる
- 厳しい現実：「主としてQAチームか外注先が作成・管理している自動テストは、ITパフォーマンスと相関関係にない」という分析結果も・・・

コスト削減を主目的にする
- 自動化の目的を「コスト削減」にすると・・・「学習コスト」や「保守コスト」等によって思ったようなコスト削減効果が得られず、「手動テストに戻る」という判断をしてしまいがち。。
- 自動化の本来の目的は「変更容易性を高めるため」＝「アジリティ―を得るため」
- 「変化についていく力」というのが企業の競争力の源泉、そのために自動テストを書く

アイスクリームコーン型とは、ユニットテストの割合が少なく、E2E自動テストの割合が多い、その上にさらに多くの手動回帰テストが載っている、という状態を表した図のことです。詳細については、講演資料P.52をご参照ください。

学びその３：自動テストを「チームの文化」とする

最後に、「自動テストを文化としてチームに根付かせることの重要性」「どのように自動テスト文化を根付かせるか」について述べられました。

「テストコードのメンテナンス」と向き合うことの重要性
「テストにコストがかかることの解決方法は、テストをやめることではありません。うまくなることです」– Sandi Metz
テストのメンテナンスコストを下げるようなスキルを身につける、テストコードをうまく書けるようになること、これが自動テスト文化
自動テストの重要性と保守性（理解容易性、変更容易性）をチームが理解し、改善努力を継続的に行うことが大切

まとめ

以上、基調講演から得た学びをご紹介させていただきました。

テスト自動化のアンチパターンの話では、「アイスクリームコーン型」の発想に陥りがちだなと反省しました。これから、少しづつ「テストピラミッド型」に近づけていきたいです。

ちなみに、「テストピラミッド型」とは、Mike Cohnさんの「Succeeding with Agile」という本で最初に提唱されたモデルです。下から単体テスト、機能テスト、E2Eテストの順に積み重なっていて、より下の層のテストほど、自動化の導入コストが低く、高速かつ安定して動作し壊れにくいため、投資対効果が高いとされています。（もっと詳しく知りたい方は、こちらをご参照ください）

今回、和田さんの講演を聞いて、自動テストを書く「意義」について、非常に理解が深まりましたし、自動化を推進する立場として、必要なスキルをもっと身に付けたい！継続的に改善していきたい！と思うようになりました。そして、自動テストを文化として根付かせるためには、「どうやってやるのか？(How)」よりも以前に、チーム全員が「なんのために？(Why)」という本質を理解することが近道であるように感じました。

和田卓人さんの講演を聞くのは2度目になりますが、圧倒的な知識量に裏付けされた講演内容で、毎回、ものすごく感銘をうけております。常に世界の動向にアンテナを張り続けておられる和田さんの姿勢、私も見習っていきたいです！もし、今回の内容に少しでも興味が湧きましたら、実際に和田さんの講演を聞かれることを、強くおススメいたします！

以上、ご覧いただきありがとうございました。