QAエンジニアのフリーランス案件の仕事内容｜案件の種類別の1日・1か月の流れ

フリーランスのQAエンジニアの仕事は、テストの対象と観点を決め、確かめ、見つかった問題と品質の状態を、判断する人に分かる形で渡すことです。ただし、テスト工程の一部を任されるのか、開発チームの中に入るのか、発注側の受入れを支えるのかで、1日の過ごし方も、やり取りする相手も、手元に残る成果物も大きく変わります。

この記事では、フリーランスのQA案件を5つの型に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はQAエンジニアの報酬の記事、求められる力はQAエンジニアのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「入る工程」と「開発の進め方」で決まる

QAエンジニアの案件は、同じ「テスト」の募集でも働き方が違います。違いを生むのは、主に次の2つです。

• 入る工程：テストの実行から入るのか、設計や計画から入るのか、受入れや品質の取りまとめを担うのか
• 開発の進め方：工程を順に進める開発の後半にテスト期間があるのか、短い周期で開発とテストを繰り返すのか

この2つと、テストの対象（Web、モバイル、機器）を組み合わせると、フリーランスのQA案件はおおむね次の5つに分けられます。

以下では、それぞれの1日と1か月の流れを典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

テスト工程の担当の仕事

1日の流れ（例）

朝は、テストのリーダーとその日に実行する範囲を確かめ、前日に報告した不具合の修正状況を見ます。午前中はテストケースに沿って検証環境で操作し、結果を管理表やテスト管理のツールに記録します。期待どおりに動かない箇所があれば、再現の手順をそろえて不具合として報告します。午後は、修正された不具合の再確認と、仕様があいまいな箇所の問い合わせ、翌日以降のテストケースの作成やレビューに時間を使います。

1か月の流れ（例）

• テストの準備の時期：仕様書を読み、観点を洗い出し、テストケースを作る。レビューを受けて直す
• 実行の時期：決められた範囲を順に実行し、不具合を報告する。日々の消化件数と残りの件数を報告する
• 終わりの時期：修正の再確認と、修正による影響が出ていないかを確かめる回帰のテストを行う

工程を順に進める開発では、テストの期間が開発の後半にまとまるため、開発の遅れがテストの期間を削る形で表に出やすいのが特徴です。

成果物

テストケース、実行の結果の記録、不具合の報告、日々の進み具合の報告などです。設計まで任される案件では、テストの観点の一覧や、どの技法でケースを出したかの説明も成果物に含まれます。

アジャイルのチーム内QAの仕事

1日・1か月の流れ（例）

スクラムなどの短い周期で開発を進めるチームに、QAの役割で入る案件です。朝はチームの短い打ち合わせに出て、その日に完成しそうな機能と、テストに回ってくる時期を確かめます。日中は、開発が終わった機能から順にテストし、気づいた点をチャットやチケットで開発者に返します。

周期の初めの計画の会議では、これから作る機能について「何ができたら完成とするか」の条件を、プロダクトの責任者や開発者と一緒に詰めます。QAがここで観点を出しておくと、後から仕様の食い違いが見つかる回数が減ります。周期の終わりには、出す機能の確認と、振り返りの会議での改善の提案が入ります。

成果物

受け入れの条件、機能ごとのテストの観点、探索的なテストの記録、不具合のチケット、回帰のテストの一覧などです。決まった様式のテスト計画書を作らない現場も多く、チームの作業の流れの中に確認を組み込むことが仕事の中心になります。テストの自動化と組み合わせる現場もあり、その場合の仕事はテスト自動化エンジニアの仕事内容で解説しています。

受入れテストの支援の仕事

1日の流れ（例）

発注元の側に立ち、ベンダーが作ったシステムを、業務で使えるかどうかの観点で確かめる案件です。午前は業務部門の担当者と、確かめたい業務の流れや例外の扱いを整理します。午後はベンダーとの打ち合わせで、テストの進み具合や不具合の扱いを確かめ、発注元として判断すべき事項を持ち帰ります。業務部門の担当者がテストを実行する場合は、手順書を用意したり、結果の記録を集めたりする役割になります。

1か月の流れ（例）

• 計画の時期：受入れで確かめる範囲と、合格とする基準を発注元の中で決める
• 実行の時期：業務の流れに沿ってテストし、見つかった問題を不具合か仕様の誤解かに分けてベンダーに渡す
• 判定の時期：残った問題と影響をまとめ、受け入れるかどうかを決める会議の材料をそろえる

テスト工程の担当と違い、「仕様どおりか」より「業務で困らないか」を確かめる比重が大きくなります。

成果物

受入れテストの計画、業務のシナリオ、手順書、結果の集計、残った問題の一覧と影響の整理、受入れの判定の資料などです。読み手が業務部門や管理職になるため、技術の言葉を減らした説明が求められます。

実機・機器のテストの仕事

1日・1か月の流れ（例）

スマートフォンのアプリ、家電や車載の機器、決済の端末などを対象に、実物の端末や機器で確かめる案件です。1日は、決められた機種とOSの版、機器の設定をそろえるところから始まります。テストの条件ごとに端末を切り替えながら確認し、画面の記録や機器のログを残します。機器の状態や通信の条件によって結果が変わることがあるため、環境を記録する手間が多いのが特徴です。

1か月の単位では、OSの更新や新しい機種の発売、機器の試作の版の更新に合わせて、確認の範囲が決まります。検証の拠点や作業する部屋が決められている案件も多く、働く場所の事情はQAエンジニアのリモート案件の記事で整理しています。

成果物

端末と条件の組み合わせの一覧、テストの結果、画面の記録やログを添えた不具合の報告、端末の管理の記録などです。

品質の取りまとめ（QAリード）の仕事

1日・1か月の流れ（例）

テストの計画を立て、テストの担当者の作業を割り振り、進み具合と品質の状態をまとめて報告する案件です。1日の多くは、テストの担当者からの相談への対応、開発のリーダーとの不具合の優先順位の調整、PMや事業部門への報告で埋まります。自分でテストを実行する時間は少なくなります。

1か月の単位では、リリースの計画に合わせてテストの範囲と期間を決め、リリースの前には、残っている不具合とその影響を整理して、出してよいかを決める人に判断の材料を渡すのが山場になります。チーム全体の品質の仕組みまで任される役割は、QAマネージャーの仕事内容で解説しています。

成果物

テスト計画、テストの範囲と優先順位の説明、進み具合と不具合の推移の報告、リリース前の品質の報告、テストの進め方の改善の提案などです。

どの案件にも共通する仕事

型が違っても、次の仕事はほぼすべてのQA案件にあります。

1. 仕様の確認：分からない点やあいまいな点を、テストの前に問い合わせて記録に残す
2. 不具合の報告：手順、期待した結果と実際の結果、環境をそろえ、誰が読んでも再現できる形で書く
3. 進み具合の報告：どこまで確かめ、何が残り、どんな危うさがあるかを短く伝える
4. 環境とデータの準備：テスト用のアカウントやデータ、端末を、必要な時期までにそろえる

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。月の稼働時間に幅を決めて精算する契約が多いため、テスト期間の終盤に作業が延びた時間も日々つけておきます。精算の仕組みは精算幅の記事、稼働の報告の仕方は稼働報告の記事をご覧ください。

関わる相手と、その相手に出すもの

QAエンジニアの1日は、誰に何を渡すかで組み立てられています。相手ごとに整理すると、次のようになります。

どの相手にも共通して求められるのは、事実と、自分の見立てを分けて伝えることです。「この不具合が出た」という事実と、「この範囲にも同じ問題があるかもしれない」という見立てを混ぜずに伝えると、受け取った人が次の判断をしやすくなります。

よくある質問

フリーランスのQAエンジニアは、テストの実行ばかりになりますか？

実行が中心の案件もありますが、設計や計画から任される案件、受入れの支援や品質の取りまとめの案件もあります。どの工程を担うかは案件票と面談で確かめられます。実行から設計へ広げたい場合は、面談でその希望と、設計に関わった経験を伝えておくとよいでしょう。

テストの対象が変わると、仕事の進め方も変わりますか？

変わります。Webの業務システムでは仕様と業務の流れの確認が、モバイルや機器では端末と条件の組み合わせの管理が、それぞれ大きな比重を占めます。扱った対象と環境は、スキルシートに具体的に書いておくと案件を選びやすくなります。

参画して最初の1か月は何をすることが多いですか？

仕様と既存のテスト資料の読み込み、検証環境とテスト用のアカウントの準備、不具合の報告の型と流れの確認から始めるのが一般的です。初月の進め方はQAエンジニアの参画初月にやることで詳しく解説します。