みなさんこんにちは。エリアマネージメント部のゆーてぃです。
今回はテストを始める前にいつも行っていることを記事にしたいと思います。
要求は人によって様々
みなさんは買い物の時にどんなものがあるか見てから決める時があるのではないでしょうか。時には店員さんに「こういう機能がついてる物がほしい」、「●円の予算に収まる物がほしい」、「在庫があってすぐに持って帰れる物から選びたい」などの要求を伝えた上でアドバイスを聞くこともあると思います。
それはテストも同じことで、テストの目的はプロジェクトによって様々で、「これらを満たすようにテストしたい」や「この予算内でテストしたい」、「いついつまでに完了するようにテストしたい」といった内容もあります。
「JSTQB Foundation Level シラバス」にも以下の記載があるように、我々は店員の目線からしっかりと要求事項を整理した上でそのプロジェクトにあったプランを検討し、共通のゴールを明確にして進めることが重要だと考えています。
(以下、JSTQB FLシラバスから抜粋)
「1.4.2 テストの活動とタスク」
テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する(例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成する)。
出典:ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
では「多端末テスト」に対して「できるだけたくさんの端末でテストしたい」との要求を伺った場合を例として、日頃どのようにゴールを決めているか、一つ一つ説明していきたいと思います。
要求事項を整理
・目的の確認
多端末テストを行う目的として「画面比が異なることによる表示バグがないか確認したい」や「OS依存の不具合を見つけたい」、「一般ユーザー向けに公開する推奨環境を検討したい」など目的は様々あります。
目的を理解していないと、目的にあった端末を選定できず、テストアプローチも正しく検討できません。目的から外れた効果の薄いテストにならないよう、まずは目的を明確にします。
・プロダクトタイプ、ユーザー層の確認
テスト対象のプロダクトがどのようなもので、どのユーザー層をターゲットとしているかで、テスト端末の選定幅も変わってきます。たとえば、BtoBなのであれば、ユーザーとなる企業で実際に使われている端末でテストするのが効果的ですし、BtoCなのであれば市場シェア率を考慮した選定を行います。
また、性別、年代によってシェア率は変わりますのでユーザー層を把握した上で端末選定を行うとより効果的になります。
・制約事項の確認
次にプロジェクトの制約事項について確認していきます。
予算、納期、リソースのすべてに余裕があり、やりたいテストをすべて実行可能なプロジェクトはない。と言っても過言ではないと思います。制約事項を把握することで正しい優先度付けができると考えています。
テストプランの検討
ある程度の情報が揃ったところで一度テストプランを3パターン程検討します。
・パターン1: 品質優先のおすすめプラン
要求をしっかり理解した上で、テストの知見、実績ベースの過去データをもとに品質を高めることを優先としたアプローチを検討し、予算、納期への影響を明確にします。
・パターン2:品質、納期をキープするプラン
目的の達成、且つ納期に間に合うアプローチを検討し、テスト内容、予算への影響を明確にします。
・パターン3:一部目的を削り制約内でテストするプラン
決められた予算、納期の制約内でテストを行った場合のテスト内容、および品質に対するリスクを明確にします。
そして、テストプランを検討した後は、各パターンの期待される効果を説明した上ですり合わせを行います。もちろん我々としては「品質優先のおすすめプラン」を推奨しますが、プロジェクトによってマッチするものは変わってくると思います。最後はしっかりとすり合わせた後、プランを選択することで、共通のゴールが明確な状態でプロジェクトを進めることができます。
まとめ
今回はテストを始める前にいつも行っていることを「多端末テスト」を一例として記事にしてみました。何れのプロジェクトでも要求は様々だと思いますので、我々はスタート前にしっかりとゴールを決めた上で、プロジェクトを進めることが重要だということを日々念頭において、業務を遂行したいと思います。
テストプランを検討する際、テスト自動化を視野に入れることも有効です。こちらも参考にしてみてください。
テスト自動化ツールならATgo