うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

仕様書にないものをどうやって思いつくか？ #CafeTesting

Testing
").prependTo(".entry-content"); } //スクロールを滑らかにする $('.sectionList a').on("click", function() { $('html,body').animate({scrollTop: $(this.hash).offset().top}, 600); return false; }); });

先日、 Cafe.Testing で ソフトウェアテスト実践ワークブック の演習2をやりました。そこで話題になったのですが、「どうやって仕様書にないものを思いつくか？」ということです。他にもたくさんあって不十分な部分はあるのですが、そこで話した内容をメモがてら書いておきます。また、こういったことに興味があったり聞いたり話したりしたい人はきてもらえるとうれしいです！

Cafe.Testing - connpass

ソフトウェアテスト実践ワークブック

ソフトウェアテスト実践ワークブック

発端

この書籍を持っている人はわかると思うのですが、演習2の回答例にはミドルウェアやハードウェアが起因でソフトウェアが動かなくなるようなテストケースはなかったりしました。

あとは、参加者の方では「使いたくないようなUIではない」とか「ポップアップが出続ける」とかのテストが思いつかなかったそうです。

そういったものを話していくうちに「仕様書にないものをどうやって思いつくのか？」という質問がでました。

僕の回答

テストだけに限りませんが、ここでは2つの回答をしました。（ちょっといいのがしたことを追記してあります。）

  • 一次利用者、間接利用者の紙芝居を描く
  • システム構成とそれぞれのライフサイクルを描く

それぞれどういうことかを見ていきましょう。

一次利用者、間接利用者の紙芝居を描く

テストを設計するときにはユースケースとかユーザーストーリとかUIを書いたりすることはよくあると思います。ですが、自分にとってはあまり足りませんでした。 例えばスマートフォンのアプリを作るときに、画面があって、ユーザーが親指でこうやって操作するんだろうなぁ。。。っていうだけではなく、その人が使う前後を含めて紙芝居に書いてみます。そうすると、その人はいつどこでスマートフォンを手に取って、どこでどんな姿勢でさわって、どの順番でそのアプリを起動して、どこでやめるタイミングを見計らって。。。って描くんです。そうするとそれは夜ベッドに寝転がりながら触りそうってわかったりして、じゃあ、寝転がりながらでも触りやすくしようとか、あまり目が冴えないような配色がいいものがあるかもしれないとか気づいたりします。

今回の演習2であれば、外で利用するっぽかったので、明るいところでもみやすいUIになっているかとか、より色弱に配慮する必要があるんじゃないかとか。あと、5分単位で使うようなソフトウェアみたいで駅にあることがいいみたいなので、大きくてシンプルで見えやすくて少ない手順で使えるのもポイントになりそうです。

そういう意味で僕は紙芝居で描いたりするのが自分にはやりやすかったりします。で、紙芝居の前の整理としてはコンテクスチュアルデザインとかペルソナ描いたりとかはいいと思います。まぁでもどっからやっても結局全部描くので、どれからやってもいいと思います。

で、これはいわゆるエンドユーザーだけではなくて、開発者だったり運用者だったり、カスタマーセンターだったりする人の分も描いたりします。

システム構成とそれぞれのライフサイクルを描く

こっちはかなり「それなんてドメイン知識」っていう感じなんですけど、テストってそういうものなので！

対象としているソフトウェアの論理的な構成や物理的な構成を描いていきます。Webアプリだったらクライアントサイドはこんな設計になっていてイベントがこうやって伝わって、サーバーサイドはここでURLマッチさせていて、例外はここで補足されて、DBとのコネクションはこうなっていて、プールの管理はここでされていて、サーバーサイドの設計はこんな感じで、、、っていうのが対象ソフトウェア部分の構成ですね。

そこからさらに派生してそのソフトウェアがほかにどんなものと関わっているかを描きましょう。HTTPは誰が受け取っていて、時刻はどこで管理していて、コネクションはどうで、OSはどうなっていて、プロセス監視はどうなっていて、ミドルウェアは何をつかっていて、そのミドルウェアはソフトウェアから受け取ったものをどうやって他に伝えていて、ハードウェアとそのマシンはどのように関連していて、、、って構成が書けますね。（クライアントサイドももちろん描きましょう）

って構成が描けたらあとはそれぞれのライフサイクルを描きます。いつどんなパラメータで起動して、実行されつづけて、どうやって中断されることがあって、どうやって終了することがあって、だれがその通知を受け取れるのか、再起動すると内部的に何が変わるのか、、、などなど。

っていうのを描いていけばいくほど、僕はだいたい描けません。つまりそこは知らないことになります。知らないということはそこはテストできないということです。知らないものに対するリスクは見積もれません。ということで調べていきます。もちろんチームに聞いたり有識者に教えてもらったりしながら。

ってやると、足りないテストがでてきます。○○が再起動するときってこのソフトウェア考えていないけど大丈夫なんだっけ？みたいな。

まとめ

ということで、ソフトウェアに関わる人たちの紙芝居を描いたり、ソフトウェアの論理的や物理的な構成とライフサイクルを描くことでだいたいテストをつくっています。ということを話しました。 他にも言うべきことはたくさんありますが、それはまたの機会に！！