テストのエビデンスはどうやって取る?作業の無駄を無くすエビデンスツールも紹介
システム開発のプロジェクトにおいて、テストの実施は不可欠です。
テストにおいては、リリースするシステムの品質を担保するため、エビデンスを残すことが推奨されています。
ですが、エビデンスを残すかどうかは現場によって異なるのが現状です。
コストをかけてエビデンスを残すのにはどんな意味があるのか、いまいち分からないという人は多いです。
また、表計算ソフトを用いたエビデンス作成は非常に手間がかかるため、
「エビデンスなんて時間の無駄だ」
という声もあります。
この記事では、そもそも何を指してエビデンスと呼ぶのかから初めて、エビデンスの必要性と取り方、また近年登場した「エビデンスツール」について解説します。
エビデンスとは
証拠や根拠という意味を持つ「エビデンス(evidence)」という言葉ですが、ITの分野では何を指すのでしょうか。
ここでは、テストにおけるエビデンスの意味と、エビデンスがなぜ必要なのかについて解説します。
テストをおこなった証拠と結果
システムの開発がある程度のレベルまで進んだところで、仕様通りに動作するのか、バグがないかなどのテストを実施します。
ITにおけるエビデンスは、このテストをおこなった証拠と、テスト結果をまとめたものを指します。
システムやテスト方式によってエビデンスの形は変わりますが、一般的にはキャプチャ画面やログファイル・システムの生成データとしてエビデンスを作成します。
開発においてエビデンスを作成することは大切ですが、開発スピードが速い現場や特定のシステムではエビデンスを残さない場合もあります。
また、単体テストでは作成しないけれど、結合テストでは詳細なエビデンスを残すという方針も一般的です。
エビデンスはなぜ必要?
テストにおいて、単純な結果だけではなく、わざわざエビデンスを残すのはなぜでしょうか。
エビデンスのもっとも重要な役割は「テストを実施したという証拠」です。
開発したシステムを実際に稼働させ、何かトラブルが発生したとき、先方から
「ちゃんとテストをしたのか」
と尋ねられることになります。
ここでエビデンスが重要となり、なぜトラブルが発生したのか、相手への説明をスムーズに進めることができます。
また、システムに異常が起こり、原因究明をするときにもエビデンスは効果を発揮します。
テスト結果を参照することによって、どこに問題があったのかを探っていくことができます。
言い換えるなら、
「バグが起こった際の責任の所在を明確にし、バグ調査の際の足がかりにする」
これが、エビデンスを取る必要性なのです。
エビデンスの取り方
エビデンスについては、対象のシステムの性質や、開発チーム内のルールなどによって異なります。
そのためここでは、基本的なエビデンスの作成方法を解説します。
エビデンスとして残すデータ
エビデンスとして残すデータの形式が指定されているのであれば、それにしたがってエビデンスを作成します。
特に指定が無い場合は、一般的に次のようなエビデンスを取ります。
まず、システム全般としては、テスト前後のデータ状態と、システムを実行した際のログを合わせてエビデンスとします。
Webシステムをはじめ、スクリーン表示があるシステムでは、テスト時の画面のキャプチャをエビデンスとして残します。
特に、テストを実行した際のログは、システムについての貴重な情報が含まれているため、ずっと後になってから発見された不具合に対しても役立つことが少なくありません。
エビデンスを作成するコストとのバランスを考慮する必要がありますが、なるべく詳細なデータまでエビデンスとして残すことが重要です。
テストシナリオ・テストケースの作成
テストをおこなう手順とテスト結果の評価方法をまとめたものを、テストシナリオやテストケースと呼びます。
結果がテストケースで定められた基準をクリアするかどうかで、テストの可否を決定します。
テストシナリオで手順を指定するときに、いつ・どのようにエビデンスを作成するのかも決めておきます。
エビデンスの紐付け
エビデンスは、それ単体で効果を発揮するものではなく、必ずテストケースと結びつけられる必要があります。
そのためには、テストとエビデンスのデータが紐づいていなければなりません。
紐付けの方法としては、エビデンスにテストナンバーを振って、フォルダで階層を作成して管理するのが一般的です。
そのほか、スプレッドシートに格納する、あるいは専用のソフトウェアを使用して管理する方法もあります。
結果・不具合管理表の作成
テストをひとつ実施するごとに、エビデンスとテストを紐付け、結果を記録し、不具合管理表を作成していきます。
基本的に、結果として記録するべき項目は、実施日・担当者・テスト結果の3点です。
テスト結果を受けて対応が必要になることを考慮して、その分の項目を合わせて作成しておくことも大切です。
そして、テストを実施して不具合が発見されたら、不具合管理表に記載していきます。
不具合管理表には、結果に記載する項目と合わせて、具体的な不具合の内容と、システムとして想定されていた動作、どのような段取りでテストをしたのかなどを記録します。
エビデンスツールとは
開発したシステムのクオリティを担保することが、エビデンスの大きな役割です。
そのため、ほぼすべてのシステムについてテストをおこない、エビデンスを作成していくことになります。
エビデンスの作成・管理に表計算ソフトを用いている現場は多いのですが、現在は専門のエビデンスツールが数多く登場しています。
ここでは、表計算ソフトによるエビデンス作成・管理の負担と、エビデンスツールの有用性について解説します。
表計算ソフトを用いたエビデンス作成の負担
多くは無料で利用でき、操作も簡単でさまざまなカスタマイズが可能なため、エビデンスの作成や管理に表計算ソフトを利用している現場は数多くあります。
ですが、表計算ソフトによる管理には無駄が多く、負担に感じる人も少なくありません。
表計算ソフトでエビデンスを作成・管理することの主な問題点は以下のようなものです。
・どこかにまとまっているテストケースやテストについての情報を引っ張ってくるため、人的ミスが発生しやすい。
・画面キャプチャを表に載せると見づらい。
・以前のテスト結果を参照したいが、記載データが多いと見つけにくい。
・テストやシステムのバージョンごとにファイルを作成するため、ファイル数が膨大になり、管理が煩雑になる。
・そもそもすべてを手作業で記録するため、大変な時間がかかる。
このように、表計算ソフトを用いたエビデンス作成・管理には、さまざまな負担が発生していることがわかります。
エビデンス作成の自動化と効率化
こうした負担を軽減して、エビデンス作成を効率的に進めることができるのが、エビデンスツールです。
エビデンスツールには、テスト自動化ツールの一機能として搭載されているものもありますが、現在は、直観的な操作でエビデンスの作成・管理を効率化するソフトウェアが普及しており、テストやエビデンスにまつわる苦労を解消することができます。
代表的なエビデンスツールを紹介
現在は、テスト自動化ツールと合わせて、数多くのエビデンスツールが登場しています。
ここでは、そうしたエビデンスツールの中から、代表的なソフトウェアを紹介します。
TestRail
エビデンス作成をはじめとするテスト管理ツールの代表が、世界で1万社以上が導入している「TestRail」です。
Webブラウザベースで利用できるツールで、エビデンスやテストケースをはじめとする、テストにまつわるさまざまな情報を紐付けて管理することができます。
分かりやすいUIによる操作感の良さが特徴で、データの作成・編集・管理を容易におこなえます。
また、JIRAやRedmineといった外部の課題管理ツール・テスト自動化ツールとの連携も可能で、テストにまつわる業務効率を劇的に向上させます。
(TestRail:https://www.techmatrix.co.jp/product/testrail/index.html)
TestLink
Webベースのテスト管理ツールである「TestLink」は、オープンソースで提供されているソフトウェアです。
TestLinkは基本的に、外部ソフトと連携して使用します。
テストケースや不具合管理表などのテンプレートを作成してデータベースに保存することができるため、仕様変更や参照がやりやすいという特徴があります。
外部ツールと連携することで、テスト結果を自動で記録することも可能となります。
(TestLink:https://testlink.org/)
PractiTest
「PractiTest」は、そのセキュリティの高さから評価されるテスト管理ツールです。
PractiTestでは、自動テストからテスト結果、エビデンスまでを一元管理することができます。
また、マネジメントツールとしての機能も持っており、テストの進捗といったプロセスを監視することで、開発チームの業務効率向上に大きく役立ちます。
(PractiTest:https://www.practitest.com/)
Qase
開発者向けテスト管理ツールの代表が、この「Qase」です。
テストケースをグループ単位で作成し、重要度に応じて管理することができます。
複数人のチームメンバーが同時に参加して情報を共有し、プロジェクトを進めていく機能に優れているのも特徴です。
(Qase:https://qase.io/)
品質の高い開発はAMELAに
今回は、システム開発で重要なテストの「エビデンス」についてお話してきました。
エビデンスの取り方は、本文中でも記載した様に、会社やプロジェクトによって様々です。
現場でも、フォーマットが統一されていないことが多く、エクセルの見にくい資料が大量に残っているケースもあるでしょう。
オフショア開発に強いAMELAでは、質の高い開発を行っています。
海外人材を使うことによって、非常に安価な開発が可能であると同時に
「適切なテスト工数を見積もれる」
という特徴もあります。
国内のエンジニアを使った開発の場合、予算の関係上
「テスト工数を出来るだけ削る」
という見積もりを出す会社もあります。
そうなると、納品直後は正常に動いていても、長期的に運用していく中で、多くのバグが見つかる可能性があります。
しかし、開発時点でしっかりとテスト工数を設けることで、その問題も未然に防ぐことが可能です。
是非、ご相談いただければと思います。