はじめに
未経験でIT企業に就職して早３ヶ月半が経ちました。
今回はQAエンジニアについて学習しましたので、
アウトプットも兼ねて記事にしたいと思います。
使用した教材
QAエンジニアとは
一言で言うなら ソフトウェアやシステムの品質を確保する役割 を持ちます。
QAは Quality Assurance の略称で「品質保証」という意味なので
ほぼ直訳です(^_^;)
この業界に入るまで、QAエンジニアという存在は知らず、、今回の学習で初めて知りました。
主な業務内容
・テスト全般（実施・設計・計画）
・テスト中に発生した不具合の報告・修正確認
・不具合の検証・原因調査
・テスト結果報告
テスト関連の作業が主な業務であり、
報告された不具合の確認や問題の根本原因を突き止める作業も担当する。
今までテストの実施や不具合の報告・修正確認はしたことがあります。
色々なパターンを試したときは思いの外時間がかかりました。
テスト実施に関わる人たち
| 職種 | 役割 | 内容 |
|---|---|---|
| プロダクトマネージャー | 作成する機能の決定 | 仕様の策定や外部との調整 |
| エンジニア | 案件の開発 | 主にプログラミング全般 |
| QAエンジニア | テスト・品質の向上、維持 | 主にテスト全般 |
QAエンジニアがいると、エンジニアの方は開発に集中して取り組めそうだなと思いました。
他の職種の人たちとの関わり方も重要。
テストの流れ
| 項目 | 内容 |
|---|---|
| 要件の調査 | 何をどこまでテストするか、期限はいつまでかなどの調査 |
| テスト計画 | 大まかなテストケースの件数見積もり、期間、要員を概算 |
| テストケース | テスト計画に基づいて作成 |
| テスト実行 | 作成したテストケースを実行 |
| バグ検知・報告 | テスト中に想定外の動作が起きた場合、バグとして報告 |
| 修正 | バグ修正が完了した場合、再度テストを実行し修正されたことを確認 |
| テスト結果報告 | テスト結果を報告 |
☁️補足 テストの種類
・フルリグレッションテスト
→ソフトウェアの全機能を対象に行う回帰テスト
大規模な機能追加や変更後、リリース前に実施する
・リグレッションテスト
→システムに新しい機能を追加したり、バグ修正や変更を加えたりした際に、
既存の機能に悪影響を及ぼしていないか確認するテスト
テストの一連の流れがあるため経験を積めば要件の調査〜テスト結果報告までの
時間を短縮出来そうな気がします。
バグ検知・報告について
QAエンジニアは、バグ報告・修正確認・対応完了 を担当する
バグの修正作業などはエンジニアが担当
バグが検知された場合、エンジニアに対してどのようにわかりやすく伝えるか
伝え方が大切だなと思います。
主なバグ報告の内容
| 種類 | 内容 |
|---|---|
| タイトル | バグの概要を要点を押さえたタイトルを記載 |
| 前提条件 | テスト仕様書通りに記載 |
| 再現手順 | バグを再現するための具体的な手順を詳細に記述 |
| 期待動作 | バグの影響範囲の度合いを記載 |
| 影響範囲 | 何回か試し、再現率を計算し記載 |
| デバイス | バグが発生した環境を詳細に記述 |
| サービスのバージョン | バグが発生した環境を詳細に記述 |
| 優先度・深刻度 | バグの優先度や深刻度を指定する |
| スクショ | バグが発生した時のスクショを添付 |
| 再現手順を録画した動画 | バグが発生する流れを録画し添付 |
⚠️バグ報告で気を付けなければならない点
①誰が再現をしても確認できるような報告内容にする
②バグの対応を見送るか判断できる報告内容にする
全てのバグは修正しなければならないと思っていましたが、
優先度・重要度によっては「バグを見送る」という選択肢があることを初めて知りました。
理想的な進捗報告について
・現在取り組んでいるテストの内容は何か
・テストの進行状況はどの程度か
・テスト完了の予測時期はいつか
・発見されたバグの件数はどれくらいか
・テストを進める中で何か障害や問題が発生していないか
・次に予定している作業内容は何か
これらの内容を含めることで、報告を受けた人が多忙な場合でも
一度の進捗報告でおおよその概要や問題点が１度で把握することが出来る。
ここでも文章力が問われますね。進捗報告はしたことがないのですが、
する際はこれらの項目を意識します。
テスト設計について
☁️前提知識 ３つのテストレベル
①単体テスト
→機能の最小単位ごとに行うテスト
一般的に開発したエンジニアが担当
②結合テスト
→機能間の結合や画面間の結合のテスト
単体テストが完了したもの同士を組み合わせ、不具合が出ないか確認する
QAが担当
③総合テスト
→出来上がったシステムを可能な限り運用想定で確認するテスト
QAが担当
☁️テスト技法
①ホワイトボックステスト
→プログラムの内部の動作が正しく行われているかを確認するテスト
主に単体テストで用いられる
②ブラックボックステスト
→あくまで仕様書に基づいて、ユーザーに見える部分を網羅するテスト技法
主に結合テストで用いられる
③同値クラステスト
→テストケースを減らすための技法
テスト対象の入力データをいくつかの「同値クラス」に分類し、
それぞれのクラスから代表的な値を選んでテストを行う手法です。
バグを見逃してしまう可能性が高い
④境界値テスト
→同値クラステストと同様、テストケースを減らす技法
処理が切り替わる部分とその前後をテスト
この辺りは、２ヶ月くらい前に勉強したITパスポートで学んでいました✏️
テストケースは減らせるなら減らしたいですよね〜
テスト設計の流れ
1.テスト対象への理解
↓
2.テスト観点の洗い出し
↓
3.テストケース作成
1.テスト対象への理解
💡一般的にテスト設計するときに機能の説明をした仕様書があり、
この仕様書からテストに必要な情報を取得する必要がある
💡仕様書に記載されていない情報を明らかにしておく
（Excel等で一覧化しておくと良い）
💡不足している情報を見つけたらプランナーに確認をする
2.テスト観点の洗い出し
💡テスト観点を作成せずにいきなりテストケースを作成すると、
「テストケースが抜け漏れなく設計されているか確認できない」
「全体が見えないため、いつまでに完了するかわからない」などという問題が発生するため
テスト観点の作成は必須
💡まず機能一覧を作り、出来上がったらそれぞれの正常系・異常系を記載して完成させる
正常系・・普通に動くことを確認する
異常系・・意図的に不正な操作を行い、エラーが発生するかを確認する
3.テストケース作成
| 内容 | 概要 |
|---|---|
| テストの準備 | テストを実施するために作っておかなければならない状態 |
| 試験の手順 | 操作する手順を１つずつ記載したもの |
| 期待動作 | 試験手順を実行した結果、テスト対象がどのような動作をするか想定 |
| 結果 | 期待する結果の場合はOK、そうでない場合はNG |
⚠️「試験手順」は誰がやっても同じ操作になるように記載する
⚠️「期待動作」は誰が見ても同じ結果を想像できるように記載する
誰がいつどうやっても同じ結果になるテストケースを作成することが大事
テストケースを設計したことはありませんが、実際にテストを実施していた時に
色々なパターンを試し、テストケースを考えるのは大変そうだなと思っていました。
QAエンジニアは準備が８割と記載されていましたが、まさにその通りだなと、、。
まとめ
・QAエンジニアは準備が大切
・しっかり仕様書を理解する読解力や、不明点があればプランナーやエンジニアに相談する
コミュニケーション能力なども必要
・テストの結果次第でリリースの可否が決まるため、テストだからといって油断しない