【ソフトウェアテスト】エラー推測テスト
エラー推測テストは経験ベーステストの一種です。
最も単純な表現をするならば、「どうすればエラーが発生するか」を想像して試行し、エラーを再現させることを目的としたテストの手法です。
1. エラー導出へのアプローチ
決まったテンプレートはなく、実施に必要なのは自身のナレッジと経験、過去に類似の対象に対して実施されたテストの方法、過去に検出された不具合例など、定型化されていないような技術や方法を求められます。
しかし、テスト対象ごとにエラー推測の方法はさまざまですが、全く無軌道に推測をするというよりも、対象によって想定する観点はある程度指針を決められます。
2. コードベースのエラー推測アプローチ
・コードの構造
プログラムのソースコードに関する知見があると、どのような記述ミスが発生しやすいかという観点をもとに、不具合を想定することができます。
境界値分析のテストスコープなどにも含まれますが、数値の境界を設ける際に、自然言語の仕様定義で「以上」「以下」「未満」「超える」と記載した各表現に対し、コード内で「>=」「<=」「>」「<」を記述する際に仕様の想定とは違う境界を設けてしまい、不整合が発生するというケースが考えられます。
ソースコードと動作させる実物の両方を用いて、このコードの書き方ならこの辺りの記述が間違えていそうだと推測、実機を操作した結果で生成されたコードを読む、この一連の確認を繰り返して、操作した結果で生成されているコードが想定と違うといった場合に、実機では想定外の動作となり不具合につながるというケースもあります。
コードの記述からエラーを推測するという方法のため、いわばコードレビューの側面もあるので、領域としてはホワイトボックステストとブラックボックステストの両方の性質を有したグレーボックステスト手法とも言えます。
JSTQBに記されるテストの7大原則の一つ「不具合は偏在する」に通じていますが、記述ミスの発生するコードのパターンというのも実際にあり、コードの書き方も一定の規則はあれど個人のクセや特徴があるのが常ですが、このエンジニアはこのコードの記載ミスをよくするといった傾向がつかめると、エラーは推測しやすくなります。
3. 過去に検出した不具合からのアプローチ
・不具合分析結果
不具合分析活動をするプロジェクトでは、過去に検出した事象の分析結果をエラー推測に活用することができます。
エラー発生率の高い部品や要因を特定できれば、過去にこういうエラーが多かったから同様のエラーが発生するかもしれないと予測して、対象箇所のテストを厚くすることでより早期にエラーが発見できる可能性が高まります。
「【ソフトウェアテスト】欠陥分析手法について」記事でも取り上げていますが、各種欠陥分析手法を用いて、過去データの統計的分析から不具合の偏在する傾向を予測してエラーを推測することもできますし、「【ソフトウェアテスト】不具合報告のインシデントレポートについて」記事でも取り上げたように、過去に報告された不具合はbug tracking system（BTS）で管理することで、各事象個別に詳細な事例を過去のチケットから参照することもできます。
・本番環境発生不具合のフィードバックと対応
テストでは検出せず、リリース後の本番環境で初めて不具合を検知するということもよくありますが、それはやはりテスト実施時のデータや環境はあくまでテスト用であり、エンドユーザーが使用しているデータや環境でこそ発生しやすい不具合があるということです。
発生時の再現手順やデータの詳細が判明しているのであれば、その内容からエラー再現パターンが推測できるようになるので、そうした情報を蓄積し分析することで、テストで検知しにくい不具合もカバーしやすくなります。
4. 実環境の状況に基づくエラー推測
・デバイスの仕様
テスト対象を動作させるデバイスに関するナレッジは、エラー推測に際して必要なものです。
スマートフォン向けのアプリケーションにおけるエラー推測に関して、iOS系端末/Android端末では仕様が違ったりや固有の操作が存在していたりします。
メジャーなものでは、iOS端末の3Dタッチやアクセスガイド、Android端末のホームボタンや戻るボタンなどです。
検証に使用するデバイス自体にも動作スペックがあり、特定のスペックのみで再現するエラーなどはいくらでも存在するので、対象となるデバイス以外にどのようなパターンのスペックが存在するのかという広い知識を持っていると、より高度で詳細なエラー推測が可能になります。
・時間や日付のエラー原因
テスト環境では検知や確認が難しいが実環境では発生しやすいエラーとして、時間や日付に関するものはメジャーな存在です。
これはテストというものの性質にも起因していますが、日付に関わるテストはそのほとんどがリアルタイムでのテストが困難であるということです。
日付の切り替わりの動作テストを実施するときに、実際に対象となる時間をリアルタイムで待ってからテストするのでは、リリース前にテストすることができないため、テスト環境のみ時間設定をテストデータとして操作可能にする必要があります。
このため、テストデータとして時間を任意に変更すると、現実ではありえないような時間の逆行などの現象が発生し、テスト環境でしか再現しないような偽陰性の現象を検知してしまう事があります。
上記の他にも時間や日付がエラー原因となる理由として、日時によって切り替わる以下のようなシステムが関連した際に、仕様を想定していない動作が発生することがあります。
・年の変わり目
・2000年問題
・閏年
・海外展開しているサービスは国外との時差
・アメリカ合衆国圏内に展開しているサービスではサマータイム
等
5. 追記
この手法自体は体系化されたシステマティックなものかといわれればそうではなく、定量的にテストの実績を明確な数字で出せるものでもありません。
開発の現場でテスト担当の実績を求められる場合に、何件テストをして何件不具合を検出したかという件数でしか実績を認められず、テスト担当者は消化テストケース数と不具合検出数を稼ぐことばかりに腐心するようなマインドに偏りがちになります。
工数と費用を割いてテストをする以上、実績となる件数を上げることはもちろん大事ですし、プロジェクトとしてもテスト活動を評価するときに、「1件の再現困難な不具合を解明した」より「何日までに何件テストできた」の数字を元に評価したほうが、費用対効果が目に見えるので評価しやすい面はあるため、テスト担当者の能力を問う際に求める要件として、定量的にテストケース数に関わる同値分割法やデシジョンテーブルテスト手法などの理解があるかに重点を置かれることがあります。
しかし、やはりバグ探しの根本は「どうすればバグるのか」を考えるところから始まっているので、テスト活動の根本的な目標である「品質の向上」を達成するためには、こうした定性的な技法についても造詣を深めることが必要です。