実績ゼロでQA・テストに応募する人が、代わりに出せるバグ報告の書式

まず、安心してください。QA・テストの分野で実績ゼロから応募するとき、経歴の空白は思っているほど不利になりません。この職種で発注者が本当に見ているのは、過去の年数ではなく、あなたが書いた文書の読みやすさだからです。そして文書は、実績がなくても今日作れます。この記事では、実績の代わりに提出できるバグ報告の書式を、項目の定義から具体的な文例まで、そのまま真似できる形でお伝えします。

私自身、43歳で製造業を離れて独立しましたが、そのとき手元にあったのは経歴書ではなく、自分で作った文書の型だけでした。皆さんに一番伝えたいのは、型を持っている人は評価されやすい、ということです。

実績ゼロでも通る理由は、この職種の構造にある

なぜ書式が実績の代わりになるのか。理由は、QA・テストという仕事が抱えているリスクの性質にあります。

品質保証の担当者が不在の現場で何が起きるかについて、業界の解説では次のように整理されています。

たとえばQAが不在だとテスト設計があいまいでテスト仕様書が整備されないまま、作業が属人化する可能性があります。その場合、経験豊富なテスト担当者が異動や退職で不在になると、テスト品質を維持できない、テスト作業の生産性が落ちるなどの問題につながります。このように、QA不在の状態がつづくと最終的には不具合が混入したままプロダクトがリリースされるリスクが高まり、ユーザーへの影響が出ることでブランドの毀損や顧客離れにつながるでしょう。 出典: service.shiftinc.jp

ここで挙げられている問題の中心は「属人化」です。特定の人の頭の中にしか手順がない状態が、いちばん怖い。逆に言えば、発注者が求めているのは、頭の中にあるものを文書として外に出せる人です。

つまり、バグを見つける能力そのものより、見つけたものを他人が使える形に落とす能力が評価されている。この構造があるから、実績がなくても書式で示せるのです。

私も現場にいた頃、検証の腕は確かなのに報告が伝わらない方を何人も見てきました。逆に、経験は浅くても報告が整理されている方は、すぐに任される範囲が広がっていきました。これは業界を問わず共通する現象だと思います。

報酬の水準も、担当する工程で決まっている

もう一点、皆さんが気にされる報酬についても触れておきます。この職種の年収は、公的な統計にもとづく数字が公開されています。

厚生労働省の職業情報提供サイト（job tag）の給与データによると、幅広いテスト担当者を含む「デバッグ作業（職業別名：デバック技術員、デバック作業員、QA（Quality Assurance）テスター、QAエンジニア、ゲームテスター）」としての年収は、578.5万円です（全国）。 出典: veriserve.co.jp

同じ解説では、担当する範囲によって水準が大きく動くことも示されています。

また、QAエンジニアはAIを活用したテスト自動化や、プロダクトに対する要求品質を満たすためのプロセスマネジメントといった専門スキルを持つため、そのスキルの幅に応じて年収帯が大きく変わります。求人市場でも、テスト自動化ツールの活用経験や品質マネジメントプロセスの構築実績を持つ高度人材は、年収800万円以上の人も珍しくなく、より高い条件で採用される場面が増えています。 出典: veriserve.co.jp

平均が578.5万円で、専門性を持つ層は800万円以上も珍しくない。この幅は、実行だけを担う工程と、設計やプロセス構築まで担う工程の違いから生まれています。

実績ゼロの段階では、当然ながら下側から入ることになります。ただ、ここで大事なのは、入口の位置ではなく、上に伸びる道筋が見えているかどうかです。書式を整えることは、その道筋の最初の一段にあたります。報告が整理できる人は、次にテスト設計を任され、その次に観点の洗い出しを任される。この順番で進んでいきます。

相場の全体像を確認しておきたい方は、ソフトウェア開発領域の水準をまとめたソフトウェア作成者の年収・単価相場を見ておくとよいです。報告書や仕様書の作成が業務の中心になる案件では、著述家，記者，編集者の年収・単価相場のほうが実態に近いこともあります。自分の担当がどちらに寄るかで、目安が変わります。

バグ報告の書式、7つの項目

ここから具体的な中身に入ります。実績の代わりに提出する文書は、次の7項目で構成してください。

1. タイトル

一行で、何が起きているかを言い切ります。ここが最も差が出る項目です。

悪い例を挙げます。「エラーが出る」「保存できない」「画面がおかしい」。これらは、読んだ人が中身を開かないと何も分かりません。起票が10件並んだときに、優先度を判断できないのです。

良い例はこうです。「会員登録画面で、メールアドレスに全角文字を入力すると送信ボタンが無反応になる」。どの画面で、どんな操作をすると、何が起きるか。この三つが入っていれば、開かずに判断できます。

長さの目安は40文字前後です。短すぎると情報が足りず、長すぎると一覧で切れます。

2. 発生環境

どこで起きたのかを、機械的に列挙します。

OSの名称とバージョン、ブラウザの名称とバージョン、端末の機種名。スマートフォンなら画面サイズも入れます。アプリならアプリのバージョン番号を必ず。

ここを省略すると、ほぼ確実に「環境を教えてください」という質問が返ってきます。皆さんの時間も、相手の時間も、その一往復で削られます。

書き方は箇条書きで構いません。むしろ、文章にすると読みにくくなります。

3. 再現手順

番号を振り、一行に一操作だけを書きます。ここが書式の心臓部です。

粒度の目安は、「その業務を知らない人が、書かれたとおりに指を動かせば同じ結果にたどり着く」レベルです。

悪い例。「ログインして設定を変更すると落ちる」。これでは、どの設定をどう変えたのかが分かりません。

良い例。

1. トップページの「ログイン」を押す
2. 登録済みのメールアドレスとパスワードを入力して「ログイン」を押す
3. 右上のアイコンから「設定」を開く
4. 「通知」タブを選ぶ
5. 「メール通知」のスイッチをオフにする
6. 画面下部の「保存」を押す

この粒度まで落とすと、相手は考えずになぞれます。手順が6つを大きく超える場合は、前提条件を別項目に分けて短くします。

4. 期待結果と実際の結果

この二つは、必ず分けて書きます。まとめて書くと、何を不具合と判断したのかが伝わりません。

期待結果には、仕様上そうなるはずの動きを書きます。「設定が保存され、画面を再読み込みしてもオフのままになる」。

実際の結果には、実際に観察した事実だけを書きます。「保存ボタンを押した直後は成功のメッセージが出るが、画面を再読み込みするとオンに戻っている」。

ここで推測を混ぜないのがコツです。「おそらくデータベースに保存されていない」といった原因の推定は、この欄には書きません。原因の推定は次の項目に回します。

5. 発生頻度

毎回起きるのか、たまに起きるのか。たまにの場合は、試した回数と発生した回数を書きます。

「10回試して3回発生」。この数字があるだけで、相手の調査の進め方が変わります。毎回起きるなら手順の問題、たまにしか起きないならタイミングや状態の問題、と当たりが付くからです。

再現しないまま報告することに、後ろめたさを感じる方がいます。ですが、発生頻度を正直に書いた報告は、隠して断定した報告よりずっと価値があります。分からないことを分からないと書けるのは、能力の一つです。

6. 証跡

スクリーンショットか、短い画面録画を添えます。

撮り方にもコツがあります。画面全体を撮り、問題の箇所に赤い枠を付ける。全体が写っていないと、どの画面の話か分かりません。逆に、枠がないと、どこを見ればよいか分かりません。

エラーメッセージが出る場合は、文字が読める解像度で撮ってください。文字が潰れた画像は、添付していないのとほぼ同じです。

録画を使うのは、操作の流れが要るときだけにします。30秒を超える動画は、たいてい見てもらえません。

7. 切り分けた範囲

自分が試したことと、その結果を書きます。ここが、実績ゼロの人が最も差を付けられる項目です。

「別のブラウザでも試したところ、同じ現象が発生しました」「ログアウトして再ログインしても変わりませんでした」「別のアカウントでは発生しませんでした」。

こうした記述があると、相手は同じことを試す時間を節約できます。そして何より、考えて動いている人だという印象が残ります。経歴に書ける実績がなくても、思考の跡は文書に残せるのです。

7項目を並べた完成例

言葉で説明するより、並べたものを見ていただくほうが早いと思います。架空のサービスを題材にした例を1件、そのまま載せます。

タイトル。「予約確認画面で、キャンセル後に一覧へ戻ると予約が残ったまま表示される」

発生環境。macOS 15.5 / Google Chrome 140.0 / 画面幅1440px。ログイン済みの一般会員アカウントで実施。

再現手順。

1. ログインした状態でヘッダーの「予約一覧」を開く
2. 一覧の先頭にある予約の「詳細」を押す
3. 詳細画面下部の「予約をキャンセルする」を押す
4. 確認ダイアログで「はい」を押す
5. 「キャンセルが完了しました」の表示を確認する
6. ブラウザの戻るボタンではなく、画面上部の「予約一覧へ」を押す

期待結果。キャンセルした予約が一覧から消えている、またはキャンセル済みの表示に変わっている。

実際の結果。キャンセルした予約が、キャンセル前と同じ表示のまま一覧の先頭に残っている。画面を再読み込みすると消える。

発生頻度。5回試して5回発生。

証跡。キャンセル完了画面と、戻った直後の一覧画面のスクリーンショットを添付（該当箇所を赤枠で囲んでいます）。

切り分けた範囲。Safari 18.5でも同じ現象を確認しました。別アカウントでも発生します。ブラウザの戻るボタンで戻った場合は正しく消えていました。一覧画面が再取得されていない可能性がありますが、原因の特定はできていません。

この1件を読むのにかかる時間は、おそらく40秒ほどです。そして読み終えた時点で、開発者は何をすればよいか分かっています。実績ゼロという言葉が持つ不安を打ち消すのは、この40秒の体験です。

悪い書き方との対比

同じ現象を、整理せずに書くとこうなります。「予約をキャンセルしたのに一覧に残っています。バグだと思います。再読み込みすると消えます」。

情報としては嘘を書いていません。ですが、環境が分からない、手順が分からない、他の条件で試したかも分からない。受け取った側は、まず質問を返すところから始めることになります。

この差は、能力の差ではなく型の差です。だからこそ、実績がなくても埋められます。

書式を作る手順を、時間の配分で示す

はじめて作る方向けに、所要時間の目安も書いておきます。全部で3時間ほどの作業です。

最初の30分で、題材を決めて一通り触ります。この時点ではメモを取るだけで、報告書の形にはしません。気になった箇所を箇条書きで並べておきます。

次の60分で、気になった箇所の中から3件を選び、再現手順を確定させます。ここがいちばん時間を使うところです。手順を書いては試し、書いては試しを繰り返して、書いたとおりになぞれば必ず同じ結果になる状態まで詰めます。1回で確定することは、まずありません。

続く30分でスクリーンショットを撮り、赤枠を付けます。撮り直しが発生するので、余裕を見ておいてください。

最後の60分で、7項目の形に流し込み、タイトルを整えます。タイトルは全部書き終わってから付けるほうが、的確なものになります。

なお、この3時間は一度きりの投資です。2件目からは題材を変えるだけなので、1時間ほどで作れるようになります。

提出の形式と、渡すときの一言

作った文書をどう渡すかも、意外と結果を左右します。

ファイルはPDFにしてください。文書作成ソフトの形式のままだと、相手の環境で表示が崩れることがあります。スクリーンショットが本文からずれると、それだけで読みにくくなります。

ファイル名は、開かなくても中身が分かるものにします。「検証報告サンプル_氏名.pdf」「テストケース表_氏名.pdf」。連番だけのファイル名は避けてください。

渡すときの一言も、短くまとめます。「実務経験がまだないため、公開されているサービスを題材に、普段の報告の形式をまとめました。ご確認いただければ幸いです」。

ここで、経験のなさを長く釈明しないことです。事実を一行で書いて、あとは文書に語らせる。この姿勢のほうが、結果として信頼されます。

重要度と優先度を、どう付けるか

書式に慣れてきたら、もう一段進めてください。見つけた不具合に重み付けをする項目です。

重要度は影響の大きさ、優先度は対応の順番

この二つを混同している方が多いので、整理しておきます。

重要度は、その不具合が利用者に与える影響の大きさです。データが消える、決済が二重に走る、ログインできない。こうしたものは重要度が高い。表示が少しずれている、といったものは低い。

優先度は、いつ直すかの順番です。重要度が高くても、発生条件が極端に稀であれば、優先度は下がることがあります。逆に、影響は小さくても、全利用者が必ず目にする画面の誤字であれば、優先度が上がることがあります。

実績ゼロの段階では、優先度の判断は発注者に委ねるのが正解です。ただ、重要度については自分の見立てを書いてください。「重要度は高いと考えます。理由は、購入手続きの完了を妨げるためです」。理由を添えれば、判断が違っていても議論の材料になります。

判断に迷ったものは、迷ったと書く

不具合か仕様か分からないものは、必ず出てきます。これを勝手に不具合として起票すると、差し戻されます。逆に、黙って捨てると、本当の不具合を見逃すことになります。

正解は、判断を保留した状態で共有することです。「仕様の確認が必要な点」という項目を別に立て、そこに集めます。

「削除ボタンを押すと確認画面なしで即座に削除されます。仕様として意図されたものか、確認をお願いします」。この書き方なら、相手は判断だけすればよく、あなたは見落としをしていません。

テストケース表を1枚添えると、評価が変わる

バグ報告の書式が整ったら、もう1種類の文書を用意してください。テストケースの一覧です。

表の作り方

表計算ソフトで、次の列を作ります。

番号、確認する機能、前提条件、操作手順、期待結果、実施結果、実施日、備考。

行は20件程度で十分です。多ければよいというものではありません。一つの機能について、正常な入力の場合、境界値の場合、不正な入力の場合、の三種類を並べると、観点を理解していることが伝わります。

例えば会員登録のメールアドレス欄なら、正しい形式を入力した場合、空欄のまま送信した場合、@を含まない文字列を入力した場合、極端に長い文字列を入力した場合。この並びを見せると、思いつきで触っているのではないと分かります。

なぜ表が効くのか

バグ報告は「見つけた結果」を示す文書ですが、テストケース表は「どう探したか」を示す文書です。

発注者から見ると、後者のほうが再現性のある能力に見えます。今回たまたま見つけた人なのか、体系的に探せる人なのか。この違いが、継続して任せられるかの判断に直結します。

実績ゼロの方こそ、この表を用意してください。経歴で示せない体系性を、文書で示せる唯一の方法です。

ポートフォリオという形で自分の仕事を見せる考え方は、他の職種でも共通します。構成の作り方や見せ方の順序についてはWebライターのポートフォリオの作り方｜案件獲得率が上がるテンプレート付き【2026年版】が参考になります。職種は違いますが、実物を見せることで判断コストを下げるという原則は同じです。

題材の選び方と、守秘義務の扱い

実績ゼロの段階では、題材を自分で用意する必要があります。

公開されているサービスを使う

誰でも触れるWebサービスやスマートフォンアプリを一つ選び、それを題材にします。実案件の成果物ではないので、守秘義務の問題は生じません。

選ぶ基準は、応募したい領域に近いことです。業務システムの検証案件を狙うなら、業務系のWebサービス。ゲームの検証なら、無料で遊べるゲーム。ジャンルが近いほど、読む側は自分ごととして受け取ります。

一点だけ注意があります。応募先が運営しているサービスを題材にするのは避けてください。頼まれていない指摘を送る形になり、受け取り方が分かれます。

見つからないときの考え方

「触ってみたが、不具合が見つからない」という相談をよくいただきます。まず、安心してください。それは普通のことです。

そういうときは、不具合ではなく「気づいた点」を書いてください。入力欄の説明が分かりにくい、エラーメッセージが何をすればよいか示していない、同じ操作なのに画面によってボタンの位置が違う。これらは不具合ではありませんが、品質に関わる観察です。

観察を言語化できることも、この仕事の能力です。無理に不具合をひねり出すより、正直な観察を丁寧に書いたほうが、はるかに良い印象になります。

スキルの伸ばし方と、次の一段

書式を作れるようになったら、次に何を積むか。道筋を示しておきます。

資格は道しるべとして使う

この職種に必須の資格はありません。ただ、実績がない期間に、学んでいる証拠として機能します。

報告書や連絡文の型を体系的に扱うビジネス文書検定は、報告の読みやすさが評価軸になるこの仕事と方向が合っています。ネットワークやインフラ寄りの検証に進みたい方には、CCNA（シスコ技術者認定）が、原因の切り分けを開発者と同じ言葉で説明する力につながります。

ただし、資格を取ることが目的にならないよう気を付けてください。書式が1枚もない状態で資格だけ増やしても、発注者の判断材料にはなりません。順番としては、書式が先です。

単価を上げる道筋を先に知っておく

実行だけを担う段階から、設計や観点の洗い出しまで担う段階へ。この移行が、報酬が動く分岐点です。

移行のきっかけは、たいてい報告の中に生まれます。テストケースを実行していると、「この条件が抜けている」と気づく場面が出てきます。それを報告に添えていくと、設計の相談が回ってくるようになります。

単価を段階的に上げていく考え方そのものは、他の職種でも共通します。値上げの伝え方や実績の積み上げ方についてはWebライターが文字単価を上げる方法｜1円→5円にステップアップする戦略【2026年版】の組み立てが参考になります。

発注される作業の形を知っておく

自分の書式をどこに向けて磨くかを決めるには、実際にどんな作業が発注されているかを知る必要があります。QA・テスト・コードレビューのお仕事には、この職種で切り出される作業の種類と進み方が整理されています。

将来的に領域を広げたい方は、AI・マーケティング・セキュリティのお仕事も見ておくとよいです。テスト自動化やセキュリティ検証は、品質を見る目がそのまま活きる隣接領域です。

1本ではなく、同じ書式で3本そろえる

書式が固まったら、次に効くのは本数です。1本だけだと、たまたま上手く書けた1件なのか、いつでもこの水準で書けるのかが、読む側には分かりません。

同じ7項目を使って3本作ってください。そのとき、3本の中身は意図的に散らします。1本目は明らかな不具合、2本目は表示の崩れのような軽いもの、3本目は仕様なのか不具合なのか判断がつかないものです。

三つ目が入っていると、評価が変わります。判断のつかない事象を、断定せずに、しかし相手が判断できる材料をそろえて書ける。この力は実務で使う場面が最も多く、書式を写しただけでは出せない部分だからです。

使い回すときに、1行だけ足す

3本そろえたら、応募のたびに全部を作り直す必要はありません。同じものを添えて構いません。

ただし、渡すときの一言だけは募集ごとに変えてください。「募集内容にある管理画面の検証に近い形で、権限まわりの確認を1本目に入れています」。この1行があるかどうかで、出来合いのものを配っているのか、募集を読んだうえで選んで渡しているのかが分かれます。

そして、3本は古くなります。題材にしたサービスの画面が変わると、再現手順が現状と合わなくなる。半年に一度は開き直して、手順が今でも同じかを確認しておいてください。開いてみたら画面が変わっていた、というのはよくあることで、その差分に気づけること自体も、この職種で見られている力の一つです。

長く市場を見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、実績ゼロから入って定着する方には、共通した特徴があります。最初の1件を取るまでに作った文書を、その後も使い続けているという点です。

多くの方は、案件が取れると見本を作ったことを忘れます。ですが定着する方は、実案件の報告書を毎回少しずつ改良し、次の応募の材料として更新し続けています。運営者として見てきた限りでは、この積み重ねの有無が、2年後の単価に効いています。

もう一つ、取引の形についての実感も書いておきます。仲介手数料が乗る取引では、発注者が払った金額と受け手が受け取る金額のあいだに差が生まれます。手数料0%の直接取引に意味があるのは、受け取りが増えるからというより、手取りが厚くなることで一件に使える時間が増えるからです。実績ゼロから始めた方にとって、この差は大きい。急いで数をこなす必要がなくなると、報告の精度に時間を回せるようになり、その精度が次の依頼を呼びます。

皆さんに最後にお伝えしたいのは、実績ゼロという状態は、書式を持っていない状態とは違うということです。年数は買えませんが、型は今日から作れます。1枚のバグ報告と1枚のテストケース表。これを用意するのに必要なのは、数時間の作業だけです。

よくある質問

Q. 実績ゼロでQA・テストの案件に応募できますか？

応募できます。この職種で発注者が見ているのは、見つけたものを他人が使える形に文書化できるかどうかです。公開サービスを題材にしたバグ報告とテストケース表を用意すれば、経歴の代わりに書き方の実力を直接示せます。

Q. バグ報告の書式には何を入れればよいですか？

タイトル、発生環境、番号を振った再現手順、期待結果と実際の結果、発生頻度、証跡のスクリーンショット、自分が試した切り分けの7項目です。とくにタイトルは、どの画面でどんな操作をすると何が起きるかを一行で言い切ってください。

Q. 題材にするサービスはどう選べばよいですか？

誰でも触れる公開サービスから、応募したい領域に近いものを選びます。業務システムを狙うなら業務系サービス、ゲームならゲーム。実案件の成果物ではないので守秘義務の問題は生じません。応募先が運営するサービスを題材にするのは避けてください。

Q. 触ってみても不具合が見つからないときはどうしますか？

不具合ではなく「気づいた点」を書いてください。入力欄の説明が分かりにくい、エラーメッセージが対処法を示していない、画面によってボタンの位置が違うなど、品質に関わる観察は評価の材料になります。無理に不具合をひねり出すより印象がよくなります。