先日のテスト設計コンテストで、聴講者の方からよく質問を受けたのがテストアーキテクチャに関する質問でした。
恥ずかしながら、私もテスト設計コンテストに出るまで、テストアーキテクチャが何なのかよくわかっていませんでした。
でも、参加した後の今なら、ちょっとだけ人に説明できるかもしれない。そう思ったので記事にしてみます。
テストアーキテクチャについて考える上で、わからないポイントが3つあるような気がしました。
この記事では、「1. テストアーキテクチャがなぜ必要なのか？」と「2. テストアーキテクチャで何を表現したいのか？」に焦点を当てて考えてみたいと思います。
テストアーキテクチャがなぜ必要なのか
あなたにはこんな経験がありますか？
- 具体的な入力値や期待結果などが書かれた数百件、数千件となるテストケース(もしくはその一部)を渡されて、レビューをお願いされた
- そして、テストしたいこと、バグが出たら困るのでテストして欲しいことがあるけれども、それがどこで確認されているのかわからない
- 組織におけるテストの全体像はよくわからないけど、とりあえずこれまでの慣習でテストしている
- 過去のテストスイートを参考にして、いい感じに新しい機能のテストケースを作ってと依頼される
- 「これを実行して」と渡されたテストスイートが制約事項により実施できなかった
- テスト実行しているけど、いまいち何を確認したいテストケースなのかわからない
「ソフトウェアテストに携わっているけどそんな経験ないよ」という方は、本当に素晴らしい現場にいらっしゃるので、その現場で経験したことを大事にしていただきたいです。 一方、私は当事者として、少なからず上記のような課題に直面する場面がありました。
これらの課題を解決する一つの手段がテストアーキテクチャの設計であると考えています。
テスコン チュートリアルの資料を見てみます。
テストアーキテクチャ設計とは、テストスイートの全体像を把握しやすくしつつ 後工程や派生製品、後継プロジェクトが作業しやすくなるように、テスト観点を グルーピングしてテスト要求モデルを整理する工程である。
テスト設計チュートリアル テスコン編資料(講義編) https://aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf
この説明を別の視点から考えていきたいと思います。
夢のマイホームを建てるとしましょう。
理想の完成像として、「趣味をとことん楽しむためのガレージルームが欲しいな」、「シアタールームが欲しいな」など夢が広がります。
一方で、現実問題として家を建てる際には、土地の広さや建ぺい率、予算などさまざまな制約があります。
そういった制約を踏まえて、より現実的で「実現可能な完成像」である間取りやデザインが出来上がっていくはずです。
ソフトウェア開発においても同様に、ステークホルダが考える理想の完成像、つまり要求があり、
システム化によって解決できる課題を具体化していくことで、実現可能な完成像がブラッシュアップされ、要件に落とし込まれていくと思います。
その完成像を実現していくために必要なのが、ソフトウェアのアーキテクチャですが、
テストに置き換えるならば、完成像が実現できていることを示すためのもの、それがテストアーキテクチャなのではないでしょうか。
テストアーキテクチャで何を表現したいのか
引き続き、家を建てることを例に取りつつ考えてみます。
先ほど、間取り図やデザインは「実現可能な完成像」であると述べましたが、実際に家を建てるためには、
柱を何本建てるか、材質は何か、壁や窓をどこに配置するか、などの具体的な構造を検討していく必要があります。
そして、検討した構造が法令で定められた基準を満たしているか検査していく必要があります。
テストアーキテクチャとして考えてみると、テストの目的を果たすために、どのようなアプローチを取れば良いのか、
具体的に、どこまでのスコープに対し、どのようなテストレベルを定義し、その中でどのようなテストタイプを選定するのかを検討することであると捉えることができるかもしれません。
(何がテストレベルで、何がテストタイプかというのも、それだけでブログ記事が一つ書くことができそうな話題なので、ここでは雰囲気で察してください)
ここで注意をしなければならないのは、家を建てるときは建築基準法など特定の法令を遵守する必要があるのに対し、ソフトウェアの場合は、対象のドメインによって遵守・適合すべき法令が異なるということです。
例えば、医療機器に搭載されるソフトウェアでは、国内ならば薬事法、米国ならばFDAへの届出・承認を検討しなければならないかもしれません。
つまり、テストアーキテクチャとして何を考慮すべきかは、自分たちが扱っている対象システムによって大きく変わってきます。
さて、考えるのは構造だけで良いのでしょうか。 改めてテスコン チュートリアルの資料を見てみます。
テスト要求を、テストケースを導くエンジニアリング的テスト要求と、
テストケースを導かないマネジメント的テスト要求に分けるテスト設計チュートリアル テスコン編資料(講義編) https://aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf
先ほど検討したテストレベル、テストタイプは、エンジニアリング的テスト要求に分類されるものです。 従って、マネジメント的テスト要求の検討ができていません。
再び、家を建てる話に戻ります。
土地や道路の制約がなければ、全ての材料を搬入して、建てていけば良いかもしれません。
ただし、現実問題として、土地の広さや前面道路の幅などの制約があり、搬入する順序やタイミングを考慮する必要があります。
また、「アーキテクチャ」ではないかもしれませんが、職人さんが何人いれば良いのか、天候などの不確実な要素に対応するためのスケジュールなどのマネジメントの要素も検討する必要があります。
これはソフトウェアテストにおいても同じことが言えるのではないでしょうか。
例えば、相互に依存関係のあるシステムや機能を考慮する必要があるかもしれません。
また、組み込み機器であれば評価機器などの制約、ハードウェアの開発状況などソフトウェアの外の世界にも目を向ける必要があります。
そして、これまで検討したエンジニアリング的テスト要求を満たすために、テスト全体の規模感を知り、リソースの調整をする必要があります。
すなわち、これらのポイントを考慮してテストアーキテクチャを考えていかなければなりません。
おわりに
テストアーキテクチャの必要性と、テストアーキテクチャで表現すべきものについて、建築を例にとりながら考えてみました。
実際に私がどう表現したのか？という話は今回も筆が乗らなかったのでまたの機会に。
指摘、コメント歓迎します。
