こんにちはエンジニアリンググループの森内です。私はエムスリーデジカルというクラウド型電子カルテチームでQA（品質保証）を担当しております。本ブログでは、今期に実施したスモークテスト*1の改修で得た知見をお話します。今回の改善の効果は将来のリリースの度に授かることができるので、少しでも参考になれば幸いです。
また以前デジカルQAでの取り組みをご紹介するブログも執筆してますので、エムスリーのQA活動やデジカルというサービスにご興味ございましたら併せてご参照下さいませ。 www.m3tech.blog
改善に至るまでの背景
スモークテスト
デジカルチームでは1ヵ月に一度リリースが行われ、その直前に開発環境でスモークテストを行っています。チーム内でのスモークテストの目的は『リリース直前のスプリントタスクに対して、メインサービスがリリースを許容できるレベルで動作することを確認すること』です。スプリント内で様々な新機能が開発されそれらに対して個別に機能テストを実施してますが、スモークテストではそれら新機能が同じブランチにマージされた状態で既存機能にデグレード（正常に動いていたものが新たなコーディングによって起こる不整合・不具合）が発生していないかを検証するために行っています。
抱えていた問題点
既存のスモークテストは大きな3つの問題を抱えていました。
- 目的が明確でない
- 実施範囲に根拠がない
- 実施に時間がかかる
私は2019年9月にチームにアサインされたのですがその時点では既に作成者が離職しており、「何を担保するために（目的）この機能を（範囲）テストしているのか」を誰も理解していない状態でした。そのため時間の経過とともにケース数が徐々に増えていき、効果の曖昧なテストを時間をかけてやり続ける習慣ができてしまいました。
具体的な改善活動
目的の明確化
まず、何のためにスモークテストを行うのかを明確にしました。その結論が先ほど述べた『リリース直前のスプリントタスクに対して、メインサービスがリリースを許容できるレベルで動作することを確認すること』です。ここでのリリースを許容できるレベルとは、万が一止まってしまった場合の影響が大きい機能を確実に担保するなどが挙げられます。
実施範囲の基準を設ける
次にデジカルの機能を洗い出し、スモークテストでどこまで検証するのかの基準を決めました。今回の改善でこの作業を一番慎重に行いました。しっかり品質を担保しつつ実施の工数を削減するという範囲とコストのトレードオフの中で両方を達成することが今回の改善の目標だったからです。具体的には3つの基準で機能を精査しました。
- ビジネス的要求が大きいところ＝万が一止まった場合のインパクトが大きいところ
- 過去に本番バグが出てしまったところ
- 開発陣が影響範囲として見落としがちなところ
特にテストしなくても良い理由は判断が分かれてしまうので、基準を設けることは重要だとやっていて感じました。
テスト方針の策定
ビジネス要求の大きい機能は既にチームでまとめられていたので、それを用いていくつかのペルソナを設定しシナリオをつくることでその周辺の機能を含めた優先度の判断を行いました。例えば診察に来た患者さんをペルソナにした場合、(1)受付(2)診察画面で症状を記録し薬を処方(3)処置や薬に応じて会計(4)次回の予約といった具合に関連する機能を導き出しました。また同じロジックを使い回している箇所は開発陣に確認した上で、代表的な数ケースのみ確認することで品質を下げることなくコストを削減できました。作業面では機能の一覧と実施範囲のビフォーアフターは表にまとめて他のQAメンバーや一部開発陣にレビューを貰いつつ作成しました。
テストケース作成
こちらは普段のテスト活動と変わりませんが、今後修正を入れやすいように先程の一覧表を基に機能ベースでテストケースを整理したり、誰が実施しても同じ内容になるように手順と期待値を明確にしQAメンバー同士でレビューをしました。
改善によるメリット
- 実施コストが削減できた
- スムーズに実施できるようになった
- 誰でも同じテスト内容を再現できるようになり分担しやすくなった（脱属人化）
コスト面では、400近くのテストケースを5~6時間かけて実施していたのが、改善後のケース数は160にまとまり実施時間も約半分の3時間ほどまで短縮できました。テストケースの書き方にこだわったのもコスト短縮の要因で、実施がスムーズになったり分担がやりやすくなったとの声もありました。品質面の評価はしばらく運用してみないと分かりませんが、現状バグを見過ごしてして本番に流出していないので一安心です。
まとめ
スモークテストの改善はこれで終わりではなく継続した改善も必要です。ひとつはこれから新たに増えていく機能に対しても必要に応じてスモークテストに加えなければなりません。そして、実施範囲を選定している過程で自動テストに向いている項目がいくつかあったのでそれらを自動化することで更なる品質と工数の最適化が図れそうです。またもし将来的に毎日リリースなどスプリントそのものが超高速化した場合などは今回のスモークテストも作り直しが必要になると思われます。しかし、今回の活動で得られた目的や基準はそのまま使えると思うのでブラッシュアップしつつ残したいです。
We're hiring!
エムスリーではQAエンジニアの採用活動にも力を入れております。 私はエムスリーに入社する前からQAエンジニアとして様々なチームに参画してきましたが、エムスリーは開発者の品質意識が非常に高く、バグの作りこみを事前に防ぐ文化が強く根付いています。 開発者とQAエンジニアが二人三脚でプロダクトを良くするためには、QA側のパワーアップが必要です。 カジュアル面談も受付ておりますので、興味を持たれた方は下記よりお問い合わせください。
*1:本ブログでは、JSTQBに則り『プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視するテスト』をスモークテストとさせていただきます。
