こんにちは。エンジニアリンググループ QA チームの窪田です。以前、中村の記事や福林の記事で紹介させていただいた、Docpedia チームで QA エンジニア*1 をやっています。 QA エンジニアという職種は所属する組織によって活動内容にバリエーションが有り、会社の外からだとどんな活動をしているかあまり知る機会がないと思います。本記事では、QA 活動の簡単な紹介と、Docpedia の QA エンジニアをやっていて品質計画をきちんと作成することの大切さを改めて感じたので、エムスリーの品質計画についての説明をしたいと思います。
Docpedia での品質保証活動概要
現在、 Docpedia では QA エンジニアも開発チームに入り活動しています。テスト・レビューなど、品質確保のために必要な活動としては以下のものが挙げられます。
- 仕様レビュー
- テスト計画 / レビュー
- 開発・ユニットテスト
- 統合テスト
- システムテスト (E2E テスト)
- 不良分析
- リリース確認
上記の中で QA エンジニアが率先して実施しているのは以下となります。
- 仕様レビュー
- テスト計画 / レビュー
- システムテスト (E2E テスト)
- 不良分析
仕様レビューへの参加は、 「仕様への理解を高めてより効果的なテストを実施する」といった目的と、早めに仕様を見ることによる「仕様不備の刈取り」が目的となっております。特に後者はテストのタイミングで抽出したときの「手戻り工数が大きい*2」といったリスクを防ぐことができるのではと考えています。
システムテストは、本番環境とほぼ同等である検証環境を用いてテストを実施します。ユニットテストと統合テストについてはエンジニアで実施し、それ以降のシステムテストを QA エンジニアが主に実施しています。システムテストが終わると機能が本番にリリースされるため、サービスに支障をきたすような不良を残さないようにテストする必要があります。そのために事前準備とバグの管理が重要となります。事前準備については後で詳述いたします。
不良分析は過去に福林の記事で紹介しています。現在は不具合分析結果をWiki(Confluence) にまとめて横展開の実施にも取り組んでいます。
テストについて
さて、本題のテストの実施についてです。軽微な修正以外の案件では、以下の流れでテストを実施しています。
- 品質計画の作成
- テストケースの作成
- テスト実施
- テスト結果分析
テストを無作為に実施すると不良を見逃してしまう場合が多いため、前述の通り事前準備が重要になります。本記事では品質計画の作成方法と気をつけていることをまとめていきます。
品質計画とは
品質計画とはどのような活動を通じて品質を確保するかの計画です*3。数年前までエムスリーでは、テスト計画をドキュメント化せずにテストを実施していました。うまくいく部分もありましたが、以下の点が問題となっていました。
- 何をテストするかは担当 QA エンジニアの判断のみとなる
- 何をテストするかを考える標準的かつ、明示的なプロセスがない
- 何をテストするかステークホルダーと合意したエビデンスが残らない
これらの点を解消して以下を達成することを目指し、品質計画書を導入しました。
- 品質計画書のテンプレートを用意し、プロセスを標準化する
- 何を品質保証するかを明示する
- どのような方法で品質保証するかを明示する
- リスクベースでテスト計画し、適切なリソース配分をする
- QA エンジニア以外の視点もテストの内容に取り込める仕組みとする
品質計画書を導入した現在では、以上の多くが達成できており品質計画導入の効果が出ていると考えます。Docpedia の QA 活動をする際に実施した内容をふまえて、上記狙いがどのように達成されているかを説明していきます。
品質計画の作成
エムスリー QA チームの中では前述の通り品質計画書テンプレートを用意し、品質計画を担当 QA エンジニアが各々作成できるようにしました。このテンプレートはチームごとにシステムの特性や案件の特性を加味して必要な項目を追記して作成しても良いものとなります。私の場合以下の項目を整理しています*4。
- 背景
- 機能作成の経緯
- 機能とシステムの特徴
- 受入条件
- リスク
- テスト計画・概要
- 確認する環境
- 確認対象機能
- 対象ユーザ
- 機能確認観点
- 非機能確認観点
- リスク観点
- ワークフロー（プロジェクト全体でやらないといけないことを時系列に並べる）
背景 (機能作成の経緯)
本当に何が作りたいのか、求められているのかを知らないとテストを通じて品質確保をすることはできないと考えています。背景を知らずに仕様書通りの動作確認をテストとして実施していたとしても、「起案者が意図した実装」になっているとは限りません*5。そのため背景を知る必要があり、自分の言葉で背景を品質計画書に落とせているというのは結構重要な気がします。初期から仕様レビューに参加するのは背景を知る上で非常に重要であるため、積極的に参加したいなと私が考える所以です。
背景 (機能とシステムの特徴)
また、開発の経緯と同様にシステム自体の特徴も掴んでいる必要があります。どういった仕組みで動いているかを知っていると確認しないといけないポイントを多く洗い出すことができます。これも仕様書をみたり、開発者や QA 活動経験者にヒアリングしてシステムの特徴と暗黙知を理解していきます。これら開発の経緯とシステム特徴を掴んでおくことにより、どこまでテストをすればよいかや、逆にテストをどこまでしなくてよいかを判断できます。
受入条件
どの状態になったらテスト終了にするかを定義します。受入条件を満たせばリリースできますし、満たしていなかったらリリースを止める必要もあります。また、受入条件はビジネス判断も伴ってくるため、変化する場合もあります*6。
具体的にどんなことを受入条件にしているかというと以下のものが例として挙げられ、機能要件、非機能要件を含みます。
- 機能要件が満たされていること
- 要件＝仕様書である場合が多いです
- レスポンスが n 秒以内となっていること
- ユーザビリティが良いこと
- 現行運用と同等の作業効率となることなど
受入条件は案件の特徴を踏まえて列挙する必要があります。性能が重要となるものであれば性能テスト結果が受入条件になりますし、大勢が同時に扱うワークフロー的なシステムだと、排他時の使用性を受け入れ条件にする場合もあります。 また、受入条件を QA エンジニアで勝手に決めて勝手に門番をやるのは、「何のテストを実施するのか」が各ステークホルダーに伝わらないですし、リリース目前に受入条件で揉めること*7もあるため、必ずステークホルダー間で合意を取ります。決めた受入条件を開発・QA のゴールに設定するイメージです。
リスク
リスクは背景に紐付くものだと考えています。開発の経緯やシステムの特徴を掴んでいると案件の成果物を世に出したときに発生するシステムリスクを洗い出しやすくなります。例えば、記事を複数人で作成・編集できるような機能を追加した場合、同一記事を複数人で操作をすると自分の編集が他人の編集で上書きされたり、ロックの仕組みがあった場合には予期しないエラーでロック状態が解除されず記事が編集できなくなるなどです。このようにその開発で起きうる状態を列挙してリスクの大きさを評価します。すると以下のような表ができます。
| # | リスク | 重要度 |
|---|---|---|
| 1 | 他人の作業が衝突して記事が上書きされる | 高 |
| 2 | エラーにより記事の排他ロックが掛かったままとなり記事が編集できない | 高 |
| 3 | 画面のリニューアルにより操作性が損なわれる | 中 |
| ... | ... | ... |
表中のリスクを参考にテスト計画でリスク対策を検討します。低リスクのものは優先度を下げるといった判断もありますし、高リスクなものについてはテストを手厚くするなどの対策を取ることもできます。もちろんテスト以外の対策も取ることも可能です。
テスト計画・概要
背景、リスク、受入条件を踏まえた上で実施するテストについて考えることができます。この部分では何を対象にどんな観点でテストをすることを計画します。上述したとおり以下のポイントを考慮します。もちろん以下以外に必要なものがあれば追加しています。
| 概要 | 説明 |
|---|---|
| 確認する環境 | PC / スマートフォンのハードウェア、OS の種類、ブラウザやアプリの種類 |
| 確認対象機能 | 今回開発となる機能とリグレッション確認が必要な機能の洗い出し |
| 対象ユーザ | どんなユーザが使うのかを規定。エンドユーザの種類や社内の画面だとユーザのロール（作業者・承認者など） |
| 機能確認観点 | どのシステムでも使用する共通的な観点と、確認する仕様のポイントを細かくなりすぎないように記載（後述） |
| 非機能確認観点 | 品質特性*8を元に観点を洗い出したもの |
| リスク観点 | リスク洗い出しで列挙した各リスクに対するテストや対策方針を記載 |
機能確認観点、非機能観点、リスク観点については細かくなりすぎないように注意しています。 なぜかと言うとテスト計画は案件に変更がある度に更新が入るため、細かく書きすぎるとメンテナンスが辛くなるからです。また、本当に細かく記載する必要があるのはこの後のテストケースとして詳細化するタイミングです。そのため、テストデータや状態は詳細化せずに基本的な振舞いのみを記載することが多いです。例えば「作業開始画面から終了画面までのすべての操作がエラー無く実施でき、 更新内容が各画面上で入力したデータとなっているか」みたいなテストデータや詳細な操作を省いたようなものです。これを愚直に積み上げていきます。
この作業を実施するときは仕様書の読込み、関係者へのヒアリングが多くなります。その結果、仕様の問題を発見することもありテストを実施する前に早めのフィードバックを実施することも可能です。
場合にもよりますが、Docpedia チームでは仕様書が完成したタイミング*9から品質計画書を作成するため、開発と並行した作業になります。多少手戻りはあるかもしれませんが、テストで不良として摘出するよりは手戻りが少ないものと考えています。
タイムライン
タイムラインは開発全体でやらないといけないことをまとめたものです。 要件・仕様レビューから、各種テスト、社内の事務システムだと操作マニュアルの作成などを洗い出します。基本的にやることは各案件によりあまり変わらないため、特徴的なポイント（前述の操作マニュアル作成など）が漏れていないかをしっかり考える作業となります。また、このタイムラインは担当が QA エンジニアなのか開発なのか、プロダクトマネージャーなのかについても記載します。チーム全体で品質確保しているといった意識の表れですね！
品質計画レビュー
レビューはステークホルダーを交えて開発チーム全体で実施します。レビューでは計画書に書かれている内容に不備があるかを確かめてもらい、開発者特有の観点などのステークホルダー特有の観点を更にブラッシュアップできます。さらに計画書自体が案件の特徴や内容をまとめた文書となっているため、開発チームメンバーそれぞれの作業に漏れがないかを確かめて貰う機会にもなります。
レビュー完了後、品質計画に基づきテストケース作成、テストの実施を行っていきます。
最後に
品質計画を作成することはどんな開発手法をとっていても大事だと考えます。もちろん今回紹介した記載レベルで作成する必要はなく、大事なポイントが抑えることができれば良いかなと思います。重要なのは背景・要求をきちんと把握して特徴をきちんと分析することです。計画のタイミングできちんと分析することにより実施すべきテストの方針は洗い出せているため、テスト漏れを軽減することできるのではないかと考えております。テストケースの管理や実施については、今後まとめていきたいと思います。
We're hiring!
エムスリーでは品質技術に興味のある QA エンジニアを募集しています。社員とカジュアルなお話をすることもできますので、興味を持たれた方は下記よりお問い合わせください。
*1:QA とは Quality Assurance の略で直訳すると「品質保証」となります。
*2:仕様策定段階での誤り修正のコストを1とした場合、テスト段階では20となる：ソフトウェア開発201の鉄則（日経BP社）
*3:エムスリーでの品質計画書は大まかにはJSTQBシラバスのテスト計画～テスト設計部分に該当する活動となります。
*4:これらの情報は、入社して間もないタイミングに何人かの先輩 QA エンジニアに聞いて、いいなと思ったことをすべて詰め込んだものになります
*5:仕様書の曖昧さによります。暗黙知は仕様書に書かれることは少ないです。また、「仕様の読み間違いによる確認ミス」が今まで体験してきた中では多いです。
*6:スコープや要件の変更などにより。要件変更はしばしばあるので受入条件や後述のリスク、テスト計画は適宜変更されます
*7:ステークホルダーが求めている品質は各々異なっているため、リリースできると思っている人と、まだまだ品質がリリースに耐えうると判断していない人での衝突を見てきました。受入条件に達していない場合もありますが、受入条件がしっかり合意されていないことに起因する場合が多いです。
*8:https://ja.wikipedia.org/wiki/ISO/IEC_9126
*9:たまに背景と大まかな仕様がわかっているときは仕様書作成と並行して作成するときもあります。
