テスト自動化プロジェクトでExcelを使わない10の理由
モチベーション
この記事はソフトウェアAdvent Calendar 2017の11日目のブログエントリとして書いています。
昨日参加したシステムテスト自動化カンファレンス2017で、「もう2年以上、テスト自動化プロジェクトの中でExcelを使ってないなぁ」ということを思い出した。
2年半前にガチのExcelファイルで書かれたテスト設計ドキュメントを初めて見て、このやり方ではテストが成長できなくなるということを痛切に感じた。その時の考えを2次元の表によるテスト管理の限界 - Test Automationというブログエントリにまとめてから、うちのチームではExcelをテスト自動化の中で使っていない。
前回のエントリより2年半経って、Excelを使ってない理由についての考えがより鮮明になってきた、ここでは、それらExcelをテスト自動化で使わない理由をつらつらと書き連ねていく。
テスト自動化プロジェクトでExcelを使わない理由
理由①:Excelはユーザー環境の互換性や移植性が低い
Excelの問題の1つ目は、開発者や運用エンジニアなどを含めたテスト自動化プロジェクトの大半のステークホルダーの環境で期待通りに動作しないことだ。Windows上で綺麗に整形されていたり、職人技の関数芸やVBA芸でまとめられたExcelファイルは、残念ながらMacやLinuxでは期待通りに表示されない。僕が今年見た一番ひどいExcelファイルでは、1回データを入力するごとに僕のMac上ではエラーが表示される。
開発エンジニアや運用エンジニアに人気のOSであるMacやLinuxでまともに動かないツールをテスト自動化プロジェクトで使うことは、エンドユーザー向けにWindows Phoneでは動くが、AndroidやiOSではバグだらけのアプリをリリースするようなものだ。
理由②:テストケースに対するスケーラビリティが低い
Excelはデータサイズのスケーラビリティが低い。まず、仕様が最大約100万行、最大約2万列と、一般的なテスト自動化プロジェクトで取り扱うテストケース数を考えると少なすぎる。また、実際には数万行を超えたくらいから動作がもっさりしてくる。Excelで表現できるテストケース数はせいぜい数百から数千だろう。
理由③:テストエンジニア/クライアントに対するスケーラビリティが低い
Excelはユーザ数に対するスケーラビリティが低い。ファイル共有について、メール、共有ファイル、オンライン版など、どれを使うかにもよるが、そもそも数百人が同時にアクセス&編集するユースケースを想定しているものではない。多分、同じタイミングで一つのファイルを編集する人間は一人か、せいぜい声を掛け合える範囲の数人を想定しているように思う。
この問題はExcelファイルにアクセスするのが人間でなくテストクライアントの場合、顕著に起こる。テスト実行時間が長くなってきた場合など、テストクライアントを複数並べ平行に実行するようにすることでテスト実行時間を短縮する。数十から数万のテストクライアントが同時に1つのExcelファイルにアクセスした場合、ここがボトルネックになってしまうことは明白だ。
理由④:テスト実行頻度に対するスケーラビリティが低い
Excelはテスト実行頻度に対するスケーラビリティが低い。同じテストをプロジェクト中に一回、または年に数回程度実行するだけならばExcelでも十分だ。しかし、ほとんどのテスト自動化プロジェクトの目的は柔軟なテストの実行だ。一年を通して毎日継続的に実行したり、場合によっては1日に何百回も実行することもあるだろう。
テスト実行頻度が増えるにつれ、例えば、テスト結果ドキュメントの数も増大する。Excelでテスト設計を管理すると、数万に及ぶテスト結果との対応関係をとっていくことが難しくなってしまう。
理由⑤:テストケースの最新性の低下
ExcelファイルがローカルPCと共有ファイルサーバーで2重管理される場合、テストケースの最新性が低下する可能性がある。共有ファイルサーバーにあるファイルが最新なのか?最新のファイルが誰のローカルPCにあるのか?などのデータの最新性の問題が簡単に起こる。加えて、複数のメンバーがローカルのファイルをどんどんと更新し続けたため、あとで変更を1つのファイルにマージするのが大変になるなんてのも、よく聞く話だ。
これらの問題は、継続的インテグレーション(CI)のような、継続的にファイルをマージしていくフローを作ることで防ぐことが可能だが、ExcelユーザにはCIのような文化がそもそもない
理由⑥:テストケースの差分管理が煩雑
Excelは2次元でデータを表現するため、行指向でデータを管理するSVNやGitで差分管理しようとすると煩雑になる。極端な例で言えば、1列追加しただけでもすべての行に変更が入るため、データ更新履歴としてはすべての行が対象となってしまう。そのためPullRequestのレビューで、ソースコードとテストケースの変更箇所の比較を行ったりすることが煩雑になってしまう。
理由⑦:テストコード設計の表現力が低い
テスト設計の成果物であるテスト設計ドキュメントは、その次のアクティビティのテスト実装の入力になる。テスト自動化プロジェクトの場合は、テスト設計ドキュメントを入力として自動実行可能なテストコードを実装する。ここで問題になることは、2次元の表形式のテスト設計は、オブジェクト指向設計などのプログラム設計の手法を用いたテストコードの設計を表現できないことだ。
例えば、テスト設計では個々のテストケースがテストに必要な情報を網羅する完全性が重視されるが、テストコード設計では、重複する部品を再利用可能なクラスとして定義することが重視される(今年のアドベントカレンダーのこれとかこれとか)。
理由⑧:テストケースの表現の煩雑さが増す
1つのテストケースは、事前条件、テスト対象、テスト手順、テスト条件、期待値、環境など様々な情報によって表現される。これは、テストケースを表現する軸は多次元であることを意味するが、Excelの表では2次元で表現することになる。
人間は多次元のデータ操作が苦手なので、多次元のテストケースを非正規化しExcelで表現することにも手動テストの場合には一定の価値がある。しかし、コンピュータもデータ操作するテスト自動化プロジェクトの場合、多次元のデータを2次元で表現するとデータモデルが煩雑になり自動化が難しくなってしまう。
理由⑨:テストケースの保守性<テスト項目の追加>
Excelの凄いところは、データサイズがそれほど大きくない場合、データの追加や変更のみならず、スキーマやデータモデルの変更も簡単に行える点だ。データベースなどではスキーマ変更などを伴う変更も、列を追加したり変更したりするだけで出来る。
しかしこの簡便性は、データスキーマの一貫性とトレードオフの関係にある。データベースの煩雑なテーブル定義の制約は、一方でスキーマの一貫性を保証する役割を担っている。しかしExcel自体はスキーマ変更を保証しないため、例えばExcelファイルのテストケースに新しい項目を追加する場合、人間がすべてチェックす必要がある。数十万、数百万のテストケースすべてに対しスキーマの一貫性をチェックするのは困難だ。
理由10:テストケースの保守性の低下<リファクタリングが困難>
テストケースが増えてきたとき、テスト設計をリファクタリングしたくなることがある。テストカバレッジが下がらないことを保証しながら、テストスイートのグルーピングを変更したり、テストの実行順序を変更したり、テストケースを削除したりする作業だ。定期的にリファクタリングすることで、テストケースを継続的に保守可能な形に保つ。
テスト設計をリファクタリングするためには、多次元のテスト設計を様々な2軸に射影することが不可欠になるが、もともと2次元の表で表現されている場合、この写像が困難だ。そのため、大胆なリファクタリングを行って大量のテストケースを削減することなどができなくなる。
まとめ
テスト自動化プロジェクトでExcelを使わない理由をつらつらと書いてきた。もちろんExcelは素晴らしいツールだし、場合によってはテスト自動化プロジェクトでも使っていい場合もあるかもしれない。例えば、チームにあったテスト設計のアプローチを議論する際には、数百くらいのテストケースをExcel上で操作しながら話し合うのはいいかもしれない。また、テストレポートに掲載するグラフのドラフトバージョンを作成したりするのにもExcelは簡便なツールだ。
一方で、テスト自動化プロジェクトに組み込むためには、Excelには制限が多すぎる。 特に、テストケース数やテストエンジニア/クライアント数に対するスケーラビリティの問題は、テスト自動化にとっては致命的と言える。また、繰り返し実行することが前提のテスト自動化プロジェクトでは、2次元の表でテストケースを表現することはテストの保守性に深刻な影響を与える。
個人の経歴・プロフィール 2016年末バージョン
講演・執筆活動
カンファレンス講演等(日本)
- 「アジャイル開発におけるメトリクスの活用 (パネルディスカッション) 」[発表スライド](SQiP 2016)
- 「DevOpsから見たテスト自動化と価値の見える化」(JaSST' 関西 2016)
- 「三位一体の自動化で壊せDevとOpsの壁」(デブサミ2016)
- 「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析(再演)」(SQiP 2015)
- 「継続的システムテストについての理解を深めるための開発とバグのメトリクス分析」(SQiP 2014)
- 「システムテストの自動化による大規模検索プラットフォームの開発工程改善」(JaSST' Tokyo 2014)
カンファレンス講演等(国外)
執筆関連
- 「変革の軌跡 世界で戦える会社に変わる"アジャイル・DevOps"導入の原則」へのDevOps事例「楽天のDevOpsエンジニアのストーリー」の寄稿 (2017)
- 「楽天でのエンタープライズアジャイルとDevOps」(情報処理学会デジタルプラクティスVol.7 2016)
- 「安心なサービスの品質改善を実現する為の継続的システムテスト」(IPA 先進的な設計・検証技術の適用事例報告書2015年度版)
勉強会での発表
- 「オフショアテストチームが、テスト自動化チームとして生まれ変わった物語」(第4回Seleniumユーザーコミュニティ勉強会, 2016)
- 「楽天の品質改善を加速する継続的システムテストパターン(再演)」(エンタープライズ勉強会 2016年2月セミナー)
- 「楽天の品質改善を加速する継続的システムテストパターン」(システムテスト自動化カンファレンス2015)
- 「Rakuten and Microsoft talk DevOps in Real World 」(楽天テクノロジーカンファレンス2015)
- 「誰がテスト自動化をするべきか?」(楽天テックカンファ前夜祭, 2014)
- 「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析(再演)」(第21回カフェソフトウェアクオリティ, 2014)
- 「Data Driven Development」(システムテスト自動化カンファレンス2013 LT)
- 「リーンキーワード駆動型漫才」(DevLove現場甲子園2013完結編)
- 「Software Engineer in Test @ 楽天の検索基盤開発の現場」(DevLove現場甲子園2013)
- 「検索基盤開発のための結合テスト環境の自動化」(第6回テックヒルズ, 2013)
勉強会企画
- Tokyo DevOps 2.0 Meetup 企画, 2017
- Test Engineers Meetup #1企画, 2016
- カフェソフトウェアクオリティ第24回 企画, 2015
- テスト自動化の社内勉強会企画, 2015
- 楽天テックカンファ前夜祭, 2014
書籍関連・インタビュー・ブログ記事など
- 「DevOps時代のテスト要求分析」(個人ブログポスト, 2016)
- 「DevOpsについてのインタビュー」(日経コンピュータ2016年11月10日号)
- 「DevOps事例提供」(エンタープライズアジャイルの可能性と実現への提言, 2016)
- 「Rakuten DevOps Evidence January」(2016)
- 「DevOpsインタビュー:第1回 楽天さんのDevOpsについて聞いてみた」 (2015年)
- 「"グローバル化"と"コミュニケーションとアジャイルとテストエンジニア"」(Ultimate Agile Stories Iteration 5, 2015)
- 「アジャイルテストのテスト設計の話」(個人ブログポスト, 2015)
- 「継続的システムテスト」(個人ブログポスト, 2014)
資格
- JSTQB Advanced Level テストマネージャー (2015)
- JCSQE 初級 (2014)
- JSTQB Foundation Level (2014)
- プロダクトオーナー(2014)
DevOps時代のテスト要求分析
はじめに
こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。
ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。
DevOps時代のテスト要求分析は難しい
DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。
- (理由1)ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する
- (理由2)開発中にシステムのアーキテクチャ設計が変化する
このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性について示す。
おさらい
DevOps時代のテストの難しさについて述べる前に、テスト要求分析とVモデルについておさらいし、従来のテスト戦略に存在する暗黙の仮定を洗い出す。
テスト要求分析
テスト要求分析は"テスト要求の源泉"を分析し"テスト要求"を洗い出すアクティビティだ[1]。「テスト観点を体系化」し、「テスト対象」と「テスト目的」を明らかにしていく。また、テスト活動を実施していく上でのビジネス要因やプロジェクトのリスクを洗い出したり、テスト対象のアーキテクチャを分析し、品質特性とテスト観点の紐付けを行ったりすることもここに含まれる。
テスト要求分析の結果は、テストアーキテクチャ設計(*1)においてテスト戦略(*2)を決定していくことにに用いられる。
Vモデル
Vモデルは、「要求分析」「設計」「コーディング」などの開発工程と、「受け入れテスト」「システムテスト」「単体テスト」などのテスト工程の対応関係を示すものだ。開発工程とテスト工程の対応関係により、それぞれのテスト工程の検証対象のスコープが明確化される[2]。ISTQBでは、「システムテスト」や「単体テスト」などの各テスト工程をテストレベルとしてまとめ、それぞれのレベルテスト計画を行うことを推奨している[3]。
従来のテスト戦略
ウォーターフォールに基づく従来のテスト戦略では、これらのテストレベルを左から順に時系列で実施していくことが多かった。Vモデルと従来のテスト戦略の対応関係を下記の図に示す。
この従来のテスト戦略に従いテスト活動を進めていくためには、3つの仮定が正しいことが暗黙的に求められる。
- テスト活動開始以前にプロダクトやサービスを取り巻くビジネス要因が決定されており、テスト活動中にそれらが変更されないこと(仮定A)
- テスト活動開始以前にプロダクトのアーキテクチャが決定されており、テスト活動中に変更されないこと(仮定B)
- テスト活動開始以前にソースコードの変更が終了しており、テスト活動中には(バグ修正以外の目的では)変更されないこと(仮定C)
これら3つの仮定が正しい場合、ビジネスやアーキテクチャなどにまつわるリスクを固定化して考えることが出来るので、それ以外の要因、すなわちテスト対象のスコープを優先順位付けのための唯一の軸とすることができる。そのため、ウォーターフォール開発では、単体テスト→結合テスト→システムテストと、小さいテスト対象から大きなテスト対象へとスコープを広げていくテスト戦略が一般的になっている。
従来のテスト戦略がDevOpsでは使えない理由
DevOpsにおいて従来のテスト戦略がそのまま使えない理由は単純だ。上述の仮定Aと仮定Bが正しくないからだ。それぞれ詳しくみてみる。
理由1:ビジネスの成熟度によってサービスやプロダクトに必要となる品質が変化する
DevOps時代のビジネスでは、リーンスタートアップの考え方に代表されるように、ムダな要素を最小限に抑え、仮説検証を続けるビジネス開発手法が一般的だ[4]。ビジネスの成長に伴って、それぞれのビジネスのフェーズに一番価値のある部分にフォーカスする。下記にビジネスの成熟度とビジネスのフェーズの例を示す。
ここで重要なことはビジネスフェーズが進むにつれてシステム開発でフォーカスすべき品質は変わってくることだ。たとえば、
- スタートアップ期:プロダクトの最小限の機能性
- ステップアップ期:プロダクトのユーザービリティ。ユーザーに安心して使ってもらうための信頼性やセキュリティなど
- スケール期 :多数のユーザーに使ってもらうためのスケーラビリティやパフォーマンスなど
- 安定期 :コスト効率化のための運用性や効率性
といったように、求められる品質が変化していく。(もちろんこれらは例であり、求められる品質の変化はビジネスにより様々だ。)
ビジネスフェーズが変わるごとに求められる品質が変化する、すなわち(仮定A)が成り立たないため、従来のテスト戦略の使用は困難となる。
理由2:開発中にシステムのアーキテクチャが変化する
アジャイル開発では、システム開発中に要求変更を受け付けるのと同様に、アーキテクチャ設計もどんどん進化していく。これは「Evolutionary Design」として知られる[5]。そのため、新規機能と既存機能の結合テストや、アーキテクチャの変更に伴う品質特性のテストを適切なタイミングを計画し実施していく必要がある。
下記に、各イテレーションにおける実装とテストの対応関係の例を示す。
この例では、イテレーション1と3においてそれぞれ機能1と2を実装しているため、それぞれ対応するイテレーションでの機能テストを行っている。一方で、イテレーション2でセキュリティ強化を行っているため、イテレーション3で実施される機能2のテストよりも前にセキュリティテストを実施している。また、機能2のテストと機能1と2の結合テストが並行して実施されている。
この図で示したいことは、時間軸上でアーキテクチャが変化する場合、テストは単純なVモデルの繰り返しではなく、複数のVモデルを考慮しなければならないということだ。そのため、単純に単体テストから受け入れテストへと進めていくことを前提とせず、しっかりと機能の結合やアーキテクチャ変更のタイミングも見据えたテスト要求を洗い出す必要がある。
DevOps時代のテスト要求分析の方向性
これらの問題点を踏まえ、DevOps時代のテスト要求分析には以下の3点の方向性が重要になる。
- ビジネス要因とアーキテクチャ設計の変化を時間軸上で捉えること
- テスト戦略へのフィードバックを可能にすること
- ビジネスやアーキテクチャ設計へのフィードバックを可能にすること
変化を時間軸上で捉える
ここまで見てきたように、DevOps時代のテスト活動では、ビジネス要因やアーキテクチャ設計を固定として考えることはできない。これらは時間軸上で変化していくものとして捉え、変化に対応可能なようにテスト要求分析をしていく必要がある。
たとえば、ビジネス要因では今後3年の事業計画から、3ヶ月くらいごとのテスト要求を導出することが考えられる。また、モノリシックからマイクロサービスへとアーキテクチャ設計を変化させる上で重要となる、回復性やデータ品質といった要求について優先順位を決め、どのタイミングでテストする必要があるかを考えていく。
テスト戦略へのフィードバック
テスト戦略は一度作ったら終わりではなく随時改良していく必要があることが知られている。DevOps時代のテスト要求分析では、より積極的にテスト戦略改善のフィードバックを回していく。
単純な例を挙げれば、計画当初は一度だけのセキュリティテスト実施を計画していたが、セキュリティテストの結果を踏まえ、セキュリティテストを自動化し以降のスプリントでも継続的に実行していくように戦略を変更する、といった事が考えられる。
逆に、テスト実行に時間がかかるが、今までほとんどバグが検出されていないテストについて、優先順位の高い20%のみを実行するように変更する、といったケースも考えられるかもしれない。
プロジェクトが進みプロダクトが大きくなるにつれて、たとえばテストケース数は膨れ上がり、テスト活動はどんどんコントロール不可能なものになるだろう。テスト活動をコントロール可能なものとして保つため、随時フィードバックよりテスト活動で起きている変化を把握し、テスト戦略を更新していく。
ビジネスやアーキテクチャ設計へのフィードバック
DevOpsでは「本番からのフィードバック」が大切な事が指摘されている[6]。チームが継続的に「要求的にもアーキテクチャ的にも学びを得る」ことによって、プロダクトを成長させる。
DevOps時代では、テストもビジネスやアーキテクチャ設計へと直接フィードバックを回していく事が求められる。そのため、ビジネスやアーキテクチャ設計への学びがテスト要求にも入ってくるはずだ。
ベータテストやABテストなどは、テストからビジネスへのフィードバックの典型的な例だ。新バージョンの本運用に入る前に、小規模のユーザーに試験的に使ってもらい、そこで得たフィードバックを本運用前に改善する。
また、本番運用での学びを積極的に採用できないセキュリティなどのケースでは、依然、きちんとしたテスト環境で破壊的なテストを実施し、アーキテクチャ設計にフィードバックする事が求められる。
まとめ
DevOps時代のテスト要求分析が難しい理由を、従来のVモデルにもとづいたテスト戦略から考察した。また、今後のテスト要求分析の方向性を3つ示した。
ここで大事な事は、DevOps時代には「プロダクトの価値」が時間軸上で変化する事だ。そのため、テスト要求分析もしっかりと時間軸上での変化を捉える必要がある。また、テスト活動やビジネス、アーキテクチャの変化をリアルタイムで把握し、フィードバックループを作っていくことも重要になる。
注意
- (*1)(*2)このブログエントリでは専門家以外の分かりやすさ重視のため、「テストアーキテクチャ設計」と「テスト戦略」を同義語として扱っています。「テストアーキテクチャ設計」の詳細についてはQAアーキテクチャの設計による説明責任の高いテスト・品質保証をご参照下さい[7]。
参考文献
- [1] 智美塾 テスト要求分析の概念
- [2] Guidlines for Verifying and Validating Software Requirements and Design Specification
- [3] ソフトウェアテスト標準用語集(日本語販)
- [4] リーンスタートアップとは (Lean Startup): - IT用語辞典バイナリ
- [5] Is Design Dead?
- [6] 本番環境の「聖域化」を再考する - DevOps の「リードタイムの短縮」の次に来るもの - メソッド屋のブログ
- [7] QAアーキテクチャの設計による説明責任の高いテスト・品質保証
2015年個人的なコミュニティ系の活動まとめ
2015年に行ったコミュニティ系の活動についての個人的なめも。
1月
テスト自動化に関するTechTalkの企画
Gebに関する勉強会がしたいとの声が社内で上がったので拾って企画。開催後、上の方から色々指令が飛んできたw
2月
社外カンファレンス参加:JaSST' Tokyo 2015
特にレポートなど書いていない(笑)。アジャイルテスト系が面白かった。
3月
社外事例報告集への寄稿:IPA 先進的な設計・検証技術の適用事例報告書 2015 年度版
3月に執筆、11月に公開。2014年度のJaSSTとSQiPの発表を事例報告としてまとめた。
公開資料:https://www.ipa.go.jp/files/000049409.pdf
4月
社内勉強会企画&LT:Global Engineer Gathering Tokyo
DevOps系のエンジニアを世界中から集めた勉強会。テスト自動化についてLT。資料非公開
5月
ブログへのポスト:アジャイルテストのテスト設計の話。
Scaled Agile Framework上でどのようにアジャイルテストを行うかと、テストのRefactorobilityについて考えていた。
6月
社外コミュニティへの寄稿: Ultimate Agile Stories Interation 5への寄稿
グローバルの多様性の高い文化でのソフトウェアテストについて色々考えていたので、そこらへんについて書いた。
7月
社外勉強会への参加:Web Service QA Meeting Vol.1
この頃は、テストの永続性とRefactorabilityのことばかり考えていたので、その辺の視点でレポートを書いている。
8月
資格受験:JSTQB Advanced Level Test Manager
8月に受験。11月に結果発表。受かっていた。ソフトウェアテストについては独学で勉強している部分が多く、自分の理解があっているか不安な部分もこれ以前は多々あったが、合格率10%程度の資格に受かったので結構自信を持てた。
継続的システムテストのテストレベルとテストフェーズについて、考えたブログ記事。
9月
社外カンファレンス参加:XP祭り
特にレポートなど書いていない。インフラ系の発表をXP祭りで聞けたのがよかった。
社外カンファレンス参加と発表:ソフトウェア品質シンポジウム
昨年度の発表を再演。また、アジャイルテストのエキスパートたちと交流できたのがよかった。
発表資料:
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
10月
社内勉強会参加:DevOps会議
他部署がどんなDevOpsをやっているか知れた。資料非公開。
社外ブログインタビュー:Live DevOps in Japan!
インタビューとなって公開されていますが、実質はエバンジェリストやアジャイルコーチの方達とお酒を飲みながらディスカッションした飲み会w
この飲み会を通してテスト自動化だけでなく、チームやプロセス、アーキテクチャについて濃いディスカッションが出来たのが今の業務に効いてきてる。
11月
社外カンファレンス参加:Google Test Automation Conference
初めてのGTAC。グローバルジャイアントと比較して、テスト自動化の差が追いつけない距離じゃないことを知れたことがよかった。
社内・外カンファレンス発表:
共同セッション。純粋に楽しかったw 懇親会でも、社内、社外問わずこれからのDevOpsについて様々なディスカッションが出来た。資料非公開。
rakutentechnologyconference2015.sched.org
12月
社外カンファレンス発表:システムテスト自動化カンファレンス
継続的システムテストについて体系的にまとめた内容を発表した。漫才も楽しかったし、懇親会も楽しかった。
発表スライド:【システムテスト自動化カンファレンス2015】 楽天の品質改善を加速する継続的システムテストパターン #stac2015
感想
- こうやって振り返ってみると、前半はソフトウェアテストを深掘りしていたが、後半はDevOpsにシフトチェンジしてきているのが面白い
- 昨年後半の発表は2件とも共同セッションだったのが面白かった。今年もうすでに決まっているものも、共同セッションや共著ばかりだw
- 社外の方から声がかかるようになってきたのが成長なのかなと思う。コミュニティから得た知見で、業務で成果を出せたときは、その経験を積極的にコミュニティにフィードバックしていきたい
- テックカンファで英語での社外発表をした。
- 社内勉強会の企画を前半は少し行っているが、後半まったく出来ていないことが反省
- チームメンバーをコミュニティにうまく巻き込めていないことが反省。社外発表できるくらいの成果をチームメンバーに出してもらって、それを自分の言葉で社外で発表できる。そんなチームに育てていきたいなあ。
- 海外カンファレンスでの発表もやりたいなあという気持ちがありつつ、積極的には動けてない。うーーん。。。
- 大きな声では言えないけれども、採用につながるような発表ができるようになりたいなあ。そこまで出来たらコミュニティ系活動が会社に貢献している感がリアリティを増す。
Google Test Automation Conference 2015に行ってきた
2015年11月10~11日にかけてボストンで開催されたGoogle Test Automation Conference 2015に参加してきました。 このブログエントリでは、カンファレンスの雰囲気や講演内容の感想についてレポートします。
GTAC 2015 | Google Test Automation Conference | Google Developers
参加の背景
ある日、上司に「何か海外カンファレンス参加しないの?」と聞かれて、そういえば先日モバイル系のテスト自動化をしている同僚から「俺、Google Test Automation Conference申し込んだけども、お前も申し込まない?」と誘われてた事を思い出して申し込みました。
僕は運良く抽選にあたり、同僚は運悪く抽選に外れてしまったのですが、、、。正確な数字は公表されてなかったと思いますが、1000人くらいの申し込みに対して100~200人が抽選に当たったようです。他の参加者からは「うちの会社は100人くらい申し込んで、3人だけ参加できた」との話も聞いたので、参加できた事自体かなりラッキーでした。
会社の業務では海外のテストエンジニアと関わる事も多い、というか、80%くらいのコミュニケーションは外国籍のエンジニアとなんですが、海外のエンジニアコミュニティとの関わりは多くないので、海外のトップエンジニアの話が聞ける機会として大きな期待を持って参加しました。
全体的な印象
全体的な印象として、スマートフォンやChrome Castのような物理的なデバイスを扱うテストの話の比率が多かったなという印象を受けました。発表タイトルで言うとこの辺りですね。
- Robot Assisted Test Automation
- Mobile Game Test Automation Using Real Devices
- Using Robots for Android App Testing
- Nest Automation Infrastructure
- Effective Testing of a GPS Monitoring Station Receiver
- Automation on Wearable Devices
やっぱりGoogleさんとしても、これからのIoT時代のテストを意識しているという事でしょうか。他の発表は以下のようにカテゴライズできると思います。
- Fearless Change系
- Testability改善のためのアプリケーションや自動テストシステムの設計
- テストデータの生成・管理
- テストの品質評価
以下、それぞれのカテゴリについて感想を書きます。
講演を聞いての感想
1.Fearless Change系
KeynoteであったJürgen Allgayerさんの講演が、YouTubeにおけるテスト自動化のFearless Changeの発表で本当に素晴らしかったです。
解くべき課題として、複数のサービスやコンポーネント間での結合、システムテストの問題が挙げられていました。このあたりはどこの開発・運用でも一緒なんですね。
で、その課題を5年くらいかけて解いていくFearless Chageが紹介されてました。最初の数年で、自動化プラットフォームの構築をして、その後チーム作りをし、今は文化作りをしているそうです。
チーム作りの部分で
- Metricsやレポートの自動化、見える化、透明化
- Metricsにもとづいたチーム主導でのプロダクト、運用、テストの品質改善
- 自動化!!
- 自動化とインフラのスキルのチームミックス
が紹介されていて、すごいなと思うとともに、今のチームが進んでいる方向と段階も間違っていないなwと思いました。
2. Testability改善のためのアプリケーションや自動テストシステムの設計
Testabilityの設計改善系では「Flaky(なテスト)」という言葉が使われていました。日本のコミュニティでは「自動テストの信頼性」として取り扱われている分野ですね(*1 *2)。印象的だったのは、
- デバッグモードでしか動作しないテスト用の機能をアプリケーションに埋め込んでおく
- テストのコントローラーにGod Classのようなものを作るのではなく、各デバイスやコンポーネント間で協調動作するようなメッセージ機能をアプリケーションに埋め込んでおく
のような、Testabilityに関するアプリケーション設計へのフィードバックが当たり前のように行われていることでした。
後は、モックを使うことはいいことなのか?Microserviceな世界でのモックの在り方とかが今後の議論になりそうだと感じました。
3. テストデータの生成・管理
テストデータの生成にはみなさん苦労していますね(笑)。カンファレンスでは、"Statistical Data Sampling"という発表の中で確率論的なアプローチ、"Event Generators"で、決定論的なアプローチが紹介されていました。どちらもアルゴリズムの詳細な説明がなかった事が残念でしたが。
"Statistical Data Sampling"が非常に面白く、ソフトウェアテストではテストデータの統計的な分布の情報よりもEdgeケースの方が重要という点を指摘した上で、その解決方法のアプローチを簡単に紹介していました。詳細は語られていないので分からないのですが、機械学習のクラスタリングを緩く適用することで、テストデータの"Representative Point"を炙り出しているようです。
4.テストの品質評価
テストの品質評価のために、自動テストのリファクタリングの必要な部分を見つけ出すアルゴリズム(発表タイトルは"Test Suites and Program Analysis")と、テストのカバレッジは直接的にはテストの品質には関係ない(発表タイトルは"Coverage is Not Strongly Correlated with Test Suite Effectiveness")という話が紹介されていました。
特にテストの品質の方では、「バグの検出能力とコードカバレッジには相関関係はあるけども因果関係はない」といった趣旨の話がされており、個人的にはうーんどうなんだろうとも思いつつ、この辺りの議論が将来盛り上がると面白くなりそうですね。
おまけ
11月21日に私の所属している会社で、楽天テクノロジーカンファレンスが開催されます。
Microsoft牛尾さんとのセッション内でGTAC 2015の内容も少しフィードバックしようと考えてますので、ご興味のある方はぜひご参加ください。
rakutentechnologyconference2015.sched.org
リンク
GTAC 2015のビデオ
- 1日目
- 2日目
参考文献
- (*1) テスト自動化の品質モデルの扱い
- (*2) テスト自動化とアーキテクチャ
テストエンジニアにこそ楽天テックカンファのDevOpsセッションに参加して欲しい
タイトルからして分かりやすいステマ記事ですね。
はい。 ま、僕はカンファレンススタッフではないのでステマ記事を書く必要はないんですけども、ちょいちょいと流れてくるDevOpsセッションの情報を見ると「おー豪華だなー」と。
rakutentechnologyconference2015.sched.org
その一方で「Dev? Ops? ってか、楽天テックカンファにはソフトウェアテストのトラックがないの?!」、と思ったテストエンジニアの方も多いのではないかと思います。
違うんです。
テスト自動化はDevOpsを支えるための一番重要な技術。継続的デリバリーを読んでみても、半分くらいのページはテストや品質の話。ということで、楽天テックカンファではテスト自動化関連のトピックはDevOpsのトラックに吸収されています。
これからのソフトウェアテストを考える上で重要なことは「テストがチームにもたらす価値」。
アジャイルテスト4象限見てみましても、「開発をサポートするテスト」「エンドユーザーのためのテスト」に区分することからテスト戦略の立案が始まっています。僕はここにもうひとつ「素早く安定した運用を実現するためのテスト」が重要だと考えています。
つまり、DevOpsによってユーザーに価値を届けるためには、自動テストによってDevとOpsに素早く改善のフィードバックループを回していく。
DevOpsのトラックでは、DevOpsの基本から実際の企業での実例、そしてテスト自動化がDevOpsにもたらす価値と技術についての議論などが展開されるようです。 テストエンジニアの方々の楽天テックカンファのDevOpsセッションへのお越しをお待ちして居ります。
システムテストフェーズで単体テストレベルを実行する?!
テストフェーズとテストレベル
昨日受けたソフトウェアテストの資格試験で面白い問題があった。
縦軸にテストフェーズ、横軸にテストレベルをとってテスト計画を作れ
という趣旨のもの。
システムテストフェーズで単体テストレベルのテストを実行する?!
みたいなw
継続的システムテストのコンセプトが一般的にまだまだ理解されにくく、その原因は
- Myersの言う「テストフェーズ」[1]
- Beizerのいう「テストのスコープ・観点(テストレベル)」[2]
あたりを混同しているエンジニアが多いからなのかなとちょうど考えていたので、この問題は僕の心にクリティカルヒットした。このブログエントリでは、継続的システムテストをテストフェーズとテストレベルから整理し直してみる。
継続的システムストのテストフェーズとテストレベル
継続的システムテストのテストフェーズ
継続的システムテストでは、
・開発テストフェーズ (開発者の行うテスト)
・システムテストフェーズ (テストエンジニアの行うVerification)
・ユーザーテストフェーズ (プロダクトオーナーなどが行うValidation)
の3つのテストフェーズがある事を前提としている。
ここでのテストフェーズはMyersが言う通り、テスト活動の時間的順序を表しているわけではなく、工程の実施時期が重なっても構わない[1]。例えば自動化が進み1日に何回もデプロイとテストしているような環境であれば、これらのフェーズはそのほとんどが重なり平行に実施されるようになる。
フェーズがほとんど重なるのであれば、フェーズを分ける事のメリットは何だろう?という疑問が湧くと思う。フェーズを分ける事のメリットは、それぞれのテストフェーズによってもたらされる価値が明確になる事だ。この3つのテストフェーズは、ソフトウェア開発ライフサイクル内の実施される時期にもとづいて、それぞれ異なる価値をプロジェクトに提供する。
開発テストフェーズは開発者に「素早く実装可能な開発環境」という価値をもたらす。ユーザーテストフェーズは「ユーザーに価値のある正しい機能が提供されているか?」を確認する。
継続的システムテストが主眼を置くシステムテストフェーズの価値は3種類の受け取り手が存在する。
- 1つ目は開発者。継続的にシステムテストを実行し素早くテストからのフィードバックをする事で、開発者はバグの修正を短縮したりと開発のアジリティが向上する[3]。
- 2つ目はプロジェクトマネージャー。継続的にテストを実行しそのメトリクスをモニタリングする事でプロジェクトの進捗状況が見える化される[4]。
- 3つ目はユーザーテストの担当者。ユーザーテストフェーズの準備ができている事をシステムフェーズが保証する事で、ユーザーテスト環境の安定性が向上する。
継続的システムテストのテストレベル
継続的システムテストでは、各テストフェーズがそれぞれ適切なテストレベルを持っている。ここでいうテストレベルはBeizerの言う「テストのスコープや観点」だ[2]。なので、例えば
システムテストフェーズの中で
の両方を実施する
- 「単体テスト」や「インターフェースの結合テスト」といった低レベルのテスト
- 一般的にテストレベルの文脈の中でシステムテストと呼ばれる「パフォーマンステスト」「信頼性テスト」「運用性テスト」
という、言葉的には少し奇妙な事態が発生する。
しかし、この一見すると少し奇妙な現象がもたらすメリットは大きい。システムテストフェーズでも、単体テストレベルからシステムテストレベルまでのテストレベルを網羅する事で、
- テストの網羅性を担保する事
- 柔軟にテストレベルを変更したり、テスト設計のリファクタリングを行うことででテスト活動を効率化する事
が可能になる[5]。
アジャイルテストと従来のソフトウェアテスト
勘のいい人はお気づきだと思うけれども、僕は継続的システムテストは継続的デリバリーと同様にアジャイルテスト四象限と自動化にのっとってテストを整理し直したコンセプトだと考えている[6]。
アジャイルテスト四象限では「誰に」「どんな」価値をテストが提供するのかを考える[7]。次にそれらの価値の提供を「いつ」「どのスコープのテスト」によって実現するのかを考える。
この『「誰に」「どんな」価値を提供するのか』の部分が『V&Vとテストフェーズ』だし、『「いつ」「どのスコープのテスト」』の部分が『「テストフェーズ」「テストレベル」』だ。
これらのコンセプトや考え方は別にウォーターフォールやテスト自動化を前提としていない[8][9]。もちろんウォーターフォール開発でも実現可能だが、継続的デリバリーやアジャイルテストにおいても実現可能だ。
継続的システムテストやアジャイルテスト四象限は従来のテストの考え方を積極的に取り入れている。突然変異的に生まれたものではなく、むしろソフトウェアテストの発展の歴史の中で正統的に出てきたものだ。
お知らせ
継続的システムテストについて2015年9/18(金)にソフトウェア品質シンポジウムでお話しします。ご興味のある方は是非ご参加ください。
参考文献
- [1] ソフトウェア・テストの技法第2版 - グレンフォード・J.マイアーズ - 4764903296 : 本
- [2] ソフトウェアテスト技法: ボーリス バイザー, Boris Beizer, 小野間 彰, 山浦 恒央: 本
- [3] 継続的システムテスト - Test Automation
- [4] ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
- [5] テストの期待値を分解すると言う事 ~Web Service QA Meeting Vol.1の感想~ #webqa - Test Automation
- [6] 楽天ブックス: 継続的デリバリー - 信頼できるソフトウェアリリースのためのビルド・テス - ジェズ・ハンブル - 4048707876 : 本
- [7] Agile Test Planning with Agile Test Quadrants
- [8] Guidelines for Verifying and Validating Software Requirements and Design Specifications
- [9] システムテスト自動化 標準ガイド - MarkFewster - 4798139211 : 本