テストは増え続ける、でもボトルネックにはできない
今、あらゆることが爆速で進む。飛行機は、生まれてからユーザー数が5000万人に到達するまで68年かかった。自動車は62年。電話は50年。テレビは22年。インターネットは7年。ここから情報の伝達が早くなり、YouTubeは4年、Facebookは3年。そしてPokémon GOになるとわずか19日。朱峰氏はこうした状況を鑑みて「超爆速な時代」と評する。
となると、時間をかけてはいられない。どんなに素晴らしいアイデアでも開発や準備に何年もかけていると、誰かに先を越されてしまうかもしれない。さらに市場のニーズも変わる。時間をかけるほど、リスクは高まる。
満を持して完ぺきなものをリリースしたとしても、市場に受けいれられるか分からない。朱峰氏は「アジャイルは成功を保証するものではないと考えていますが、失敗のリスクを少しでも少なくするプロセスです。こまめに出して軌道修正していくのがアジャイルの本質」と話す。アジャイル開発は不確実な時代においてITビジネスリスクを低減させるシステム開発のスタイルと言える。
いまはあらゆるソフトウェアやプロダクトが継続的に進化する時代である。そうなるとテストも継続的に追随する必要がある。これは大変なことだ。朱峰氏はこの理由について「回帰テストがつきまとうからです」と説明する。手を入れていないところへの影響も確認しなくてはならないので、テスト頻度が増加すればするほどテストが津波のように押し寄せる。
さらに大規模アジャイルについて考えると、大きく分けてエンタープライズ企業の事業トランスフォーメーションのパターンと小さく始まった事業がスケールするパターンがある。スタート地点が異なるのでいろいろと差異はあるものの、朱峰氏は「基本的にはどちらも分割と統合」と言う。ただし分割の仕方がいろいろと進化している。
どんな形にしても分業や分割をすると、全体感がつかみにくくなる。さらに、先述したような回帰テストの問題も顕著になってくる。そのため大規模アジャイル実践では、分業や階層化に起因して全体的な統一感が無くなることに歯止めをかけることや、統合テストがボトルネックにならないようにテスト活動を効率化することに気を配ることが求められる。
テスト効率化のカギとなる「テスト資産」とは？
大規模アジャイルにおける課題について朱峰氏は対応方法を紹介する。1つめのアプローチはテスト資産管理の効率化だ。テストプロセス全体の流れを見渡すと、最初はテスト計画から始まる。リソースは有限なので、いかにコスパ良く実行できるか作戦を立てて（分析・設計）、テストケースに落とし込む（実装）。ここで自動化する場合もある。データや環境などの準備をしたうえで、ようやくテスト実行へと進む。実際は全てが計画通りに、1回でテストが通るとは限らない。どこかでバグが見つかり2周目、3周目の繰り返しを経て、最終的に全体を振り返ってようやくテストは完了する。
この一連のプロセスの中で、テストで使うテスト観点、テストケース、テストデータといった成果物がテスト資産だ。
そしてもう1つ、朱峰氏は「テスト結果もうまく扱っていくべき」と提言する。プロジェクトは繰り返し発生するため、過去のテスト結果をうまく活かすことで、以降のテストのアジリティを上げることができると期待できるためだ。
朱峰氏によるとテスト資産管理に着目する理由は主に2点あるという。1点目は、仕様変更時の分析の効率化だ。日常的にテストを繰り返すなか、「今回は仕様のどこが変更されていて、どこか変更されていないのか」と、仕様変更が既存テストに与える影響を分析することは結構な手間になる。
この作業を効率化するには「愚直に仕様とのトレーサビリティが取れるテストケースのバージョン管理が求められる。ここは何かしらの支援がないとテストエンジニアが大変になる」と朱峰氏は言う。何せテストは増え続ける。どこかバグがあると、テスト範囲を広げることにもなる。
「そもそもテストは終わりのない活動なのでいくらでも増えてしまうが、ヒューマンリソースは有限」と朱峰氏は言う。どこかで増えたら、その分、どこかで減らすことも考えなくてはならない。
それではどこのテストを減らせるか。これはテスト担当者としては苦渋の決断になる。削ったことでバグを見逃してしまったら……と想像するだけでも恐ろしい。
そこで、テストを減らす判断の助けになるのが過去の実績だ。例えば過去10〜20回のテストで「この機能でバグは出ていない。安定している」ことが分かれば、テストを減らす判断の根拠にできる。朱峰氏は「過去のテスト結果はテストの数や分量を最適化するのに役立つのではないでしょうか」と提案する。
絶え間なくプロダクトは進化する。それに伴い仕様も変化していく。仕様変更の影響分析をいかに迅速に行うか。そして増加の一途をたどるテストから、いかに不要なところを自信を持って削減させていくか。これらの課題を解決するにはテスト仕様とトレーサビリティも含めたテスト資産を人間の頭の中や表計算アプリケーションで管理するのではなく、何らかのツールを使うのが現実的だろう。
ツールについて、朱峰氏は「自社ツールも含め、誤解を恐れずに言えば、まだまだで進化している途上にあります」と前置きしつつも、テスト管理ツールというジャンルを紹介した。
テスト管理ツール導入時には、カタログスペックやプリセールスレベルでの机上判断、無料プランやトライアルにて小規模パイロット案件適用で比較していくことになるだろう。朱峰氏によると、パイロット案件に含めるべきは「100件以上、できれば1000件以上のテストケース」だという。また1プロジェクト内での繰り返し（パスしなかったテストの2周目以降のテストや、パスしたテストの回帰テスト）、2プロジェクト目以降の繰り返し（仕様変更を想定したテストケースなど）を考慮するのがポイントだという。
朱峰氏は「テストケースや過去のテスト結果をしっかり資産として、手の内化して、自分たちのテスト活動を効率化していくこと」とアドバイスする。
仕様書が不完全でも「とりあえず触る」、アジリティの高いテスト
もう1つのアプローチがテストプロセスの全体最適化だ。朱峰氏はテストの大枠の活動においても改善の余地があると考えている。実際プロジェクトのアジリティが高くなるほどドキュメントの更新が後手にまわり、後で認識齟齬が起きて手戻りが発生してしまうこともある。このような場合は、探索的テストが有効だ。これはテスト担当者がテストアイテムや以前のテスト結果の知識や調査情報を使用して、テストを動的に設計、および実行するもの。朱峰氏は「端的に言うと『だったら、触ろうぜ』という単純な発想です」と述べる。
開発段階のプロダクトに直接触れて、そこで得た理解や知見をテストケースに落とし込み、次のスプリントでは回帰テストとして活用していく。そうすることでアジリティの高いテスト活動にできると朱峰氏は考える。
さらに形式張ったプロセスではなく、カジュアルにみんなでプロダクトに触れることで、冒頭の課題にもあった全体的な統一感が無くなってしまうことにも歯止めがかかると期待できる。もっと言えばゲーム感覚でプロダクトに関わることができる。
朱峰氏は探索型のプロセスで行うテストのポイントとして「チームみんなで実施」と「気になるを逃さない」を挙げる。前者はいろいろな立場（プロダクトオーナー、デザイナー、エンジニア、テスターなど）がロール横断で同じプロダクトに触れることで多様な視点で気づきの抽出を加速し、共有する。後者は仕様通りかどうかにこだわらず、気になったらみんなで「これどうなの？」と共有して議論を深めていくということだ。
そうした観点からテストを進めて行くと「みんなのプロダクトへの気持ちがより一体となり、こうした新しいテスト活動がアジャイルチームを支えるインフラになるのではないか」と朱峰氏は提言する。
最後に朱峰氏は「テスト資産をうまく活用すること、そしてテストにもゲーミフィケーションを適用しパフォーマンスを高く、プロダクトに触れることを通じてみんなの一体感を醸成していくことも合わせて進めていくといいのではないかというアイデアの提案でした」と述べて講演を締めた。
テスト活動の効率化に課題を感じている方におすすめ！
仕様の変更/更新/修正に合わせ繰り返されるテストプロセスの生産性を高めるテスト管理ツール「QualityForward」。ベリサーブがご支援した1,100社以上の品質向上のノウハウを生かし、テスト管理の効率化を実現するための機能を提供しています。本記事で興味を持たれた方は、QualityForward公式サイトをご覧ください。
