.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
セールスフォーステスト
言語
.svg)
.svg)
テストは必要不可欠です。しかし、最終的に突き詰めると、大きな疑問が残ります。それは「手動でテストを行うのか、それともプロセスを自動化するのか？」ということです。
はい、その違いは確かにあります。どちらもそれぞれの役割がありますが、この章では手動テストに焦点を当てます。つまり、実際に人間（つまりあなた）がテストを主導する場合についてです。手動テストとは何か、誰が行うのか、そしてそれをどのように整理するかをカバーしていきます。混乱することなく進められるようにしていきましょう。
手動テストはその名の通り、人間が行うテストのことです。これは、専用ソフトウェアが主導する自動化テストの対極に位置します。
テストを「手動」と「自動化」に分ける考え方自体、よく考えると少し奇妙です。実際に完全に自動化可能なのはテストの実行部分だけです。テストケースの作成、結果の分析、何をテストする必要があるのかを決定することなど、それ以外の部分は手動プロセスが依然として大部分を占めています。
しかし、AIの進化によりその境界は日々曖昧になっています。将来的には、人間が行う作業がさらに少なくなる可能性があります。でも、それは次の話題にしておきましょう。この章では手動テストに集中します。
手動テストを行う人々は「手動テスター」と呼ばれることが多いです。そして手動テスターには、大きく分けて2つのタイプがあります：
冗談っぽく言うなら、第3のタイプも追加できます。それは偶発的なテスターです。つまり、テスト中に見逃されたバグに偶然出会ったユーザーです。でも、ここまで読み進めているあなたなら、それを未然に防ぐ方法をしっかり知っているはずです。そうですよね？
プロフェッショナルテスターは、テスト手法に精通しており、ソフトウェアのバグを見つけ出すスキルを持っています。彼らにとって「手動」と「自動化」の線引きはあまり意味がなく、どちらにも熟練しています。
一時的なテスターは、通常、自分の仕事で使用するソフトウェアをテストするために招集される従業員です。彼らはそれぞれの業務プロセスのSME（Subject Matter Experts：専門家）であり、「ビジネステスター」と呼ばれることもあります。
手動テストを計画する際には、答えるべき重要な質問がいくつかあります。心配しないでください。これらの質問はシンプルですが、詳細が成功の鍵を握っています：
多いように感じるかもしれませんが、心配しないでください。これらの質問は思ったよりシンプルです。真の課題は、これらの質問を全く考慮せずに進めてしまうことです。これが多くの組織がつまずく原因です。しかし、心配無用です。一つひとつ詳細に説明していきます。
他のテストタイプに取り掛かる前に、開発者がコードに対して単体テストを実行するようにすることが最優先です。これにより、初期段階で些細なプログラミングエラーをキャッチできます。もし反対意見が出た場合には、「シフトレフト」という用語を使って説得しましょう。この専門用語に感心して、反論できなくなるかもしれません。
アプリケーションに新しい機能を追加したり既存の機能を変更したりすると、何かしら壊れる可能性があります。しかし、常にすべてをテストする余裕はないでしょう。たとえそうだったとしても、それは非効率的かもしれません。ここで必要なのは戦略です。手動テストにおける有効な方法を以下に示します：
ポイント1、2、3は比較的簡単です。しかしポイント4と5は少し厄介です。何が壊れるリスクが高いのかを知るための魔法の方法はありません。アプリケーションを十分に使用していれば、変更時に問題が発生しやすい箇所について直感が働くでしょう。しかし、アプリケーションを新しく引き継いだばかりの場合はどうでしょうか？残念ながら、マーベルには「テスト直感」のスーパーパワーを持つヒーローはまだ登場していません。
「新しいものはすべてテストすべき」という考えは、実際には曖昧です。例えば、新しいレポート機能が導入されたとしましょう。レポートを開いて結果を確認し、期待通りに動作するかをチェックします。これで十分だと思うかもしれませんが、実際には違います。
レポートが壊れやすいシナリオを試しましたか？アクセス権を持たないユーザーでもレポートにアクセスできてしまわないか確認しましたか？編集権限がないはずのユーザーがデータを変更できないかチェックしましたか？
これがリスク駆動型テストの出番です。この目的は、壊れる可能性が高いものや、壊れた際に重大な影響を及ぼす可能性があるものを優先してテストすることです。新しい機能は既存機能よりも壊れる可能性が高いですが、それだからといって既存機能を無視してよいわけではありません。特に新しい変更に関連する部分は見逃せません。
要するに、高リスク領域に焦点を当てたテストを常に優先するべきです。新機能や変更された機能はもちろんですが、間接的に影響を受ける可能性のあるコンポーネントや、失敗した場合に大きな問題を引き起こす可能性のある部分も忘れずにテストしましょう。
テストを開始する前に、まず深呼吸して計画を立てましょう。何をテストするべきかが明確になれば、必要な作業量を見積もり、テスターに求められるスキルを決定できます。
DevOpsやアジャイルソフトウェア開発を実践している場合、テスト計画はプロセスに組み込まれているはずです。そうですよね？アジャイルの基本理念は、小規模で頻繁な展開による最小限の混乱を目指すものです。そのため、テストは継続的かつ随時行われるべきです。理想的には、その多くが自動化されているでしょう。
もしまだそこに到達していない場合でも、大丈夫です。ほとんどのチームはそうではありません。ただし、完全にアジャイルを実践していない場合は、DevOpsのメリットを最大限に活用できていない可能性があることを理解しておきましょう。例えば、欠陥を早期に発見し、ソフトウェア開発を加速させる能力などです。
ウォーターフォール、アジャイル、そして実際の多くの企業が行っているもの—それはこの両者の中間地点にあります。「よりアジャイル」または「ややアジャイル」と呼ぶことができるでしょう。現状を正直に評価し、継続的な改善を目指してください。
アジャイルでは、最初のテストラウンドは開発者に迅速なフィードバックを提供するための手動テストであることが多いです。このテストは、専任のテスターが実行する場合もあれば、テストを兼任する人が行う場合もあります。手動テストは高価に思えるかもしれませんが、頻繁かつ小規模なテストは、大規模かつまれなテストキャンペーンよりも通常は速く、コスト効率が高いです。
新しい機能が手動でテストされた後は、それらのテストを自動化するのが次のステップです。これにより、同じことを手動で繰り返しテストする必要がなくなります。これらの自動化されたテストは必要に応じていつでも実行でき、テスターの負担を軽減します。ただし、完全にパイプラインに統合されるまでの間は、誰かがその「実行」ボタンをクリックする必要があります。
ここで、「自動化テストが速いなら、なぜ最初に手動テストをするのか？」という疑問が出てくるかもしれません。その理由は、Salesforceの自動化テストは確かに速いですが、セットアップに時間がかかるからです。その時間を節約するために、まず手動テストを行うのです。
頻繁に展開せず、大きな変更をまとめてリリースする場合は、より大規模なテストキャンペーンが必要です。これはアジャイルの頻繁なテストと比べるとコストがかかるように感じるかもしれませんが、必ずしもそうではありません。違いは、継続的なテストが時間をかけて負荷を分散する一方、「一括型」アプローチはより少ない頻度で、より高い労力が必要になるということです。
それでも、アジャイル環境でも大規模なテストキャンペーンの余地はあります。多くのチームがプレプロダクション環境で頻繁に展開しますが、本番環境へのロールアウトはあまり頻繁には行いません。この場合、ユーザーがシステムに慣れたり、リリースに正式な承認を与えたりすることを目的とした大規模なユーザー受け入れテスト（UAT）キャンペーンが理にかなっています。
テスト計画は、全体的な開発プロセスによって異なります。アジャイルを採用している場合は、小規模で頻繁なテストを継続的に行っているでしょう。アジャイルが少ない場合は、より大規模なテストキャンペーンを組織化している可能性があります。どちらの場合でも、目標は同じです：欠陥を迅速に発見して修正し、生産性を向上させ、リスクを軽減することです。
テストに利用可能な人々は、手動テストの実施方法に大きな影響を与えます。業務ユーザーがテストを行う場合、テストを一から設計することを期待するのは現実的ではありません。そのため、テストを作成する役割を持つプロフェッショナルが必要です。業務ユーザー向けには、主に以下の2つのアプローチがあります：
スクリプトベースのテストでは、テスターに詳細な手順を提供します。「これを入力して、これをクリックして」といった指示に従うだけです。一方、タスクベースのテストでは、テスターに広範なタスクを与えます。例えば、「新しいリードを作成する」や「最近開いた商談のレポートを実行する」といった内容です。
タスクベースのテストは、現実的なシナリオを模倣する点で優れています。テスターがタスクを完了する際に直面する問題や不具合を明らかにしやすくなります。たとえば、アプリが技術的には機能しているが、特定のボタンのラベルが曖昧でユーザーを混乱させる場合など、使いやすさに関する問題を特定できます。
探索的テストは、タスクベースのテストをさらに発展させたものです。テスターは具体的な指示を受け取るのではなく、業務プロセスの一般的な概要を伝えられ、それを基に「探求」します。この方法では、アプリケーションが期待通りに機能するかどうかを確認するだけでなく、どのような問題が潜在的に発生するかを積極的に調査します。
探索的テストは非常に効果的ですが、再現性に欠けるという欠点があります。問題が発見されても、どのようにそれを再現すればよいのかが分からない場合があります。このような課題は、後の章で詳しく説明します。
テスターのスキルレベルは、どのような指示を出すべきかを決定します。大まかに以下の3つの方法があります：
これらの方法は、以下の3種類のテスターに対応しています：
業務プロセスとテストの両方に精通している人は「ユニコーン」のような存在で、非常に希少です。もしチームにそのような人がいれば、大いに活用しましょう！
「何も知らない」テスターには、各タスクの詳細な手順を提供する必要があります。例えば：
このようなスクリプトベースのテストでは、業務プロセスに詳しい必要はありません。ただし、このような詳細な指示を作成する時間があるなら、テストを自動化する時間もあるはずです。
現代のテスト自動化ツール（特にAIベースのもの）では、自動化されたテストを作成するのは、人間が読めるスクリプトを作成するのとほとんど変わりません。
業務ユーザー向けには、タスクベースのアプローチが最適です。具体的な手順ではなく、目標を設定します。例えば：「新しいリードを作成する」や「最近開いた商談のレポートを実行する」などです。
プロフェッショナルテスターや高度なスキルを持つ業務ユーザーには、目標ベースのテストが理想的です。たとえば：「新しく追加された商談レポートを探索する」などです。
この種のテストは、抽象的ではありますが、テスターに自由な裁量を与え、アプリケーションのリスク領域をより深く探ることができます。
手動テストは、どんなテスト戦略においても重要な役割を果たします。特定の状況では、自動化よりもコスト効率が高い場合もあります。
計画は必須です。たとえ簡単なテストであっても、計画を怠ることは避けてください。シンプルな機能にはシンプルな計画で対応できますが、計画そのものを省略してはいけません。
人間のリソースは貴重です。彼らの時間を尊重し、慎重に計画を立てましょう。これにより、強力で関与度の高いテスターのチームを維持できます。
次の章では、AIがどのようにテストを変革し、自動化のROI（投資対効果）を向上させるかを探ります。
次の章へ進みましょう！
.svg)
.svg)
.svg)