はじめに

前回の投稿『テストにも「リーン・スタートアップ」を取り入れたら効果的！って話』ではリーン開発において、ユーザーにさわってもらって問題を発見する、いわゆる「探索的テスト」がいかに有効であるかを紹介しました。
今回は書籍「リーン開発の本質」に書かれているリーン開発の原則と照らし合わせて、特にスタートアップにおいて探索的テストが有効であることを書籍の引用を見ながら紹介したいと思います。

ムダを省く

リーン開発ではいかに速く開発するかが重要です。そのためには、いかにムダを省くかがポイントになってきます。書籍ではソフトウェア開発におけるムダとして、以下の7つが挙げられています。

• 未完成の作業のムダ
• 余分な機能のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ

「探索的テスト」を用いることで上記の「遅れのムダ」と「欠陥のムダ」を削減できます。

テストをしないという選択

そもそもスタートアップではスピード優先のためテスト工程を設けていないというチームもあるでしょう。とくにスマホアプリの開発では顕著かもしれません。
すると、致命的な問題をかかえたままリリースする可能性が高まります。その場合、リーンキャンバスとして検証するべき要素にユーザーが到達するまえに離脱してしまう可能性も高まります。

したがって、ここは少しだけ遠回りした方が賢明です。

20%の労力で80%を実現する

では、テストを行うという前提で、なぜ「探索的テスト」で「遅れのムダ」と「欠陥のムダ」を削減できるのでしょうか。
その前に、書籍ではコーディングにおける原則として以下のように書かれています。

私たちが必要としているのは80パーセントの価値を提供する20パーセントのコードをまず開発し、その後初めて、次に重要な機能の開発に取りかかれるようなプロセスである。

これは、テストにおいても言えることだと思うのです。たとえば、キチンとテスト設計を行って想定される観点を元にテストパターンを洗い出しテストを実施したとします。これでバグはなくなるのでしょうか？　経験豊富なみなさんならきっとご存知ですよね。それでもバグはなくならないって。

いくらテスト設計に時間をかけても、それに見合った成果を得ることは非常に難しいのです。したがって、スタートアップの初期段階では、おもいきってテスト設計を行うことをやめてしまい、20%のコストで80%の成果を得る方法を考えましょう。

書籍では自分達で行うテストについて以下のように書かれています。

それらのテストは、コードが私たちの考えどおりに動いているということと、事前に想定したやり方では失敗しないということを証明しているにすぎない。ソフトウェアはときどき、思いもよらない失敗のし方をする。

重大な問題をいかに効率的に発見するか

テストにおいて 20%のコストで80%の成果を出す方法の１つが「探索的テスト」です。

探索的テスト

事前・直前のテスト結果に応じて、次のテストを適宜に施していくソフトウェアテストの方法をいう。探りを入れながら臨機応変にテスト項目を決めていくテストスタイルといえる。[IT Media 情報マネジメント用語辞典]

探索的テストはテストケースを作成しない、すなわちテスト設計を行わずにテストを行う方法です。いいかえるとテスター任せのテストともいえます。そのため、一般的にはテスト設計を行う網羅的テストと双方を実施し、相互補完することでバグを少なくできるとされています。

ですが、リーン開発においては必ずしもそこまでの品質は必要ありません。それよりもスピードです。したがって、探索的テストだけを行い主要な機能における致命的な問題だけを検出できれば、リーンキャンバスで検証するべき項目「解決策」の検証には十分です。
あまり発生しないニッチな問題にはコストをかけるのをやめましょう。

実施のタイミング

では、いつ「探索的テスト」を実施すべきでしょうか。テストしようにもバグだらけで主要な機能の動作すらもままならない状態では、さすがにテストになりません。「主要な機能はひととおり問題なく動作する」という状態でなければなりません。
したがって、単体テストをキチンと行っているのであれば単体テスト後、そうでないのであれば結合テスト後がよいと思います。

探索的テストを手軽にできるサービス

「探索的テスト」を手軽に実施できる「あれれサーチ」を立ち上げました。ただいまサービス体験キャンペーン（無料）を実施中です。

>>> あれれサーチ <<<