はじめに
この記事は、「KNOWLEDGE WORK Blog Sprint」第9日目の記事になります。
ナレッジワークのQAエンジニアの Tommy です。
今回はQAエンジニアのAsk Devinの活用についてご紹介し、皆様の業務で役立つ内容となることを目指しています。
まず初めにAsk Devinを活用するに至っての背景として、QAエンジニアとして業務を進める上で「仕様理解」に課題を感じていました。
QAエンジニアの多くがそうであるように、私自身もまずは振る舞いベースで機能を理解を行っています。もちろんユーザー視点での振る舞いを理解するだけでもテスト設計は可能ですが、機能が複雑になり、因子や水準が増えてくると理解のハードルは一気に上がります。
ドキュメント（ProductRequirementsDocumentやDesignDoc）が整備されている場合でも、常に最新の状態とは限らず、担当交代やオンボーディング時には特に「どこまで正しい情報なのか」「自分の理解は正しいのか」と迷うことが少なくありません。その結果、細かい点は開発者に確認することになり、双方に負担がかかるケースが多くあります。
このように「仕様を正しく理解する」こと自体に課題を抱えておりました。
本記事では実際のQAエンジニアの業務での活用事例をご紹介します。
Ask Devinとは
Ask Devinの画面
Ask Devin(旧：Devin Search) は、リポジトリを対象に対話型で質問や調査をできるツールです。詳細は公式ドキュメントからご覧いただけます。
自然言語で質問することで、リポジトリに関する情報を引き出したり整理したりできます。
QAエンジニア視点での活用ポイントは以下の通りです。
- 複雑な仕様を「解説」してくれる
自然言語で質問するだけで、機能の振る舞いや内部処理を分かりやすく解説してくれます。コードが苦手なQAエンジニアでも、仕様の核心を掴むことができます。
- 仕様を「可視化」ができる
文章だけでは理解しにくい処理の流れを、シーケンス図やフローチャートで自動生成します。これにより、直感的な仕様理解が可能になります。
- リポジトリ視点のテスト観点を引き出す「情報提供者」となる
リポジトリの情報に基づき、テスト観点のリストアップや発生しそうなバグの洗い出しを支援してくれます。これにより、リポジトリの視点の情報でセルフレビューができます。
活用事例
事例①：仕様のキャッチアップ
課題
自分が開発当初は担当していない機能のQAを担当になったとき、ProductRequirementsDocumentやDesignDocは存在していても「機能開発当初のスナップショット」であり、細かな仕様変更が反映されていないことがあります。また、機能の振る舞いは変わらず内部処理の変更をした場合、その対象となる処理のrpc名を確認しただけではどんな処理が行われているか理解ができないことがあります。結果として、ドキュメントを読み込むだけでは最新仕様を理解しきれず、開発者への確認が頻発し非効率になりがちです。
Ask Devinの活用方法
まずは質問の対象となる機能について質問を行い、全体像を図付きで回答を依頼します。全体像を把握ができたら、その上で、知りたい処理に絞って詳細を図解で説明してもらう、という流れでキャッチアップします。
効果
- 図があるため理解がスムーズになる
- ユーザーの振る舞いと内部処理をリンクして把握できる
- 開発者に質問する前に自分の理解を深められる
プロンプト例
仕様を確認するとき
〇〇〇の△△△機能について調べてください。調査結果についてQAエンジニアでも理解がしやすいように解説してください。必ず図を使用して解説してください
仕様の詳細を確認するとき
{rpc名}でどのようなデータを使用して、どのようなロジックでナレッジが検索されるか詳しく教えてください。図も用いて説明してください
回答結果
参考：フローチャート
事例②：オンボーディング時の仕様理解を効率化
課題
オンボーディングを担当するとき、新しいQA担当者に既存機能を説明する必要があります。しかしドキュメントには図がないことが多く、図をゼロから作成するのは大きな負担になります。
Ask Devinの活用方法
Ask Devin に既存機能を図解つきで説明させ、そのアウトプットを使いながらUI操作のデモを行います。さらにQA視点の補足を加えることで、新しいQA担当者は図と実際の操作を対応付けながら効率よく理解できます。
効果
- 図作成の手間を削減できる
- 新しい担当者が「UI操作 ↔ 仕様」のつながりを早期に把握できる
- レクチャーする側・受ける側の双方にとって効率的である
プロンプト例
/[サービス名]/[機能名]/[設定項目]に〇〇〇管理機能があります。この機能で設定した設定値によって△△△機能を編集・閲覧・閲覧不可ができます。具体的にどのような設定値によって編集・閲覧・閲覧不可が制御されるのか調査してください。また条件についてデジションテーブルで教えてください。UIベースの視点で回答してください
回答結果
参考：デシジョンテーブル
事例③：テスト観点漏れのセルフチェック
課題
仕様を理解してテスト設計をしても、「観点が漏れていないか」という不安は残ります。コードベース視点での観点補完は最終的に開発者レビューに頼らざるを得ませんが、レビュー前にコードベース視点でのセルフチェックができない点が課題でした。
Ask Devinの活用方法
テスト対象となるドメインや機能名を記載してその機能に関するテスト観点のリストアップを依頼します。その結果を自分の設計と突き合わせることで、観点漏れを事前に発見できます。
効果
- テスト設計レビュー前に一次レビューを自分で実施できる
- 観点漏れを早めに発見でき、成果物の質が向上する
- 開発者レビューではより深い議論に集中できる
プロンプト
〇〇〇機能：/[サービス名]/[機能名]/[設定項目]で△△△を作成・編集できる機能があります。その機能のマニュアルテストで考慮した方がいいテスト観点をリストアップしてください
回答結果
参考：テスト観点
事例おまけ：バグのリストアップ
おまけ
Devinに開発中の機能で発生しそうなバグのリストアップを依頼すると、発生しそうなバグをリストアップしてくれます。この情報を実装中の開発担当者と確認して実装の漏れや懸念がないかなどの確認に活用しています。
プロンプト例
〇〇〇機能：/[サービス名]/[機能名]/[設定項目]や〇〇〇機能で設定した項目を△△△で作成・編集・表示ができる機能があります。その機能のマニュアルテストを実施予定です。コードベースをもとに発生しそうなバグの事象を箇条書きでxx件リストアップしてください。もしxx件を超える場合は超えて報告してください
参考：プロンプトのコツ
プロンプトに「QAエンジニアでも理解がしやすいように」や「UIベースの視点で」のように、「誰の視点で」「どのような形式で」 回答してほしいかを明確に伝えることが、精度の高い回答を得ることができました。また、同じような機能名が複数ある場合、該当機能のURLの情報を伝えることで誤った回答を防ぐことができました。
Ask DevinにはDeepモードがあります。このモードをONにすることで高度なクエリが可能になるようです。私はAsk Devinを使用する際、複雑な機能や調査する対象が多い場合はDeepモードをONにして使用しています。ただし、DeepモードがONの場合はOFFのときよりもクエリの時間が長くなるため、検索対象によってはDeepモードをOFFで使用しています。
Devinを活用する上で気をつけていること
Devinに質問する際、検索対象の機能名が別の機能名と同じような機能名の場合は、プロンプトに曖昧さがあるとQAエンジニアの視点でも別の機能のことを回答していそうなときがありました。また、Devinの回答を確認しても、自分自身の理解が不十分だったり不明なことがあったりする場合があります。そのような場合は、必ず関連する担当者に確認するようにしています。
まとめ
QAエンジニアにとって仕様理解は避けて通れない課題であり、業務の効率と品質を左右します。
Ask Devin を活用すれば、仕様の理解を加速させることができ、また、オンボーディング支援やテストプロセスといった「これまで時間と労力をかけていた部分」を効率化することができます。
Devinは仕様理解にかかる負担を大幅に減らし、これまでできなかったことを支援してくれる味方です。
Devinを使用できる環境にある方は、ぜひ一度試してみてください。
KNOWLEDGE WORK Blog Sprint、明日の執筆者は私と同じグループのフロントエンドエンジニアの zi です。ご期待ください！
Discussion