Test Automation

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

個人の経歴2018年バージョン

講演・執筆活動

カンファレンス講演等（日本）

カンファレンス講演等（国外）

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

JaSST'18 Tokaiが楽しかったw話

カンファレンス参加レポート 講演活動

モチベーション

　このブログエントリのモチベーションは、ソフトウェアテスト#2 Advent Calendarを完走することです。今現在（2018年12/10）6つの枠が空いてるので、それぞれの空き日当日になっても空白だったら、どんどん埋めてきます。

qiita.com

JaSST' 18 Tokai

　2018/12/07 (金)に愛知県刈谷市で開催されたJaSST' 18 Tokaiに講演者として参加してきました。カンファレンスは、講演としては平鍋さんの基調講演と我々の特別講演があり、その他にもポスターセッションやチュートリアルなど盛りだくさんで、最後には参加者同士で意見交換する情報交換会もありました。

　このブログエントリでは、JaSST'18 Tokaiで楽しかったところを挙げていくことにします。

JaSST' 18 Tokaiの楽しかったところ

楽しかったところ①:オープニングスピーチの委員長

　オープニングスピーチの委員長のスピーチがエネルギーいっぱい、駄洒落いっぱいで面白かったです。いろいろ話を聞いてみると、委員長のスピーチはJaSST' Tokai名物で毎年恒例のものらしいです。

　その場のノリとアドリブで盛り上げている感じのスピーチなのですが、後で「実は、そういうスタイルのスピーチに見えるように、前日カラオケで練習している」というお話も伺いましたが真偽のほどは分かりません。

èªå代æ¿ãã­ã¹ãã¯ããã¾ããã

楽しかったところ②:平鍋さんの基調講演

　平鍋さんの基調講演でのメッセージで印象的だったものとして

  • プロダクトだけでなく顧客も開発するしチームも設計して育てる
  • アジャイル開発では、ウェブサービスは内製化が進んでるし、ベンダーはアジャイル開発拠点に参加するようになる
  • プロジェクトの見える化/透明化が重要。カンバンなど。

があります。特に最初の「顧客も開発する」については、きっとアジャイルの導入やチームへの新規ツールの導入、またOSSの開発など、チームや市場にどんなニーズがどれくらいあるか分からないものについては、みんなアジャイルにやってくのがいいのだろうなあと思いました。

　あと、後で平鍋さんから「１０年間同じ内容で講演している」という話を伺いまして、なるほどこういう情熱を持っている方が持続してメッセージを発信し続けることで日本のアジャイルは発展してきたのだなということを肌で感じました。

　平鍋さんの基調講演の内容については、平鍋さん自身がブログを書かれてますのでそちらもご参照ください。

anagileway.com

楽しかったところ③: 特別講演

　特別講演では、この半年間一緒にDevOps研修を育て上げてきた吉田さんと一緒に、アジャイルやテスト自動化導入の文化的・技術的な事例を紹介しました。

www.slideshare.net

f:id:kokotatata:20181210150955p:plain

アジャイルにおけるテスト自動化の役割

　講演内容についてはスライドを参照いただくとして、ここではtwitterでの感想を紹介します。

 

 

 

 　一緒に発表した吉田さん。実は社外発表は初めてだったのですが、ブルドーザー的なパワーで全部かっさらっちゃいまして、その後の情報交換会などでも吉田さんの講演内容の話題で持ちきりでした(笑)

楽しかったところ④: 情報交換会＆打ち上げ＆飲み会

　情報交換会、打ち上げとその後の飲み会とすごく盛り上がりました。このあたり、シンポジウムの主催者の方達が、会を一方向のものにしないで、双方向のものにしようという気遣い・努力がすごいなと思いました。

　やっぱりこういう社外のシンポジウムでは、普段お話する機会がない方たちといろいろお話できるのがいいですね。少しビックリしたのが、東海の方だけでなく東京や関西から参加されている方がいらっしゃったり、あとエンジニアだけでなく人事の方なんかも参加されてました。この辺、JaSST' Tokaiは懐が深いシンポジウムなんだなーと感じました。

　あと、シンポジウム後の飲み会では平鍋さんとたっぷりお話する機会と、素敵なカード（ハガキじゃないよ）を頂きました。ありがとうございます！

f:id:kokotatata:20181210200449j:plain



楽しかったところ⑤: JaSSTで「アジャイル」という単語を使ってもいいんだと確信した

　完全に個人的な偏見ですが、JaSSTには長らく「アジャイル」をキーワードとして使うことに対する暗黙の禁句的ななにかがあったように思います。完全に個人的な偏見ですが、JaSSTで「アジャイル」というキーワードを出すと、参加者から拒絶反応が返ってくると思ってました。なので2014年に初めてJaSSTで発表した時も、出来るだけアジャイルという言葉を使わずに自分たちの取り組みを説明することに苦心しました。

　ですが今年2018年、「アジャイルとテスト自動化について」前半にはJaSST'18 Tokyoでパネルディスカッションの依頼を頂き、後半には今回のJaSST'18 Tokaiで特別講演する依頼を頂き、流れは変わってきたなあと。

　特に今回、講演後の情報交換会で、参加者のみなさんもアジャイルの導入を始めたりもうすでにいろいろと導入してるお話を聞きました。話の方向性として「アジャイルめっちゃ楽しい」よりも「アジャイル大変」成分が多めなんですが、それでもみんなアジャイルについて話したい、話すことが好きなんですね。

 

最後に

　今回JaSST' 18 Tokaiに参加させて頂きとても楽しかったです。お呼び頂きまして、企画者のみなさまありがとうございました。インタラクティブな会を作ろうとしているのがすごくよくわかりましたし、あと日本の東海地方には東海地方独自のアジャイルがあるんだということが発見でした。ぜひ、また参加してみたいシンポジウムの一つですね。

f:id:kokotatata:20181217183911p:plain

f:id:kokotatata:20181217183924p:plain

 

アジャイルもテスト自動化も当たり前？！ ~AIがテスト設計をする日が来るかも~

はじめに

 このエントリは、ソフトウェアテスト #2 Advent Calendarの６目の記事として書いています。

qiita.com

モチベーション：JaSST'18 Tokyo 振り返り

　JaSST' 18 Tokyo のクロージングパネルでは、実は当初予定していたモノから内容を少し変更してお届けした[1]。GoogleのJohn Miccoさんによる基調講演の際に、Googleのような「アジャイルの導入も100%のテストの自動化も、もう当たり前」という考えと、JaSSTの参加者の多くの「アジャイルの導入もテストの自動化も道半ば、もしくはこれから検討する」との現実の間に、大きなギャップを感じたからだ。

　このブログエントリでは「アジャイルやテスト自動化は当たり前」と考えている人たちが、次の自動化としてどのようなことを考えているのか、なぜアジャイルやテスト自動化はもう当たり前なのかについて簡単に紹介してみたいと思う。

現在のテスト自動化の対象領域

　下記にいわゆるテストプロセスと、その中での現在のテスト自動化の対象領域を示す。

f:id:kokotatata:20181206124037p:plain

現在のテスト自動化の対象領域

一般的にテストプロセスの中には

  • テスト要求分析
  • テスト設計
  • テスト実装
  • テスト実行
  • テスト終了作業

が含まれる。このなかで現在の自動化の対象領域になっているのはテスト実装とテスト実行だ。SeleniumやAppium、またCucumberなどのテスト自動化ツールは、テストコードとして記述したテストの実行を自動で行う[2][3][4]。また、MagicPodのようなツールでは、テスト対象の要素認識やテストコードへの自動変換など、テスト実装の一部を自動化することができる[5]。

　一方、テスト要求分析、テスト設計、テスト終了作業の自動化はあまり行われていない。これは、分析や設計などの判断を伴う作業は単純に自動化することは難しく、人間が判断をする必要があるからだ。では、AIを用いればこれらの判断を伴う作業も自動化ができるのだろうか？

AIとテストエンジニアの共通点

　実は、AIとテストエンジニアはその学習モデルに共通点が多い。次にAIとQAの学習モデルを示す。

f:id:kokotatata:20181206125325p:plain

　AI（この図ではロボットになっているが）は、環境との相互作用から事前知識のない環境について学習する。例えばブロックを扱うロボットの場合、ロボットはブロックに対して触ったり持ったりするアクションを実行する。そのアクションによって引き起こされた結果を、画像や触覚などの様々なセンサーからフィードバックとして受け取る。AIは自分のアクションに対するフィードバックから、環境についての知識を獲得する。このアクションとフィードバックを繰り返すことで、事前に知識がない事象についても学習することができる。

　テストエンジニアも探索的テストにおいて、これと似たプロセスをとる。テストエンジニアはテスト対象システムについての完璧なテスト設計を持たないところからテストを実行し、テスト対象とテスト設計について学習する。UIのボタンをクリックしたり、フォームに文字を入力したり、また強制的にシステムをシャットダウンするなど様々なアクションをテスト対象に実行する。そのアクションによって引き起こされた結果を、システム応答、画面上のメッセージ、エラーなどからフィードバックとして受け取る。テストエンジニアはこのアクションとフィードバックを繰り返すことで、テスト対象システムについての理解を深め、少しずつテスト設計を改善する。

　こうしてAIとテストエンジニアの学習モデルを比較してみると、どちらもアクションとフィードバックを繰り返すことによって対象の知識を獲得していっていることが分かる。

次のテスト自動化の対象領域

　上で見たように、テスト対象に対する理解を深めテスト設計を改善していくためには、アクションとフィードバックのループをテストプロセスの中で構成する必要がある。1回のテスト実行（アクション）が終了しテスト結果が出たら、そのテスト結果をテスト要求分析にフィードバックし学習する。次のテスト実行ではそれにもとづいて改善されたテスト設計を使いテストを実行する。

　このフィードバックループをテストプロセスの中に作ることが出来れば、同じ学習モデルでAIもテスト設計について学習する枠組みを作ることが出来るようになるだろう。これは、将来テスト要求分析やテスト設計をAIを利用して自動化していくことに繋がる。

　しかし、このフィードバックループを作るためには

  1. フィードバックループの精度を向上させる
  2. テスト終了作業の一部を自動化する

必要がある。

　1.は、AIが学習で利用するデータの品質が、AIの品質に直接影響するためだ。例えば、毎回テスト結果の異なるFlaky Testが学習データに大量に含まれていると、AIは効率よく学習することができないだろう。

　2.は大量のテストを高頻度で自動実行している環境では、テスト終了作業を手作業で実行していては追いつかなくなるためだ。実際John Miccoはパネルディスカッションの中でも、「数百万件のテスト結果を人間がすべて確認するのは不可能だ」と話していた。

f:id:kokotatata:20181206134303p:plain

　AIの台頭の中で、テスト実行だけではない、テスト設計やテスト終了作業の自動化がにわかに盛り上がってきているのである。JaSST'18 Tokyo のJohn Miccoさんの基調講演は、テスト終了作業でFlaky Testを自動判別し、テスト結果のデータベースをキレイにするための取り組み出し、例えばFacebookなどもバグ修正の自動化の取り組みを行っている[6]。

次のテスト自動化を始めるためには

　この「次のテスト自動化」を始めるために必要なのがアジャイルとテスト実行の自動化だ。

　テストプロセスの中に学習のためのフィードバックループを作るには、小さなテスト活動を何回も繰り返し回していく必要がある。一度きりの大きなテスト活動では、学習のフィードバックループは回らない。小さなテストを回していくためには、開発自体もアジャイルにする必要があるし、テストもアジャイルに進めていく必要がある。

　もう一つはテスト実行の自動化だ。テスト実行が自動化されていれば、テスト実行にかかるコストがほぼ0になるので、より高速、高頻度でフィードバックループを回すことが出来るようになる。自動化さえしていれば、たとえテストケースが数百万件あろうともこのフィードバックループを数週間から1日で回すことが可能になるのである。

　なので、次のテスト自動化に取り組んでいる人たちは、アジャイルもテスト自動化も当たり前と考えているのだ。

終わりに

　このブログエントリでは、テスト自動化における次の自動化対象領域について紹介した。現在のテスト自動化の多くはテスト実行に集中しているが、テスト設計やテスト終了作業の自動化への取り組みももうすでに始まっている。これらの領域を自動化していくにはAIの利用は必須だろう。AIを効率的にテストプロセスの中で利用するためには、テストプロセスの中でのフィードバックループの構築が重要になる。テストのフィードバックループの構築には、少しずつテストを繰り返すアジャイルの導入と、繰り返しテストを実行するためのテスト実行の自動化は必須となる。

参考文献

個人の経歴・プロフィール2017年バージョン

講演・執筆活動

カンファレンス講演等（日本）

カンファレンス講演等（国外）

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

テスト自動化プロジェクトでExcelを使わない１０の理由

モチベーション

　この記事はソフトウェアAdvent Calendar 2017の11日目のブログエントリとして書いています。

　昨日参加したシステムテスト自動化カンファレンス2017で、「もう２年以上、テスト自動化プロジェクトの中でExcelを使ってないなぁ」ということを思い出した。

　２年半前にガチのExcelファイルで書かれたテスト設計ドキュメントを初めて見て、このやり方ではテストが成長できなくなるということを痛切に感じた。その時の考えを２次元の表によるテスト管理の限界 - Test Automationというブログエントリにまとめてから、うちのチームではExcelをテスト自動化の中で使っていない。

　前回のエントリより２年半経って、Excelを使ってない理由についての考えがより鮮明になってきた、ここでは、それらExcelをテスト自動化で使わない理由をつらつらと書き連ねていく。

テスト自動化プロジェクトでExcelを使わない理由

 理由①：Excelはユーザー環境の互換性や移植性が低い

　Excelの問題の１つ目は、開発者や運用エンジニアなどを含めたテスト自動化プロジェクトの大半のステークホルダーの環境で期待通りに動作しないことだ。Windows上で綺麗に整形されていたり、職人技の関数芸やVBA芸でまとめられたExcelファイルは、残念ながらMacやLinuxでは期待通りに表示されない。僕が今年見た一番ひどいExcelファイルでは、１回データを入力するごとに僕のMac上ではエラーが表示される。

　開発エンジニアや運用エンジニアに人気のOSであるMacやLinuxでまともに動かないツールをテスト自動化プロジェクトで使うことは、エンドユーザー向けにWindows Phoneでは動くが、AndroidやiOSではバグだらけのアプリをリリースするようなものだ。

理由②：テストケースに対するスケーラビリティが低い

　Excelはデータサイズのスケーラビリティが低い。まず、仕様が最大約100万行、最大約2万列と、一般的なテスト自動化プロジェクトで取り扱うテストケース数を考えると少なすぎる。また、実際には数万行を超えたくらいから動作がもっさりしてくる。Excelで表現できるテストケース数はせいぜい数百から数千だろう。

理由③：テストエンジニア/クライアントに対するスケーラビリティが低い

　Excelはユーザ数に対するスケーラビリティが低い。ファイル共有について、メール、共有ファイル、オンライン版など、どれを使うかにもよるが、そもそも数百人が同時にアクセス＆編集するユースケースを想定しているものではない。多分、同じタイミングで一つのファイルを編集する人間は一人か、せいぜい声を掛け合える範囲の数人を想定しているように思う。

　この問題はExcelファイルにアクセスするのが人間でなくテストクライアントの場合、顕著に起こる。テスト実行時間が長くなってきた場合など、テストクライアントを複数並べ平行に実行するようにすることでテスト実行時間を短縮する。数十から数万のテストクライアントが同時に１つのExcelファイルにアクセスした場合、ここがボトルネックになってしまうことは明白だ。

理由④：テスト実行頻度に対するスケーラビリティが低い

　Excelはテスト実行頻度に対するスケーラビリティが低い。同じテストをプロジェクト中に一回、または年に数回程度実行するだけならばExcelでも十分だ。しかし、ほとんどのテスト自動化プロジェクトの目的は柔軟なテストの実行だ。一年を通して毎日継続的に実行したり、場合によっては1日に何百回も実行することもあるだろう。

　テスト実行頻度が増えるにつれ、例えば、テスト結果ドキュメントの数も増大する。Excelでテスト設計を管理すると、数万に及ぶテスト結果との対応関係をとっていくことが難しくなってしまう。

理由⑤：テストケースの最新性の低下

　ExcelファイルがローカルPCと共有ファイルサーバーで２重管理される場合、テストケースの最新性が低下する可能性がある。共有ファイルサーバーにあるファイルが最新なのか？最新のファイルが誰のローカルPCにあるのか？などのデータの最新性の問題が簡単に起こる。加えて、複数のメンバーがローカルのファイルをどんどんと更新し続けたため、あとで変更を１つのファイルにマージするのが大変になるなんてのも、よく聞く話だ。

　これらの問題は、継続的インテグレーション(CI)のような、継続的にファイルをマージしていくフローを作ることで防ぐことが可能だが、ExcelユーザにはCIのような文化がそもそもない

理由⑥：テストケースの差分管理が煩雑

　Excelは２次元でデータを表現するため、行指向でデータを管理するSVNやGitで差分管理しようとすると煩雑になる。極端な例で言えば、１列追加しただけでもすべての行に変更が入るため、データ更新履歴としてはすべての行が対象となってしまう。そのためPullRequestのレビューで、ソースコードとテストケースの変更箇所の比較を行ったりすることが煩雑になってしまう。

理由⑦：テストコード設計の表現力が低い

　テスト設計の成果物であるテスト設計ドキュメントは、その次のアクティビティのテスト実装の入力になる。テスト自動化プロジェクトの場合は、テスト設計ドキュメントを入力として自動実行可能なテストコードを実装する。ここで問題になることは、２次元の表形式のテスト設計は、オブジェクト指向設計などのプログラム設計の手法を用いたテストコードの設計を表現できないことだ。

　例えば、テスト設計では個々のテストケースがテストに必要な情報を網羅する完全性が重視されるが、テストコード設計では、重複する部品を再利用可能なクラスとして定義することが重視される（今年のアドベントカレンダーのこれとかこれとか）。

理由⑧：テストケースの表現の煩雑さが増す

　１つのテストケースは、事前条件、テスト対象、テスト手順、テスト条件、期待値、環境など様々な情報によって表現される。これは、テストケースを表現する軸は多次元であることを意味するが、Excelの表では２次元で表現することになる。

　人間は多次元のデータ操作が苦手なので、多次元のテストケースを非正規化しExcelで表現することにも手動テストの場合には一定の価値がある。しかし、コンピュータもデータ操作するテスト自動化プロジェクトの場合、多次元のデータを２次元で表現するとデータモデルが煩雑になり自動化が難しくなってしまう。

理由⑨：テストケースの保守性<テスト項目の追加>

　Excelの凄いところは、データサイズがそれほど大きくない場合、データの追加や変更のみならず、スキーマやデータモデルの変更も簡単に行える点だ。データベースなどではスキーマ変更などを伴う変更も、列を追加したり変更したりするだけで出来る。

　しかしこの簡便性は、データスキーマの一貫性とトレードオフの関係にある。データベースの煩雑なテーブル定義の制約は、一方でスキーマの一貫性を保証する役割を担っている。しかしExcel自体はスキーマ変更を保証しないため、例えばExcelファイルのテストケースに新しい項目を追加する場合、人間がすべてチェックす必要がある。数十万、数百万のテストケースすべてに対しスキーマの一貫性をチェックするのは困難だ。

理由10：テストケースの保守性の低下<リファクタリングが困難>

　テストケースが増えてきたとき、テスト設計をリファクタリングしたくなることがある。テストカバレッジが下がらないことを保証しながら、テストスイートのグルーピングを変更したり、テストの実行順序を変更したり、テストケースを削除したりする作業だ。定期的にリファクタリングすることで、テストケースを継続的に保守可能な形に保つ。

　テスト設計をリファクタリングするためには、多次元のテスト設計を様々な２軸に射影することが不可欠になるが、もともと２次元の表で表現されている場合、この写像が困難だ。そのため、大胆なリファクタリングを行って大量のテストケースを削減することなどができなくなる。

まとめ

　テスト自動化プロジェクトでExcelを使わない理由をつらつらと書いてきた。もちろんExcelは素晴らしいツールだし、場合によってはテスト自動化プロジェクトでも使っていい場合もあるかもしれない。例えば、チームにあったテスト設計のアプローチを議論する際には、数百くらいのテストケースをExcel上で操作しながら話し合うのはいいかもしれない。また、テストレポートに掲載するグラフのドラフトバージョンを作成したりするのにもExcelは簡便なツールだ。

　一方で、テスト自動化プロジェクトに組み込むためには、Excelには制限が多すぎる。 特に、テストケース数やテストエンジニア/クライアント数に対するスケーラビリティの問題は、テスト自動化にとっては致命的と言える。また、繰り返し実行することが前提のテスト自動化プロジェクトでは、２次元の表でテストケースを表現することはテストの保守性に深刻な影響を与える。

個人の経歴・プロフィール 2016年末バージョン

講演・執筆活動

カンファレンス講演等（日本）

カンファレンス講演等（国外）

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

 

DevOps時代のテスト要求分析

継続的システムテスト DevOps

はじめに

こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。

qiita.com

ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。

DevOps時代のテスト要求分析は難しい

　DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。

  • （理由１）ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する
  • （理由２）開発中にシステムのアーキテクチャ設計が変化する

このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性について示す。

おさらい

　DevOps時代のテストの難しさについて述べる前に、テスト要求分析とVモデルについておさらいし、従来のテスト戦略に存在する暗黙の仮定を洗い出す。

テスト要求分析

　テスト要求分析は"テスト要求の源泉"を分析し"テスト要求"を洗い出すアクティビティだ[1]。「テスト観点を体系化」し、「テスト対象」と「テスト目的」を明らかにしていく。また、テスト活動を実施していく上でのビジネス要因やプロジェクトのリスクを洗い出したり、テスト対象のアーキテクチャを分析し、品質特性とテスト観点の紐付けを行ったりすることもここに含まれる。

　テスト要求分析の結果は、テストアーキテクチャ設計(*1)においてテスト戦略(*2)を決定していくことにに用いられる。

Vモデル

　Vモデルは、「要求分析」「設計」「コーディング」などの開発工程と、「受け入れテスト」「システムテスト」「単体テスト」などのテスト工程の対応関係を示すものだ。開発工程とテスト工程の対応関係により、それぞれのテスト工程の検証対象のスコープが明確化される[2]。ISTQBでは、「システムテスト」や「単体テスト」などの各テスト工程をテストレベルとしてまとめ、それぞれのレベルテスト計画を行うことを推奨している[3]。

従来のテスト戦略

　ウォーターフォールに基づく従来のテスト戦略では、これらのテストレベルを左から順に時系列で実施していくことが多かった。Vモデルと従来のテスト戦略の対応関係を下記の図に示す。

 f:id:kokotatata:20161211124709p:plain

　この従来のテスト戦略に従いテスト活動を進めていくためには、３つの仮定が正しいことが暗黙的に求められる。

  • テスト活動開始以前にプロダクトやサービスを取り巻くビジネス要因が決定されており、テスト活動中にそれらが変更されないこと（仮定A）
  • テスト活動開始以前にプロダクトのアーキテクチャが決定されており、テスト活動中に変更されないこと（仮定B）
  • テスト活動開始以前にソースコードの変更が終了しており、テスト活動中には（バグ修正以外の目的では）変更されないこと（仮定C）

これら３つの仮定が正しい場合、ビジネスやアーキテクチャなどにまつわるリスクを固定化して考えることが出来るので、それ以外の要因、すなわちテスト対象のスコープを優先順位付けのための唯一の軸とすることができる。そのため、ウォーターフォール開発では、単体テスト→結合テスト→システムテストと、小さいテスト対象から大きなテスト対象へとスコープを広げていくテスト戦略が一般的になっている。

従来のテスト戦略がDevOpsでは使えない理由

　DevOpsにおいて従来のテスト戦略がそのまま使えない理由は単純だ。上述の仮定Aと仮定Bが正しくないからだ。それぞれ詳しくみてみる。

理由１：ビジネスの成熟度によってサービスやプロダクトに必要となる品質が変化する

　DevOps時代のビジネスでは、リーンスタートアップの考え方に代表されるように、ムダな要素を最小限に抑え、仮説検証を続けるビジネス開発手法が一般的だ[4]。ビジネスの成長に伴って、それぞれのビジネスのフェーズに一番価値のある部分にフォーカスする。下記にビジネスの成熟度とビジネスのフェーズの例を示す。

f:id:kokotatata:20161211132311p:plain

　ここで重要なことはビジネスフェーズが進むにつれてシステム開発でフォーカスすべき品質は変わってくることだ。たとえば、

  • スタートアップ期：プロダクトの最小限の機能性
  • ステップアップ期：プロダクトのユーザービリティ。ユーザーに安心して使ってもらうための信頼性やセキュリティなど
  • スケール期　　　：多数のユーザーに使ってもらうためのスケーラビリティやパフォーマンスなど
  • 安定期　　　　　：コスト効率化のための運用性や効率性

といったように、求められる品質が変化していく。（もちろんこれらは例であり、求められる品質の変化はビジネスにより様々だ。）

　ビジネスフェーズが変わるごとに求められる品質が変化する、すなわち（仮定A）が成り立たないため、従来のテスト戦略の使用は困難となる。

理由２：開発中にシステムのアーキテクチャが変化する

　アジャイル開発では、システム開発中に要求変更を受け付けるのと同様に、アーキテクチャ設計もどんどん進化していく。これは「Evolutionary Design」として知られる[5]。そのため、新規機能と既存機能の結合テストや、アーキテクチャの変更に伴う品質特性のテストを適切なタイミングを計画し実施していく必要がある。

　下記に、各イテレーションにおける実装とテストの対応関係の例を示す。

f:id:kokotatata:20161211140342p:plain

　この例では、イテレーション１と３においてそれぞれ機能1と2を実装しているため、それぞれ対応するイテレーションでの機能テストを行っている。一方で、イテレーション２でセキュリティ強化を行っているため、イテレーション３で実施される機能２のテストよりも前にセキュリティテストを実施している。また、機能２のテストと機能１と２の結合テストが並行して実施されている。

　この図で示したいことは、時間軸上でアーキテクチャが変化する場合、テストは単純なVモデルの繰り返しではなく、複数のVモデルを考慮しなければならないということだ。そのため、単純に単体テストから受け入れテストへと進めていくことを前提とせず、しっかりと機能の結合やアーキテクチャ変更のタイミングも見据えたテスト要求を洗い出す必要がある。

DevOps時代のテスト要求分析の方向性

　これらの問題点を踏まえ、DevOps時代のテスト要求分析には以下の３点の方向性が重要になる。

  1. ビジネス要因とアーキテクチャ設計の変化を時間軸上で捉えること
  2. テスト戦略へのフィードバックを可能にすること
  3. ビジネスやアーキテクチャ設計へのフィードバックを可能にすること

変化を時間軸上で捉える

　ここまで見てきたように、DevOps時代のテスト活動では、ビジネス要因やアーキテクチャ設計を固定として考えることはできない。これらは時間軸上で変化していくものとして捉え、変化に対応可能なようにテスト要求分析をしていく必要がある。

　たとえば、ビジネス要因では今後３年の事業計画から、３ヶ月くらいごとのテスト要求を導出することが考えられる。また、モノリシックからマイクロサービスへとアーキテクチャ設計を変化させる上で重要となる、回復性やデータ品質といった要求について優先順位を決め、どのタイミングでテストする必要があるかを考えていく。

テスト戦略へのフィードバック

　テスト戦略は一度作ったら終わりではなく随時改良していく必要があることが知られている。DevOps時代のテスト要求分析では、より積極的にテスト戦略改善のフィードバックを回していく。

　単純な例を挙げれば、計画当初は一度だけのセキュリティテスト実施を計画していたが、セキュリティテストの結果を踏まえ、セキュリティテストを自動化し以降のスプリントでも継続的に実行していくように戦略を変更する、といった事が考えられる。

　逆に、テスト実行に時間がかかるが、今までほとんどバグが検出されていないテストについて、優先順位の高い20%のみを実行するように変更する、といったケースも考えられるかもしれない。

　プロジェクトが進みプロダクトが大きくなるにつれて、たとえばテストケース数は膨れ上がり、テスト活動はどんどんコントロール不可能なものになるだろう。テスト活動をコントロール可能なものとして保つため、随時フィードバックよりテスト活動で起きている変化を把握し、テスト戦略を更新していく。

ビジネスやアーキテクチャ設計へのフィードバック

　DevOpsでは「本番からのフィードバック」が大切な事が指摘されている[6]。チームが継続的に「要求的にもアーキテクチャ的にも学びを得る」ことによって、プロダクトを成長させる。

　DevOps時代では、テストもビジネスやアーキテクチャ設計へと直接フィードバックを回していく事が求められる。そのため、ビジネスやアーキテクチャ設計への学びがテスト要求にも入ってくるはずだ。

　ベータテストやABテストなどは、テストからビジネスへのフィードバックの典型的な例だ。新バージョンの本運用に入る前に、小規模のユーザーに試験的に使ってもらい、そこで得たフィードバックを本運用前に改善する。

　また、本番運用での学びを積極的に採用できないセキュリティなどのケースでは、依然、きちんとしたテスト環境で破壊的なテストを実施し、アーキテクチャ設計にフィードバックする事が求められる。

まとめ

　DevOps時代のテスト要求分析が難しい理由を、従来のVモデルにもとづいたテスト戦略から考察した。また、今後のテスト要求分析の方向性を３つ示した。

　ここで大事な事は、DevOps時代には「プロダクトの価値」が時間軸上で変化する事だ。そのため、テスト要求分析もしっかりと時間軸上での変化を捉える必要がある。また、テスト活動やビジネス、アーキテクチャの変化をリアルタイムで把握し、フィードバックループを作っていくことも重要になる。

注意

　

参考文献