ITテスターは、Webサイト、業務システム、スマートフォンアプリ、ゲームなどを決められた条件で操作し、期待どおりに動くか確かめる仕事です。問題を見つけたら、操作手順、実際の結果、端末・OS、画面証跡をそろえて開発者へ報告します。
未経験求人ではテスト実行から始めることが多いものの、『画面を適当に触ってバグを探すだけ』ではありません。同じ結果を再現できる記録、仕様の読み取り、データ準備、変更後の再確認までが品質に直結します。職業訓練後は担当範囲と教育体制を見て選びます。
テスター・デバッグ・QAの違い
| 役割 | 主な仕事 | 未経験者の入口 |
|---|---|---|
| テスト実行者 | 項目書どおりに操作し、結果と証跡を記録 | 手順・判定基準が整った案件から入りやすい |
| テスト設計者 | 仕様から観点、条件、項目、データを作る | 実行経験と業務・仕様理解が必要 |
| QA担当 | 開発工程全体の品質基準、レビュー、改善を担う | テスト以外の調整・分析経験も求められる |
| デバッグ | 不具合の原因を調べ、修正または切り分ける | 求人によって報告までかコード修正までかが違う |
| プログラマー | 仕様に基づき機能を実装し、単体テストする | 言語・設計・開発環境の力が必要 |
厚生労働省のIT職種解説でも、テスターはテストの実施、テストエンジニアは計画・設計を担う役割として分けています。求人名に『テストエンジニア』とあっても実行だけの場合があるため、工程と成果物を確認します。
公的情報：job tag「IT関連の仕事」
テスト実行の1日の流れ
- 対象バージョン、仕様変更、テスト範囲を朝会で確認する
- テスト端末、アカウント、データ、接続先環境を準備する
- 項目書の前提条件と操作手順どおりに実行する
- 期待結果と実際結果を比較し、合格・不合格・保留を記録する
- 画面、ログ、動画など指定された証跡を保存する
- 不具合票を登録し、再現確認や開発者からの質問に答える
- 修正版を再テストし、影響範囲の回帰テストを行う
- 進捗・未実施・阻害要因を集計して引き継ぐ
ゲームのデバッグ、銀行システムの受入テスト、ECサイトのブラウザ確認では、必要な正確さと知識が違います。対象サービス、テスト工程、利用者、障害時の影響を理解してから項目を実行します。
公的情報：job tag「デバッグ作業」
職業訓練で準備できること
- HTML・CSS・JavaScriptやプログラミングの基本構造
- 要件、仕様書、画面遷移図、データ項目の読み方
- 正常系・異常系・境界値というテスト観点
- SQLでテストデータや登録結果を確認する基礎
- Git、チケット管理、チャットなど開発ツール
- ブラウザの開発者ツール、ログ、スクリーンショット
- 端末・OS・ブラウザ・通信条件を変える考え方
- 事実、推測、未確認を分けた報告文の作り方
訓練の制作物は、完成画面だけでなくテスト仕様書も残します。入力欄の空白、最小値・最大値、権限違い、二重送信、戻る操作などを項目にし、不具合を修正前後で比較すると、品質を考えて開発した証拠になります。
公的情報：JEED「ソフトウェアテストによる品質保証」訓練モデル
良いバグ報告に必要な情報
| 項目 | 記録する内容 | 悪い例 |
|---|---|---|
| 環境 | 端末、OS、ブラウザ、アプリ版、接続先 | 自分のPCで発生 |
| 前提条件 | ログイン権限、登録データ、設定状態 | 準備済み |
| 再現手順 | 第三者が同じ順番で操作できる番号付き手順 | いろいろ触ったら落ちた |
| 期待結果 | 仕様上どうなるべきか | 普通は成功する |
| 実際結果 | 表示、値、エラー、発生時刻 | 動かない |
| 証跡 | 画面、ログ、動画、対象データ | 画像だけ添付 |
| 頻度 | 5回中5回、特定条件のみなど | たまに起きる |
重大度と優先度も混同しません。データ消失は重大度が高く、表示の小さなずれは低い場合がありますが、公開直前の重要画面なら優先度が上がることがあります。個人の感想で決めず、案件の基準に従います。
テスト項目書を読むときの注意
- 一つ前の項目の結果が前提になっていないか
- 入力データと利用者権限が指定どおりか
- 期待結果が画面だけか、DB・メール・外部連携までか
- 実行順序を変えると結果が変わらないか
- 仕様変更で古くなった項目を勝手に読み替えていないか
- 実行不能を不合格として処理してよいか
- 証跡のファイル名と保存場所が決まっているか
手順や期待結果に矛盾があれば、都合よく進めず、質問票やチケットで確認します。テスト実行者が仕様を決めるのではありません。止まった理由と確認した事実を残すことで、項目書自体の不備も品質改善の材料になります。
テストデータと個人情報を安全に扱う
本番に似た確認が必要でも、実在する顧客の氏名・住所・カード情報を許可なくテスト環境へ複製してはいけません。会社が用意した匿名化データ、ダミーアカウント、指定された番号を使い、画面証跡へ機密情報が写る場合は保存・共有のルールを確認します。
不具合票やチャットは関係者が長く参照します。パスワード、秘密鍵、接続情報を貼らず、必要なログだけを承認された場所へ置きます。端末の持出し、在宅作業、生成AIや外部翻訳への貼付けも、案件の情報管理規程に従います。
SES・派遣・受託の求人を分ける
テスト案件はプロジェクト期間に合わせ、SES、派遣、受託チームで募集されることがあります。求人企業のオフィスではなく顧客先へ常駐する可能性、案件終了後の配属、待機中の賃金、勤務地変更の範囲を確認します。
『未経験研修あり』でも、研修後の仕事内容が決まっていない求人は注意が必要です。テスト実行から設計・自動化へ進んだ実例、評価基準、学習時間、コードへ触れる機会を質問します。常駐先が変わるたび単純実行だけを繰り返すと、経験年数ほどスキルが増えないことがあります。
求人票で確認する15項目
- Web、業務システム、スマホ、ゲームなど対象製品
- 単体・結合・システム・受入のどの工程か
- テスト実行、設計、管理、自動化の割合
- 仕様書と項目書の整備状況
- 一日あたりの項目数と証跡の基準
- 使用する端末、OS、ブラウザ、実機台数
- チケット、テスト管理、ログ確認、SQLの使用範囲
- 不具合の重大度・優先度を誰が判定するか
- 開発者、顧客、海外チームとの連絡方法
- 在宅勤務時の端末・通信・情報管理
- 常駐先、転勤、案件変更の範囲
- 契約期間、更新、待機時の賃金
- リリース前の残業・休日・夜間作業
- 研修期間と単独実行になる基準
- 設計・自動化・開発へ進んだ人の実績
自動化でなくなる仕事・残る仕事
定型的な回帰テストは、自動テストやCI/CDへ置き換わります。ただし、何を確認するか決める、変化した仕様を読む、利用者視点のリスクを見つける、失敗の原因を切り分ける仕事は残ります。手動実行の経験を、観点設計と自動化へつなげることが重要です。
次の段階では、テストコード、APIテスト、SQL、ログ解析、性能・セキュリティの基礎を学びます。プログラマーを目指す場合も、品質を守る視点は役立ちますが、テスト経験だけで開発へ自動的に異動できるわけではありません。社内制度と実績を確認します。
面接で伝える実務に近い経験
訓練制作物で、仕様をどう分解し、どの境界値を選び、何件のテストを実施し、どんな不具合を修正したかを説明します。『バグを見つけるのが好き』より、再現手順と証跡をそろえ、修正後に関連機能も再確認した経験の方が仕事に近いアピールです。
不具合を見つけた人が偉いのではなく、開発者と協力して利用者への影響を減らす仕事だと理解していることも大切です。強い言葉で責任を追及せず、事実、影響、未確認事項を分けて伝えます。
入社後90日の目標
- 対象システム、利用者、用語、基本操作を覚える
- 環境・データ・証跡の準備を一人で行えるようにする
- 項目書どおりに実行し、判断に迷ったら止めて確認する
- 第三者が再現できる不具合票を作成する
- 変更箇所と影響範囲を考えて回帰テストへ参加する
- 小さな項目修正やテスト観点の提案を担当する
よくある質問
IT未経験でもテスターになれますか
手順が整った実行求人はあります。ただしPC操作だけでなく、仕様を読む力、環境・データをそろえる力、正確な報告を準備しておく必要があります。
ゲームを遊ぶ仕事ですか
ゲーム案件でも、決められた端末・条件・手順で繰り返し確認し、証跡と再現手順を残します。娯楽として遊ぶこととは違います。
テスターからプログラマーになれますか
コード学習と社内の異動・案件機会があれば可能性はあります。応募時に開発へ進んだ実例を確認し、テスト自動化や小さな修正から経験を広げます。
まとめ｜実行だけでなく観点・報告・改善へ広げる
ITテスターは、仕様と利用者の間で問題を見つけ、再現できる形で開発へ渡す仕事です。未経験求人では、対象製品、工程、項目書、証跡、常駐・契約条件を確認してください。
職業訓練で作ったシステムに自分でテスト項目を作り、修正前後を記録すると応募材料になります。入社後は正確な実行から始め、テスト設計、API・SQL、ログ、自動化へ範囲を広げると、単純実行にとどまらないキャリアを作れます。
