2006年の設立以来、Unrulyはチームとしてエクストリームプログラミング(XP)を実践してきた。Unrulyは、専任のテスト担当者なしで小さなチームでソフトウエア開発をしている。テストファーストの手法を用いてコードを書き、ステージングでの手動テストに頼るのではなく、自動テストに投資をしてきた。
UnrulyのアジャイルコーチであるRachel Davies氏はAgile Testing Day Netherlands 2015で継続的テストについて講演を行った。InfoQは氏にインタビューし、テストの継続的手法の重要性やその育て方、Unrulyで生み出している価値について話を聞いた。
InfoQ: あなたのチームでなぜ自動テストが大切なのか教えていただけますか。
Davies: 自動テストは素早く、手動でテストするより信頼が置けるので重要です。手動テストは退屈な仕事です。セールス部門から変更を依頼されたその日にその変更を配置することができるのが望ましいです。これを可能にするには、配置スクリプトを自動化する必要がありました。これによって自動テストも実行できるようになりました。コンピューターは反復的な処理を人間よりも素早く実施できますので、自動化することで価値あるソフトウエアを素早く提供できます。
InfoQ: Unrulyのチームが自動テストでどのくらい助かったのか具体例を教えてください。
Davies:セールスパーソンが本番環境に変更を依頼できます。私たちは日を置かずに数時間でこの変更を反映したいと考えています。しかし、私の環境はコードを配置するべき内部のステージング環境を待たないという特殊な環境です。その代わり、直接運用環境に変更を反映します。価値をなるべく早く提供したいからです。運用環境へ新しいコードを配置しますが、そのまますべてのユーザに公開されないようにする方法をいくつか持っています。小さく発展的なステップを踏み自動テストを使って望ましい動きになっていることを確認します。遅いテストや扱いにくいテストの問題はチームの振り返りで議論をします。
InfoQ: 継続的テストに投資してきましたね。なぜ継続的テストは価値があるのでしょうか。どのような利益がありますか。
Davies: テストファーストのアプローチを採用することで、機能が期待された動作をすることを確認するテストの網羅性が大幅に改善しました。変更によって既存の自動テストが動作しなくなってもすぐに把握できます。サービスの自動モニタリングも、予期しない条件が生まれていないかどうかを見つけるのに役に立ちます。テストによって製品開発を駆動することでチームは開発すべき機能と運用継続に注力することができます。
InfoQ: Agile Testing Day Netherlandsで、あなたは実際の運用環境で継続的にチェックする方式で自動テストをテストする方法について話しています。この点について説明していただけますか。
Davies: 運用環境のさまざまな条件について通知をするようにNagiosのアラートを仕込んでいます。問題が発生したら、SMS経由で通知をもらい、大きなモニタで負荷と性能を把握します。私たちの開発者のひとりが書いたmonitoring check smellsというブログを読んでみると興味がわくでしょう。
InfoQ: この数年でUnrulyの自動テストはどのように進化したのでしょうか。
Davies: 弊社は2006年に設立され、XPとTDDを実践しました。なので、テストは最初から自動化されていたのです。数年に渡って、テストをブラウザからデバイスのテストへと広げていく必要がありました(ブラウザもモバイルプラットフォームもより多くの機能を持つよう進化したからです)。製品も拡充し、ディスクトップでもタブレットでもモバイルでも、"レスポンシブ"なウェブサイトへ移行するという大きな動きもありました。タブレットなど2006年の段階では想定できませんでした。
非技術者でも理解できるBDDのスタイルのテストは採用しませんでした。最初の頃、FiTnesseを使って受け入れテストを自動化して痛い目にあったからです。開発者はビジネスアナリストではなく利害関係者に直接話します。テストは製品と同じ言語で開発者によって書かれます。なので、BDDスタイルの利点がほとんどないのです。
InfoQ: Chaos Monkeyを使っているとのことですが、詳しく教えてください。
Davies:Netflixのインフラで使われているChaos Monkeyに触発されて、私たちは私たちのドメインに特有な"猿"を開発して、遅延が致命的になるアプリケーションのレスポンシブでないサービス部分など、運用環境のアプリケーションレベルに潜在的な障害を注入しています。これは、テスト環境では見つからない問題を特定し修正するのに役に立ちます。私たちの開発者のひとりであるAlex Wilsonは運用環境のアプリケーションに障害を注入することについてブログで書いています。
InfoQ: 有望そうな新しいテスト手法や検討中のテスト手法はありますか。
Davies: 手動の探索的テストにもっと注力すると効果があるかもしれないと思っています。探索テストの従来の定義は、"学習とテスト設計、テスト実施を同時に行う"ということでした。これは、Cem Kaner氏、James Bach氏、Bret Pettichord氏が書いた2002の本であるSoftware Testingに書かれている定義です。自動テストと違い、スクリプトなしでシステムの振る舞いを調査する方法であり、偶発的にシステムの振る舞いを学習します。
InfoQ: 継続的テストに興味がある企業にアドバイスをお願いします。
Davies: 回帰テストをすべて自動化することから始めましょう。BDDに惑わされないようにしましょう。スモークテストとして自動のヘルスチェックを始め、段階的に網羅性を改善します。ビジネス上最も重要なロジックやよく不具合を起こす領域から始めるのがいいでしょう。