Continuous System Test
Written by Kotaro Ogino and Francois Picalausa
Background of this entry:
We reported on our experience with automated system testing for improving development process of large and distributed search platform (システムテスト自動化による大規模分散検索プラットフォームの開発行程改善) at Japan Symposium on Software 'Tokyo 2014.
This entry is the English version of 継続的システムテストについて - kokotatata's blog which explains the background of continuous system testing presented at the symposium.
Note: Currently the slides are only in Japanese. We hope we will have the opportunity to hold the presentation in English in the near future.
Background: Why continuous testing is important for Lean and DevOps.
Lean is a software development style which focuses on fast delivery of features of software to customers[1].To this end, one small requirement is implemented in each development cycle. Hence requirements analysis and development cycles are short, and value can be delivered rapidly to customers. Lead time is also decreased. Compared to waterfall, in which analysis, design, implementation and quality assurance are each tackled in one go, Lean allows to deliver value to customers more quickly.
On the other hand, a key factor in sucessful implementations of Lean and Agile development is software quality. For ensuring software quality in a Lean and Agile development, quality assurance activities should be conducted from earlier phases of a project[2]. In particular continuous testing helps verifying new features and preventing regressions.
DevOps is a culture where quick and fast feedback from customers to developers and analysts is valued. The realization of DevOps requires making a continuous improvement framework based on Agile practices[3]. Such practices include continuous integration (CI), continuous delivery (CD), and continuous monitoring. Continuous testing is not as well kown as CI and CD, but it can also help creating a safer continuous improvement cycle.
Objective: Why should we automate system tests?
The test automation pyramid is a representation of ROI and priority of automation for different test categories[4]. In general, unit tests and component tests lie at the bottom of the pyramid as they have high ROI. Integration tests, System tests, and acceptance tests which are a few levels above, should have lower ROI in theory, as quality is accumulated from lower levels. However, the effectiveness of test automation strongly depends on the context of the project, such as the culture of the team, and the characteristics of the software[5]. For instance, Ito Hiroyuki reports on a project which whose prioritisation of automation of acceptance tests led to high ROI [6].
Big Data related applications analyze large volumes of data with complex algorithm. In general, these applications are designed as distributed and collaborative. In addition, values for customers are not only depending on functionality of software but also on quality and size of the data.
Therefore, verification of cloud platforms characteristics including availability and operability and evaluation of both algorithm and data are important to assure customer's values. System testing is one of the places where those verification and evaluation can be conducted. Providing a continuous verification and evaluation environment for those test categories accelerate the continuous improvement cycle for both developers and analysts.
Benefits of continuous system test: reducing the time before a bug is fixed.
From our experience, continuous system tests allow to greatly reduce the time before bugs are fixed.
We identified two reasons for this. 1. We avoid big bang merges resulting from fixing system wide issues. 2. Developers can conduct system testing in their own timing.
We detail these two points next.
1. System tests can detect integration issues including specification and interface mismatch, incompatibility of versions and unexpected external specification changes. Continuous system testing aims to avoid encountering these issues at the very end of a project. Indeed, fixing these issues often implies having big bang merges that only makes the situation worse as the bugs are becoming more complicated and bigger in scope, which in turn means that investigation and fix take longer time.
Continuous system tests aim to reduce this problem by exercising the whole system in a continuous way. In particular, quick feedback is provided to developper by means of smoke tests which are quick, but usual test scenarios that the system should handle.
Using this technique, along with continuously merging source code changes allow developers to find out the integration issues as soon as possible, when their resolution is easier and quicker. This observation was also made by Henrik Kniberg in Lean from the Trenches (in its Japanese translation リーン開発の現場).
2. In addition, the cost of system test execution was very high so we needed to minimize the number of system tests that are run. For this reason, we run system tests only after a set number of bug fix and we verify them together. Since we automated these tests, our developers can verify the impact of their changes on their own schedule. The time frame for fixing bugs, from their discovery to the verification of the fix by automated system test, is shorter and the process becomes lean.
Evaluation: A reason for using "number of days for bug fix" for evaluation
For evaluating Software development practices and processes, evaluation metrics must allow comparing different practices and processes[7]. For evaluating test automation, coverage improvement, cost reduction, and number of days for bug fix can be used as metrics.
We have two important believes. First, tests themselves do not increase the quality of software, it can only be increased through analysis and development. Our second belief is that the objective of test automation is to accelerate the continuous improvement cycle of analyst and developers.
Of course, we calculated coverage improvement and cost reduction for internal project management purpose. However, to verify our assumption that is that continuous system testing accelerates the continuous improvement cycle, we chose the number of days to bug fix as our main evaluation metric.
Conclusion: Continuous system tests initiate continuous improvement.
In this report, we showed that continuous system tests is a first step towards improving development agility. In particular, it accelerates continuous improvement cycle of developers and analyst. Developers and analyst can aggressively push changes and improvments to the software safely, by verifying that their changes meet both functional and non-functional requirements using automated system test. In addition, automation of system test allows us to monitor and collect metrics for service improvement.
We hope to see more and more techniques to improve quality assurance in an agile way. Our journey to continuous improvement starts from now.
References
[1] "リーンとカンバンの本質", 平鍋健児
[2] アジャイル開発における品質保証部門によるシステムテストのアプローチ, 永田敦
[3] 事例から学ぶDevOps実現のためのプラクティス, 黒川敦
[4] はじめてのスクラム体験ワークショップ ~ アジャイル時代のテスターを目指して, 川口 恭伸
[5] コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて, 森崎修司
[6] 「最強」のチームを「造る」技術基盤 ディレクターズカット, Ito Hiroyuki
[7] 関係者に理解してもらえるアジャイル開発にむけて, 森崎修司
継続的システムテスト
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。
ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。
背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる
リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに対して、要件を小さくする事でlead timeを短くし、顧客に価値を迅速に届けられるようにする。
一方で、リーンやアジャイルの開発スタイルを成功させる鍵はソフトウェアの品質であり、早期からシステムテストを実行する事が重要である[2]。継続的にシステムテストを実行し、新機能の振る舞いが正しい事やデグレが起きていないかを検証をするには自動化が必要になる。
DevOpsは、顧客からのフィードバックを迅速に開発へと反映させるサイクルを作ろうという概念だ。顧客からのフィードバックをもとにした迅速な改善を継続的に実現するために、継続的インテグレーション（CI）や継続的デプロイ(CD)、継続的モニタリングなどのプラクティスを実践する[3]。CIやCDほど知られていないが、継続的テストの実施は迅速な改善のサイクルを安全に回すためやはり重要だ。
目的：何故、自動化の対象がシステムテストなのか？
テスト自動化ピラミッドはそのROIと優先順位について説明している[4]。一般的に、単体テストやコンポーネントテストはシステムテストに比べて自動化のコストが低く、ROIが高いと考えられている。品質は積み上げる必要があり、セオリーとしてのテスト自動化ピラミッドに疑問の余地はない。しかし、テスト自動化の効果はプロジェクトやソフトウェアのタイプ等、コンテキストに強く依存する[5]。アクセプタンステストの自動化を優先したプロジェクト運営の事例も報告されている[6]。
ビッグデータ関連のアプリケーションは複雑なアルゴリズムを大規模なデータに適用するため、複数のコンポーネントが複雑に分散、協調するように設計されている。また顧客に提供する価値はソフトウェアの機能性だけでなく、分析に使っているデータの質や量にも強く依存する。
そのためビッグデータ関連のアプリケーションでは可用性や運用性といったクラウドプラットフォームとしての性質の検証と、アルゴリズムとデータの両者の面から評価する事が顧客の価値につながる。これらの検証と評価を行うのがシステムテストであり、それを継続的に実行していく環境を提供する事は、すなわち開発者や分析者の継続的な改善のサイクルにつながる。
継続的システムテストのメリット：バグ修正日数の改善の理由は？
ビッグバンマージが解消された事と開発者のタイミングでシステムテストを実行出来るようになった事が理由として考えられる。
プロジェクトの最後に結合の開始やスモークテストの実施を行うと、そこで初めて仕様やインターフェースの不一致、バージョン間での互換性の問題や、予期しない外部仕様の変更が見つかる事がしばしばある。ビッグバンマージにより、それらの問題が複雑に絡み合い、バグの特定や修正に時間がかかってしまう。継続的に変更をマージし、スモークテストを実行する事で、まだシンプルなままの形でバグを見つけ修正する事が出来る。"リーン開発の現場"にも同様の解説がある。
また、手動で行っていたときはシステムテストのコストが高かったため、他のバグが直るのを待ってから複数のバグの再検証を一度に行う必要があったが、自動化してからは開発者や分析者が自分のタイミングでシステムテストを実行出来るようになった。バグが発見されてから修正し検証するまでがリーンになる事もバグ修正日数の改善に影響している。
評価：バグ修正日数を評価軸に使った理由
プラクティスやプロセスなどの開発スタイルを評価する場合、異なるプラクティスやプロセスとの比較が可能な評価軸を選択する事が重要である[7]。テスト自動化の評価の場合、カバレッジの向上や、コストの削減、バグの修正日数が考えられる。
我々は２つの大きな信念を持っている。１つ目は、テストそれ自身はサービスのクオリティを上げない、サービスのクオリティを上げるのは分析と開発である事。2つ目は、テスト自動化の目的は分析者や開発者の継続的な改善のサイクルを加速する事である。
自動化によるカバレッジの向上や、コストが○○億円下がった事についての計算はしている。しかし、この発表の論旨は"継続的にシステストを実行する事で、継続的な改善のサイクルを加速する"ことなのでバグ修正日数を評価軸として採用した。
まとめ：継続的システムテストは継続的改善の始まり
継続的システムテストの実現によりアジリティを改善する事は、開発者や分析者の継続的な改善のサイクルを加速する重要な１ステップ目だ。継続的システムテストにより、機能、非機能要件やアルゴリズムにデグレが起きていない事を確認する事で、積極的で安全な改善を促進出来る。加えてシステムテストの自動化は、サービス改善のためのメトリクスの収集を継続して行うための枠組みが出来た事を意味する。これから、継続的改善が始まる。
追記
継続的システムテストでの自動テストの質やバグカーブについてメトリクスに基づいて行った分析と考察をソフトウェア品質シンポジウム2014で経験発表しました。こちらも合わせてご覧下さい。
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
参考文献
[1] "リーンとカンバンの本質", 平鍋健児
[2] アジャイル開発における品質保証部門によるシステムテストのアプローチ, 永田敦
[3] 事例から学ぶDevOps実現のためのプラクティス, 黒川敦
[4] はじめてのスクラム体験ワークショップ ~ アジャイル時代のテスターを目指して, 川口 恭伸
[5] コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて, 森崎修司
[6] 「最強」のチームを「造る」技術基盤 ディレクターズカット, Ito Hiroyuki
[7] 関係者に理解してもらえるアジャイル開発にむけて, 森崎修司
