はじめに
現在、iOS向けアプリの総合テストを行っており、スクリーンショットを取得してExcelに貼り付け、エビデンスとして管理しています。
総合テストの開始当初は、エビデンスをどの粒度で残すべきかが曖昧で、レビュー時の指摘が多く上がっていました。
そこで、サイクルを回しながら指摘内容を整理し、取得粒度を見直していった結果、少しずつ精度を上げることができました。
この記事では、そのときに見直したポイントと、もし自社で同様の開発を行うなら検討したい効率化・自動化案をまとめます。
最初に起きていたこと
当初は「必要そうな画面を残す」くらいの感覚で進めていました。
ただ、実際には次のような指摘が出ました。
- この画面だけでは前後の流れが分からない
- ダイアログだけでは、どの画面上で表示されたのか分からない
- 結果だけでは、何を入力してその結果になったのか分からない
- 帳票出力でファイルだけ残っていても、確認としては足りない
つまり問題だったのは、スクリーンショットの枚数ではなく、
第三者に確認内容が伝わる粒度になっていなかったことでした。
指摘をまとめることで、取得粒度を見直した
指摘が出るたびに個別対応するだけだと、同じような指摘が繰り返されます。
そのため、レビューで上がった内容をまとめて、どこが不足していたのかを整理するようにしました。
その結果、取得粒度として主に次の3点を見直しました。
1. ダイアログ表示時は、画面全体を残す
最初はダイアログの内容が見えていれば十分だと思っていました。
ただ、それだけでは
- どの画面で表示されたのか
- 何の操作結果なのか
- 背景画面の状態がどうだったのか
が分かりにくくなります。
そのため、ダイアログ表示時はダイアログのみではなく画面全体を取得するようにしました。
これにより、ダイアログの文言だけでなく、表示された文脈ごと残せるようになりました。
2. テスト項目の「開始・遷移・入力・結果」を残す
結果画面だけを残しても、レビューする側から見ると情報が足りないケースがありました。
そこで、テスト項目については少なくとも以下を残すようにしました。
- 開始
- 遷移
- 入力
- 結果
こうすることで、
- どこから始まったか
- 想定どおりに遷移したか
- 何を入力したか
- その結果どうなったか
を追いやすくなりました。
単に「結果が正しい」だけでなく、確認の流れ全体が分かるエビデンスになりました。
3. 印刷・帳票出力は、ファイルだけでなく比較材料も残す
印刷や帳票出力のテストでは、最初は出力されたファイルを残せば十分だと思っていました。
ただ、それだけでは
- どの操作で出力に至ったのか
- 画面上の内容と出力結果が一致しているのか
が分かりません。
そのため、印刷・帳票出力では次をセットで残すようにしました。
- 印刷・出力までの遷移
- ファイル内容と比較するための画面
- 出力されたファイル
これにより、出力されたことだけでなく、内容が正しいことを比較できる形で残せるようになりました。
やってみて感じたこと
今回見直した内容は、どれも特別に難しいことではありません。
ただ、意識してやらないとどうしてもばらつきが出やすい部分だったと感じています。
エビデンスを取る際には「残したかどうか」に重きを置きがちですが、第三者が見て確認内容を追えるかどうかが大事でした。
特に総合テストでは、実施者本人は流れを分かっていても、レビューする側にはその前提がない場合もあります。
そのため、結果だけではなく文脈まで残すことが重要だと感じました。
自社開発なら検討したい効率化・自動化案
今回の案件では、効率化や自動化の提案まではしていません。
ただ、もし自社で同様の開発・テスト運用を行うのであれば、次のような改善は検討したいと思いました。
1. エビデンス取得ルールのテンプレート化
まずは自動化の前に、どのケースで何を残すかをテンプレート化するのが有効だと思います。
例えばテスト観点ごとに、
- 開始画面が必要か
- 入力画面が必要か
- 遷移途中を残すか
- 結果だけで足りるか
- 比較用の画面が必要か
を整理しておけば、判断のブレを減らせます。
2. Excelフォーマットの固定化
手動運用を続ける場合でも、
- 画像の貼り付け位置
- 補足記載欄
- ケース番号
- 比較対象の記載欄
を定型化するだけで、記録のしやすさと見返しやすさはかなり変わると思います。
3. 命名ルールの統一
スクリーンショットや出力ファイルに対して、ケース番号や処理内容を含んだ命名ルールを決めておくと、
- 後から探しやすい
- 貼り間違いに気づきやすい
- テストケースとの紐付けがしやすい
といった効果が期待できます。
4. UIテストを使ったスクリーンショット取得の一部自動化
将来的には、XCTest などを使って、特定画面の遷移や結果画面の取得を自動化する余地がありそうです。
Apple のドキュメントでは、UI テストで取得したスクリーンショットをテスト結果に添付できる仕組みが用意されています。
また、画像やファイルなどを attachment として残す考え方もあります。
- https://developer.apple.com/documentation/xcuiautomation/xcuiscreenshot
- https://developer.apple.com/documentation/xctest/adding-attachments-to-tests-activities-and-issues
すべてを一気に自動化するのではなく、取得ルールが固まった部分から段階的に自動化するのが現実的だと思います。
5. 帳票出力系は「比較しやすい形」で自動化する
帳票や印刷系は、単にファイルが出力されたことを確認するだけでは不十分です。
そのため、もし自動化するなら、
- 出力前画面の保存
- 出力ファイルの保存
- 画面上の値とファイル内容の比較
まで含めて考えたいところです。
単なる「ファイル生成確認」ではなく、比較可能な証跡を残す仕組みにできると、確認品質も上げやすいと思います。
6. 決まった操作で決まった画面を取得する仕組みを作る
fastlane の snapshot は、本来は複数デバイス・複数言語でスクリーンショットを自動取得するための仕組みですが、
考え方としては、決まった操作で決まった画面を取得するという点で参考になります。
そのまま適用できるかは別として、証跡取得の自動化を考える際のヒントにはなりそうです。
まとめ
総合テスト開始当初は、エビデンス取得粒度が曖昧で指摘が多く上がっていました。
ただ、指摘内容をまとめて見直したことで、少なくとも次の観点は整理できました。
- ダイアログ表示時は画面全体を残す
- テスト項目は開始・遷移・入力・結果を残す
- 印刷・帳票出力は、ファイルだけでなく比較用の画面や遷移も残す
今回の経験を通して感じたのは、エビデンスは「あること」よりも「確認内容が伝わること」が大事だということです。
また、今回の案件では提案していませんが、自社で同様の開発を行うなら、
まずは取得ルールの整理とテンプレート化を進め、そのうえで一部を自動化していく流れが現実的だと思いました。