テスコンチュートリアルを聴講したのでテストアーキテクチャを過去の経験から考えてみる
アドベントカレンダー3日目です。
1日遅れての進行はもうデフォです。
お題
テスト設計コンテストに参加して考えたこと、わかったこと、わからなかったことを書いて欲しいです
お題の提供ありがとうございます!
残念ながら、テスト設計コンテストに参加してその感想を書ける頃には既に年が明けて暖かくなってしまっています。
(参考 : テスト設計コンテスト)
ですので、先日行われたOPENクラスのチュートリアルで説明された、テストアーキテクチャについて少し書いてみます。
資料は上記リンクからでも下記のconnpassからも閲覧できます。
チュートリアルは地方にも中継されますので、興味のある方は来年になってしまいますが是非聴講してみてください。
本題の前に
「テストアーキテクチャ」 という概念については今回のチュートリアルでまともに聴いた程度ですので、誤った解釈、用語の使い方、偏った説明をする可能性が高いです。
本記事におけるテストアーキテクチャに関してはチュートリアルの資料の定義を自分なりに解釈したものになりますので、本家の資料も是非ご参考にしてください。
テストアイテムについて
テストアーキテクチャを考えるために、テストの対象となるシステムが必要になります。
今回は、自分が過去に業務で担当したプロジェクトを参考にアーキテクチャの図を描いてみます。
※ テスト計画書に自分が書いているような内容を図にするイメージなので、多少本来使用する用途や効果とズレが生じる可能性があります。
前提となるシステムは以下のようなものです。
- Webアプリケーション
- クライアントがデータを入稿する
- 一般ユーザーは入稿されたデータを検索・閲覧できる
- 入稿データは一覧ページと詳細ページが存在する
そして、今回のプロジェクトの要件は以下のようなものになります。
- 既存のものとは異なる新たな検索方法を追加する
- 検索するために入稿されたデータを加工する必要がある
- データの加工はバッチ処理で行われる
- 新規の一覧ページを作成する
- 既存の一覧ページ・詳細ページに新規の一覧ページへの導線を設置する
※ 流石に内容を細かくは載せられないため、簡略化とぼかしを入れています。
検討したテスト
テストレベル毎に、どのようなテストを検討したか書いていきます。
呼び方はこの記事のために独自に定義しましたので、後日直接この記事の話を振られても本人に伝わらない可能性がありますがご理解ください。
ユニットテスト
データ加工
クライアントから入稿されているデータを何段階かに分けて加工するため、それぞれの工程をコンポーネント単位でテストします。
回帰テスト(CI)
既存のデータフローに影響がないかマージする前にCIで確認します。
結合テスト
データフロー
データを加工する各コンポーネントを確認したため、それらを結合させデータを流して想定通りに加工されるかを確認します。
データは入稿時にバリデーションされていますが、異常値についてもハンドリングできるかテストします。
パフォーマンステスト
データの加工をバッチ処理で行うため、それらの処理にどれくらいの時間が掛かるのか、どれくらいのデータ量を捌けるか、どれくらいのマシンを用意する必要があるのか検証します。
システムテスト
機能テスト
新たな検索方法をブラウザから動かせるか、検索結果が正しいかをテストします。
また、表示についてもテストします。
(OS/ブラウザ間の互換性も見ますが、図を書いたときに失念して追加が面倒なので省略します。)
セキュリティテスト
新たなページの作成、POSTするデータの種類が増えるため、それらに脆弱性が含まれていないかテストします。
シナリオテスト
新たな検索手段を用いたシナリオや、既存の機能と絡めたシナリオを用意し、一連の操作を通しで行うテストをします。
探索的テスト
過去の障害や仕様/設計の複雑な箇所などを中心にチャーターを準備してテストを実施します。
受け入れテスト
回帰テスト(e2e)
e2eの自動回帰テストを実行し、プロジェクトのスコープ外で問題が起きていないかを確認します。
テストアーキテクチャ
これらをテストコンテナ(資料 p24あたりを参照)にまとめてみます。
また、今回はそれらをテストレベルで区分けし、実施順の観点でつなげてみます。
(きれいな図を作る精神力がなかったので、手書きですがご勘弁を)
それぞれのテストを開始するために、終了していなければいけないテストがひと目でわかるようになりました。
「まぁそうなるよね」 といった具合の図ではありますが、テキストで羅列しているよりはわかりやすいです。
そして、このプロジェクトは想定していたこのアーキテクチャ通りに進みませんでした。
データ周り、つまり結合テストまでテストが終了した時点で、その先の実装が遅れており、テスト仕様書の作成も間に合っていない状態にありました。
進め方を変えなければ普通に考えてプロジェクトは遅延しますので、アプローチの変更を行いました。
よって、アーキテクチャも組み替えます。
(くどいようですが、実際には図やコンテナを意識せずプロジェクトを進めていますので、合っているかも進めやすいのかもわかっていません。あしからず。)
アプローチを変更し、探索的テストを前倒ししました。
探索的テストのアプローチも変え、
「開発側がテスト仕様書を作成している間に、QA側で問題を可能な限り発見して手戻りを減らす」という方針にしました。
(※ 弊社では基本的に開発チームがテストを設計・実施しています。QAは計画やレビュー、探索的テストやその他諸々のサポートを行っています。)
探索的テストで早期に大きめなバグをあげ、細かい箇所は網羅的なスクリプトベースのテストでおさえます。
各機能でテストを進め、機能テストが終了した機能で可能なシナリオテストも進めます。
といった具合に、図にすることで進め方やアプローチの変更点がわかりやすくなりました。
実際は各テストの中にもっと小さいコンテナを入れたほうが良いのだと思います。
詳細は載せられないことと単純にそこまで記憶していないので、そこまで含めた使い勝手までは検証できませんが、少なくとも説明はしやくなるのだと思います。
そして、考えていることが伝わりやすくなるので、それに対する議論や指摘などもより活発に行えるのだろうなとも思います。
実際、上記の図を見て思うところがある方もいらっしゃるでしょう。
まとめ
テストアーキテクチャについて、
一人の脳内で完結させず、周りに共有し検討できる脳を増やすためのツールのようだなと思います。
また、ここでは大雑把なテストコンテナをテストレベルや実施順でしかわけていませんが、テストのアプローチに応じて柔軟に見せ方を変えることができるとより強力だと思いますので、この記事はあくまで書き方の参考にだけしてください。(こんなのでもいいんだな程度に)
そして改めて、こんな感じ( 書き方とか考え方とか見せ方とか )でよいのかどうか、書いている本人もよくわかっていません。
現時点では、テストするコンポーネントで区分けしたり、テストを実施する人で分けたり、目的でまとめたりするとおもしろそうだなと感じているくらいです。
理解を深めるために、色々な資料を読み、実際に手を動かし、アウトプットを残してみてください。
( できれば自分にそれらで得た知見を共有してくださると嬉しいです。 )