手動テストとは何をする？｜プロセス設計から自動化との棲み分けまで迷いを減らす！

ソフトウェア開発やWeb運用で「手動テスト」が必要と言われても、何をどこまでやれば十分なのか迷う人は少なくありません。

本記事では、手動テストの定義から実務の進め方、設計のコツ、よくあるミス、ツール活用、自動化との切り分けまでを一つの流れで整理します。

品質とスピードを両立させるために、現場でそのまま使える考え方を中心にまとめました。

手動テストとは何をする？

手動テストは、人が実際に操作しながら仕様どおりに動くか、使いにくさがないかを確かめるテストです。

ここでは「どんな種類があるのか」「何が得意で何が苦手か」「どの成果物を作るのか」を押さえ、作業イメージを具体化します。

手動テストの定義

手動テストは、テスターが画面やAPI、帳票などを操作して結果を観察し、期待結果と照合して合否を判断する活動です。

コードで手順を固定化する自動テストと違い、人の判断を活かして仕様の抜けや違和感を見つけやすい点が特徴です。

一方で、繰り返し作業は時間がかかり、担当者の経験によって検出力がぶれやすい側面もあります。

自動テストと比べた強み

手動テストは、見た目の崩れや文言の不自然さ、操作感の悪さなど、数値化しにくい品質を拾いやすいです。

仕様が頻繁に変わる初期フェーズでも、テストスクリプトの保守に追われにくく、柔軟に追従できます。

探索的に触りながら検証することで、想定外の使われ方による不具合の芽を早期に見つけられます。

手動テストが苦手な領域

回帰テストのように同じ手順を何度も繰り返す作業は、手動だと工数とヒューマンエラーが増えがちです。

大量の組み合わせや負荷の高い検証は、手作業だけでは網羅が難しく、観測も主観に寄りやすくなります。

そのため、目的に応じて自動化や計測ツールを組み合わせる設計が重要になります。

よく使うテストの種類

手動テストは、工程や目的に応じて複数の型を使い分けます。

特に「何を保証したいのか」を先に決めると、過不足のない範囲設定がしやすくなります。

• スモークテスト
• 受け入れテスト
• 回帰テスト
• 探索的テスト
• ユーザビリティテスト
• 互換性テスト
• 障害再現テスト

成果物として残すもの

手動テストは、実施した事実と判断根拠を残して、次の改善につなげるのが価値です。

最小限でも「何を」「どの環境で」「どう操作し」「何が起きたか」が追える形にします。

手動テストが向くケース

仕様が固まりきっていない機能や、見た目・体験の品質が重要な画面は手動が効果的です。

また、障害が出た直後の切り分けや、ログと現象の突き合わせにも人の推理が役立ちます。

「短期で発見したい未知の不具合」に強いと捉えると、投下工数の判断がしやすくなります。

手動テストの基本プロセス

手動テストは、設計して実施して報告するだけでなく、学習して次に反映するまでが1サイクルです。

この流れを固定すると、担当者が変わっても品質が安定し、ムダな往復が減ります。

現場で迷わない手動テストの進め方

手動テストは「とにかく触る」だけだと、抜け漏れや重複が起きて工数が膨らみます。

ここでは、目的と範囲の決め方から、観点設計、実施、報告までの段取りを具体化します。

目的を先に言語化する

最初に「何の安心を提供するテストか」を短い文で定義すると、範囲の衝突が減ります。

例えば「リリース可否の判断材料を集める」「問い合わせ増を防ぐ」「決済失敗をゼロに近づける」など、目的で粒度が変わります。

目的が決まれば、後述する優先順位付けもブレにくくなります。

範囲を決めるときの考え方

範囲は「画面」「機能」「ユーザーロール」「デバイス」「外部連携」を単位に切ると管理しやすいです。

境界が曖昧なままだと、誰も見ていない穴が生まれ、逆に同じ箇所を複数人が重複して確認しがちです。

「やらないこと」も明示して合意を取ると、後からの追加依頼に強くなります。

観点を抽出するコツ

観点は「入力」「遷移」「権限」「データ整合」「例外」「表示」「性能体感」のようなカテゴリで洗い出すと漏れにくいです。

さらに、過去障害や問い合わせ履歴があるなら、そこから再発しやすい観点を優先すると効率が上がります。

仕様書が不十分な場合は、期待結果を作る作業自体が品質向上になります。

優先順位の付け方

時間が限られる現場では、全部を同じ深さで実施しない判断が必要です。

影響度と発生可能性でマトリクスを作り、上位だけを厚く、下位は薄くするのが現実的です。

実施と記録の最小セット

実施結果は、後から第三者が再現できる粒度で残すと、調査コストが下がります。

特に「環境」「手順」「入力値」「期待結果」「実結果」「日時」「担当」を揃えると、報告が速くなります。

• 端末とOSバージョン
• ブラウザとバージョン
• アカウント種別
• 入力値
• 発生手順
• 期待結果
• 実結果
• 再現率

手動テスト設計の質を上げる技法

手動テストの強さは、人の判断で「効く観点」を選び、限られた時間で最大のリスクを潰せる点にあります。

ここでは、テスト技法を使って観点の網羅性と効率を両立する方法を紹介します。

同値分割で入力を絞る

入力パターンが多い項目は、すべてを試すのではなく、同じ振る舞いをするグループに分けます。

例えば「文字数」「文字種」「範囲外」は代表値で検証し、境界は別技法で補完します。

これだけでも、手動テストの総ケース数を大きく減らせます。

境界値分析で落ちやすい点を突く

不具合は、許容範囲の端で起きやすいです。

最小値・最大値とその前後を押さえることで、少ない回数で高い検出力を得られます。

状態遷移で画面フローを崩す

ログイン前後、購入前後、申請中など、状態が変わるアプリは遷移の抜けが起きやすいです。

「戻る」「二重送信」「別タブ」「セッション切れ」など、現実の操作を混ぜて遷移の破綻を探します。

画面単体では正常でも、状態の組み合わせで異常が出ることは多いです。

組み合わせを最小化する

端末×OS×ブラウザ×権限×プランのような組み合わせは、総当たりすると破綻します。

重要度が高い軸を固定し、残りは代表組み合わせに圧縮すると、現実的な工数に収まります。

• 最多利用の端末を基準にする
• 障害が出やすいブラウザを優先する
• 権限差分が大きいロールに絞る
• 決済やメールなど外部依存は厚めにする

手動テストで頻発する落とし穴と対策

手動テストは柔軟な反面、属人化しやすく、ミスが見えにくいのが課題です。

ここでは、現場で頻繁に起きる失敗パターンを先回りで潰すための対策をまとめます。

期待結果が曖昧なまま進めてしまう

期待結果が曖昧だと、現象を見ても合否が判断できず、結局「確認待ち」が増えます。

仕様がない場合は、プロダクトオーナーや開発とその場で期待結果を決め、文章として残すのが最短です。

期待結果を決める行為そのものが仕様の穴埋めになり、後工程の手戻りを減らします。

環境差分を軽視して再現できない

端末、OS、ブラウザ、拡張機能、キャッシュ、通信品質などで挙動は変わります。

再現できない不具合の多くは、環境情報が欠けていることが原因です。

最低限の環境メタデータをテンプレ化して、記録漏れを防ぎます。

テストデータが汚れて検証が破綻する

同じアカウントを複数人で使い回すと、状態が壊れて原因が追いにくくなります。

ロール別のアカウントや、決済・メールのテスト用データを用意し、毎回初期化できる仕組みを作ります。

データ準備は地味ですが、総工数を左右するボトルネックです。

不具合報告が再現手順になっていない

「動きませんでした」だけでは、開発が直しようがなく、往復で時間が溶けます。

再現手順は、操作を時系列で番号付きにし、入力値と画面遷移を明確にします。

• 手順は最短経路に整理する
• 入力値はコピペ可能に残す
• 発生画面のURLや識別子を添える
• 再現率を記載する

手動テストを支えるツールと運用の整え方

手動テストの効率は、テスターの腕だけでなく、道具立てと運用設計で大きく変わります。

ここでは、ツールの使いどころと、チームで回る運用の作り方を整理します。

バグ管理は粒度を揃える

チケットの粒度がバラバラだと、優先順位と工数見積もりが崩れます。

「1チケット＝1現象」を基本にし、影響範囲や再現条件はテンプレで統一します。

起票の揺れが減ると、修正・確認のサイクルも短くなります。

エビデンスは「撮る」より「伝わる」

スクリーンショットや動画は有効ですが、撮ること自体が目的になると工数が膨らみます。

重要なのは、誰が見ても状況を理解できることです。

リリース前の最終確認を固定化する

毎回ゼロから考えると、重要ポイントの抜けが起きます。

リリース判断に直結する項目だけを短く固定し、そこは必ず通る運用にします。

• ログインと主要導線
• 購入や申込の完了
• メール送信の成否
• 権限で見える範囲の差
• 致命的な表示崩れ

テスト環境の整備で手戻りを減らす

環境が遅い、データがない、権限が足りないといった障害は、テスト時間を削ります。

本番相当の設定差分を把握し、必要な外部連携はスタブやサンドボックスも含めて準備します。

環境準備を「個人の工夫」にせず、チーム資産として整えることが重要です。

自動化とどう棲み分けると成果が出るか

手動テストと自動テストは対立ではなく、目的で役割を分担させると最も効果が出ます。

ここでは、自動化の候補選定と、手動を残すべき領域、移行の進め方を具体的に扱います。

自動化に向く条件

仕様が安定し、同じ手順を繰り返す箇所は自動化の恩恵が大きいです。

特に回帰テストや、APIの契約確認のように期待結果が明確なものが適しています。

• 繰り返し頻度が高い
• 期待結果が明確
• 環境差分が少ない
• 失敗時の原因が追いやすい

手動で残すべき領域

UIの違和感、文章の自然さ、操作の迷い、視認性などは、人の感覚が重要です。

また、新機能の初期段階は変更が多く、自動化の保守が先行してしまいがちです。

探索的テストは、未知の不具合を見つける役割として手動の価値が高いです。

混在運用の設計ポイント

自動化は増やすほど良いわけではなく、保守コストを見込みに入れる必要があります。

「落ちたら止める」テストと「情報として見る」テストを分けると、運用が安定します。

段階的に自動化へ移す手順

いきなり全面自動化を目指すと、失敗しやすいです。

まずは回帰の中でも「壊れると痛いが手順は単純」なところから小さく始めます。

手動のテストケースを、後で自動化しやすい形に整えるだけでも移行が楽になります。

手動テストを強くする要点整理

手動テストは、人の判断を活かして未知の不具合や体験品質の問題を見つけるのに向いています。

成果を出すには、目的と言語化された期待結果、範囲の合意、観点の設計、再現できる記録が欠かせません。

同値分割や境界値分析などの技法で効率と検出力を上げ、繰り返しが多い箇所は自動化と役割分担すると、品質とスピードの両立が現実的になります。

まずは「目的→範囲→観点→記録テンプレ」を整え、次に回帰の一部から自動化を試すと、手戻りを抑えながら改善を積み上げられます。