CAT GETTING OUT OF A BAG

What the tester is thinking.

チームでテストを共有した話(テストの地図)

探索的テストを含む「テスト」をチームで共有したときに、やってみたことを紹介します。キーワードはこの4つ。

・テストの地図(今回はこれ!)
・ペアテスト
・テストの渡航履歴
・朝会とテストの夕会

チームでテストを共有した話
「テストの地図」はテストチャーター(のようなもの)を想像してください。
つくりはじめるタイミングは、ざっくりしたユーザー要件と、大雑把な仕様が出てきて「これから○○という機能を作りはじめるよー」というくらいのときです(プログラマーが実装してからだと遅い)。「テストの地図」は、国境と国名と主要な都市くらいしかない、白地図のようなものから、はじまります。

「こんなものを作るんだよね?」
「ここはこんなふるまいをするのかな?」
「仮にユーザーがこういう使い方をするとして、どうなるのがいいんだろう?」
「これまでのデータの持ち方を変えたりする?」
「前にこんなバグ、あったよね」
「もともとある○○機能には手を入れないの?」
「こんな問題が起きそう」
「わたしならこういうテストをしたくなるかも」

これからつくるモノのイメージを、チームのみんなでディスカッションしながら具体化していき、白地図にどんどん書き込んでいきます。当然(あれ、ここの仕様はどうなっているんだろう?)と分からないところも出てきます。それらは「不明点」として地図に残し、仕様が明らかになった時点で書き換えていきます。

このディスカッション自体が「テストの共有」です。わたしはテスターなので「テスト」を共有したつもりでいるのだけど、これから開発するモノに対してのすべて(要件、機能仕様、ふるまい、テスト、スケジュール、リソース、みんなの疑問 etc)を共有しているのかもしれません。こう書いてみると当たり前というか(なあんだ)という感じですが、こういったアナログで地味な活動がとても大事。他にも良いことがあるので、列挙しておきます。

完璧な仕様(書)がなくてもはじめられる
だから「ドキュメントがないからテストできない」「テストの計画、設計ができない」という事態に陥りません。わたしは自社製品の組み込みシステムを開発しているからできることなのかもしれないけど。でもそんな環境でも、開発チームとテストチームが分かれていたりすると、そういうことが容易に起きたりします。ドキュメントができてからだと遅いんですよ。完璧なソフトウェアがないように、完璧なドキュメントもないんです。(ああ、こんなことを書いたらまた叱られちゃうかも、、、)

暗黙の要件が見つかる
仕様書には明記されないけど一般的にはこう動くべきだよね、といったものを「暗黙の要件」と(わたしは)呼んでいます。この「暗黙の要件」について考えたり、実装そのものや、それに関するテストがポロッと抜けてしまうことがあるんですよね。例えば、マウスダウンのときに動作すべきなのか、それともマウスアップのときに動作すべきなのかとか、そういうの。

つくるモノの要件や仕様がガシッと決まってから考えはじめると、どうしてもそっち(決まっているもの)にみんなの目が行きがちなのかもしれない。

心配ごとが次の行動の入力になる
起きたら嫌なこと(心配ごと)は、それが「起きない」要件なり、テストに展開して、地図に追加していきます。テスターの心配ごとを聞いたプログラマーは、それが起きないように設計、実装していくだろうし、テスターはプログラマーの心配ごとが起きないことを試すために、どうテストしていくのかを考えたり、準備する。データの互換性が心配なら「今のバージョンでデータを取っておいてテストデータにしよう」「どのような種類のデータを取っておけばいいかな」のようにね。

おわりに
「テストの地図」を使い、チームのみんなでディスカッションをしながら「テストを共有」した話をしました。「テストの地図」はディスカッションするためのツールです。「テストの地図を作ること」を目的にしてしまうと、うまくいかなそうなので注意してくださいね。

そうそう「テストの地図」を使ってテストを共有したのは、わたしがいま所属している(ハズれ値かもしれない)チームではない!ので、導入しやすいプラクティスのひとつかもしれないな、と思っています。

「テストの地図」について興味のある方は @miwa719 にメンションしてください。4月23日(土)に開催するとちぎテストの会議に参加していただけると、もっと丁寧にお話しできます!