テスト実行しかしていない人の職務経歴書｜担当業務を伝える書き方と例文

こんにちは！

「職務経歴書を書こうとしたけど、担当業務が『テスト実施』の一行で止まってしまう」

決められた手順どおりに操作して、結果を記録する毎日。
設計や開発はしていないので、何をアピールすればいいか迷いますよね。

そんなときは、普段の作業を少し細かく思い出すところからで大丈夫です。
僕は、いつもの一日の流れをたどると、書く材料を見つけやすいと思っています。

この記事でわかることはこちらです。

• テスト実行の経験から、職務経歴書に書ける担当範囲を整理する方法
• テスト実行・不具合報告の具体的な記載例
• 実務経験と自主学習を分けて伝える書き方

まずは、今ある経験で担当業務欄を埋めてみましょう。

「テスト実施」に、対象と作業内容を足してみる

テスターの職務経歴書は、何を対象に、どんな作業を担当したかを具体的にすると書きやすくなります。

たとえば、「テスト実施」だけだと、確認した画面も作業の進め方もわかりません。
次のように書くと、担当した仕事が見えてきます。

社内向け勤怠管理システムの打刻・申請画面で、手順書に沿った動作確認を担当しました。
確認結果を一覧表に記録し、指定された画面の画像を保存しました。

新しい実績を足したわけではなく、普段の作業を言葉にした例です。
「料理を担当」だけの説明に、「仕込みと盛り付け」を添える感覚に近いですね。

テスト設計（確認する内容や手順を考える作業）の経験がなくても、実行した内容は書けます。
手順を作った人と、手順に沿って確認した自分の役割がわかるようにしましょう。

ステップ1：担当範囲を棚卸しする

最初は文章にせず、思い出せる作業をメモするだけで十分です。
テスト開始前から、その日の報告までを順番に振り返ってみてください。

確認対象と、実際に手を動かした作業を並べる

次の表は、書く材料を探すためのメモです。
当てはまる欄だけ埋めれば大丈夫ですよ。

たとえば、画面画像を残す作業は、エビデンス（確認結果の証拠）の保存にあたります。
現場では当たり前の作業でも、書類では省略せずに書いていいんです。

ただし、準備されたデータを使っただけなら、「テストデータを作成」とは書きません。
「指定されたデータを用いて実行」と書くと、自分の担当範囲に合います。

自分で行ったことと、相談して進めたことを分ける

同じ不具合報告でも、担当の仕方は現場によって違います。
報告先や確認を受けた相手まで思い出すと、役割を説明しやすいですよ。

• 現象をリーダーに伝え、その後の報告は任せていた
• 報告文を自分で作成し、リーダーの確認後に登録していた
• 報告の登録から、開発担当者への追加説明まで行っていた

どれも記載できますが、使う言葉は変わります。
リーダーへの報告までなら、そのまま「リーダーに報告」と書けば十分です。

チームで不具合の原因を調べていても、自分が担当していなければ原因調査には含めません。
面接で「具体的には？」と聞かれたとき、実際の作業を説明できる表現を選びましょう。

ステップ2：テスト実行・不具合報告を例文にする

担当業務は「対象」「実施したこと」「記録や報告の方法」の順に並べるとまとまります。
以下は架空の記載例です。
実際に担当した部分だけを使い、対象やツール名を自分の経験に置き換えてください。

テスト実行と結果の記録を担当した場合

手順書どおりの実行が中心なら、確認した機能と記録方法を書きます。
操作だけでなく、結果をどこに残したかも仕事の一部ですよね。

社内向け勤怠管理システムで、打刻・申請画面のテスト実行を担当しました。
確認方法は、作成済みの手順書に沿った操作と、想定された結果との照合です。
判定をExcelの一覧表へ記録し、指定された画面の画像を保存しました。

担当業務欄を箇条書きにするなら、次の形でも伝わります。

• 作成済みの手順書に沿った打刻・申請画面の動作確認
• 想定された結果と実際の表示の照合、判定結果の記録
• 確認結果の画面画像の保存

テストケース（確認条件・操作手順・想定結果をまとめた項目）という言葉も使えます。
ただ、職務経歴書でも「何の画面を確認したか」を添えると具体的です。

不具合の一次報告まで担当した場合

想定と違う動きをリーダーに伝えていたなら、伝えた内容を書いてみましょう。
不具合管理ツール（発生した問題や対応状況を記録する道具）を使っていなくても記載できます。

想定と異なる動作を確認した際は、実行した手順と画面画像を整理しました。
報告先はリーダーで、想定された結果と実際の動作を併記する運用でした。
不具合として扱うかの判断は、リーダーが担当していました。

「不具合を発見」と言い切りにくい場合は、「想定と異なる動作を報告」で大丈夫です。
仕様（システムがどう動くかを定めた内容）の確認が必要なケースにも合います。

報告の登録や、修正後の再確認まで担当した場合

自分で報告を登録していたなら、記入した項目まで書くと作業内容が伝わります。
修正後の確認も担当していた場合は、別の一文として加えましょう。

不具合管理ツールに、発生条件、再現手順、想定結果、実際の結果を記載しました。
登録前には画面画像を添付し、リーダーの確認を受ける運用でした。
修正の連絡後は、報告した手順で再度操作し、確認結果を追記しました。

再現手順とは、同じ現象を起こすための操作の順番です。
入力値や操作順まで残していたなら、その点も記載できます。

なお、修正された動きを確認する作業と、プログラムの修正は別の担当業務です。
「不具合修正を担当」とまとめると、コードを直した経験に見えてしまうので気をつけたいですね。

実績の数字がわからない場合

件数を覚えていなくても、担当機能や作業の頻度を使って説明できます。
たとえば「完了した項目と未実施の理由を、毎日リーダーに報告」といった書き方です。

数字を入れるなら、自分の担当分と集計した期間をそろえましょう。
再確認を含む件数かどうかも説明できると、読み手が作業量を把握しやすくなります。

チーム全体の実行件数を、自分の実績として書くのは避けてください。
正確な数字が確認できないときは、無理に件数を埋めなくても大丈夫ですよ。

また、不具合の報告件数だけで「品質を大幅に改善」とまでは言い切れません。
効果を裏づける記録がなければ、実際に行った確認や報告を書きましょう。

ステップ3：職務要約・担当業務・自己PRに配置する

材料がそろったら、職務経歴書の各欄に置いていきます。
職務要約には経験の全体像、担当業務には作業の詳細を書くと整理しやすいです。

以下は、テスト実行からリーダーへの一次報告までを担当した人の架空の例です。
期間などの角括弧は、提出前に実際の情報へ置き換えてください。

職務要約の例

［会社名］にて［期間］、社内向け勤怠管理システムのテスト業務に従事しました。
主な担当は、作成済みの手順書に沿ったテスト実行と、結果の記録です。
想定と異なる動作があった際は、操作手順と画面画像を添えてリーダーに報告しました。

職務要約は、詳しい担当業務を読む前の案内になります。
担当したことが伝わればよいので、立派な肩書きを足さなくても大丈夫です。

職務経歴の記載例

担当業務

• 作成済みの手順書に基づく、打刻・申請画面のテスト実行
• 想定された結果との照合、判定の記録、画面画像の保存
• 想定と異なる動作を確認した際の、リーダーへの一次報告
• 担当分の実行状況と未実施の理由の報告

派遣や客先で働いた経験は、雇用元と担当案件の関係がわかる形で記載しましょう。
たとえば、勤務先の欄には雇用元を置き、案件の欄に客先で担当した業務を書きます。

案件名に社内だけの略称を使うと、何のシステムかわかりにくいんですよね。
公開できる範囲で「社内向け勤怠管理システム」など、用途がわかる表現にしてください。
社内の手順書や実際の画面画像を、応募書類に添付する必要はありません。

自己PRの例

自己PRには、仕事の中で気をつけていたことを一つ選びます。
「正確性があります」と書くだけでは、その根拠が見えにくいです。

たとえば、判断に迷う結果を確認してから記録していた人なら、次のように書けます。

テスト実行では、判定に迷う結果を自己判断で完了扱いにしないようにしていました。
リーダーへの確認時に添えていたのは、想定結果と異なる箇所の説明と画面画像です。
確認が取れた内容を結果一覧表に反映し、判断の経緯を残しました。

これも、実際に行っていた場合に使う例文です。
入力値の確認や報告前の見直しなど、自分が続けていた行動から選んでみましょう。

実務経験と自主学習は、欄を分けて書く

自主学習も、取り組んだ内容を伝える材料になります。
「業務で使った経験」と「個人で学んだ経験」が区別できることが大切です。

たとえば、仕事では画面操作を担当し、自宅でSQLを学んでいる場合を考えてみましょう。
SQLは、データベース（データを整理して保存する仕組み）から情報を取り出すためなどに使う言語です。

スキル欄に「SQL：半年」とだけ書くと、仕事で半年使ったのか判断できません。
次のように、使った場面とできる操作を添えてみましょう。

学習欄に少し詳しく書く場合は、次のような形です。

［開始年月］から、業務外でSQLを学習しています。
教材の練習用データを使い、条件を指定したデータの取得と件数の集計を練習しています。
SQLを使用した実務経験はありません。

教材を見ながらできる段階なら、その状態がわかるように書いて大丈夫です。
仕事で用意済みのSQLを実行した経験がある場合も、自分で作成した経験と分けて記載します。

自主学習でテストを自動実行するプログラムを作った場合も、同じ考え方です。
「個人学習」と明記し、作成したものと動かした範囲を書きましょう。
仕事で導入していなければ、「業務を自動化した実績」には含めません。

提出前に、例文と自分の経験が合っているか確認する

最後は、文章を声に出して読みながら、具体的な作業場面を思い出してみてください。
僕なら、表現をかっこよく整える前に、この確認をします。

• 「担当した」と書いた作業は、自分で実際に行ったか
• テスト設計・実行・修正後の確認を、正しく書き分けているか
• 不具合報告の相手と、自分が記入した内容を説明できるか
• 数字は自分の担当分で、期間や数え方も説明できるか
• ツール名に、業務での使い方や学習範囲を添えたか
• 例文の仮の情報や、置き換え用の角括弧が残っていないか

応募先に指定の書式があれば、その項目に合わせて内容を移しましょう。
書類全体を一度に完成させようとせず、まずは一つの案件の担当業務からで十分です。

おわりに

「テスト実施」の一行で手が止まったら、最近担当した画面を一つ思い出してみてください。
何を操作して、結果をどこに残し、困ったときに誰へ伝えたか。
そこまで書けると、自分の担当業務を説明する文章になります。

テスト実行を続けてきた経験も、具体的に書いていいんです。
まずは「対象」「実施したこと」「記録や報告の方法」を、メモに一行ずつ書いてみましょう。