「QAって何をする人？」～上流工程におけるQAの役割とその重要性～

【QAチームブログリレー6日目】こんにちは。エンジニアリンググループクオリティアシュアランス(QA)チームの今井(@tak-imai-m3)です。新年度が始まってから3か月が終わり、各社新人研修も終わった頃かと思いますが、QAについての研修はありましたでしょうか？ QAはプロダクトマネージャーやエンジニアなど様々な方々と仕事をしていますが、具体的な業務内容のイメージが湧かないという声を聴くことがあります。自分も同様の質問を先日いただきました。

今回はその時に回答した内容も交えて、普段QAがどのような業務をしているのか、また各フェーズにおいてどのような思考で業務をしているのかをご紹介できればと思います。特に下流工程でのQA業務がイメージされ易いことは承知しておりますが、上流工程におけるQA業務とその重要性についてもご紹介できればと思います。

上流工程でのQA業務
下流工程でのQA業務
その他
- アジャイル開発におけるテスト
- テスト自動化
まとめ
- We're hiring!

上流工程でのQA業務

一般的な開発工程として、「V字モデル」や「W字モデル」などがあります。「W字モデル」の一般的な図は下記のようなものですね。このモデルでは、左側のフェーズが主に上流工程、右側のフェーズが下流工程となっております。件題の「QAって何をする人？」って問いに対して、こちらのモデルを参考にまずは上流工程でのQA業務について解説します。

「要求分析」に対する「要求テスト」

自分が担当しているサービスのチームでは、月に十数本のプロジェクトが企画されています。プロジェクトを企画されるのはプロダクトマネージャーさんで、経営会議に承認を貰う前にデザイナーさん、エンジニアさん、そして我々QAに対して、プロジェクトの概要説明と承認後の開発にどれだけの工数を要するのかを確認する場が設けられます。ここでQAが担っている役割とは？

想定されるリスクや懸念点を予想できないか
弊社のガイドラインなどに沿った形でプロジェクトが企画されているか。もしくは、新規のガイドラインを規定する必要があるか
プロジェクト開発の規模感を概算し、QA業務に要する工数はどのくらいか

リスクや懸念点に関しては、主に下記のようなものを想定しています。

法務部門などへ事前に確認しておくべき法的なリスク
企画を悪用されることで損害が発生するリスク
既に展開中の他プロジェクトに対して与える悪影響
ユーザ体験に影響を与える企画の場合、想定されるマイナスの影響リスク

「システム仕様」に対する「仕様テスト」

プロジェクトが経営会議で承認を貰いますと、次にプロダクトマネージャーさんがシステム仕様を作成されます。ここでQAが担っている役割とは？

どのようなパラメータが記載されているか
条件や状態によって、どのような期待値が設定されているか
仕様に記載されていない行間を読み、考慮不足の条件や状態、パラメータなどがないか

「システム設計」に対する「テスト設計」

ここまでは、QAとして成果物と呼べるものは発生していません。エンジニアさんがシステム設計のフェーズに入りますと、QAは「テスト設計」として「品質計画書」の作成に着手します。「品質計画書」には主に下記の内容を記載しています。

機能テストでの受け入れ条件とテスト対象、テスト観点の設定
シナリオテストや非機能テストの要否
リグレッションテストの範囲指定
発生しそうな障害から導いたテストの検討
本番環境へのリリース前、リリース後での確認事項の整理

下流工程でのQA業務

エンジニアさんたちのコーディング、コードレビューが完了しますと、いわゆる下流工程としてのQA業務が始まります。上流工程では、いかに事前にバグの作り込みを防ぐかを重点に活動していましたが、下流工程では、いかに作りこまれてしまったバグを見つけ出すかが重要になってきます。

テストケース作成

テストケース作成では、プロダクトマネージャーさんが作成された「システム仕様」、エンジニアさんがコーディングの際に作成された設計書、そして、我々QAが上流工程で作成した「品質計画書」をベースにして作成をしていきます。ここで意識していることは、「テストケースでどれだけ網羅性を高めることができるか」です。よく「バグは想定（テストケース）の範囲外で多く検出される」と言いますが、裏を返せば「どれだけ事前に想定する範囲を広げられるか」だと考えています。

テスト実行

とはいえ、QA業務の性質上、開発後半での作業となるため、リリースまでの期日やQA業務に従事するリソースによって、すべてのテストが実施できない事態も想定されます。我々のチームでは、プロダクトの性質上リリースまでの期日は結構柔軟に対応できるのもあり、作成したテストケースのほとんどを確認してからリリースが可能となりますが、時には「どれを確認するか」「どのテスト対象を除外したら、プロダクトに影響はないか」などを考えます。

不具合報告

テスト実行をしてる際に、多種多様な「欠陥」が検出されます。 ISTQBでは、「欠陥」は以下の4つに分類され、定義されています。

エラー（誤り）：間違った結果を生み出す人間の行為
フォールト（fault）：要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備
故障（failure）：コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと
インシデント：実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象

我々QAが検出する欠陥としては「インシデント」が多く、日本では「不具合」や「障害」と呼ばれており、これを報告することを「不具合報告（インシデントレポート）」としています。不具合報告で心掛けていることとしては、「不具合を検出し、報告すること」が目的ではなく「不具合が改修されること」なので、報告の際には改修されるエンジニアさんに分かりやすく、必要な情報の提供が重要になってきます。自分が意識していることは下記の点です。

タイトルを見ただけで、不具合の概要が把握できるか
不具合を再現するのに必要な情報が記載されているか
逆に不具合を再現するのに不要な情報は極力排除しているか
「体言止め」と「箇条書き」など、記載がブレブレになっていないか

テスト結果報告

全てのテスト実行や不具合の改修確認が完了したら、テスト結果を関係者に報告します。現場によっては、「テスト終了報告書」を作成するところもあったりしますが、我々のチームでは、下記の実施をもってテスト結果報告としています。

テスト結果が入力されたテストケース
テスト結果として、強調して残しておくべきエビデンス（実際の挙動や出力結果、ログなど）
検出した不具合の状況報告（主には改修確認が完了しているか）
BTSチケットで、上記に関するレポートとチケットステータスの更新

リリース後

本番環境にリリース後は、変更箇所を中心に最終確認をします。何か大きな問題が発覚した時には、緊急の対応をすることになります。発覚まで時間を要してしまうと、それだけ損失が大きくなるので、リリース後から短期間での発覚が重要になってきます。

その他

アジャイル開発におけるテスト

エムスリーでは、リリース頻度が比較的高く、短期間での品質確保が要求されます。そのようなアジャイル（的）開発の現場では、先述に説明した下流工程のQA業務をするのではなく、アジャイルテストと言われるテストケースに沿った形でのテスト実行ではない手法を用いることがあります。例えば「探索的テスト」というテスト手法があります。*1 事前に固定的にテストケースを作成せずに、プロダクトの振る舞いを見ながら柔軟にテストの内容を作成、調整していく方式です。重要な箇所やQA担当者が不審に感じた箇所を集中的にテストすることができるため、欠陥を発見する効率も良いとされています。そのため、プロダクトに対する知識や過去に発生した欠陥を考慮したことによる経験などが必要となることが多いのですが、知識量や経験値に関係なく、欠陥を見つけるセンスに長けているメンバーの方もおり、そういったセンスがある方は羨ましいと思うことがあります。

テスト自動化

テストケース作成の範囲外となるテストとして、エムスリーではリグレッションテスト（標準テスト）を適切なタイミングで実施しています。近年（とは言っても自分が入社した10年前からエムスリーでは推進していますが）、定期的に実施されるリグレッションテストに対して、手動で実施するのではなく、自動テストを実施しています。エムスリーでは、seleniumやmablなどのツールを駆使して、テスト自動化の実現を目指しています。

まとめ

よくQA業務は下流工程で紹介した作業が注目されがちですし、その作業自体はQA業務の主流であることは間違いないのですが、上流工程で紹介した作業などは、事前に不具合の作り込みを防いだりなどの効果があり、こちらも重要な作業であります。今回ブログの中で紹介した内容を含めて、エムスリーのQAでは様々な活動をしております。結果、まだまだ道半ばではありますが、良い感じの品質保証活動が達成できていると実感しております。