【テスターとしての心得】5つの考え方
1. テストには、予想される結果の比較だけでなく推論が必要
ソフトウェアテストは、単に「予想される結果」と「実際の結果」を比較するだけの作業ではありません。
もちろん、両者を比較することはテストの基本ですが、それだけでは不十分です。
効果的なテストを行うためには、
・何をテストすべきか? ・どのような結果を期待すべきか? |
といった問いに対して、自ら考え、推論する能力が求められます。
テスト設計の難しさ
残念ながら、テスト設計の「正解」を示してくれるような万能なガイドは存在しません。
既存のガイドラインやベストプラクティスは参考になりますが、それらをそのまま適用すれば良いというわけではありません。
それぞれのソフトウェアやプロジェクトの特性に合わせて、ガイドラインを解釈し、適切なテスト設計を行う必要があります。
経験に基づく推測
多くの場合、テスト設計は、テスターの経験に基づいた推測によって行われます。
過去の経験や知識を活かして、「この機能は、このような使い方をされるとバグが発生しやすいのではないか?」「この入力値は、境界値としてテストする必要があるのではないか?」といった推測を立て、テストケースを作成していきます。
変化への対応
ソフトウェア開発は、常に変化を伴います。新しい機能が追加されたり、仕様が変更されたりすることがあります。
テスターは、このような変化に対応し、柔軟にテスト設計を修正していく必要があります。
探索的推論
テスターは、探索的推論の技術を身につけることで、より質の高いテストを実施することができます。
探索的推論とは、仮説を立て、それを検証するための情報を収集し、分析し、結論を導き出すというプロセスです。
テスターは、ソフトウェアの動作を観察し、問題が発生する可能性のある箇所を特定し、仮説を立てます。
そして、その仮説を検証するためのテストケースを作成し、実行します。
テスト結果を分析し、仮説が正しいかどうかを判断し、必要があればテストケースを修正したり、新しい仮説を立てたりします。
探索的推論を繰り返すことで、テスターはソフトウェアの品質に対する理解を深め、より効果的なテストを実施することができます。
2. 技術的、創造的、実践的に考える
優れたテスト担当者になるためには、様々な角度から物事を捉える柔軟な思考力が必要です。
具体的には、以下の4つの思考力をバランス良く育むことが重要です。
技術的思考
ソフトウェアの仕組みや技術的な背景を理解することは、効果的なテストを行う上で不可欠です。
例えば、システムの構造を理解していれば、どの部分にバグが発生しやすいかを予測することができますし、プログラミングの知識があれば、エラーメッセージの内容を理解し、原因を特定することができます。
技術的な思考力を高めるためには、
・プログラミング言語を学ぶ ・システムのアーキテクチャを理解する ・ネットワークやデータベースの知識を習得する ・最新技術の動向を常にウォッチする |
などの努力が求められます。
創造的思考
創造的な思考力とは、既存の枠にとらわれず、自由な発想で新しいアイデアを生み出す力です。
ソフトウェアテストにおいても、創造的な思考力は非常に重要です。
「ユーザーは、ソフトウェアをどのように使うだろうか?」「どのような操作をすると、バグが発生するだろうか?」といった視点で、様々な可能性を検討することで、より効果的なテストケースを設計することができます。
創造的な思考力を養うためには、
・様々なソフトウェアに触れる ・ユーザーの行動を分析する ・ブレインストーミングを行う ・アイデアをメモする習慣をつける |
などの方法があります。
批判的思考
批判的思考力とは、物事を客観的に分析し、論理的に判断する力です。
テスト担当者は、テスト結果を分析し、バグの原因を特定するために、批判的思考力を活用します。
また、ソフトウェアの仕様や設計に問題がないか、ユーザーにとって使いやすいかどうかを判断する際にも、批判的思考が求められます。
批判的思考力を鍛えるためには、
・情報の真偽を確かめる ・複数の情報を比較検討する ・論理的な思考を心がける ・結論を急がない |
などの習慣を身につけましょう。
実践的思考
実践的思考力とは、理論や知識を実際の行動に結びつける力です。
テスト担当者は、テスト計画を立て、テストケースを作成し、テストを実行するという一連のプロセスを実践的に行う必要があります。
また、テスト結果を分析し、改善策を提案する際にも、実践的な思考力が求められます。
実践的思考力を高めるためには、
・計画的に行動する ・優先順位をつける ・問題解決能力を養う ・積極的に行動する |
などの意識を持つことが重要です。
これらの思考力をバランス良く身につけることで、テスト担当者としての能力を高め、より質の高いソフトウェア開発に貢献することができます。
3. 時にはヒューリスティック(経験則)を活用
ソフトウェアテストでは、論理的な思考力だけでなく、経験に基づいた直感力も重要です。
限られた時間とリソースの中で、効率的にテストを行うためには、ヒューリスティックを活用することが有効です。
ヒューリスティックとは?
ヒューリスティックとは、経験則に基づいた問題解決の方法です。
「過去の経験から、こうすればうまくいくことが多い」という知識やノウハウを、テストに活かすことを指します。
なぜヒューリスティックが必要なのか?
ソフトウェアテストでは、考慮すべき要素が非常に多く、全てのケースを網羅的にテストすることは現実的に不可能です。
そこで、ヒューリスティックを活用することで、限られた時間の中で、より効果的なテストケースを設計することができます。
例えば、経験豊富なテスターは、「過去のプロジェクトでは、この機能にバグが発生することが多かった」という経験から、その機能を重点的にテストするといった判断ができます。
ヒューリスティックの共有
優れたテスターは、自身の経験から得られたヒューリスティックを、チーム内で共有することで、チーム全体のテスト効率向上に貢献することができます。
例えば、「入力フォームでは、境界値をテストすることが重要」「セキュリティテストでは、クロスサイトスクリプティングの脆弱性を確認することが重要」といった知識やノウハウを共有することで、チーム全体でテストの質を高めることができます。
ヒューリスティックの注意点
ヒューリスティックは、あくまで経験則に基づいたものであり、常に正しいとは限りません。
状況によっては、ヒューリスティックが通用しないケースもあることを理解しておく必要があります。
また、ヒューリスティックに頼りすぎると、柔軟な思考力が失われ、新たなバグを発見する機会を逃してしまう可能性もあります。
ヒューリスティックは、あくまで補助的な手段として活用し、論理的な思考力とバランス良く組み合わせることが重要です。
4. 明確な仕様だけでなく、暗黙的な仕様も考える
システム開発の世界では、設計書や仕様書などのドキュメントに、すべてが事細かに書かれているとは限りません。開発現場では、こうした明確な仕様に加えて、暗黙的な仕様も考慮しながらテストを進める必要があります。
例えば、ECサイトで商品を購入する際、入力フォームに氏名や住所などを入力しますが、「入力欄に半角カタカナは使えない」といったルールが明記されていないケースもあるでしょう。
しかし、多くのユーザーは、一般的なウェブサイトでは半角カタカナを使用しないことを知っていますし、システム側でも半角カタカナの入力を想定していない可能性があります。
このような、明文化されていないけれども、ユーザーが当然のように期待していることが、暗黙的な仕様です。
明確な仕様に違反している場合は、「仕様書に〇〇と書いてあるのに、実際には△△になっている」と、比較的容易にバグを報告できます。しかし、暗黙的な仕様に違反している場合は、「なんとなく使いにくい」「違和感がある」といった、漠然とした指摘になりがちです。そのため、テスト担当者は、ユーザーの視点に立って、「本当にこれで良いのか?」と、常に疑問を持ち続けることが大切です。
暗黙的な仕様を考慮したテストを行うためには、様々なケースを想定し、多角的な視点から検証する必要があります。
例えば、先ほどのECサイトの例では、半角カタカナ以外にも、機種依存文字や絵文字など、様々な文字を入力してテストする必要があるでしょう。
暗黙的な仕様を意識することで、よりユーザーフレンドリーなシステム開発に貢献することができます。
明確な仕様の特徴
・顧客や開発チーム全体で合意された公式な情報 ・設計書、仕様書、APIドキュメントなどに明記されている ・テストの根拠として明確に示せる |
暗黙的な仕様の特徴
・明文化されていない、潜在的なルールや慣習 ・ユーザーの期待や一般的な常識に基づいている ・過去の開発事例や類似システムから推測される場合もある ・テストの根拠として示しにくく、説明に工夫が必要となる |
5. 反論的思考と推理的思考を駆使して製品を評価する
質の高いテストを行うためには、反論的思考と推理的思考をバランス良く駆使することが重要です。
反論的思考とは、「本当にそうだろうか?」と疑いの目を持ち、既存の情報や前提を批判的に吟味する思考法です。
テスト担当者は、開発者や設計者の意図を鵜呑みにするのではなく、「なぜこの仕様になっているのか?」「他に良い方法はないのか?」と常に疑問を持ち、多角的な視点から検証する必要があります。
例えば、ログイン画面のテストを行う際、「ユーザー名とパスワードが正しければログインできる」という仕様書があったとします。
反論的思考を持つテスターは、この仕様書を鵜呑みにせず、「ユーザー名とパスワードが正しい場合でも、ログインできないケースはないだろうか?」と考えます。
そして、パスワードの入力回数制限やアカウントのロック機能など、様々な観点からテストケースを設計し、潜在的なバグを洗い出す努力をします。
一方、推理的思考とは、限られた情報から論理的に推論し、結論を導き出す思考法です。システム開発では、すべての情報が明確に提示されるとは限りません。
仕様書に記載されていない動作や、開発者の意図が不明確な場合でも、テスト担当者は、過去の経験や知識、関連情報などを基に、システムの挙動を推測し、適切なテストケースを設計する必要があります。
例えば、新しい機能が追加された際に、その機能が既存の機能にどのような影響を与えるかを、事前に推測することが重要です。
過去のバグ発生状況やシステムの構造を分析することで、潜在的なリスクを特定し、重点的にテストする箇所を絞り込むことができます。
反論的思考と推理的思考は、一見相反するようですが、両方をバランス良く活用することで、より質の高いテストを実現できます。反論的思考によって、思い込みや先入観にとらわれず、客観的な視点でバグを発見することができます。
また、推理的思考によって、限られた情報から効率的にテストケースを設計し、潜在的な問題を予測することができます。
テスト管理業務の効率化ならPractiTest
システムテストを効果的に行うためには、優れたテスト管理ツールの導入が不可欠です。PractiTestは、プロジェクトごとのカスタマイズ性やすでにあるテスト資産の再利用性、他ツールとの連携性にすぐれた総合テスト管理ツールであり、あらゆるテスト活動を一元管理することができます。システムの品質向上とテスト業務の効率化を図りたいと考えているなら、ぜひPractiTestの導入を検討してみてください!
資料請求・トライアルお申し込みはこちらから!
この記事の監修
Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。
記事制作:川上サトシ