QA・テストのポートフォリオの作り方｜見る人が知りたいこと

QA・テストのポートフォリオを作ろうとして、最初の1行で手が止まる人は多いはずです。開発者なら動くアプリを見せれば済みますが、QAの仕事は「壊れていないことを確かめた」という、目に見えにくい成果だからです。

結論から書きます。QA・テストのポートフォリオで見る人が知りたいのは、あなたが何本のテストを実行したかではありません。何を守る仕事として引き受け、どこまでを対象と決め、なぜその範囲に絞ったのかという判断の筋道です。テストケースの枚数を増やしても評価は上がりません。逆に、対象が小さくても判断の根拠が書いてあるものは、その場で読み切られて次の話に進みます。

この記事では、受け取る側がどの順序で何を見ているのかを分解し、素材が手元にない状態からポートフォリオを組み立てる手順、守秘義務のある仕事をどう扱うか、そして提出形式の選び方までを整理します。

QA・テストのポートフォリオは「読まれる時間」から逆算する

ポートフォリオの作り方を考える前に、それが読まれる状況を具体的に想像しておく必要があります。ここを外すと、丁寧に作ったのに読まれないという結果になります。

読み手は、採用担当者か、開発チームのリーダーか、業務委託の発注者のいずれかです。いずれの場合も、共通しているのは「同時に複数人分を見ている」という点です。最初に開いてから、続きを読むかどうかを決めるまでにかけている時間は1分前後と考えておくのが現実的です。その短い時間で伝わらなければ、中身がどれだけ良くても届きません。

この前提から導かれる作り方は、次の3点に集約されます。

第一に、冒頭に要約を置くこと。「どんなプロダクトを、どの観点で、どこまで検証したか」を3行以内で書きます。第二に、成果物へのリンクを要約のすぐ下に置くこと。スクロールしないと本体にたどり着けない構成は、それだけで離脱の原因になります。第三に、量を誇らないこと。テストケース数や実行件数を並べても、読み手はその数字の妥当性を判断できません。

見られ方には職種特有の事情もあります。QA・テストの仕事は、開発工程の中で「最後に入って、最初に切られる」と誤解されやすい領域です。だからこそ、読み手は無意識に「この人はコストなのか、リスクを減らす投資なのか」を測っています。ポートフォリオが判断の筋道を示していれば後者に見え、作業記録の羅列なら前者に見えます。この差は決定的です。

実務でどんな案件が動いているかを知っておくと、書くべき粒度も掴みやすくなります。テスト設計から不具合の再現手順の作成、リリース前の回帰確認までの流れはQA・テスト・コードレビューのお仕事にまとまっているので、募集側が何を求めているかを確認したうえで、ポートフォリオの見出しをそこに寄せると読み手の負担が減ります。

見る人が最初に確認する4つの点

読み手が確認している項目は、経験上ほぼ固定されています。順番に見ていきます。

何を保証したのかという範囲の宣言

最初に見られるのは、検証の対象と、あえて対象外にしたものです。「Webアプリ全体をテストしました」という書き方は、実質的に何も言っていないのと同じです。読み手はここで「範囲を切る訓練を受けていない人だ」と判断します。

書くべきなのは、たとえば「会員登録から初回ログインまでの導線を対象とし、決済とメール配信は対象外とした」という宣言です。そして重要なのは、対象外にした理由を1行添えることです。「外部サービス連携のため検証環境で再現できない」「今回は新規実装部分に工数を集中させる方針」といった一文があるだけで、判断できる人だという印象になります。

QAの現場では、テストを尽くすことは原理的に不可能です。すべての入力の組み合わせを試すことはできません。だからプロの仕事は「どこを捨てたか」に表れます。捨てた場所とその理由を書くのは、弱みの開示ではなく、専門性の提示です。

なぜその設計にしたのかという根拠

次に見られるのは、テスト設計の根拠です。同値分割や境界値分析といった技法の名前を並べるだけでは足りません。読み手が知りたいのは、その技法を「この画面のこの項目に、なぜ当てたのか」という接続部分です。

たとえば入力欄の文字数制限に対して境界値を取ったなら、「仕様書に上限の記載はあるが下限の記載がなく、実装を確認したうえで0文字と1文字を分けて確認した」と書きます。仕様の欠落に気づいて動いた記録は、技法の知識よりはるかに強いアピールになります。

リスクの重み付けも同じです。「決済に近い機能ほど障害の影響が大きいため優先度を上げた」「利用頻度の高い画面から着手した」といった、優先順位の付け方の説明を必ず入れます。優先順位を説明できるかどうかは、限られた時間で成果を出せる人かどうかの判定に直結します。

不具合をどう伝えたかというバグ票の質

ポートフォリオに入れる成果物の中で、最も評価に効くのはバグ票です。テストケースは形式が整っていれば誰が書いても似た見た目になりますが、バグ票には書き手の力量がそのまま出ます。

良いバグ票の条件は明確です。開発者が読んで、再現手順のとおりに操作すれば、その場で同じ現象に到達できること。そして、期待結果と実際の結果が分けて書かれていること。この2つが満たされていない報告は、開発側で「確認できません」と差し戻され、往復が発生します。この往復コストを減らせる人が、現場では信頼されます。

ポートフォリオに載せるバグ票は、実際に見つけたものを匿名化して2件から3件載せれば十分です。数より、1件ごとの完成度を上げてください。環境情報、前提条件、手順の番号付け、スクリーンショット、発生頻度、影響範囲の推定まで書かれた1件は、量産された10件より雄弁です。

守秘の扱いを理解しているか

意外に見落とされがちですが、読み手はここも見ています。前職や受注案件の情報をそのまま載せているポートフォリオは、たとえ内容が優れていても評価を下げます。「この人はうちの情報も外に出す」と読まれるからです。

対処は難しくありません。プロダクト名を「大手向けの業務管理システム」といった抽象表現に置き換え、画面のスクリーンショットは自作のダミー画面に差し替えます。数値も丸めます。そのうえで、冒頭に「守秘義務に配慮し、固有名詞と画面は差し替えています」と一文を添えておく。この一文があるだけで、配慮ができる人だという印象に反転します。

素材がないときにポートフォリオを作る手順

実務経験がまだ薄く、見せられる成果物がないという状態は珍しくありません。この場合は、公開されているアプリやサービスを題材にして、自分でテストの一式を作ります。手順を具体的に示します。

題材の選び方

題材は、機能が多すぎず、仕様が公開されているものを選びます。オープンソースのタスク管理ツール、自治体や公的機関が公開しているWebフォーム、あるいは自分で作った小さなアプリでも構いません。避けたいのは、大手のサービスをそのまま題材にして「不具合を見つけました」と公開することです。公開の仕方によっては相手方との関係で問題になります。題材にする場合も、報告は自分のポートフォリオ内に留め、外部への指摘として発信しない配慮が要ります。

選定の理由も書いておきます。「仕様がドキュメントとして公開されており、期待結果を第三者が検証できるため選んだ」という理由は、それ自体がテスト観点の説明になります。

テスト計画を1枚にまとめる

次に、テスト計画を1枚だけ作ります。長い文書は要りません。含める項目は、目的、対象範囲、対象外、前提となる環境、優先度の付け方、完了の判断基準の6つです。特に完了基準は必ず入れてください。「重大度の高い不具合が残っていないこと」「主要導線が通ること」といった線引きを自分で決めた記録が、判断できる人という印象を作ります。

テストケースを書く

テストケースは、全機能を網羅しようとしないでください。1つの機能に絞り、そこを深く掘ったほうが評価されます。目安として、深さを見せるには20件程度で足ります。

各ケースには、前提条件、操作手順、期待結果を必ず分けて書きます。そして、どの技法を適用したかを列として持たせると、設計の意図が一目で伝わります。同値分割で代表値を選んだケース、境界値で上限と下限を取ったケース、状態遷移で異常な順序を試したケースが混在していると、引き出しの多さが自然に伝わります。

バグ票と報告書で締める

最後に、見つかった問題をバグ票にまとめ、全体の結果を短い報告書にします。報告書は、実行件数の集計だけでなく、「今回の範囲では品質上の懸念はこの部分に集中している」という所見を1段落入れてください。数字を並べるだけの報告は、読んだ人が次に何をすればよいか分かりません。所見まで書けるかどうかが、テスト実行者とQAエンジニアの分かれ目になります。

自動化の成果はどう見せると伝わるか

テスト自動化の経験がある場合、コードをそのまま置いただけでは伝わりません。読み手が知りたいのは、自動化した対象の選び方と、その後の保守がどうなったかです。

まず、なぜその範囲を自動化したのかを書きます。「毎リリースで必ず実行する回帰項目のうち、変更頻度の低い画面を選んだ」といった選定理由は、自動化の投資判断ができる人であることを示します。逆に、変更が激しい画面を自動化して壊れ続けた経験があるなら、それも正直に書いて、どう対処したかまで書くほうが評価されます。

次に、実行環境と再現性です。誰かが手元にクローンして動かせる状態になっているか。READMEに前提条件と実行コマンドが書かれているか。ここが整っていないコードは、読み手が動かすのを諦めます。動かしてもらえない自動化コードは、ポートフォリオとしての価値がほぼゼロになります。

最後に、保守の記録です。テストが不安定になったときにどう切り分けたか、待機処理をどう見直したか、といった記録は、自動化を「作った経験」ではなく「運用した経験」として読まれます。この差は評価に大きく響きます。

自動化やテストの周辺スキルは、AI関連の検証業務にも接続します。生成AIを組み込んだ機能の品質検証はまだ手法が固まりきっていない領域で、AI・マーケティング・セキュリティのお仕事のような案件では、既存のテスト設計の考え方を持ち込める人が重宝される傾向があります。

学習中の内容と資格をどう書くか

未経験や経験の浅い段階では、実績よりも学習の記録が主軸になります。ここで大事なのは、学んだ事実ではなく、学んだことをどこで使ったかを書くことです。

未経験からQAを目指す人向けの解説では、応募書類に盛り込むべき要素が次のように整理されています。

📌 職務経歴書に記載すべきポイント ✔ ITやソフトウェアに興味を持った理由 ✔ 学習していること（JSTQB、プログラミング、テスト自動化など） ✔ ポートフォリオのリンク（GitHubやブログなど） ✔ 前職での経験をQAに活かせる形でアピール 出典: note.com

注目したいのは、学習項目とポートフォリオのリンクが並んで挙げられている点です。つまり、資格や学習内容は単体で提示するものではなく、成果物とセットで初めて意味を持つという構造になっています。

資格については、テスト技術者の認定資格を学習中と書くのは有効です。ただし「取得予定」とだけ書いて成果物がないと、意欲の表明で終わります。学習した技法を前述のテストケースに適用し、「境界値分析の考え方を学び、この項目に適用した」と接続してください。

IT基盤の知識も、QAの現場では効きます。ネットワークやサーバの基礎が分かっていると、不具合の切り分けで「アプリの問題か、通信の問題か、環境の問題か」を自分で見当をつけられるようになります。基礎を体系的に押さえたい場合はCCNA（シスコ技術者認定）のような資格の学習範囲が参考になります。加えて、報告書や仕様の読み書きを整える訓練も効きます。QAの仕事は文書を書く時間が長い職種なので、ここを軽視しないほうがいいです。

前職の経験の書き方も触れておきます。カスタマーサポートの経験があるなら、利用者がどこで詰まるかを知っているという強みになります。製造や検査の経験があるなら、手順を守って記録を残す訓練を受けています。営業経験があるなら、開発と業務側の橋渡しができます。QAは他職種の経験が転用しやすい職種なので、無関係だと切り捨てないでください。

提出形式の選び方と構成

形式は目的で選びます。それぞれの向き不向きを整理します。

リポジトリで公開する形式は、自動化コードがある場合に最適です。READMEを表紙にして、そこにテスト計画の要約と各成果物へのリンクを置きます。コミット履歴が見えるので、継続して手を動かしていることも伝わります。一方で、テストケースやバグ票のような表形式の資料は読みづらくなるため、表計算ファイルや画像を併用します。

表計算ファイルは、テストケースとバグ票の本体を置く場所として向いています。閲覧権限の設定を必ず確認してください。リンクを開いたら権限申請の画面が出た、という状態は、それだけで機会を失います。

文書形式のファイルは、通しで読ませたいときに向いています。全体を1本のストーリーとして読ませられる反面、更新が面倒になり、古い情報が残りやすいという弱点があります。

どの形式を選んでも、入口を1つに絞ることが重要です。複数のリンクを並べて「好きな順で見てください」という渡し方は、読み手に判断を押し付けています。入口となる1ページを作り、そこから各成果物へ導く構成にしてください。

分量の目安としては、入口ページが画面2スクロール以内に収まり、そこから各成果物へ1クリックで到達できる状態が理想です。

転職を狙う場合と業務委託を狙う場合の違い

同じポートフォリオでも、転職と業務委託では見られ方が変わります。ここを分けておくと、無駄な作り込みを避けられます。

転職では、伸びしろと学習姿勢が重く見られます。企業は入社後に育てる前提で採用するため、現時点の完成度より、考え方の筋の良さと、指摘を受け入れて直せるかを測っています。したがって、学習の過程や、途中で気づいて修正した記録を残すことに価値があります。求人の探し方についても、募集要項に手動テスト中心か自動化中心かが書かれているので、そこを読み分けてから応募先ごとに強調点を変えるのが有効です。

業務委託では、即戦力性が中心になります。発注者は育てる前提を持っていません。「この範囲を任せたら、こちらが手を入れずに回るか」を見ています。そのため、契約開始からどのくらいで立ち上がれるか、既存のチームの進め方にどう合わせられるかを示す情報が効きます。参画済みの環境を想定した記述、たとえば「既存のテスト管理ツールに合わせて出力形式を変えられる」といった一文が刺さります。

将来性という観点でも、両者は道筋が違います。転職ルートはテストリードや品質管理の責任者へ進む道が見えやすく、業務委託ルートは複数プロダクトの品質改善を横断的に請ける方向や、開発上流の要件レビューまで受ける方向へ広がります。近い職種の相場感を掴んでおきたい場合はソフトウェア作成者の年収・単価相場が参考になります。QAは開発職と隣接しているため、この水準感を知っておくと、条件交渉の起点を持てます。

他職種のポートフォリオの作法も参考になります。デザイン領域では制作物そのものより制作意図の説明が重視される流れがあり、UI/UXデザインのフリーランスになるには？必要スキルと案件相場で触れられている考え方は、QAの「判断の筋道を見せる」という原則と共通しています。

やりがちで損をする作り方

最後に、実際によく見かける失敗を挙げます。

テストケースを何百件も並べて提出するもの。読み手は全部を読みません。むしろ、絞れない人だという評価になります。

スクリーンショットだけを大量に貼るもの。何を確認した画面なのかが分からず、判断材料になりません。1枚ごとに、何を確認したかの1行を付けてください。

ツール名の羅列。使ったツールの一覧だけがあって、それで何をしたかがないパターンです。ツールは手段なので、目的とセットでなければ情報量がありません。

そして、正直なところ、これはどうかと思うのが、生成AIに書かせた文章をそのまま貼っているものです。テスト計画としては形が整っているのに、対象プロダクトの固有事情が一切書かれていない文書は、読めばすぐ分かります。QAは細部の齟齬に気づく仕事なので、細部が空っぽの文書を出すのは、職能の否定に近い印象を与えます。生成AIを下書きに使うのは構いませんが、対象固有の記述は自分で埋めてください。

探索的テストの記録は、どう残せば成果物になるか

台本どおりに実行するテストとは別に、その場で仮説を立てて操作を変えていく探索的テストがあります。現場で不具合を多く見つけるのはこちらであることが多いのですが、記録が残りにくいため、ポートフォリオに載せづらいと感じている人が多い領域です。

残し方には型があります。まず、開始前に「今回はこの仮説を検証する」というテーマを1行書きます。たとえば「入力途中で通信が切れたときの状態保持」「複数タブで同時に操作したときの整合性」といった粒度です。次に、時間を区切ります。30分や60分で1セッションとし、その中で操作した内容と気づいたことをメモしていきます。最後に、セッション終了後にメモを整理し、不具合として報告するもの、仕様確認が必要なもの、次のセッションで深掘りするものに仕分けます。

この一連の記録をそのまま貼れば、ポートフォリオの成果物になります。テストケース表と違って、思考の動きがそのまま見えるのが強みです。仮説が外れたセッションも隠さずに載せてください。外れた記録があると、当てずっぽうではなく仮説検証をしている人だと伝わります。むしろ全部が当たっている記録のほうが、後付けで整えた印象を与えます。

書式は凝る必要がありません。表計算ファイルに、日時、テーマ、対象、操作メモ、気づき、仕分け結果の列を持たせるだけで十分です。凝った書式より、継続して記録している事実のほうが評価されます。

レビューを受けて直した記録を1件入れる

もう1つ、入れておくと効く要素があります。自分の成果物に対して他者からレビューを受け、それに応じて直した記録です。

QAの仕事は、開発者やプロダクト側との対話が前提になります。バグ票を書いたら「仕様どおりです」と返ってくることもありますし、テスト計画に対して「その範囲は今回不要」と指摘が入ることもあります。このときに感情的にならず、根拠を整理して再提示できるか、あるいは納得して引き下がれるかが、チームで働けるかどうかの判定材料になります。

具体的には、勉強会や技術コミュニティで自分のテスト設計を見てもらう、あるいは知り合いの開発経験者にバグ票を読んでもらう、といった方法があります。もらった指摘と、それに対して自分がどう直したかを、変更前後が分かる形で残してください。「期待結果の記述が仕様書の引用になっておらず、根拠が弱いと指摘を受けたため、該当箇所の仕様書のページ番号を追記した」といった具体性があると、指摘を実装に落とせる人だと伝わります。

未経験からこの職種を目指す際の学習の進め方については、次のような整理も示されています。

➡️未経験からでもQAエンジニアになれる！ ➡️テスト基礎＋プログラミング＋ポートフォリオ作成が重要 ➡️転職市場のリサーチと面接対策をしっかり行う ➡️実際に手を動かして経験を積むことが成功のカギ！ 出典: note.com

ここで「実際に手を動かす」と書かれている部分は、単に作業量を増やせという意味ではありません。手を動かして、その結果を人に見せて、指摘を受けて直す。この往復が入って初めて、経験として蓄積されます。ポートフォリオに往復の記録が1件入っているだけで、読み手はその往復ができる人だと判断できます。

運営者の視点から見た、評価されるポートフォリオの共通点

在宅ワークとフリーランスの市場を20年見てきた立場から言えば、長く仕事が途切れない人のポートフォリオには、はっきりした共通点があります。それは、自分の能力の一覧ではなく、相手の困りごとの一覧になっているということです。

QA・テストの領域でいえば、「リリース前に毎回ひやひやする」「不具合の報告が曖昧で開発が止まる」「テストの担当者が退職して手順が消えた」といった、発注側が実際に抱えている困りごとがあります。評価されるポートフォリオは、この困りごとに対して「こういう形で引き取ります」という応答になっています。技法の一覧を並べたものは、応答になっていません。

もう一点、運営者として見てきた限りでは、仲介の手数料が乗らない直接取引の場では、この応答の質がそのまま関係の長さに変わります。中間マージンがない分、同じ予算で依頼者はより多くの範囲を頼めますし、受け手の手取りは厚くなります。ただ、それ以上に効いているのは金額ではなく、発注者が「この人に任せると自分の確認作業が減る」と実感したときに、次の依頼が説明なしで来るという点です。単発の作業を積み上げている人より、この状態を作った人のほうが、結果として仕事が安定しています。

ポートフォリオは、その関係の入口です。読み手が「この人に任せると楽になりそうだ」と感じる材料を、判断の筋道という形で置いておく。それが、QA・テストのポートフォリオで最も費用対効果の高い作り込みです。

職種横断で見たときのポートフォリオの位置づけ

最後に、視野を広げた話をします。ポートフォリオという道具は、QAに限らずあらゆる受注型の職種で使われますが、職種ごとに「見せるべき中身」が違います。

成果物そのものが価値になる職種、たとえば制作系では、完成品を並べることに意味があります。音や映像を扱う領域では、サンプルを聴いてもらった時点で判断がつきます。文章を扱う仕事も近く、書いたものがそのまま直接の証拠になります。

一方でQA・テストは、成果物が「起きなかった障害」という不在の形をしています。だからこそ、成果物を並べる方式では伝わらず、判断の記録を見せる方式に切り替える必要があります。ここを取り違えて、制作系のポートフォリオの真似をしてしまうと、いくら作っても手応えが出ません。

新しい技術領域でも同じ構造が見られます。Web3 フリーランスの年収と案件獲得術！2026年最新ガイドで扱われているような、前例の少ない分野では、実績そのものより「未知の対象にどう向き合ったか」の記録が評価材料になります。QAの未経験者が公開アプリを題材にポートフォリオを作るのは、これと同じ理屈です。実績がないなら、実績の代わりに思考の過程を差し出す。それが、この職種で通用する唯一の近道です。

作った後、定期的に手を入れる

ポートフォリオは一度作って終わりにするものではありません。半年も放置すると、書いてある内容と実際にできることがずれていきます。

更新の目安は、案件や業務が1つ区切りを迎えたタイミングです。そこで、新しく扱った領域を1行足し、古くなった記述を落とします。全面的に書き直す必要はありません。冒頭の要約だけを最新の状態に保っておけば、読み手が受ける印象は大きく変わります。

もう1つ、応募や商談のたびに反応を記録しておくと精度が上がります。どの部分について質問されたか、どこで話が弾んだかを残しておけば、次に前に出すべき情報が分かります。読まれ方は自分では分かりません。相手の反応だけが唯一の手がかりです。

よくある質問

Q. 実務経験がまったくない状態でもポートフォリオは作れますか？

作れます。公開されているアプリやオープンソースのツールを題材に、テスト計画、テストケース、バグ票、結果報告の一式を自分で作成する方法が一般的です。範囲は1機能に絞って構いません。全機能を浅く網羅するより、1つの機能を深く掘って設計の根拠を書いたほうが評価されます。題材の選定理由を書き添えると、判断力の提示にもなります。

Q. テストケースは何件くらい載せればいいですか？

件数を増やすことに評価上の意味はほとんどありません。設計の深さを示す目的なら20件前後で足ります。重要なのは、前提条件と操作手順と期待結果が分けて書かれていること、そして各ケースにどの技法を適用したかが分かることです。数百件を貼り付けると、絞り込みができない人という逆の印象を与えます。

Q. 前職で担当した案件をポートフォリオに載せてもいいですか？

そのまま載せるのは避けてください。守秘義務の観点で問題になるほか、読み手からも情報管理ができない人と見られます。プロダクト名は業種と規模の抽象表現に置き換え、画面は自作のダミーに差し替え、数値は丸めます。冒頭に固有名詞と画面を差し替えた旨を明記しておくと、配慮ができる人という評価に変わります。

Q. 資格は取ってから応募したほうがいいですか？

取得を待つ必要はありません。学習中であることを書き、学んだ技法を実際のテストケースに適用した記録を添えるほうが効果的です。資格は単体では意欲の表明にとどまり、成果物と結びついて初めて評価材料になります。テストの基礎知識に加え、ネットワークや文書作成の基礎があると、不具合の切り分けと報告の両面で強みになります。

Q. 転職向けと業務委託向けで内容を変えるべきですか？

変えたほうが通ります。転職では伸びしろと学習姿勢が見られるため、学習の過程や指摘を受けて修正した記録に価値があります。業務委託では即戦力性が中心になるため、立ち上がりの速さや、既存のツールと進め方に合わせられる柔軟さを示す記述が効きます。入口となる要約部分だけを差し替える運用にすると、管理の手間を抑えられます。