継続的テスト＜Continuous Testing＞
CI（Continuous Integration ： 継続的インテグレーション）、CD（Continuous Delivery ： 継続的デリバリ）という言葉は既に広く浸透しており、システム開発にかかわる方であればご存じかと思います。
弊社OpenTextでは１０年前からCT（Continuous Testing ： 継続的テスト）という考えを推奨しており（その当時はHewlett Packard社でした）、現在までDevOpsにおける品質管理のを推進活動を続けています。
ここでいう継続的テストはxUnitに代表されるユニットテストだけにとどまらず、機能テスト／サービスのテスト／パフォーマンステストを開発の初期段階から計画し、イテレーションにおけるCI/CDプロセスにテストによる品質チェックを組み込むことによって、後半フェーズへの問題の持ち越しを防ぐ考え方です。
新しい開発手法やOS環境
継続的インテグレーションでは、定期的にビルドを実施してコンパイルエラーを取り除き、同時に静的ソースコード解析によってソースコード規約に違反しているコードや、パフォーマンス／脆弱性の問題を含んだコードを自動的に検出して早期修正を実施されるケースも多いと思います。ウォーターフォール開発では初期から実施可能なテストは静的なコード解析に限られていましたが、継続的にビルドを実施している現在ではユニットテストに加えて、画面の機能テストや負荷テストも実施可能な環境が整っていることになります。
また、開発したアプリが動作するOS（Windows、Linux, MacOS, iOS, Android）もクラウドとの兼ね合いを考えて早いサイクルで新しいバージョンがリリースされるようになっています。
開発手法やOSなどの環境面のサイクルが早くなった今、システムのテストも継続的に実施する必要があり、多くなったテスト回数に対応するためにはテスト自動化は必須と言えます。
継続的テストにおける画面の機能テスト
Agile開発を実施している環境でもっとも一般的なのは、xUnitの形式で呼び出し可能な画面の機能テストツールかもしれません。
その場合は、以下の図のようにGit等のソース管理サーバにテストスクリプトを保存し、CIツールのJobクライアントマシンに自動テストツールをインストールした状態にし、CIツールのJobによってテストスクリプトのダウンロードとテスト実施を実行します。
この場合、テスト結果として記録されるのは主に「成功」「失敗」の結果となるため、例えばテストが失敗した時にどの部分で失敗し、どこを修正すれば良いかなどはテスト結果を手作業でトレースする必要があるかもしれません。
テスト管理サーバと連動して自動実行可能なテスト自動ツールを使用する場合には、以下の構成で機能テストを「継続的テスト」にすることが出来ます。
テスト管理サーバの起用を使用することで、テストの成否とテスト結果レポート、バグ情報とのトレーサビリティ確保が可能となります。
継続的テストにおけるパフォーマンステスト
パフォーマンステストには、「負荷テスト」「ストレステスト」「スパイクテスト」など複数の種類がありますが、多く実施されているのは「負荷テスト」かもしれません。
その「負荷テスト」も、システム開発／テストの終盤で一度だけしか実施されていないのではないでしょうか。
継続的テストにおいては開発の初期段階からパフォーマンステストのスクリプトを開発者が用意し、継続的にそのテストを実行することによってパフォーマンスの問題も早期に検出／対応し、そのスクリプトを後半の負荷テストでも使用することによって大規模な負荷テストの効率的な実施を目指します。
後工程のテスト効率化も可能であることから、弊社ではこのプロセス全体をカバーするパフォーマンステストの考え方を、Shift Leftではなく「Shift Everywhere」と呼んでいます。
継続的テストにおけるサービスのテスト
Webサービスやマイクロサービスの形式で作成されたシステムが多くなってくると、画面部分とサービス部分を分けて開発することも可能となります。
呼び出されるサービスのテスト：開発の初期フェーズでサービスをテストする場合には、それを呼び出すスクリプトを作成して実行する方法や、サービスの定義を記述して呼び出すツールを使用する方法を使用することが可能です。
呼び出す画面のテスト：開発の初期フェーズで画面をテストする場合には、呼び出されるサービスのモックなどを作成し、それを呼び出す形で画面を実行します。サービスを仮想的に立ち上げることが可能なツール（Service Virtualization）を使用する場合には、サービスの定義を記述するか呼び出しをキャプチャするなどして、サービスのテストを作成します。
この環境を用意することによって、初期フェーズで開発途中のサービスや画面がある場合にも、継続的テストによって品質のチェックを回すことが可能となります。
継続的テストにおける脆弱性のテスト
脆弱性に対する静的ソースコード解析のテストは一般的であり、パスワード的なものをクリアテキストで扱っている場合や、Web画面で入力値をチェックせずにそのまま別処理に使用しているケースなどを検出して修正方法を教えてくれます。ですが、Web画面の脆弱性は実際に画面を表示させて、問題を起こす可能性がある内容を入力してみないと判断出来ないことが多く、動的なチェックが非常に重要になります。
Web画面の動的チェックはWebアプリの構造や攻撃手段、既知の脆弱性などの知識が必要となるため、セキュリティの専門家ではない開発者が自分でチェックするのは難しい場合も多くあります。
こちらも信頼性のある脆弱性診断ツールを活用することをお勧めいたします。
今回のまとめ
システム開発におけるテストは、非常に重要だとわかっていてもどうしても開発の作業に時間をとられて後工程にずれ込んだり、テスト不足になったりすることもあるかと思います。
加えて、テストを継続的に行うには同じテストを何度も実施する必要があるため、人手による作業では対応出来なくなり、自動テストツールの出番となります。
ツールは上手く使えば非常に便利なものではありますが、あくまで人を手助けするためのツールでしかありませんので、人間が考えて対応すべきところとツールで代替可能なところを見極めて、本当に重要な部分に人間がフォーカス出来る環境を構築することが大事なのだと考えます。
