株式会社ヘンリーCEOの逆瀬川です。
4月から製品企画の責任者として開発ロードマップや要件開発を行っています。
特に今後、電子カルテを開発するチームでは人数も増え、これから大きな機能開発も増えていくため、これまで以上に品質向上への取り組みを強化しています。
具体的には、品質と信頼性を上げるための施策会議（品質と信頼性の会）や、不具合分析の定例会を開始しました。
本日は、品質と信頼性の会で出てきた施策のひとつである探索的テストを学び、早速実行したところ、大きな効果が出たので共有します。
弊社の品質の守護神 Aさん依存体質からの脱却！！
探索的テストに取り組むことになった背景としては、QAのAさんへの依存です。
元々医療事務出身のAさんがQAやテストを学び、チームの全てのテストを担っていました。ドメインエキスパートでもある彼女はスクリプトテストの他に、暗黙的に探索的テストを行っている状態です。
現状でもAさんのおかげで一定の品質は担保されていますが、以下のような懸念がありました。
- 開発とQAが分離しており、品質への投資がチームとして行えず、品質が上がる速度が遅いのではないか？
- テストの視点が単一であり、複数の視点で行われておらず、特に開発者やデザイナー視点で気づく内容が漏れているのではないか？
- 品質担保が属人的になっており、彼女が体調不良になってしまった場合やチームから離れたりした時のダメージが大きいではないか？
チームとしても品質への関心が高かったため、何かチームで取り組めるきっかけがあれば改善速度が上がると考え、気軽に始められる探索的テストを取り組むことにしました。
LayerX様のET会良い！Henryでも始められそう！
奇跡的に探索的テストを取組むことを決めた翌週に、Nihonbashi Test Talk #2があり発表の一つが探索的テストだったので、早速申込みます。
今日、こちらのイベントいきます！
— Akito Sakasegawa (Gyaku) (@gyakuchan) 2024年5月16日
楽しみだ！
Nihonbashi Test Talk #2 https://t.co/BNNNMRCUBp #nihonbashitesttalk
LayerX様のmatsuさん発表で早速探索的テストを学び、ヘンリーでも試せそうな感覚を持ったので早速企画することにしました。
学んだことの一部を下記に紹介します。
探索的テストの定義
- アプリケーションから得た情報を元に仮説を構築し、その検証を反復する、柔軟かつ自由度の高いソフトウェアテストの方法
- 上手な探索的テストの言語化
バグを多く見つけることが出来る人ではなく、より多くの良質な仮説を立てられる人
- 広範囲のドメイン知識を使って、より多くの仮説を立てられる
- 有限な時間の中でより優先度の高い仮説から検証出来ること
- テスト対象の性質によって様々な視点から有効なアプローチの方法が取れる
- 良質的な仮説を立てられる探索的テストの条件
- 適切な自由度を設定したチャーター
- テスト対象に効果的なツアーが設定されている
詳細は、matsuさんの登壇資料「上手な探索的テストとその上達方法について」をご参照ください。
LayerXさんがやっている、探索テストのLT会、チームのセルフQA力もあがってめちゃくちゃ良さそう。
— Akito Sakasegawa (Gyaku) (@gyakuchan) 2024年5月16日
早速取り入れたいな。#nihonbashitesttalk
探索的テストの準備
準備としてやったことは下記の通りです。
- 探索的テストの説明をNotionにまとめる
- matsuさんのスライドとAgile Testingの2章を参考にしました
- 要求仕様の説明をNotionにまとめる
- 今回テストで用いるチャーターとツアーを準備する
- 当日の探索的テスト会のファシリテーションプランを作成する
チャーターの準備として、テスト範囲・テスト方法・テストの狙いを定めました。
初回ということもあり、完璧を求めずに自分で理解できるわかりやすいフォーマットを選んで作成しています。
参考 : 「やってみよう！探索的テスト」
テスト当日
当日、オンラインでテストを実施しました。
休みだったメンバー以外は全員参加し、10名でワイワイとテストを実施しました。
実際参加したメンバーからの声
Aさん(開発者)「結論楽しい！」
Bさん(UX リサーチャー)「(機能が)良く出来てるなぁ以上出てこない」
Cさん(PdM)「成果もシェアできるしよさそうですね！！毎週のリリースごとに1時間くらいとってやってもよさそう！！」
他にも、昨日のEpic Ownerやフロント・バックエンドの開発者などが参加し、多様なメンバーが各々の観点で仮説出しとテスト実施を行いました。
結構盛り上がり、最終的に30分予定だったところを1時間に延長しています。
実際20以上の仮説が出てきて、初回にしては大成功でした。
その後、その場で出てきた不具合に対してもemojiを付けて、どれを直すかをEpic Ownerが決めていきます。今回は仕様の考慮漏れで修正したほうが良いものが多く、仕様段階での要求開発やレビューに改善の余地がありそうです。 そして、最終的には、なんと、17個の🐲がリリース前に倒されました。
リリース当日！
今回修正した画面は、「血液検査などの検査結果を確認する画面のUI改善」。
機能を公開した当初から検査結果を瞬時に把握しづらいとフィードバックをもらっていた画面で、ユーザーインタビューを重ねてリニューアルした画面になります。UIの完成度がとても重要な画面であり、探索的テストを経てブラッシュアップした結果を祈るのみ。。。
そして、社内外からポジティブな反響が！！！！
学びとこれから
良かったこと
- リリース前にチームで同期的に機能を触ることで、チームで新しい機能を出すという一体感が生まれた
- リリース前に様々な観点より仮説が出たため、スクリプトテストでは見つけられない不具合が発見された。(特にエンジニアの技術観点が追加されたことが良かった)
- 思ったより、改善出来る内容が多くリリース前にだいたいの不具合を潰すことが出来た
- 通常ならリリース後にフィードバックを受けて潰していたことが内部で潰すことが出来、効率的な開発となった！
- 探索的テスト、とても楽しい！！
改善していきたいこと
- 仕様理解に時間がかかるため、想定より時間がかかった！ので時間が足りない
- ツアーをうまく活用できなかった
- ランドマークツアーやガイドブックツアー、FedEXツアーを活用していきたい
- 専門性を生かしたツアーを提案できればよかったかもしれない
- 開発内に閉じず、実際運用提案をしている導入 / CSのメンバーにも参加してもらいたい
- 仮説に対して、不具合を見つける。仮説と不具合が紐づくレポートフォーマットに変えたい
- 当日の仕切りの改善
- 今回は各々もくもくとテストをする感じでしたが、モブテストやチャーターごとに時間を仕切るなど、ファシリテーションを改善していきたい
探索的テストはとても楽しいし、効果テキメン！！！なので、今後も継続的に行っていきたいと思います！(次回は今週実施予定！)
一方で、品質担保が属人手的である点については、今回の取組では解消されません。ただQA以外のメンバーがテストに参加したことで、品質への取り組みに実際貢献できるという実感を感じたことはとてもポジティブでした。チーム全体での品質への優先度が上がり、開発者のE2Eテストの実装や、リグレッションテストのシナリオ作成等の取組みが行われてきております。今後もこのような活動を継続的に取り組むことで属人化から解放されることが期待できるではないかと考えております。
最後に、採用中です！
ヘンリーではQA含め、各種エンジニア職を積極的に採用しています。Henry が扱っている医療ドメインは複雑ですが、社会的にもやりがいがある領域だと思っています。また、基幹システムであることと医療の業務の特異性から、求められるQAの基準は大変高く、プロダクトだけではなくプロダクトを利用したワークフローやオペレーションレベルで高い品質の実現が求められます。ぜひ、品質の高いプロダクトを提供して、社会的に価値を出していきたいという方、カジュアル面談で弊社のVPoEとお話しましょう！！
