・テストには技法など不要？

ソフトウェアをテスト/検証する際、テストの対象ごとにさまざまなテストの技法が存在します。

極端な表現をすれば、体系化された技法を用いなくても、ソフトウェアテストを実施すること自体は可能です。

バグを見つけ出すという目的のみを達成しようとするならば、テスト対象へ無作為にアプローチして偶発的にバグを引き起こすことができれば、目的は一応達成しているといえます。

※上記のような方法も、経験ベーステストの[モンキーテスト]や[探索的テスト]に類するテスト方法です。


値を入力するような機能に関するテストなら、適当に値を入力して動くことを確認すれば、
その機能が動作することだけは証明できますし、めちゃくちゃな値を適当に入力してみておかしな行動を引き起こすことができれば、バグを検出できているといえます。

※数字入力欄にひらがなを入力するなど、明らかに想定されていなさそうな入力値をテストするような手法は[エラー推測]テスト技法に含まれます。

・バグ探しの技術

テスト現場でもエンドユーザーでも、やたらとバグを引き起こす嗅覚の鋭い人がいたりします。

ソフトウェアテストという言葉があまり一般的ではなかった時代の名残で、バグ探し作業をする人を[デバッガー]と呼ぶ風潮は今でも一部に残っており、再現性の低いバグやクリティカルなバグを容易に引き起こす人は[優秀なデバッガー]として、バグを探す能力の高さが重宝されたりします。

※補足
[デバッガー]は本来「バグを修正する作業・役割」や「バグ検出・修正用の開発ツール」などバグを取り除くという意味で用いられ、バグを探す作業者は[テスター]と呼ばれます。

・バグを全て検出できるか

本来の理想としては、ユーザーに提供されるサービスに問題があっては困るので、開発したソフトのバグはゼロであるべきですが、JSTQBが定めるソフトウェアテストの7原則に以下の点が記載されています。


 1.テストは欠陥があることは示せるが、欠陥がないことは示せない

バグを検出することでバグが存在することを示せますが、そのバグを除けばもうバグは存在しないと証明できるわけではありません。


 2.全数テストは不可能

テスト対象で複数パターンの組み合わせが想定される場合、できれば全てのパターンをテストすべきですが、時間とリソースを考慮するとリリースまでにテストしきれない可能性があるので、テスト技法を用いてテスト内容や工数を適切に選択する必要があります。


上記2点から、バグの全く存在しないソフトウェアというのは、非現実的なレベルで達成困難な目標になります。

※参照　ISTQB テスト技術者資格制度 シラバス
https://jstqb.jp/syllabus.html

・効率的なテスト

全てのバグを検出するのは現実的に不可能なので、取捨選択が必要になります。

少し表示や挙動がおかしいけれど、サービスの可用性を損なっていなかったり、エンドユーザーにはあまり影響がなかったりするものについては、たとえ検出・報告して修正の工数をかけても、エンドユーザーの利益やプロジェクトの品質向上にうまく寄与しなかったりするものもあります。


あるいは、動作パターンとして想定される組み合わせの中でも、エンドユーザーが使用する可能性が極端に低いと想定されるパターンは、工数をかけてテストをしても実際にはほとんど使用されないので、テスト工数をかけた割に開発／エンドユーザー両サイドへのリターンがあまりないという場合があります。

入力数値や境界値を検証するテスト内容で、あまりにエッジケースな数値についても、上記同様テスト工数が無駄になることがあります。


決められた期間内に限りあるリソースで効率的に検証を実施しようとするなら、優秀なデバッガーの嗅覚のみに頼った無作為なテストではカバーしきれないので、検証対象を適切に抽出して最適な検証工数を割いたり、共通化された形式を用いて個人の技術に依存しすぎずムラなく検証を実施したりすることが必要です。

より高品質なテスト実施を目指すならば、テストケースに

・バグを見つけるのが仕事？

ソフトウェア開発現場では、バグは見つけたらそこで終わりとなるものではなく、検出した問題は対処の方針を決めなければいけません。

ただ、見つけたバグを修正する作業にも工数はかかるので、検出して報告したバグは全て修正できるかといえば、こちらもリソースの問題から理想と現実に差異が生じます。


バグは本来あるべきではないので、可能な限り検出して、検出次第報告を進めるべきですが、見つけて、報告して、修正して、修正確認して、の一連の作業を見つけ次第順次で対応してしまうと、ユーザー影響のほとんどない軽度のバグから対応を進めてしまって、サービスが利用できなくなる程のクリティカルな不具合が後回しになってしまうなどの懸念があります。

より高品質のプロダクトを目指すならば、ただ片っ端からバグを見つけようとするのではなく、優先順位や重要度に基づいてテストを実施するのが望ましく、上記判断基準をテストに適用するためにもテスト技法は有効です。

・テストの立場からプロジェクトに貢献する

テストはあくまでテスト対象となるものそのものがなければ実施に至らず、そもそものテスト対象となる製品を作成する役割のエンジニアなどと比較して、作業内容が軽視されがちです。

また、テスト技法の有用性が認識されていないと、テスト作業なんて専門性がなくて誰でもできる作業なので、エンジニアに開発のついででテストさせればテスト個別にリソース割り当てする必要はないと考えられるプロジェクトもあるかもしれません。


しかし、テスト技法を用いず無軌道なテストのみでとりあえずのリリースを繰り返してしまうと、品質の低いプロダクトでユーザー不利益が増えていき売り上げが下がったり、開発も場当たり的な修正対応に追われてより工数が窮迫していくため、最終的にプロジェクトが失敗に至るリスクが高まります。

テストケース作成時にテスト技法を用いることで、体系的・網羅的・効率的なテスト実施が可能となること、テスト実施時にテスト技法を知っていることで、個人のナレッジのみに依存せず、不具合検出の精度を向上させることができることなど、テスト技法はテストとプロジェクトの高品質化に寄与します。

テスト技法を身につけ、あくまでテストを専門タスクとして開発プロジェクトに参画することで、テストという立場からプロジェクト全体に貢献することができます。

・品質保証として

テストの役割ではなく多少プロジェクト管理側の役割に寄った内容になりますが、検出した不具合については、報告以降は対応状況を観測して解決・未解決状況を整理・管理し、不具合全体を統計・観察・分析して、継続的なモニタリングとコントロールを実施することで、プロジェクトの品質向上に貢献できます。

テストケース作成やテスト実施時にも、分析した不具合をベースに適切なテストを想定できるようになるので、より高品質なテストをプロジェクトに提供できるようになります。


また、テストスケジュール管理や工数管理などテスト活動全体の分析・管理手法を身につけることで、テスト活動の無駄を見つけて省いたり、より効果的なテスト方法を適用できるようになります。