ENECHANGEにて品質保証（QA：Quality Assurance）を担当している小田部です。最近はホットサンドメーカーを購入したので肉まんや大福にチーズ蒸しケーキなどを挟んで冬のホットなおやつを楽しんでます。お勧めは小さなピザにソーセージを乗せてケチャップをかけてから二つ折りにして作るホットサンドピザです！
本記事ではENECHANGEにて2020年12月現在着手中の「QAの最適化」について紹介します。まず前提としてENECHANGEのQAの役割は主に二つあります。役割の一つ目はテストの設計から実施まで、一連のQAプロセスを担当してユーザーに提供するサービスの品質に問題がない事を確認することです。もう一つの役割は開発エンジニアや他のQAメンバーと協力して、不具合の混入防止やより効率的な不具合検出などを実現できるようにQAプロセス改善のPDCAサイクルを継続的に回していくことです。今回紹介する「QAの最適化」では、QAプロセス改善のPDCAサイクルをどのように回しているかを紹介します。
QAプロセス改善のPDCAサイクルとその概要は以下になります。
Plan：普段実施しているQAプロセスを定義（可視化）しておき、開発タスクのリスクの大きさと開発内容から実施するQAプロセスのグループを選択します
Do：Planで選択したQAプロセスを実施し、実施中の気づきを記録しておきます
Check：QAメンバーで集まって毎週振り返りを行い、気付きの共有と今後の改善案を出していきます
Action：改善案の一覧から直近で実施するものを選び、各QAプロセスの実施内容や開発ルールを見直したり各種説明資料を作成したりします
QAプロセス改善のPDCAサイクルを回して「QAの最適化」を実現する上で、重視している点は以下になります。
- QAプロセスの可視化と振り返りの定着
- 不具合の種類に応じたQAプロセスの選択
- 開発体制や開発プロセスに合わせたQAプロセスの詳細設計
QAプロセスの可視化と振り返りの定着
QAの最適化を実現するには、QAチームの各メンバーが実施しているQAの内容が属人的にならないように、現状実施しているQAの内容を第三者でも把握可能にすることが重要になります。そのために要件定義からサービスリリース後の運用保守まで、プロジェクトの各フェーズにおいてどのようなQAを実施するか、各QAプロセスを定義して可視化できるようにしています。以下が各フェーズで実施するQAプロセスを定義してグループにまとめて可視化した例です。
現状は実施内容の手厚さで High/Mid/Low 3つのQAプロセスグループを用意しています。その中から以下の表を用いて各開発タスクの実装リスクおよび開発リスクの大きさ（高/中/低）からどのQAプロセスのグループを実行するかを選択します。ここで実装リスクは実装の難易度による不具合混入のリスクの大きさ、開発リスクは開発対象の機能で市場不具合が生じた場合の損害の大きさを表しています。
QAプロセスグループを選択した後は、開発内容に応じてグループ内の各QAプロセスから実際に実施が必要なQAプロセスを取捨選択し、実施するQAプロセスを確定します。確定後は開発の進捗に応じてQAプロセスを実施し、その際に出てきた改善点や良かった点をメモしておき、定例ミーティング等でQAメンバーと共有します。そこで共有した内容は次回以降のQAプロセスに反映し、将来的にはQAの最適化へとつなげていきます。
不具合の種類に応じたQAプロセスの選択
前節の「実際に実施が必要なQAプロセスを取捨選択」の説明がこちらになります。 QAの主な役割の一つに不具合の混入防止や早期検出があげられます。また不具合自体も種類が様々で、JSTQBの用語集にて不具合関連の用語の定義を調べると以下が出てきました。 （※この記事での「不具合」は以下のいずれか又はすべてを指します）
エラー（error）：間違った結果を生み出す人間の行為をいう
欠陥（defect）：作業成果物に存在する、要件または仕様を満たさない不備または欠点
故障（failure）：コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと
不正（anomaly）：ドキュメント、標準、知見、経験から逸脱するあらゆる状態
これらの用語の内、不具合と聞いて一番イメージが近いものは「故障」ではないでしょうか。また一般にテストと聞いてイメージするのは不具合の検出ではないでしょうか。
QAプロセスを実施する際はテスト以外にも不具合の種類に対応したQAプロセスが必要になります。例えば不具合に関する課題として「テスト時に重大あるいは多数の不具合が検出されて大きな手戻りが発生する」「テストケースに抜け漏れがあって不具合が市場に流出する」等はよく見聞きするかと思います。これらの課題を解決するにはテストの実施だけでは不十分で、エラーや欠陥の時点で混入予防や早期検出が必要になります。その為にENECHANGEのQAでは開発内容に応じて課題を抽出し、それらを解決できるようにQAプロセスグループから必要なQAプロセスを選択し、逆に不要なQAプロセスがあればグループから外します。
エラーへの対策：開発およびQAの作業範囲や内容に抜け漏れ認識齟齬が無いか、擦り合わせを行う。要件や仕様を確認するとともに、開発の各プロセスに対してもどのようなQAが必要か考える。
欠陥への対策：例えばデータベースの修正などで、対象のデータがすべて修正されているか確認を行う。またその際仕様によっては修正箇所が複数存在するので個別に調査しながら修正箇所の確認を行い、それらの調査結果をテスト設計に反映させる。
故障への対策：テスト環境で実際に操作できるようになった段階でテストケースを実施する。また事前のQAプロセスにて要件や仕様の理解不足や認識齟齬を減らし、それに合わせてテスト設計の内容を見直し冗長な部分や抜け漏れが出ないようにテストケースを作成することで、故障した箇所がないか効率的にテストで確認できるようにする。
不正への対策：仕様変更による既存の仕様への影響や、実際に動かしてみないとわからない挙動などを確認する。例えばメニューの項目を一つ増やすにしても、項目名やメニューの並びに違和感がないか、一連の操作の流れや分岐に不自然さがないか、等を探索的テストを実施して確認する。
このように、故障になる前のエラーや欠陥の時点で混入防止や検出を実施する。全QAプロセスにおいてテスト設計を見直す。手戻りの発生や不具合の市場流出のリスクを効率よく最小化する。等々、不具合の種類に応じたQAプロセスを選択することで、QAの最適化へとつなげていきます。
開発体制や開発プロセスに合わせたQAプロセスの詳細設計
前節では不具合の種類とQAプロセスの関係について説明しました。ただこれだけではQAプロセスの詳細を設計するには情報が不足しています。次に必要になるのが開発体制や開発プロセス及び作業内容の情報です。
開発メンバーに各開発プロセスの作業内容をヒアリングし、ヒアリング結果から各開発プロセスで発生し得るエラーや混入し得る欠陥などを推測します。それらの推測結果を元にどのようなQAプロセスなら不具合を防止および検出できるか考えて詳細まで設計します。以下は電気料金の計算に使用されるパラメータを更新する際の詳細設計例です。
その他の工夫点としては、予想した不具合の予防コストや検出コストが最小となるようにQAプロセスを詳細設計しています。ただし設計したQAプロセスを実施する際にも認識齟齬や記入漏れ等の不具合が混入することを予想し、ダブルチェックなどある程度冗長なQAプロセスにもしています。
まとめと今後の課題
以上、要約すると開発タスクに応じて発生し得る様々な不具合を推定し、それらを効率的に予防または検出できるようにQAプロセスの最適化を進めています。
今後の課題としてはQAプロセスの最適化のみだと場合によっては部分最適になってしまい、プロジェクト全体としては非効率になってしまう場合もあります。そこでQAプロセスの最適化を安定的に進められるようになったら、その次は開発プロセスも含めたプロジェクト全体の最適化へと着手していきたいです。