2022年のテスト設計コンテスト（通称テスコン）の決勝戦が9月17日にありました。私はOPENクラス審査員として参加しました。「シーサイドゴリラ」ってTシャツ着てたのが私です。

まず、テスト設計コンテストについてはWebサイトがあるので見てもらえればと思います。

与えられたテスト対象に対してテスト設計していくのですが、コンテストに出す成果物を作るのに、100時間近く工数をかけてるチームも多く、懇親会で聞いた話では200時間かけたところもあると聞きました。実際業務とは別でこれをやるのは結構な負担になると思います。大変なことをやり切っている出場者の皆さん、本当にお疲れ様でした。

私は今年は審査員の代表の一人としてコメントする係だったので、辛口なコメントをしました。

私の講評は以下のようにツイートされてた。

実際、こんな講評をしました。

これだと、本当に嫌な審査員に見えますね。そういうならどうやるか見せてくれよ。的なことも思うでしょう。

テスコンの題材を使ってテスト分析、テスト設計を全部やって見せられればよいのですが、私にとってもそこまで簡単なことではないので、時間を1時間と決めて、とっかかりだけ以下にやってみます。

テスト対象

テスコンのテスト対象Quality Fowardというテスト管理ツールです。

QualityFowardでは、テストケースをこのツールに書いていき、テスト結果もこのツールに書いていきます。そして、貯まったテスト結果をもとにテストの進捗を見たり、品質判断をしたりするのに有効活用していくのがこのツールの使い方です。

テスト分析／テスト設計していく流れ

わたしがやるからにはゆもつよメソッドの流れでやっていきます。

テスト分析
１、テスト対象を理解しながらざっくり絵（モデル）を書く
２、テスト対象の仕様を整理して機能一覧を作る
３、テストカテゴリを決める
４、各テストカテゴリに相当する起こりうる不具合を出す
５、（テストすべき）仕様項目を洗い出して列挙していく
６、全体俯瞰（レビュー）とリファクタリング
テスト設計
1、テスト分析の結果に対してテスト設計方針を決めていく
2、P-Vを確定していく
3、P-Vの組み合わせを作る（必要な場合）
4、テストチャーターかテストケースを書く
5、（テストチャーターの場合）テスト実行しながらP-Vの組み合わせ考える

テスト分析の「1、テスト対象を理解しながらざっくり絵を描く」から始めます。

１、テスト対象を理解しながらざっくり絵（モデル）を書く

どんな価値のあるツールなのか理解する

まずはQuality Fowardがどんな価値を提供しているのかを理解するために、スプレッドシートで通常やっているテストケース管理と比較して理解を進めます。

テストケースを作る時って、最初に作ったものを保存する場所やテンプレートになるファイルを準備するところから始まりますが、QalityFowardでも、プロジェクトを作ったり、テストスイートを作ったりするので一緒です。テンプレートとして準備するようなことを設定でいろいろカスタマイズするので、そういう意味では一緒。で、エクセルにテストを書いてくように、テストスイートにテストを書いていきます。なるほど、一緒だねっていうのがわかると思います。

テストケースを書いた後に、レビューをしてもらうと思うのですが、ここら辺から、レビューをするためにテストケースを書かれたファイルを移動したり、古いやり方だとメールしたりするのが、ツールだとURLさえ知っていれば誰でも見れるのでコメント書くだけでレビュー完了なのでだんだんエクセルより便利になってきます。
テストするときには実行者が各自のローカルにファイルをコピーしたりすることなく利用できたり、テスト結果を入力した後に実行したテスト数や合格したテスト数を数えることなく自動で集計されてたりとなってくると、さらにツールの便利さが出てきます。この際にエクセルファイルに相当するものが1つや2つであれば、たいして違わないかもしれませんが、10〜100〜って増えていくと、人力でやるのもかなりの重労働になってきます。
「ここが便利ポイントのツールなのねー」ってことがわかってくるといいですね。さらに便利なのはバージョン管理をしたり、権限管理でできることを担当ごとにコントロールしたり、各自のテストすべきことだけを見ることができるダッシュボードがあったりっていうのが便利なんだーって腹落ちすると、その後のこのツールに対するテスト設計に役立ちます。

もっと言えば、他のテスト管理ツールと比べてどう便利なのかとか、本来はこういう機能になっていた方が便利だよなーとか、この段階でそういう発想が出てくるのもあると、すごくいいと思います。

登場するデータ要素

画面ごとにできることも重要ですが、データ（この場合はテストケース）を登録して、利用する（進捗を見たり、結果を追記を容易にしたりする）システムであるので、テストケースを作って結果を入れるところまでに登場するデータ要素を理解します。

テナント

• QualityFowardの課金単位です。基本的には契約してくれた顧客に対して提供する一番大きい単位って考えればよさそうです。

プロジェクト

• テナントにはプロジェクトという単位で、テストを作ったりするものを登録、利用できるようになります。テナントに対して複数存在します。

プロジェクトの中には、以下の要素があります

• テストスイート

  • テストケースを登録するところ、エクセルで言うシートと同じイメージです。このツールの根幹部分といっても良いと思います。テストスイートはバージョン管理ができます。具体的には、最初のバージョンをコピーして新しいバージョンを修正できます。コピー元になる古いバージョンは閲覧権限のみに変更するといったことができます。

• テストフェーズ

  • テスト工程を示すところ、日付（期間）を持っています。予め書いてあるテストスイートを、どのテスト期間で実行するか決めたらそのテストフェーズに紐つけていきます。

• テストサイクル

  • テストスイートのインスタンスであり、テスト結果を記載するところです。テストスイートに対してn個作ることができます。つまり、1回テスト実行した後に、またテストしたら別のテストサイクルを作って結果を書き込むことができるということです。

ここまでがこのツールに登録するデータとしてのざっくりとした登場人物になると思うので論理的に構造を整理します。

想定される使い方

テストケースを書いて、実行結果を書いていくときの機能的なフローはこんな感じになりそうです。

こういうモデルを描くことで、使い方がだんだん明確に頭の中に入ってくる感じです。

論理的機能構造でざっくり絵にする

ゆもつよメソッドでお馴染みの論理的機能構造でざっくり理解します。入力してるのはテストスイートとテストサイクルだけでなくインポートやAPIもあるってこととか、システムの全体の調整になるサポートとしては設定機能があること、また、非機能要件を考える上で、システムの外部の仕組みがクラウドでは重要になるけど、一般的にどんなことをしているのかってことを書き出してみて、大体のシステムの論理的な作りを自分の中でイメージできるようにします。

その他の主要機能

そして、テストケースを作って結果を入れるところ以外の主要機能はどういうものがあるか理解します。

• 要求ツリー

  • 要求ツリーの単位でテストの進捗が見れるようになります。どこまで品質が担保できているかといった観点で確認することもできます。

• API

  • API経由でデータの読み書きができます。

• グラフ

  • テストサイクルのケース単位の結果を集計してテスト進捗を測ることができます。JIRAのようなバグ管理と連携してグラフ出すこともできます。

• 担当者専用ビュー

  • ログインした人に対して割当たっているタスクだけ見れるようになります。

• Wiki

  • 組織としてのTestRailの使い方を書いておくといった、情報共有ができます。

ここまでで、ざっくりと絵を描いてテスト対象を理解することができてきた感じがします。

私が審査の講評で言いたかったことはこのような理解がされてないままテスト設計しているのではないか？ということです。

テスコンの成果物でも、何かしらこういうことをしてテスト対象を理解することをしてもらってあるとよかったかと思います。

時間が来たのでここまで。続きはまた時間が取れたらやりますが続き見たいって人がいるとやる気出るのでコメントください！