VSTePを使ってみよう！実践テストフレーム - 手順とデータを分離するテスト設計

はじめに

本記事はVSTePのテストフレーム設計について記載します。テストフレーム設計とその後工程のテスト実装の流れを説明したうえで、私がテストフレーム設計において特に有益だと考える以下の点についてまとめます。

• 手順とデータの分離
• テスト強度による段階的設計
• AI時代のテストフレーム設計

テストフレームの基本的な内容は以下の記事にまとめています。

テストフレーム設計とテスト実装の流れ

テストフレーム設計やテスト実装の流れとして、以下が想定されます。ここでは抽象的なテスト手順やテストケースの設計はテストフレーム設計の一部として置いています。

【テストフレーム設計】

1. テストしたいことを定める
2. テストに必要なテスト観点を集める
3. テスト観点を用いて、テスト手順を考える
4. 抽象的なテストケースを考える

【テスト実装】

1. テストスクリプトを実装する
2. 具体的なテストケースを実装する

テストフレーム設計

テストしたいことを定める

テストフレーム設計を行うにあたり、今から設計するテストフレームが「何をテストしたいのか」を明らかにする必要があります。具体的なテストを実装したり、テストを実施する場合、「そもそも、今何をテストしたいんだっけ？」となりやすいです。テストフレーム設計を実施しようとしたときに、「何をテストしたいのか」を考えたり「何をテストできれば、品質が十分だろうか」を考える切っ掛けになります。テストの目的に目が向くだけでも、テストフレーム設計を行う価値はあると考えます。

VSTePでは「何をテストしたいのか」はテストコンテナ設計→テストフレーム設計間で考える内容ですが、VSTePのプロセスとしては明瞭な作業の定義は無いと私は認識しています。「何をテストしたいのか」は、ゆもつよメソッドでは「仕様項目」に近いもの¹だと思いますので、組み合わせて解決するアプローチも有効だと考えます。

テストに必要なテスト観点を集める

テストフレーム設計ではテストしたいことを確認するためにテスト観点をテスト観点図から集めます。このとき、テスト実施時に登場するすべてのテスト観点ではなく、テストしたいことに影響の大きい（＝テスト強度²が強い）テスト観点を選定します。影響の小さいテスト観点はテストスクリプトの実装時に決定する項目（＝実装実施時要検討事項）として扱います。

また、テスト観点は適切な粒度を意識して集めます。テスト観点が因子（＝パラメータ）に相当する場合、テスト実装時にテスト観点を具体値にそのまま置き換え可能です。テスト観点が因子よりも大きな粒度である場合、キーワード（＝アクションワード）として扱えます。テスト実装をする際に、そのキーワードを実現するための手順を別途定義する必要があります。

テスト観点を用いて、抽象的なテスト手順を考える

集めたテスト観点を変数にして、抽象的なテスト手順を考えます。

【例】
<座標1>と<座標2>、および<距離の種類>を「2点間の距離を求める関数」に適用し、戻り値が<点間距離>と一致すること

抽象的なテストケースを考える

抽象的なテスト手順に対して、抽象的なテストケース（テストデータの組合せ）を考えます。このとき、網羅アルゴリズムと網羅基準を考慮して、テスト目的を達成する（＝テストしたいことを確認する）のに十分なテストケースを用意します。抽象的なテストケースにおける値は、例えば「999」のような具体値ではなく、「最大値」のように意味が分かるような抽象的な内容にする方が望ましいと考えています。値の意図が残り、将来的なテストケースの見直し時に役に立ちます。

テスト実装

テストスクリプトを実装する

テスト手順を実行可能なスクリプトとして実装します。実行可能なテストスクリプトには、テスト観点以外の項目（＝実装実施時要検討事項）もでてくるため、この時点で決定する必要があります。

具体的なテストケースを実装する

抽象的なテストケースから、実行可能なテストケースを実装します。テスト実行時に使用する具体値を選定します。

手順とデータの分離

テストフレーム設計を行う場合、テストスクリプト（テスト手順）とテストケース（テストデータ）を分けて管理することになると思います。手順とデータを分けて管理することで、以下のような利点があります。

• テストの共通構造の抽出。複数のテストスクリプトから共通項目を見つけることが難しいが、テストフレーム設計ではテスト目的やテスト観点から考えることで、手順とデータを分離しやすくしている
• 保守性の向上。共通化可能な手順をまとめることで、保守コストの高い手順の量を抑えられる。難しいテスト手順のレビュー量が減り、テストデータのレビューに注力しやすくなる

テスト強度による段階的設計

テストフレーム設計の後工程にはテスト実装があります。テストフレーム設計ではテスト強度が強い要素を扱い、テスト実装ではテスト強度を弱い要素のみにすることが望ましいです。

大規模開発においてはテスト設計、テスト実装で異なるテストエンジニアが行うことも多く、例えばアルバイトのような人がテスト実装を行う場合もあります。VSTePでは、そのようなソフトウェア開発の現状を踏まえた上で、テストエンジニアがテストの品質に大きく影響する部分を受け持ち、人手が必要な部分は影響が少なくなる（＝実装実施時要検討項目だけになる）ようにプロセス設計されて（いると私は思って）います。

AI時代のテストフレーム設計

テストフレーム設計とテスト実装は、プロセス間で、テストに対する責務の大きさが異なります。テストについてよく勉強しているテストエンジニアと、多くの作業を受け持ってくれるアルバイトなどの人たちとで適切に責務分担されるようプロセス設計されています。

生成AIによる開発工程の一部実施が可能な時代になってきていますが、責務分担を考慮されたテスト開発プロセスは生成AIとの相性も良いと考えています。生成AIがコードを生成しても、成果物は人が責任を持つ必要があります。テスト開発においては、テストフレーム設計のようにテスト強度が高い部分は人が行い、テスト実装のようにテスト強度が低い部分は生成AIが行うことで、テストの品質を保ちつつ生成AIを活かした作業効率化が図れるのではないでしょうか。

（参考）2018年テスコンのにしさんXポストまとめ

実装実施時要検討事項についてにしさんがポストされた2018年テスコン時のXポストをまとめました。

本来はまとめサイトなどでまとめられるといいのですが、古いポストは扱えないらしいので持ってきています。
まとめる別案あればご意見いただきたいです。

1. ゆもつよメソッド powered by VSTePはそういう話だと（勝手に）思っています。 https://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf ↩

2. テスト強度とはテストの保証範囲を表す言葉として用いています。よりバグを出せる項目のほうがテスト強度は高くなります。 ↩