この記事は
この記事は、テストプロセスの中の「テスト設計」「テスト実装」「テスト実行」にフォーカスした内容です。
「テスト設計」「テスト実装」「テスト実行」の３つをまとめて一言で表現する言葉を探しましたが、最適な言葉が見つからなかったため、この記事内では便宜上「テスト手法」と呼ぶことにします。
記事の目的
テスターによって、得意なテスト手法は異なります。テスターとテスト手法を傾向ごとにタイプ分けし、相性の良し悪しを把握できれば、テストマネジメントに活用できるのではないかと思いました。
テスト手法の分類
まずは、テスト手法をA〜Dの4タイプに分類します。
4タイプそれぞれの、例と特徴を説明します。
【Aタイプ】完全なスクリプトテスト
テスト設計とテスト実行でフェーズが厳格に分かれています。 例えば、テスト設計者が記述したテストケースやシナリオテストなどを、テスト実行者が記述通りの手順で正確かつ忠実に実行します。テスト実行者にテスト設計の権限は与えられず、業務上の裁量権は極めて限定的です。
【Bタイプ】スクリプト＞探索
スクリプトテストをベースに、探索的テストを融合します。 例えば、予め設計しておいたテストケースを実行している途中で怪しい点に気づいたら、自由に「寄り道」や「深堀り」することが許されます。また、テストケースを全て消化した後に時間が余れば、アドホックテストをします。
その為、テスト実行者にも小さな割合でテスト設計権限と時間配分の裁量権が与えられます。
ただし、時間に余裕がない場合には、予め設計していたテストを消化することの方が優先されます。
【Cタイプ】探索＞スクリプト
探索的テストをベースに、スクリプトテストを融合します。 例えば、テスト単位ごとに予めセッション時間を設定しておいて、まずはその制限時間内でチャーターにテスト設計しながら同時にテスト実行します。テストマネージャーや開発担当者などから「最低限これだけはやっておくべき」というチェックリストや設計済みのテストケースを渡されており、テスト実行者が任意のタイミングで実行します。
その為、テスト実行者に大きな割合でテスト設計権限と時間配分の裁量権が与えらえます。
【Dタイプ】完全な探索的テスト
テスト設計とテスト実行でフェーズが分かれていません。 例えば、テスト単位ごとに予めセッション時間を設定しておいて、その制限時間内でチャーターにテスト設計しながら同時にテスト実行します。テスト実行者にセッション時間内での100%のテスト設計権限と時間配分の裁量権が与えられます。
テスト実行者の分類
次に、テスト実行者をa〜d+新人の5タイプに分類します。
5タイプそれぞれの、例と特徴を説明します。
【aタイプ】スピード特化
テストケースの消化が速い人です。例えば、
・手を早く動かし続ける、作業スピードの持続力がある
・作業を効率化するツールを効果的に使える
・テスト設計者の意図を理解することに長け、質問が少ない
・注意深く、いい意味で神経質であり、作業が正確
などの中から、いくつかの特徴を持っています。
作業を素早く効率よく正確に進行させることにやりがいを感じる気質の人が、このタイプになりやすいです。
ただし、テスト設計のスキルがなく、アドホックテストなどではバグの検出率が下がります。
【bタイプ】スピード寄りのオールラウンダー
テストケースの消化が速く、テスト設計のスキルもある程度持ち合わせる人です。 aタイプ（スピード）の傾向が強く、dタイプ（探索）の特徴も併せ持っています。例えば、テストケースを消化するタスクをずっと担当していて、テスト設計の経験は少ないですが、自主学習などによってテスト設計の知識はつけているため、アドホックテストなどでもしっかりバグを検出できる場合にこのタイプに該当します。
【cタイプ】探索寄りのオールラウンダー
テスト設計のスキルが高く、テストケースの消化でもある程度戦力になる人です。 dタイプ（探索）の傾向が強く、aタイプ（スピード）の特徴も持っています。例えば、他のプロジェクトでテスト設計の経験が豊富ですが、新しいプロジェクトにジョインしたばかりでテストケースの消化に慣れるまで数か月かかりそうな場合はこのタイプに該当します。
【dタイプ】探索特化
テスト設計の高いスキルを持っています。例えば、
・テスト技法の知識と練度が高い
・ドメイン知識が豊富
・プロダクトへの理解が深い
・デザイン（認知心理学）の造詣が深い
・ITリテラシーが高い（開発経験だけでなく、パソコン初心者の心理や特徴も把握）
などの中から、いくつかの特徴を持っています。
専門知識やスキルを駆使して、インスピレーションに従って自由にテスト設計し、テスト実行することでバグを検出することが得意です。
【新人】原石
過去の経歴、今後の希望、性格的な特徴や志向性によって、a～dタイプにこれから分類されていく予定の人です。探索力とは
「探索力」という言葉は意味が広く曖昧なので、現時点での私の考えを述べておきます。「探索力」とは、「目的へ向かう手段について、誰にも指示されなくても自分で考え実行し、状況の変化に柔軟対応でき、最終的によい結果を生み出す力」だと思っています。
ソフトウェアテストにおける「探索力」は、主に次の５つの能力に分解できます。
・テスト技法
・ドメイン知識
・プロダクト経験
・デザイン知識
・ITリテラシー
上記５つを合わせた総合力が探索力となります。
それぞれの能力について、順に説明します。
テスト技法
数学や心理学の素養を基礎とした、テスト技法の知識量と練度です。テスト対象を分析し、求められる品質の優先度（リスク管理等）と許された作業時間を把握し、自分の中にあるテスト技法のレパートリーの中から最適なものを選択し、実行します。
どのステークホルダーが読んでも理解しやすく、過不足なく説得力とトレーサビリティのあるテスト記録を作る能力が必要です。
また、今後会社の資産として活用していけるメトリクスを作る意識を持ちながらテストを記録する能力があれば、より良いでしょう。
ドメイン知識
ユーザー業務の理解、ユーザーの所属する業界知識、マーケティング、法令遵守への意識などです。製品によって異なりますが、例えば、テスト対象が会計ソフトであれば、
・簿記、財務諸表、税法に関する知識（資格取得）
・経理や会計事務所での業務経験
などが該当します。
また、どんな製品であれ、
・競合製品の研究
・ユーザーサポート（電話・メール・常駐）の経験
は強力なドメイン知識となります。
プロダクト経験
特定のプロダクトに携わった年数です。例えば、
・プロダクトの歴史（機能が追加・廃止されてきた経緯など）
・過去にどんなバグが流出したか
・今回テストする機能が、どの機能と連動し、デグレの可能性があるか
・必要なテストデータを素早く準備できるか
などの知識は、１つのプロダクトを長く経験していないとなかなか身に付くものではありません。
ベンダーに所属するテスターはこの能力が高くなることが期待されます。
逆に、第三者検証専門のテスターは低くなる傾向があります。
デザイン知識
認知心理学を基礎理論とした、UXに関する知識です。サイトデザインについても「仕様通りだからOK」ではテストとして不十分であり、「ユーザーが使いにくい」と判断すれば、仕様バグとして報告する必要があります。
その際に、単に「自分が使いにくいと感じたから」では説得力に欠け、使っているうちに慣れていき「バグである」という自信も揺らぎます。
必要に応じてデザインで使われるどんな法則に当てはまるか示すことができれば「バグである」という確信が揺らぐことなく、バグ報告も効果的に行うことができます。
例えば、「Windows機でメモ帳のデータをコピーし、テスト対象のフォームにCtrl＋Vを押しても貼り付けできない」というバグを報告したとしましょう。
もしプロジェクトマネージャーから「重要なバグではないから、修正の優先度を低くします」と回答されても、ヤコブの法則を思い起こせば即座に疑問を提起できるかもしれません。
ITリテラシー
広くITに関する知識を差します。例えば、
・開発経験
・インフラ構築・管理経験
・通信やセキュリティに関する知識
・ソフトウェア工学の知識
・多様なソフトウェアやwebサービスや周辺機器に触れた経験
・ハードウェアの知識（自作経験など）
・デジタル機器初心者に対する理解
などが該当します。
開発経験があれば、エンジニアがどんなところでバグを仕込みやすいかを知っています。
クラッカーの攻撃方法を知っていれば、テストで試すことができます。
ハードウェアに詳しければ、テスト端末での使用感だけではなく、世代ごとのメインストリームの性能でどれだけの体感速度になるかを想像することができます。
パソコン教室の先生をしたり、パソコンメーカーやソフトウェアメーカーなどでユーザーサポートの経験があれば、初心者が引っ掛かりやすくクレームを入れやすい箇所に対するアンテナが鋭くなります。
以上、「テスト技法」「ドメイン知識」「プロダクト経験」「デザイン知識」「ITリテラシー」の5つの能力の中から、意識的に自分の強みを伸ばす、または弱みを埋めることで効果的に探索力を伸ばすことができます。
ただし、開発現場がアジャイルの場合は、特に「ドメイン知識」を優先的に伸ばすように推奨・指導されるかもしれません。
タイプ別相性
テストプロセスの4タイプとテスト実行者の5タイプには相性があります。 相性の良いものから説明していきます。安定「Aa」「Bb」「Cc」「Dd」
最も安定した組み合わせです。
得意なテスト手法なので、自己効力感が高く、高パフォーマンスを発揮します。
ただし、慣れているからと言って同じテスト手法ばかり繰り返し行っていると、成長がなく、飽きてしまい、パフォーマンスが徐々に落ちてくるリスクがあります。
テスト手法が固定化されている会社の場合、テスターが「ここではもう何も学ぶことがない」と感じれば、新天地を求め人材流出となる可能性があります。
チャレンジ「Ab」「Ba」「Bc」「Cb」「Cd」「Dc」
チャレンジ意識の高い組み合わせです。
得意なテストプロセスに近いので高パフォーマンスを維持でき、別のやり方を取り入れるため成長も期待できます。
スピードを伸ばしたい場合はスクリプト傾向（A方向）に向かい、探索力を伸ばしたい場合は探索傾向（D方向）に向かいます。
不慣れ「Ac」「Bd」「Ca」「Db」
不慣れな組み合わせです。
スピードのない人にスピードを要求したり、探索力のない人にテスト設計を任せることになるため、「作業の遅延」「混乱」「テスト設計漏れ」「バグ見逃し」などを誘発する懸念があります。
それでもあえてチャレンジする場合は、しっかりとプロジェクトに余裕を設け、同じテスト対象を複数人で確認するクロスチェックのような体制が取れると良いでしょう。
苦手「Ad」「Da」
相性の悪い組み合わせです。
「Da」（スピード特化の人が完全な探索的テストをする）の場合、一生懸命に取り組んでも、知識が足りずにほとんど戦力になりません。
コピペのテストケースを羅列して実行するだけになるでしょう。
「Ad」（探索特化の人が完全なスクリプトテストをする）の場合、ただ指示通りに手を動かすだけのロボット（交換可能な部品）のように扱われている気分になり、創造性を自由に発揮できないのでストレスがたまり、やりがいを感じることができず、パフォーマンスが極端に落ちます。
「不慣れ」の組み合わせよりもさらに「作業の遅延」「混乱」「テスト設計漏れ」「バグ見逃し」が多発する恐れがあります。
新人向け「A新人」「D新人」
新人がジョインしたばかりのタイミングでも、戦力として計算しやすい組み合わせです。
「A新人」（新人が完全なスクリプトテストを実行する）の場合は、テスト設計者が記載した指示通りに手を動かせば良いので、ゆっくりでもテストを進めることができます。
もともと性格的に探索志向のある新人でも、ジョインしたばかりであれば新鮮な気分で作業をするので、ある程度のパフォーマンスは期待できます。
「D新人」（新人が完全な探索的テストを実行する）の場合は、例えば、「マニュアルを見て仕様を覚えながら、本番環境で半日リグレッションテストをしてください」というような指示をする場合が該当します。
「プロダクト経験」の成長を促しながら、普段忙しくてなかなか手が回らない手動リグレッションテストをカバーすることに役立ちます。
まとめ：手動テスターが成長するには
仕事で「成長する」という言葉を使うと、テスターからプログラマーに転身したり、現場作業者から管理職に昇進するように「役割が変わる」というイメージを持つ方も多いかと思いますが、ここではもっと狭い意味で、「うまくバグチェックができるようになる」という意味で考えます。
手動テスターが成長するには、「処理速度」と「探索力」を伸ばすのが効果的です。
「処理速度」と「探索力」どちらか一方しか伸ばさないと特定の現場でしか活躍できませんし、プロジェクトが想定外の状況になった時に柔軟対応できません。
得意なテスト手法ばかりではなく、能動的に他の手法にチャレンジしてみるのが手動テスターとしての成長の鍵だと思っています。
テストマネージャーは、プロジェクトの状況とテスターのタイプによって適切なテスト手法を柔軟に選択できると良いと思います。安全な手法ばかり選ぶのではなく、時には「リスクと踊って」テスターの成長を促すのも良いかもしれません。
手動テスターは、いまいち成長の実感ややりがいが持てない時などは、テストマネージャーに掛け合って、いつもと違うテスト手法にチャレンジしてみたり、別の現場へ異動の希望などを打診してみると良いかもしれません。
「テスト手法に人を従わせるのではなく、人がテスト手法を使いこなすこと」
これができるようになるのが、テストマネジメントの一つの理想の形かもしれないと考えています。
参考
・JSTQB Foundation Level シラバス ver.2018
・「はじめて学ぶソフトウェアのテスト技法」リー・コープランド
・「基本から学ぶソフトウェアテスト」ケム・カナー/ジャック・フォーク/フン・クォク・グエン
・「実践アジャイルテスト」リサ・クリスピン/ジャネット・グレゴリー
・「Agile Testing Condensed Japanese Edition」リサ・クリスピン/ジャネット・グレゴリー
・「ソフトウェアテスト293の鉄則」ケム・カナー/ジェームス・バッハ/ブレット・ペティショード
・「誰のためのデザイン？」ダニエル・ノーマン
・「UXデザインの法則」ジョン・ヤブロンスキー
・「MI:個性を活かす多重知能の理論」ハワード・ガードナー
・「社会的学習理論」アルバート・バンデューラ
・「ピープルウェア第3版」トム・デマルコ/ティモシー・リスター