イベント概要
以下、connpassのイベントページから引用です。
ソフトウェアテストの「つぎの一歩が見つかる、気づきと学びの場」 TEST Study シリーズ。 Forkwell はこれまで「つくり手と、未来を拓く。」というビジョンのもと、第一線を走るエンジニアから統合的な学びを得る勉強会を継続開催してまいりました。
インフラ、フロントエンド、機械学習と技術領域にフォーカスした題材を多く取り扱う一方で、ソフトウェアテストの様な普遍的なテーマについてはこれまであまり取り扱ってきませんでした。 そこで Forkwell はソフトウェアテスト自動化プラットフォームの「Autify」を提供するオーティファイ株式会社と共同でソフトウェアテストに関する勉強会を開催します。
Test Automation Specialist の末村 拓也氏にモデレーターを依頼し、テストに関する思想や向き合い方、具体的な技術論までソフトウェアテストに関する幅広い学びを提供する場としていく予定です。 全3回をかけて行い、各回のテーマに沿った第一線を走るエキスパートの方々にお話を伺っていきます。
会で印象的だったこと
和田さんの講演
質とスピードの背景
和田さんから質とスピードの講演をした背景をまず聴いていきました。
和田さんは、エンジニアリング組織に関わるEM, PMに向けて広木さんから話をして欲しいと言われたことがきっかけでこの講演をしようと思い至ったそうです。*1
スライドは各所で何度も見ましたが、こういった発表の経緯を和田さん本人から聴くのは今回が初めてだったので非常に面白かったです。
タイトル名に込められた想い
最初は品質とスピードというタイトル*2を思いついたそうですが、品質っていうと、「品質とは…」とか「まず品質の定義を明確にしないと...」といった議論が始まってしまったりと個々で解釈の齟齬が発生しがちになることを懸念して、質という言葉だと、アレグザンダーが言う"無名の質"で言わているように皆がそれぞれ自覚している概念になるため、このタイトルにしたそうです。
質&スピードのトレードオフ
質とスピードはトレードオフの関係ではないという話が分かった時、じゃあ何が質&スピードのトレードオフになるのかという話が出てくるということですが、これは教育・新技術の調査・次世代への投資が該当するというお話が出ていました。
後の話でも出てきていましたが、新しい言語やテストフレームワークに触れている際の初期は特に、テストを書けるようにするための教育コストは払う必要がどうしても出てくる実感を個人的に持っていることもあり、この話は非常に刺さりました。
質とスピードの変遷
に最新版のスライドはありますが、初期からどのような点が変わっているかのお話がありました。
具体的には、以下の点に変更が入っているということです。
- アレグザンダーが話している無名の質について説明したスライドを無くした*3
- 品質の三角形を無くした
- 23の品質特性をISOの品質特性
- LeanとDevOpsの科学に記載されている4つのメトリクスの話を追記した
- State of DevOpsの調査結果の変遷を辿り、エリートクラスターとローパフォーマークラスターの差がどんどん広がっている旨を追記した
Q＆A
続いて、Q&Aセッションがありました。こちらについても、一問一答形式で質問と回答をまとめていこうと思います。
必要なテストだけを回しているけど実行に時間かかるけどどうしたらいいのか？
毎回全部回す必要はないということでした。
もしテストが10分以内に完了しないなら、実行順序を気にしたり、Red/greenを行き来しているテスト*4だけを実行したりするなどするのがおすすめということです。
なお、Googleでは、テストの実行結果をデータエンジニアリングしており、定期的にテストの棚卸しを行っているということでした。(具体的には、タグを活用して、目的に応じて実行するテストの数を制限するようにする)
また、時間がかかっている場合はE2Eが多すぎてテストピラミッドのバランスが崩れている可能性も往々にしてあるので、Unit Testを増やしていくことも検討した方がいいというお話も出ていました。
テストが乱立しており、カバレッジが十分に網羅できているのか見えないのだがどうしたら良いか？
まず、UTとE2Eテストを同じ設計にするのはアンチパターンだというお話が挙がっていました。(=E2Eテストはカバレッジを網羅する目的で実施するものではない)
E2Eは動く仕様書の目的があるので、テストの実行結果をツリー形式にして、実行結果と対応づけするのが望ましいということで、和田さんはプルリクにテストの実行結果を貼り付けてもらって、テストが仕様書として機能しているのかもレビューするようにすることもあるそうです。
その上で、もし仕様書として既にE2Eを設計しているというのであれば、テスト技法を学ぶことで解決するということでした。E2Eは同値分割するとケースが膨れ上がるので、背面レベルのユーザーケース(ユーザーがログインしてから満足して立ち去るところだけテストする)だけをE2Eで確認するようにするのがお勧めなようです。
また、組織構造の問題として、E2Eを書く担当を分離していると、自分の見えているところだけテストを書こうとする(E2Eで網羅しようとしてしまう)引力が働くので危険だというお話も挙がっていました。
レガシーコードとの闘い方
詳しくは、「レガシーコード改善」を参照ということですが、E2Eで無理やりカバーしながら、静的解析も活用していくという戦略が挙げられていました。
レガシーコードの場合は、あるべき論から入って、最初にテストピラミッドを目指すときついので、上(E2E)からまず攻めつつも下(Unit test)からも支えるという構造を作るのが重要だということです。
また、上記に関連して、レガシーコードと闘う時はどうあるべきは通用しないので、動きが変わったかどうかが分かるキャラクタライゼーションテストを充実させることを和田さんは推奨されていました。*5
なお、Autifyではこのようにまずキャラクタライゼーションテストから攻める戦略を後押しするプロダクトを作っているそうなので、困っている方は是非導入を検討して欲しいということです。
テストコードをみんなが書いてくれない
ユニットテストをまず書く所から始めてもいいのではないかという話がまず挙がっていました。
また、テストを書き慣れていない人は学習コスト高く、質とスピードで言われているようなテストを書きながらソースコードを書くことに慣れていない可能性も高いので、まずはテストが書ける人がテストコードを書くためのチュートリアルを充実させたり、ペアプロやモブプロでテストを書く姿をまず見せてあげることが重要だということです。
テスト文化を社内で広めるにあたってのお勧め本
以下の本が挙がっていました。
技術が分からない人にどのように質とスピードの話を説明するか？
相手に分かる語彙で話をしないとしょうがないので、質とスピードの話をお金と時間に換算して、見積もりと絡めたり不確実性の話をしたりすることが重要だというお話がありました。
このために、エンジニアリング組織論への招待をはじめとした本が参考になるということでした。
この会社or人の文化がよかったというのは？
和田さん個人の印象では、engineering in voyageに書いてある旧voyageグループや、ドキュメント系のサービスやグループウェアを作っている会社は良い文化が根付いている印象があったということです。(はてなとかサイボウズとか)
全体を通した感想
著名なスライドである質とスピードの話はこれまで色々な場所で話を聞いていきましたが、このスライドを作った経緯やスライドの変遷など、裏話的なお話がたくさん聞けて非常に楽しかったです！
Q＆Aセッションも含めて、大満足の会でした。
