テストを最初から作る研修を何度か回してみた

こちらで一回やった研修を何回か回してみました。気づきがあったので、書いておきます。

研修の概要

テスト開発＝テスト分析・テスト設計・テスト実装を一通り（どころか二通り）回して、テスト開発の流れを経験したことがない人に経験してもらう、というものです。方法論としては、VSTePとかを使うことも考えたのですが、ちょっと初心者には難しいかなと思ったので説明がしやすいように組み立てました。

テスト分析

「機能」がむずい

まずはテストベースから機能を把握しましょう、という話がよくなされるのですが、その機能の定義がやっぱり難しいです。ISO/IEC/IEEE 29119ではフィーチャー（セット）と呼ばれたりしますが、それも理解が難しいです。一応研修の中ではユーザストーリー相当でまとめて仕様の意図がわかるようにしよう、としているのですが、経験ないとそれも難しいですね。（難しいしか言ってない）

テスト条件の出し方がわからない

そもそも、の話ですね。テスト分析ってテスト条件を出すプロセスなのですが、テスト条件をどうやって十分に出すのか、説明ができない。一応6W2Hとラルフチャートを道具立てとして使う、という話はしているのですが、それでも十分性の議論は難しいです。

結局、テスト設計コンテストでもそうですけど、テスト開発において主に頭を使う部分はこのテスト分析になっちゃうんですよね。それは、確立したやり方がなくて自由度が高いから、です。でも、テスト開発の研修を受けに来る人は唯一絶対のやり方を教えてもらいに来るので、そこは期待と現実の齟齬が発生しやすいところです。

テスト設計

テスト条件の粒度

テスト設計はテスト条件に対してテスト設計技法を適用するプロセスなのですが、テスト設計技法を適用できるだけの粒度にテスト条件を調整することが、最初はとても難しいと感じています。意味の違うテスト条件をひとまとめにしちゃったり、テスト条件を細かく書きすぎてテストケースレベルになってしまったり。

ここもある程度テスト設計を経験していく中で、テスト条件のあるべき粒度というものがつかめてくるのだと思いますが、初心者は苦しみます。どちらかというとテストケースをテスト条件で書いちゃうことが多いですね。

テスト設計技法の適用方法

テスト設計技法って、同値分割、とか境界値分析とか、状態遷移テスト、とか、別々に習うじゃないですか。で、一つのテスト条件には一つのテスト設計技法しか適用できないと考えちゃうケースが結構あります。ここは、テスト設計技法の使い方だけ教えてても気づけないポイントかもです。

カバレッジ基準が決まらない

カバレッジ基準はプロジェクトの背景やそのテスト条件に関するリスクから決まるのですが、実プロジェクトではないとそこを特定するのは本当に難しいです。背景情報がたっくさん必要になるし、それを全部伝えることも時間的に難しい。ここは研修ではあきらめるポイントなのかなと思っています。

テスト実装

優先順位が決まらない

これも、カバレッジ基準とほぼ同じ理由です。実プロジェクトだと機能の優先度とか、実装の状況とかによってテスト実行の優先順位が決まったりするのですが、研修では情報を与えきれないです。ここもあきらめポイントですかね。

まとめ

というわけで、まぁいろいろ制約はあるにせよ、なんだかんだやる価値はある研修なのかなと思っています。あとは、もう少し「決まったプロセス」に寄せることができればいいんですけどね。