はじめに
製品やサービスのテスト設計をするまえに、様々な機能においてテスト分析をしていくと思います。
(機能だけではなく、非機能とかあったり品質全般的な話もありますが、ここでは省略します。あくまで機能的なところだけを話します。)
20年弱前まで開発者であったテスター & QA ですが、そんな私が開発視点よりでテスト分析するときに考えていることを少し書いてみます。
結論
結論を先に出しておきますが、テスト対象を分析するときで以下のことを考えてみればどうでしょうか。
それを考えるために中学生の数学 (因数分解と 合同・MOB) を使って説明してみようと思います。
- テスト対象を細かく分解すること (可能であればクラス設計と同じ視点で考えてみる)
- テスト対象をほかのものと比較して同じもの、異なるものを探すこと
素因数分解とは？
中学生の数学で習う「素因数分解」ですが、ある正の整数を素数のかけ算で表すことです。
素数とは primary number とも言われて、1 とそれ自体でしか割り切れない数字のことです。
たとえば、「12」という数字を素因数分解すると「2*2*3」です。
このように 1 を除いて自分自身でしか割り切れない数字に分解したものです。
合同・MOD (余り)
MOD (余り) とは、割り算の余りのみに注目した等式のことです。
例えば、合同式で書くと以下のようになります
7≡4(mod 3)
7≡6(mod 1)
テスト対象の素因数分解
さて、数学的なことはさておき、機能の素因数分解を考えてみます。
テストをするときに例えば、「設定を保存する」とか書かれていた時にどのように考えるでしょうか？
こいつを素因数分解のように分解して、これ以上分解できない(と思える)ぐらいにしていきます
- どこに保存するのか
- 何の設定を保存するのか
- どのように保存するのか
- いつ保存するのか
- ...etc
どれだけ分解してこれ以上分解できないまでにしていきます。
分解するにあたって 5W1H が役に立つかと思います。
テスト対象の合同・MOD
たとえば「設定を保存する」というテスト対象ですが、製品 (サービス) には、1つではなく複数あると思われます。
その対象をすべてテストするのは非常にコストがかかるため、いずれか1つをテストすればあとは同じだからテストしなくてもいいとしたいはずです。
そこで出てくるのが合同・MOD です。対象 A はファイルに、対象 B は DB に保存するとしましょう。
そのときに考えられるのが例えば以下のように分解できます。
そこで、標準出力する部分は共通になるので、どちらかをテストすればよいという判断になります。
対象A 設定を保存 ≡ 標準出力 (mod ファイル)
対象B 設定を保存 ≡ 標準出力 (mod DB)
このように、テスト対象の共通項を見出して、テストを絞り込んでいきます。
経験談からいうと、特に余りの部分に「バグ」が潜んでいます。
まとめ
テスト対象の機能をテスト分析をするときには、素因数分解のように細かくしていくことをお勧めします。
そして、テスト対象の機能がほかの製品や機能と共通項と仲間外れをみつけて重点的にテストしてみましょう。
余談
テスト対象がモノリシスすぎて、分解できないことがあります。
たとえば、「127」が素数か？と聞かれると多分素数と感覚になりますが、「67280421310721」が素数か？と聞かれたらわからん。。。となります。(素数らしいですが)
テスト対象も同じで、あまりにも大きすぎると分解できるのかどうか(何をもって分解するのか)判断できなくなります。
製品 (サービス) が大きくなるとリファクタリングできなくなるのと同じです。(プログラムだけではなくテスト設計も日々のリファクタリングが必要です)
このような状況にならないためには、もちろん設計が大事ですが、日々のリファクタリングを怠らずに実施することです。
「67280421310721」みたいな大きな機能がひとまとめでやってきてテストしろ (バグをみつけて) というのはイケてないです。
イケてない状況になるのには、様々な要因があると思いますが、テスト担当者は常に対象物を素因数分解と合同・MOD を考えて開発担当者にフィードバックをかけて、リファクタリングできる間に実施してもらいましょう。