Skip to main content Skip to Footer

LATEST THINKING

テスティング・サービスの現在と
今後の展望

テクノロジーコンサルティング本部
テクノロジーアーキテクチャ
グループ
シニア・マネジャー
下野 隆資

テスティング・サービスの在り方は、ITシステム全体の進歩と共に発展してきました。この論考記事では、日々、テスティングの現場でどのような課題が発生し、どのような解決が試みられているのかについて、「自動化」や「仮想化」の最新ツールについて事例を交えて解説するとともに、アクセンチュア・テスト・センター・オブ・エクセレンス（TCoE）の役割や機能、体制についても紹介します。

世界中のテスティングの知見が集約

アクセンチュアの東京ソリューションセンター（TSC）には、JavaやSAPの開発のプロフェッショナルや、テスティング、DevOpsなどを専門とするチームが集まり、多種多様なプロジェクトに参画してデリバリーを展開しております。TSCのテスティング・チームには約30名のスペシャリストが所属しておりますが、テスティングに従事するスタッフはグローバル全体で３万5000人おり、大型の専門家集団を形成しています。

私たちテスティングの専門家チームは、テスティングに関する知見や情報、アセットを連携するだけでなく、案件規模によっては海外のチームとタッグを組んでおり、アクセンチュアの組織力の結集したひとつの形であるともいえるでしょう。

テスティングの進化と今まさに取り組むべきこと

現在、テスティングはどのような状態にあるのでしょうか。またどのような進化を歩んできたのでしょうか。それを踏まえ、今後私たちはどういったことに取り組む必要があるのかを最初に考えます。

2000年代は設計開発とテストの間に連携はほとんどなく、いわゆる「V字モデル」の左側（設計・開発）と、右側（テスト）は分離していました。上流で開発・構築したシステムを下流工程でテストし、品質を保証するというのが主流ではありますが、いざ下流工程でテストをしてみると、設計に漏れがあったりバグがあったりして、プロジェクトが炎上しはじめ、しかし、リリースもすぐ先に迫ってきていることから、その中を突き進むしかないという辛い経験を多くの人がしたことと思います。

2010年代になると、テスト工程を効率化すべく、画面操作の自動化が登場しました。テストそのものだけでなく、資源管理やテスト環境構築の自動化など、DevOpsに代表される様々な自動化が登場し、日々進化しています。テスト工程の効率化はこれからも早いスピードで進化していくでしょう。

また、テスト工程をいくら効率化しても「品質そのものは高めることができない」という根本的な課題に対しては、「Shift Quality Left（シフト・クオリティ・レフト）」というアプローチが登場しました。“レフト”とはシステム開発の工程における上流を指し、「上流工程から品質を作り込んでいき、下流のテスト工程に引き渡す」というアプローチです。品質が作りこまれる要件定義や設計・開発などの上流工程をテスターがレビューし、曖昧な仕様や処理を明らかにしながら、テスト計画やテストコンディション設計を並行することで、品質そのものと品質保証（すなわちテスト）の精度を高めていきます。

2020年頃までに、テストに関する単純作業はほぼ完全に自動化されると考えられます。そこに自然言語解析やAIが加わり、より高度な自動化も可能になるでしょう。エンタープライズのシステムは社外の様々なプラットフォームと連携して、今まで扱ったこともないような大きなバリューチェーンを形成するでしょうし、AIの処理のメカニズムは人間には把握しきれないほどに複雑になるものもあるでしょう。そういった世界において品質保証をいかに行うか、新たな課題が浮上すると考えられます。

とはいえ実際のテスティングにおいて、一足飛びにAIを駆使した高度なテスティングが実現することはありえません。現時点ではどのような施策に取組むべきなのでしょうか。

（1）Shift Quality Leftとテスターへの「品質の番人」の役割の付与
テスト対象のシステムやプロダクト、プログラムが下流で品質チェックされるよりも前の段階で、品質を作り込んでいくアプローチ。これが最も重要な取組みの1つです。

また、近年はテスターの役割が変わりつつあります。従来の下流でテストに専念する立場だったテスターは、今後は「品質の番人」として、品質の作り込みから携わることが求められるようになりました。

トラディショナルなアプローチでは、上流工程の段階でテスティングを意識して開発を推進することは稀でした。テストのフェーズで帳尻を合わせるケースが頻発していたことには、そのような背景があります。Shift Quality Leftの考え方が否定されているのではなく、現場ではその実践に向けたハードルが高いのです。

（2）新しいテクノロジーへの取り組み
テスティングの効率化に貢献するテクノロジーが日々誕生しています。それらの活用がテストを効率的に進めて行きます。まずは様々なテスト自動化を理解し、活用することが重要です。我々は、前述のShift Quality Leftのアプローチにおいて、上流工程で品質を作りこむのと並行して、その品質をどのように効率的にテストしていくのかを検討し、自動化適用計画や自動化アーキテクチャーとして定義しています。

（3）フルオートメーション化
開発したプログラムを動作させ、その品質を確認するのがテストです。テストを実行するまでには、開発したプログラムを集めてビルドし、テスト環境を準備し、デプロイし、必要なデータやスタブをセットする必要があります。部分的や断片的に自動化するのではなく、これらテストの周辺作業まで含めて一覧の作業を自動化していくことが重要です。これは、様々なテスト自動化ツールとDevOpsを組み合わせることで実現します。仕様変更やバグ修正に対して、このようなフルオートメーション化によって、開発全体のスピード感を失わずに繰り返しテストを可能にします。

拡大するテスターの役割。Shift Quality Left - 上流工程の品質作り込みから下流工程の品質保証まで

従来のテスターは、下流工程でテストを計画・実行し、品質を評価する。すなわち、Test for Qualityを繰り返していました。しかし、最近は、開発スピードが速くなり、要求も複雑になり、少しの手戻りが命取りになるという状況です。品質の番人としての経験を活かして、設計・開発チームと一緒になって「上流工程の品質の作り込み」への参画が求められています。しかも、引き続きコスト削減が求められる中で、「テスト効率性の追及」も欠かせません。

従来は、開発工程の終盤に差し掛かったあたりからテスト計画に着手し、テスト設計やテスト実行に着手したころから、設計やプログラム品質の悪さに気づき、突如プロジェクトが炎上し始めるといったことが少なからずありました。テスターからすれば、品質の悪いものはテストしようがないと言って、設計・開発チームを責めるのは簡単ですが、では、テスターができることはなかったのか、あまり真剣に考えられて来なかったのが現状ではないでしょうか。

弊社では、テスターがテストをオペレーションするのみならず、上流工程におけるQuality Engineeringに取り組むべきと考えています。

最初のポイントは「全体のテスト戦略をシステム開発構想の早期段階から策定していくこと」です。

これはテスト戦略を計画書に落とし込むというだけの話ではなく、ステークホルダーやプロジェクトのスポンサー、あるいは開発アーキテクチャーの責任者、現場の有識者などと連携して情報をすくい上げ、いかにしてテスティング工程を早期に立ち上げて、どのようにテストしていくのかを早く決め、合意するということです。

また、上流で品質を作り込むための施策として、下記のような例が挙げられます。

  • ステージ別のテスト計画を立て、ステージ別のテスト計画の中でテストの観点を絞り出す。それらの観点をもってコンディションに落とし込み、テスト設計の概要を準備する。
  • 開発仕様書を1枚でも多くレビューしながら、テスト仕様に落とし込んで行く。そして仕様書をテストコンディションでチェックして、フィードバックを繰り返すことでテスタビリティの観点から上流の品質を高める。

これらの施策はシステム品質を高めるものです。しかしこれらがあらゆるプロジェクトで適用可能かというと、実はそうではありません。

なぜならば、次のような課題が上記の施策の実行を阻むケースが多いからです。

  • システム更改時に、現行システムのアーキテクチャー設計書が揃い、かつ最新化されているケースはごく少数にすぎない。
  • システム要件定義、仕様策定の前提となる、プロジェクト全体の合意形成ができていない。

テストの原点に立ち戻ると、上流工程で設計したものが仕様通りに動作することを検証するのがテストの目的です。したがって、品質保証で鏡とする、システム全体像、アーキテクチャー、機能設計などの設計成果物がどの程度定義され、最新化されているかを初期にチェックし、不足しているものを新たに準備する必要があるのかを検討します。例えば、業務の有識者であっても把握が難しいシステム仕様があれば、リバースエンジニアリングツールを使ってソースから仕様を詳細にリバースする必要があるかも知れません。

また、設計そのものを正しく行わせるために、成果物定義や成果物フローを確認し、テスト条件を設計するのに十分な情報が定義されるよう、プロジェクト全体の合意形成を推進しなくてはなりません。

自動化ツールの知見は蓄積されつつある

開発コスト全体の30%~50%がテストである。といわれており、テストの効率化は重要な課題です。そのために「テスト自動化」が検討されてきました。一言で「テスト自動化」といっても、最近では「画面操作の自動化」以外にも次のような自動化ソリューションが出ています。

  • 仮想的にインターフェースを再現できるサービス仮想化
  • テストデータ管理の自動化
  • テストケース設定やテストケースの管理の自動化

これらにはもちろんテストを効率化するメリットがあるものの、利用によって新たに生じる負荷などのマイナス面も存在します。それは特に、テスト自動化を継続的に利用し続けるためのメンテナンスです。たとえば「画面操作の自動化」のために生成されたスクリプトは、テスト対象のアプリケーションが仕様変更等で改修された場合に、同様にメンテナンスする必要があり、それを継続することはコスト面とスピード面で難しくなります。一見すると便利だが、継続して容易にメンテナンスする仕組みが無いと、スピードが失われてしまうのです。

一方、クラサバや、ネイティブアプリ（特にiOSのネイティブアプリ）で、画面上のオブジェクト構成が特定できない場合や、データ入力がフックできない複雑な構造などの場合は、画像認識で自動化するパターンも増えています。このようなケースでは「OpenCV」のライブラリを使って、画像認識で自動化します。

操作したいところの画像をあらかじめ登録しておいて、画像認知したところにデータを持って来てテストできます。Webだけでなく、クラサバ系のテストの自動化も、データを入れて自動化することができます。

最近ではRPAの案件において、オープンソースのオートメーションを組み合わせてRPAを実現するといったアプローチもあります。Sikuliを活用し業務プロセスの自動化を実際に導入しているケースがあります。

テストデータ仮想化によるテストデータ管理に成功

昨今ではテストデータの管理も自動化しています。この手順には大きく3つのステップがあります。

  1. データを取得する
  2. データのマッピングやマスキングを行う
  3. データを検証環境に配置し、テスト実行後に実行前の状態にロールバックさせる

データのメンテナンスをするうえでの課題として挙げられるのは、データのマスキングやデータの物理的な移送のための時間の確保です。また、再テストのためデータの状態を戻したい時は、バックアップ断面に戻していく運用も必要となります。

これらを解決するソリューションとして、データ仮想化技術を活用しテストデータ管理の自動化を実現した事例があります。

特に、テストデータが数百GBにおよぶ場合、検証環境にこの大量データをどう移すか、移送時間とディスク容量の両面で困難です。この課題の解決で私たちが注目しているのはデータ仮想化技術です。本番環境のデータを独自のアルゴリズムで圧縮して、マスキングして、テスト環境に仮想的なデータ断面を実現します。

実際に物理的なデータを移行するのではなくて、仮想データをマウントすることで、あたかも自分のデータベースであるかのように見せかけて動作させます。たとえば650GBのSAPのデータは、同じ形ではないとしても、数分で完了します。あともう1つ重要なのは、仮想的なデータを持っているので、テスト後にそれぞれ実行前の断面に戻すことができます。これにより、継続的なテストが可能になりました。

インターフェース仮想化

インターフェース仮想化も重要なソリューションの1つです。様々なAPIを利用して外部システムとの連携テストを行いますが、外部システム側にスケジュールや制約があって、決まったスケジュールでテストができない場合があります。

そこで応答を返すスタブやドライバー機能を作って対応するというのがこれまでの手法でした。しかしこれでは通常一定の応答方法しか実施できず、リアリティのあるデータの返し方ができません。そうしたケースで効果があるのはインターフェース仮想化のソリューションです。要求に対する応答を遅らせて返信したり、短い時間に一気に要求を送信するなどパフォーマンステストでも活用することが可能です。

ある大手銀行ではEnd-to-Endの性能試験を実施したいというニーズがありました。その業務システムは20個以上のシステムと連動しているので、それらも網羅しなければなりません。そこで連携できないシステムについてはそれぞれのスタブを作る形でコントロールしました。

20個のシステムに成り代わって仮想的に応答をする。そして自分のシステムの負荷をテストする。これならばコストも削減できますし、なにより下流システムとの調整をセルフサービス化してインターフェースのテストをするといったことが可能になります。

テスト実行管理指標

アクセンチュアでは、テスト実行管理で管理すべき項目を共通化して14個の標準指標を決めています。それらは大きく分類すると「進捗の指標」と「品質の指標」の2つに分かれます。

テスト実行管理指標を利用することで、次のようなことがわかります。

  • 現在の進捗状況や障害の解消状況などから、いつテストが完了するのか
  • 障害の発生状況を把握して、テストが終わるまでに、どれくらい障害が出るのか

現在はまだExcelのテンプレートを利用中ですが、アナリティクスツールでこういった情報をリアルタイムで見られるように工夫しています。

AIや自然言語解析によって、障害の原因分析や機能別の把握などはアナリティクスツールで実施できます。さらにその先には、「誰が関わっている機能でバグが多いのか」といったことや、障害情報をインプットする際に「発生事象や原因、発生個所など、十分な情報を記載しているか」を自動チェックするなどの高度化にもトライしています。


以上は個別の自動化の例ですが、最終的には連携することでフルオートメーション化できないかと考えています。ではどう連動させるか。キーはDevOpsとの連携です。

最終的にはDevOpsの基盤と連携させて、開発したものをEnd-to-Endで、セルフサービスで、いつでもテストできる仕組みにしたいと考えています。

アクセンチュア・テスティング・センター・オブ・エクセレンス（TCoE）

アクセンチュアでは蓄積した知見を専門組織のアクセンチュア・テスティング・センター・オブ・エクセレンス（TCoE）に集約しています。TCoEはテスティングのエキスパートや第三者のテストの専門家が常に同じアセットやプロセスを使い回していくことで、たえずテスト品質を向上させています。

テスターにもとめられる役割が広がり、テストが高度化している現在は、プロジェクト単位でテストすることや、テストの実行をシェアードチームにするだけでは、テスト品質の向上やコスト削減は難しいため、第三者、あるいは、テスト専門組織による、テスティングの集約化や工業化を通して、一定のテスト品質やコスト削減にコミットするようなモデルが最近注目されています。

第三者がテストを実施するときに「仕様書は揃っているか」「アーキテクチャー設計書は最新か」、といったことを確認しますが、満足に揃っていることはめったにありません。ですがテストは実施しなければなりませんので、アクセンチュアのテスティング・サービスは、そうした事態にも対応できる体制としています。そのデリバリーのモデルは下図のとおり、大きく4つの領域があります。

テスティングの全体計画を描き、テスト戦略を策定します。そして個別のテストを具体化して立ち上げていき、テスト設計し、実行し、品質評価を行います。テストオペレーションそのものは、弊社のオンサイトのテストリソースを主に使用しますが、アクセンチュアのテスト専門のデリバリーセンターとも連携します。そういったオペレーションも当社の専門領域となります。

オペレーションのフェーズでは次のような専門家が参画して実行を支援します。

  • 管理業務の専門家
  • テストオペレーションやテストインフラの専門家
  • インターフェース仮想化やテストデータの管理の専門家
  • 自動化技術の専門家　など

アクセンチュアならではのユニークな点として挙げられるのは、最新技術検証やアセット化を専門に行う、テストイノベーションチームです。様々なプロジェクトのテスティング活動を通して得られた知見を整理したり、最新のテクノロジーを目利きして、テスト自動化基盤に取り込んだりします。このようなデリバリモデルにより、テストに関わるサービスを一定の品質で提供しているのです。

関連コンテンツ