９月１０日〜１２日まで参加したソフトウェア品質シンポジウムでは、”継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析”という経験発表を行い、「SQiP Best report Future Award（将来役に立つ可能性を秘めているもの）」という賞を頂きました。
この記事ではこの継続的システムテストについて、ソフトウェア品質シンポジウムへ参加し聴講した基調講演やセッション、ディスカッションを通して考えた事を書きます。
継続的システムテストのバックグラウンド
ビジネスとソフトウェアの品質の変化
クラウドやスマートフォンなどの技術革新によるビジネスを取り巻く状況が変化してます。そういったビジネスの変化に伴うソフトウェア品質の変化についてのソフトウェア品質シンポジウム2014での東京会場日動システムズの横塚さんの基調講演がとても印象的でした。
ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 － Publickey
システムテストや品質保証に求められる変化
独立した組織として品質の門番の役割を果たすだけでなく、積極的に開発者やユーザーと結びついて、もっと価値を提供していこう、そういった考え方の変化がシステムテストや品質保証に求められています。ここでは２つご紹介。
継続的システムテスト
私たちは近年のこういったシステムテストや品質保証の変化の中、システムテストを自動化し継続的に日次で実行する継続的システムテストというアプローチをとっています。
JaSST' Tokyo 2014では継続的インテグレーションから継続的システムテストへと拡張するため私たちが取り行った施策、またシステムテストの自動化により自動化前に比べバグの修正日数が中央値で５日から２日へと改善されたという開発者へのメリットを報告しました。
継続的システムテストについて - Test Automation
継続的システムテストの実現
開発者とテスターのどちらがテスト自動化をするべきか？？
システムテストの自動化について社内外の勉強会でお話しすると「テストの自動化は開発者、テスターどちらがやるのが良いか？」という質問を必ず貰います。
おそらくこの質問の裏には「テスト自動化の重要性は分かる。Seleniumなどのツールも使える。開発者とテスターが協力する事が大切という事も分かる。でも、どういう風に開発者とコミュニケーションを取りながらプロセスを回せばよいのか具体的に分からない」という疑問をみなさん持っているのかなあと想像しています。
自動化とテストプロセス
実際私たちもテスト自動化がプロセスとして無理なく実行出来るようになるまで多くの苦労がありました。その中でも特に苦労した点は、テストプロセスのプロセス品質を落とさずに、そのサイクルタイムを短くすることです。ここで大事なのは意外と単純な以下の２つです。
- テストプロセスへのインプットの正確性
- 開発•テストプロセスの一気通貫したマネージメント
テストプロセスへのインプットの正確性
テストプロセスは、テスト設計を行うのに必要な機能の仕様と設計をインプットとして受け取ります。機能提供のスピードが求められるので、完璧なドキュメントを作る事はしません。しかし、この仕様や設計に間違いや抜け漏れがあると、いわゆる手戻りによるテスト設計やテストケース実装のやり直しが発生してしまいます。
仕様や設計の間違いを減らすためテスターは積極的にこれらの作成に関わります。実際にテスターのレビューにより仕様や設計の間違いや抜け漏れがテスト設計の前に発見、修正された事が何度もあります。
ここで注意したい事は「完璧なドキュメント」を求めているわけではない事です。ブレインストーミング段階のメモ程度のレベルでディスカッションを行っています。そういう意味では、機能の仕様策定や設計を開発者とテスターが一緒に行っていると言った方が正確かもしれません。
開発•テストプロセスの一気通貫したマネージメント
せっかくテストプロセスへの入力の間違いを減らす事が出来ても、開発とテストプロセスが別々にマネージメントされていては意味がありません。理想は、機能実装とテスト実装が同じタイミングで終わる事です。
機能実装とテスト実装を同じタイミングで終わらせるためには、両者のプロセスを一気通貫したものとして捉えたマネージメントが必要になります。例えば、SQiPの経験発表で取り上げた「スモークテストを壊すようなコミットを分割する」がこれにあたります。（ブログエントリトップのスライドの31p以降の分析です。）
このスモークテストについての議論は、今回の経験発表の分析の中でも個人的に特に興味深いと考えている部分です。開発•テストプロセスが一気通貫している世界で「コミット数」という開発のメトリクスと「検出バグ数」という品質保証のメトリクスを横、縦の軸にとり、いわゆるバグカーブを描いてみるとプロジェクト運営に有用な情報が色々得られる可能性がある、という事が分かったからです。
テスト自動化はバグカーブをより早く収束させるためのプロセスの最適化として捉えると、テストや品質のエキスパートの方達の得意領域になってくるのではないでしょうか。
つまり。。。？？
ここで、最初の疑問「テストの自動化は開発者、テスターどちらがやるのが良いか？」について考えてみます。開発者とテスターが協力する事で初めてテストプロセスへの入力の正確性を高めたり、開発•テストプロセスの最適化が可能になると私は考えています。つまり私の回答は「テスト自動化は開発者とテスター両者が協力してやった方が良い」です。
継続的システムテストのこれから
テストプロセスの効率化
継続的システムテストのプロセス品質を高めて行くためにはもう一つ、プロセスの効率化が欠かせません。継続的システムテストのテストプロセスでも一般的なものと同じ以下のプロセスがあります。
- テスト設計
- テストケース生成（実装）
- テスト実行優先順位付け
- テスト実行
- 欠陥特定
- 振り返り
- テスト設計や優先順位付けへのフィードバック
メトリクスと開発者の知見の活用
このテストプロセスを効率化していくためにはメトリクスと開発者の知見の活用が重要になります。
「テストの自動化」と言ったときに、今その言葉が指す自動化の対象は「テスト実行」だけである事がほとんどです。ですが、メトリクスを活用する事で、もしかしたらテストケース作成やテストの優先順位付けの多くの部分も自動化する事が可能になるかもしれません。
また、システムテストではテストの抜け漏れが問題となるケースがしばしば起きます。これは、システムテストが自動化されている環境でのテストの網羅性について実はよく分かっていないという課題が根底にあります。○○億件のテストが自動化されていると有名なGoogleのSETとICST 2014で「システムテストの網羅性と十分性とを評価する指標が今後必要になる」と話す機会がありました。
テストプロセスの中でもテスト設計と欠陥特定は特に重要な部分であり、テストが自動化された環境でもヒトがたくさんの時間をこの２つに割く必要があります。このテスト設計や欠陥特定をより早く正確に行うための開発者の知見の活用も重要です。
おわりに
「継続的システムテストは新しい概念なのか？」と言えばそんな事はないです。継続的インテグレーション(CI)や継続的デリバリー(CD)に本来内包されるべきものです。
ただ、CIやCDでは"従来のシステムテストや品質保証はどうなるのか”についてスポットライトがあてられていないため、システムテストについては様々な論争が巻き起こっているのも事実です。
私の一連のContinuous System Testについての活動について、海外のアジャイルテストのエキスパートに「Good to see system test getting some love」とコメントを頂いた事もあり、まぁシステムテストに対してみんな愛が足りないよな、と。 （笑）
この継続的システムテストという考え方と経験発表は、「システムテストの自動化」「メトリクス」に着目したアジャイルなプロジェクトの中でもかなり希有なものであり、これからの開発プロセスの変化の中でシステムテストや品質がどう変わっていくのかを考える一助になればと思います。
