BDDによるソフトウェアテスト自動化
次に紹介するのは、BDD（振る舞い駆動開発）スタイルでソフトウェアテストの自動化を行った事例のセッション「Chasing the Giant Rabbit: A tale of Software, Automation & Outsize Bunnies」です。講演者はROQ社のテスト自動化アーキテクトJonny Fletcher氏。氏は、UK最大のペット用品販売会社のシステムに対して、機能テストの自動化フレームワークを導入した経験を共有してくれました（執筆担当：千葉真弓）。
ソリューション全体の構成は、Java、Cucumber、Windowsアプリ向け自動化フレームワークのWinium。そしてCI（Continuous Integration）ツールとしてJenkinsというものです。テストフレームワークの要件としては、POS端末とのインタラクションに対応でき、.NET Frameworkベースのデスクトップアプリケーション、Windows OSのサーバという構成に対応できる必要がありました。
紹介された事例では、本番環境リリースする都度発生する、受入／リグレッションテストにかかる時間の短縮が自動化導入の目的でした。導入前、リグレッションテストすべてを実施するのに、テスター2人で2週間かかっていたといいます。
他のセッションでも出てきましたが、自動化導入時にこの「なぜ」導入するかを明確にしておくことが、自動化成功の一つのカギであると筆者は考えます。自動化は生産性向上などを目標に掲げがちですが、時間短縮や品質向上にも寄与するものであり、「とにかく自動化」とはじめてしまい、あれもこれもと求めた結果、全員が満足しない結果に終わった事例を意外に多く見かけます。
プロジェクトはアジャイル開発スタイルを採用していました。古いテストケースはアップデートされておらず、その精査から必要となりました。テストケースは既存のケースを、ユーザーストーリーとその受入基準に沿う形で作成し、BDD形式の自動化フレームワークを導入、ツールはすべてオープン系の製品で揃え、既存のCIのパイプラインとも連動させ、ダッシュボードでのレポートまでつながるようにしました。
テストケースは、ユーザーの振る舞いを「Given - When - Then」というフレームで定義するようにしました（Given：こういう条件で、When：これをしたとき、Then：何が起きる）。自然言語に近い形式のフォーマットをCucumberのようなBDDフレームワークが読み込み、Winiumを利用してデスクトップアプリケーションを自動実行します。
この取り組みにより、2週間かかっていたリグレッションテストが夜間7時間まで短縮されました。その結果、リスクベースアプローチなども考慮する必要がなくなり、リリースごとにすべてのリグレッションテストケースを実行できるようになりました。さらに、不要トランザクションの発見、新しい障害の検知、自動化スクリプトによる基本的な性能テストまでもが実現可能となり、自動化のテストケースが時間の短縮だけでなく、副次効果をもたらし、クライアントの評価も上げる結果へとつながりました。
一方で、難しい点も見つかりました。例えば、カードリーダーやレシートプリンターといった、物理的な端末の自動化です。カードリーダーが接続できないと、現金のトランザクションしか検証できませんし、レシートプリンターは紙がなくなっても動いてしまいます。自動化を進めていっても、最終的に手動テストは残ってしまうのです。
「手動テストはなくならない」というのは、今回のカンファレンスで幾度となく耳にする言葉です。ソフトウェアテストの自動化は今後も広がっていくでしょうが、ソフトウェアテスターは「まだ」生き残れるように感じます。
資料はこちらで公開されています。
