Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

継続的システムテスト

JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。

 

ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。

背景:開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる

リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに対して、要件を小さくする事でlead timeを短くし、顧客に価値を迅速に届けられるようにする。

一方で、リーンやアジャイルの開発スタイルを成功させる鍵はソフトウェアの品質であり、早期からシステムテストを実行する事が重要である[2]。継続的にシステムテストを実行し、新機能の振る舞いが正しい事やデグレが起きていないかを検証をするには自動化が必要になる。

DevOpsは、顧客からのフィードバックを迅速に開発へと反映させるサイクルを作ろうという概念だ。顧客からのフィードバックをもとにした迅速な改善を継続的に実現するために、継続的インテグレーション(CI)や継続的デプロイ(CD)、継続的モニタリングなどのプラクティスを実践する[3]。CIやCDほど知られていないが、継続的テストの実施は迅速な改善のサイクルを安全に回すためやはり重要だ。

目的:何故、自動化の対象がシステムテストなのか?

テスト自動化ピラミッドはそのROIと優先順位について説明している[4]。一般的に、単体テストやコンポーネントテストはシステムテストに比べて自動化のコストが低く、ROIが高いと考えられている。品質は積み上げる必要があり、セオリーとしてのテスト自動化ピラミッドに疑問の余地はない。しかし、テスト自動化の効果はプロジェクトやソフトウェアのタイプ等、コンテキストに強く依存する[5]。アクセプタンステストの自動化を優先したプロジェクト運営の事例も報告されている[6]。

ビッグデータ関連のアプリケーションは複雑なアルゴリズムを大規模なデータに適用するため、複数のコンポーネントが複雑に分散、協調するように設計されている。また顧客に提供する価値はソフトウェアの機能性だけでなく、分析に使っているデータの質や量にも強く依存する。

そのためビッグデータ関連のアプリケーションでは可用性や運用性といったクラウドプラットフォームとしての性質の検証と、アルゴリズムとデータの両者の面から評価する事が顧客の価値につながる。これらの検証と評価を行うのがシステムテストであり、それを継続的に実行していく環境を提供する事は、すなわち開発者や分析者の継続的な改善のサイクルにつながる。

継続的システムテストのメリット:バグ修正日数の改善の理由は?

ビッグバンマージが解消された事と開発者のタイミングでシステムテストを実行出来るようになった事が理由として考えられる。

プロジェクトの最後に結合の開始やスモークテストの実施を行うと、そこで初めて仕様やインターフェースの不一致、バージョン間での互換性の問題や、予期しない外部仕様の変更が見つかる事がしばしばある。ビッグバンマージにより、それらの問題が複雑に絡み合い、バグの特定や修正に時間がかかってしまう。継続的に変更をマージし、スモークテストを実行する事で、まだシンプルなままの形でバグを見つけ修正する事が出来る。"リーン開発の現場"にも同様の解説がある。

また、手動で行っていたときはシステムテストのコストが高かったため、他のバグが直るのを待ってから複数のバグの再検証を一度に行う必要があったが、自動化してからは開発者や分析者が自分のタイミングでシステムテストを実行出来るようになった。バグが発見されてから修正し検証するまでがリーンになる事もバグ修正日数の改善に影響している。

評価:バグ修正日数を評価軸に使った理由

プラクティスやプロセスなどの開発スタイルを評価する場合、異なるプラクティスやプロセスとの比較が可能な評価軸を選択する事が重要である[7]。テスト自動化の評価の場合、カバレッジの向上や、コストの削減、バグの修正日数が考えられる。

我々は2つの大きな信念を持っている。1つ目は、テストそれ自身はサービスのクオリティを上げない、サービスのクオリティを上げるのは分析と開発である事。2つ目は、テスト自動化の目的は分析者や開発者の継続的な改善のサイクルを加速する事である。

自動化によるカバレッジの向上や、コストが○○億円下がった事についての計算はしている。しかし、この発表の論旨は"継続的にシステストを実行する事で、継続的な改善のサイクルを加速する"ことなのでバグ修正日数を評価軸として採用した。

まとめ:継続的システムテストは継続的改善の始まり

継続的システムテストの実現によりアジリティを改善する事は、開発者や分析者の継続的な改善のサイクルを加速する重要な1ステップ目だ。継続的システムテストにより、機能、非機能要件やアルゴリズムにデグレが起きていない事を確認する事で、積極的で安全な改善を促進出来る。加えてシステムテストの自動化は、サービス改善のためのメトリクスの収集を継続して行うための枠組みが出来た事を意味する。これから、継続的改善が始まる。

追記

継続的システムテストでの自動テストの質やバグカーブについてメトリクスに基づいて行った分析と考察をソフトウェア品質シンポジウム2014で経験発表しました。こちらも合わせてご覧下さい。


ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation

参考文献

[1] "リーンとカンバンの本質", 平鍋健児

[2] アジャイル開発における品質保証部門によるシステムテストのアプローチ, 永田敦

[3] 事例から学ぶDevOps実現のためのプラクティス, 黒川敦

[4] はじめてのスクラム体験ワークショップ ~ アジャイル時代のテスターを目指して, 川口 恭伸

[5] コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて, 森崎修司

[6] 「最強」のチームを「造る」技術基盤 ディレクターズカット, Ito Hiroyuki

[7] 関係者に理解してもらえるアジャイル開発にむけて, 森崎修司