この記事はcommmune Advent Calendar 2023の2日目として投稿されました。
投稿日時がずれているのはチキューに戻る時のウラシマ効果によるものです。
はじめに
現在私はコミューン株式会社のQAマネージャーとして、教育や仕組みによって開発者自身が良いテスト設計を行える体制を作ろうとしています。
弊社では前回の記事の通りテスト分析・設計工程を細かく分割してマニュアルを作り、数ヶ月間開発者とペアテスト分析を行いました。
今回の記事では、ペアテスト分析を通じてわかってきたテスト分析に必要な能力を紹介します。人によってテスト分析結果に差が出た原因にフォーカスしており、テスト分析に必要な能力を全て網羅しているわけではありませんのでご了承ください。
また、本記事は以下を前提としています。
- プロダクトはWebアプリケーション
- プロジェクトの大半は既存プロダクトの機能追加や機能改善を行う
- 1つの画面を操作する機能テストのテスト分析（画面単体テストと呼ぶ方もいます）
テスト分析自体の説明についてはASTERオンラインセミナーの動画をご参照ください。
プロジェクトの内容を理解する能力
知らないことはテストできませんし、プロジェクトの内容を誤認していたら正しいテストはできません。そのため、プロジェクトの内容を正しく理解することは重要です。
プロジェクトの内容を理解する能力を具体的にすると以下のようなものが考えられます。
- 情報源を集める能力
- ドキュメントを探せる、詳しい人に情報を聞けるなど
- 参照した情報の情報不足に気づける能力
- テスト分析に必要な情報は何かを理解している（後述の各能力の内容など）
- 情報の内容を正しく理解する能力
- 文章の読解力
- 文章の行間（暗黙の仕様など）を読む力
- 仕様の前提となる背景（ドメイン知識や既存機能）の理解がある
これらの能力は以下のような工夫を行うことで必要な能力の水準を下げることができると思います。
- プロジェクトの規模を小さくし、1プロジェクトあたりの理解すべき内容を減らす
- テスト対象と他の機能との依存関係を減らし、理解すべき内容を減らす
- ドキュメントを読みやすくする、記載すべき情報をテンプレート化する
- ドキュメントの場所を整理して見つけやすくする
- プロジェクトに関する質問先を明らかにする
テスト対象を洗い出す能力
プロジェクトの内容を正しく理解しても、いざ何をテストするか洗い出す時にテスト対象自体が漏れていることがあります。
例えば、ログイン画面を新規開発する際に認証の成否に関するテストは行うが、ログイン画面の主要な機能ではない「パスワードをお忘れの方」リンクのテストを忘れるといった感じです。[1]
テスト対象を正しく洗い出す能力としては、以下のようなものが考えられます。
- プロジェクトの内容を「テスト用」に整理する能力
- テスト対象の洗い出しを漏れなく行う能力
これらの能力は以下のような工夫を行うことで必要な能力の水準を下げることができると思います。
- プロジェクトの規模を小さくし、1プロジェクトあたりのテスト対象を減らす
- 要件定義書や基本設計書などドキュメントの各項目とテスト分析等の成果物との間で紐付けを行い、テスト対象の漏れがないことを確認するプロセスにする
テスト対象の入出力に関する情報を洗い出す能力
何をテストするかを考える上で、テストを行う際の事前条件、テスト対象に対する入力内容・出力内容・出力内容を決めるロジックなどは重要な要素です。
例えば、数値を入力するのであれば境界値のテスト、テキストを表示するのであれば文字化けやレイアウト崩れのテスト、出力内容が動的に変わるのであれば出力内容の条件分岐を網羅するテスト、といった感じで、入力するデータの種類や出力の種類によって何をテストするかを連想することができます。
そのため、これらのテスト対象の入力・出力に関する情報をテスト分析に適した形で正しく洗い出すの能力が重要になります。
テスト対象の入出力に関する情報を洗い出す能力としては、以下のようなものが考えられます。
- テスト対象の入出力の流れを理解する能力
- ソフトウェアに関する基礎的な知識（以下は例）
- ブラウザから入力できるもの（マウス、キーボード）、Cookie、ブラウザキャッシュ
- Webアプリケーションの仕組み、サーバーキャッシュ
- DBとは何か
- テスト対象に関するシステム構成の理解
- ソフトウェアに関する基礎的な知識（以下は例）
これらの能力は以下のような工夫を行うことで必要な能力の水準を下げることができると思います。
- 出力する内容を決めるロジックをシンプルなものにする
- テスト対象のシステム構成や処理の流れを図で表現する
テストしないと不安な度合い（リスク）を分析する能力
何をテストすべきかを決める際には
- この機能は実装が難しかったので不安だから細かくテストしたい
- この機能は修正の影響が出る可能性は低いが重要な機能だから念の為軽くテストをしておきたい
といった意思決定を行います。
上記のような意思決定をするために、プロジェクトにおける各テスト対象のリスクを分析します。
リスクの大きさは、基本的には「不具合発生確率 x 不具合発生時の影響度」の掛け算で考えます。
リスクを分析する能力としては、以下のようなものが考えられます。
- 不具合発生確率を推測する能力
- プロジェクトの複雑さ、改修対象の複雑さや依存関係、実装担当者のスキル、実装工数のゆとり、など
- 不具合発生時の影響度を推測する能力
- 重要な機能は何か
- どのような不具合が予測されるか
これらの能力は以下のような工夫を行うことで必要な能力の水準を下げることができると思います。
- プロジェクトの規模を小さくして1プロジェクトの改修難易度を減らし、改修による影響の予測可能性を高める
- テスト対象と他の機能との依存関係を減らし、改修による影響の予測可能性を高める
- 過去の不具合の傾向から改修対象の不具合発生確率を推測する
何をテストすべきかを洗い出す能力
これまで収集した情報を元に[2]、何をテストすべきかを洗い出す能力です。
この能力は、汎用的な観点を洗い出す能力、テスト対象固有の観点を洗い出す能力に分類できると思います。
汎用的な観点とは、どのシステムであっても共通で利用できる観点です。経験豊富なテストエンジニア・QAエンジニアの方であれば、基本的に備わっている能力だと思います。
例えば、以下のようなものがあります。
- 文字入力ができる場合、様々な文字種（半角英数記号、全角文字、特殊文字など）を入力する
- 数値を入力する場合、境界値のテストをする
- ボタンをクリックできる場合、シングルクリックだけでなくダブルクリックをしてみる
- データの一覧を表示する場合、データが0件の場合の動作も確認する
- アクセス制限のあるページがある場合、ブラウザにURLを直接入力してアクセスしてみる
- 出力内容が動的に変わる場合、出力内容が変わる条件を何らかの網羅基準でテストする
- 基本設計書に「条件Aの場合〜ができる」と記載があったら「条件A以外の時に〜ができないこと」の確認も行う
テスト対象固有の観点とは、プロダクトAでは気をつける必要はないがプロダクトBでは気をつけないといけないようなプロダクト独自の観点です。経験豊富なテストエンジニア・QAエンジニアの方であっても、初めて関わるプロダクトについては備わっていない能力になります。
例えば、以下のようなものがあります。
- X（Twitter）ではポスト画面で#や@が頭につく文字列を入力した場合に自動で色が変わる。#や@が頭につく文字列を入力したり、#や@を削除したりするようなユーザーが実際に行いそうな複雑な操作をしても正しく色が変わるかをテストする必要がある
- Amazonでは特定の条件を満たす会員のみポイント付与をN倍にする
- 病院で患者が支払う代金を計算する場合、国が定めた診療報酬、医療保険制度、地方自治体の制度、患者の年齢などを考慮しなければならない
- 似たような画面でも管理者用の画面と一般ユーザー用の画面はソースコードが独立している。そのため、管理者と一般ユーザーの両方の画面のテストをしなければならない
- DBのテーブルAはWebアプリケーションだけでなくバッチ処理1も利用している。そのため、テーブルAに修正を加える場合はバッチ処理1への影響も考慮しなければならない
これらの汎用的な観点、テスト対象固有の観点を洗い出すために必要な能力は以下のような能力が考えられます。
- 汎用的な観点の知識
- テスト対象固有の観点の知識、テスト対象に対する理解
- 外部仕様、システム構成、ドメイン知識、実際のユーザーがどのように操作するか、など
- テスト分析時に上記知識を連想する能力
これらの能力は以下のような工夫を行うことで必要な能力の水準を下げることができると思います。
- テスト対象の仕様を複雑にしない、テスト対象と他の機能との依存関係を減らすなどして、テスト対象固有の観点を減らす
- 何らかの機能について、自分で実装するのではなく品質が保証された既存ライブラリを使う
- 例えば、文字入力のバリデーションやセキュリティ対策に関して既存ライブラリを使うことで、文字種チェックのテストを省略する
- テスト観点表（≒チェックリスト）などの活用
- テスト観点の連想を促すプラクティスの活用
終わりに
お気づきの方もいるかもしれませんが、実は上記能力は
で言及された4つのスキルと結果的に同じ内容になりました。
今回テスト分析工程を細かく定義してペアテスト分析を行うことで、上記の4つのスキルの必要性についての解像度を上げることができました。
今後もテスト分析能力を伸ばす教育、テスト分析に必要な能力の水準を下げるための施策を併用して開発者自身が良いテスト分析・設計を行える体制を目指していきたいと考えています。
なお、弊社の場合は以下の特徴があります。
- プロジェクトの規模が小さい傾向にある（ユーザーストーリーを分割、フィーチャートグルを用いた開発）
- 開発者自身がテスト分析・テスト設計を行うのでテスト対象に対する理解が深いことが多い
そのため、上記のうち「何をテストすべきかを洗い出す能力」以外の課題はあまり大きな課題と感じていません。
参考にしてみてください。
Discussion