「事業継続を支える自動テストの考え方」──Autify末村さんをお招きして勉強会を開催しました
はじめに
レバテック開発部の江間です。
現在、レバテック開発部では自動E2EテストにAutifyを活用しています。
そのご縁で、オーティファイ株式会社のQuality Evangelistであり、『テスト自動化実践ガイド』の著者でもある末村拓也さんにご登壇いただきました。
講演のテーマは「事業継続を支える自動テストの考え方」です。
スライドには載っていない話や、印象的だったフレーズも交えながら、講演の全体像が伝わるようにまとめてみました。
開催経緯
半年ほど前、部内でのAutifyの利用が期待したほど進んでおらず、その状況を改善したいと考え、末村さんに相談したのが最初の出会いでした。
その際にいただいたアドバイスをもとに取り組んだ内容の一部は、以下の記事にまとめていますので、ご興味のある方はぜひご覧ください。
その後、ある程度利用が軌道に乗ったタイミングで、
「テストやソフトウェア品質に対する意識をさらに高め、知見を広げられないか」と考えるようになりました。
そこで、テスト分野の第一線で活躍されている末村さんに講演をお願いし、チーム全体の意識や視野を広げる機会にしたいと考えました。
また、書籍『テスト自動化実践ガイド』を執筆されている方の話を実際に聞いて刺激を受けてほしいというのが、私個人の強い動機でもありました。
テーマ決め
講演会の開催にあたり、テストやソフトウェア品質に関する関心分野や、チーム内の個別課題を把握するために事前アンケートを実施しました。
特に関心が高かったのは、以下の3点です。
- コードの保守性
- ドキュメント不足
- テストカバレッジ不足
また、2024年末に実施したリスクベースドテスト勉強会では、事業インパクトをもとにテストシナリオを作成するワークショップを行い、「事業と開発を紐づけて考えることの重要性は理解しているものの、実際には意識できていない部分があるかもしれない」といった気づきも得られました。
こうした背景を踏まえ、今回は「事業継続を支える自動テストの考え方」を主軸テーマに、講演をお願いしました。
あわせて、アンケートで挙がった関心テーマやチームの課題にも触れていただけるよう、ご相談させていただきました。
日々の開発業務の中では、どうしても事業という視点が薄れがちです。
この講演が、その視点を思い出すきっかけになり、チームにとって新たな気づきや一歩につながる時間になればという思いを込めて、今回の講演を企画しました。
講演内容
詳細はスライドをご覧いただくのが良いかと思いますが、ここでは当日印象に残った話や、スライドには記載されていない補足的な内容をいくつかピックアップして紹介します。
事業とソフトウェア
講演はまず、事業継続にともなうソフトウェアの課題についての話から始まりました。
- 退職や異動により、仕様や要求の背景がわからなくなる
- 仕様書が古いまま放置され、最新の状態が追えない
- 実装が積み重なり、内部ロジックが複雑化する
- 影響範囲が見えず、改修すること自体がリスクになる
事業側の視点からも、以下のような課題が挙げられていました。
- 開発スピードの低下
- 問い合わせに対する返答が曖昧・遅れる
- リファクタばかりしていて進捗が見えないように映る
これらの問題に対する解決策のひとつが、自動テストです。
講演では、自動テストは「エンジニアの知恵」であると表現されていたのが印象的でした。
自動テストは契約を守り続けるための技術
続いて、自動テストを「契約(コントラクト)を守る技術」として捉えるという話に展開されました。
ここで登場する役割は3つです:
- プロバイダー:機能を提供する側(=システム)
- コンシューマー:機能を利用する側(=ユーザー、他システム)
- 契約(コントラクト):期待されるふるまいを定義するもの
明示的な仕様書だけでなく、暗黙の期待も含めてこの「契約」が成り立っているとのこと。
プロバイダーのふるまいが変われば、契約が破られる可能性があり、それによってシステム全体が意図しない挙動を引き起こすリスクが生まれます。
それを検知・維持するのが、自動テストの重要な役割です。
印象的だったのは、「自動テストは、常にアップデートされ続ける具体例である」という表現でした。
この話の中では「ECサイトが突然ラーメン屋に変わったらテストで検知できるか?」という、ユーモラスな例えを交えて解説されていました。
- ドキュメントは常に最新とは限らないが、テストは具体例として動作する
- 開発フローに組み込むことで、生きたドキュメントの役割を果たせる
- 特にE2Eテストはその性質が顕著で、現場で非常に有用
実際、私たちがAutifyを利用する中で、新規参画メンバーにはシナリオ作成画面を共有することがあります。
画面キャプチャ付きで主要なユースケースを説明できるため、この点はまさに講演で語られていた通りだと感じました。
事業、アプリケーション、テストは必ずセット
最後に、「事業の進化とともにアプリケーションもテストも進化させるべき」というメッセージが強調されていました。
- ビジネスルールの変更に伴い、アプリケーションやテストも変化する
- 変更のたびに、テストケースの見直し・追加が必要になる
その上で、特に大事なのがテスト可能性を意識してビジネス要件を設計すること。
ここで紹介されたのが、ユーザーストーリー設計のフレームワーク「INVEST」でした。
- I: Independent(独立している)
- N: Negotiable(交渉可能)
- V: Valuable(価値がある)
- E: Estimable(見積もれる)
- S: Small(小さい)
- T: Testable(テスト可能)
Autify社の実例として、「具体例をあらかじめ考え、自動テストを早い段階で作成する」といった現場での工夫も紹介されました。
要件をINVESTの観点で捉えることで、ビジネスの変化にも柔軟に対応できるテスト設計につながるという示唆がありました。
まとめ
今回の記事では、講演の中から印象的だった話題をいくつか取り上げてご紹介しました。
当日はこのほかにも、保守性との付き合い方や、参加者からの個別質問にご回答いただきました。
中でも特に印象に残ったのは、講演の終盤に強調されていた次のメッセージです:
「私はAutifyの人間ですが、Autifyに限らず、さまざまなツールや手法を試してほしいと思っています」
特定のツールにとらわれず、本質的な価値を見極めていくことの重要性を、あらためて気づかせてくれる言葉でした。
講演を通して、事業と開発・品質の関係性を改めて見直すきっかけになったと感じています。
お忙しい中、貴重な知見と実践的な視点を共有してくださった末村さんに、改めて御礼申し上げます。
Discussion