システム周りのテストは当社のような少人数の制作会社にとって毎回頭を悩まされます。
何に悩まされるかというと、バグそのものは自分の問題として、テストの進行そのものについてです。

制作の体制としてディレクターとエンジニア、デザイナーでチームを組んでいたとするとテストするのはたいていディレクターだったりします。

もちろんテスト部隊をきちんと組んでいたり、外部のテスト会社へ発注してテストされている会社もあるでしょう。
ですが、テスト工数や費用をきちんと取れないなどの要因で、実際には間接的な役割であるディレクターの方がチェックすることが多いのではないでしょうか。

こういった場合にディレクターの方にテストについての見識があれば問題ないのですが、闇雲にチェックしてしまうと、どうしてもチェックの抜け漏れが出てきたり、システムテストと言っても浅いレベルでしかチェックをしきれなかったりします。

今回は少人数体制でもテストとバグ修正をしやすいテスト計画のポイントについて考察してみました。

やり方は会社や人によっても違いますので参考までに。

 

マトリクスなどを作成してチェックポイントを明確にする

できればテストをする際にテスト項目票をきちんと作成してテストを実施するのに越したことはありません。

ですが、リリース納期や工数などの様々な要因で時間をかけずにテストをしないといけない場合もあります。

こういった場合によくやってしまうのが、ざっくりと全体的に登録や編集をして表示されたところまでを確認するというテストの仕方です。
こういうチェックの仕方をしていると、細かい部分でチェック漏れが発生します。

具体的にいうと、例えばページャーをクリックして次のページへ行ってみたら検索条件が初期化されてしまった、などの細かいバグです。(もしかしたら細かくないかもしれません。)

もちろん細かくチェックできる方もいらっしゃると思うのですが、人間見落としはあります。

闇雲に登録などをしてチェックするのではなく、画面の要素に対してどこの何をチェックするのかチェック票などを用意してからテストをするのが良いでしょう。

 

時間を区切ってチェックをする

テストをしていると初期のチェックではバグが多すぎて大混乱をきたす場面があります。

ここでよくあるのがエンジニアが修正しつつ、テストを実施してしまっているケースです。
これをやってしまうと、場合によっては重複した内容のバグをいくつも挙げてしまい、バグ件数だけが膨大な量になってしまい、エンジニアの精神的負荷も大きくなってきます。

バグを起こすのが悪いんだ！と言われてしまうとそれまでですが、修正するエンジニアも人間です。
ゴールが見えてこない作業は嫌になってくるものです。冷静に対処すれば問題ない場面でも精神的な負荷をかけることで新たなバグを生み出すこともあります。

ですので、機能毎もしくは時間をきちんと区切ってテスト⇒修正を繰り返すのが一番確実かな、と思います。
やみくもにチェックして気が付いたところをどんどん挙げていくのではなく、品質のゴールを明確にしながら進めていくのが無難です。

修正する側としてはテストと修正を区切ってひとつひとつ課題を潰していくという部分が非常に重要だと思っています。



 

セキュリティー関係のチェックは分かる人にきちんと確認

例えばディレクターの方がテストを行う際に、SQLインジェクションなどのセキュリティチェックについてはどのようなテストを行うのか知っておく必要があります。個人的な経験からいうと、ディレクターの方がシステムのセキュリティー周りのことに対して広く知識を持っているということは少ないように思います。

とはいえ、勿論チェックは必要なので、事前にエンジニアの方とセキュリティ周りのチェックポイントや対策について話合いを行い、それに基づいてテストデータを作ってからテストすることをお勧めします。

当社ではテストデータ含めてドキュメントを用意して誰でもデータを使えばテストできるようにしています。

 

バグなのか改善なのかを明確に

最後に現場が納期に差し迫ってピリピリしているときにネックになるのが、バグなのか仕様変更(改善)なのかという種別分けです。

バグと改善や要望などを混同して挙げてしまうと、混乱と怒りを生み出す原因になります。
例えばバグだけを先に挙げて改善は一通りバグが修正された後で挙げるなど、フェーズをきちんと分けたほうが修正はスムーズです。

「これは仕様なんだよ！」
なんていう怒号を聞いたことある方も多いと思いますが、一つの要因としてはレポートの挙げ方だったりします。



 

 

少ない人数だからこそ計画的にテストをやらないと大混乱を来たす場合もあります。
テスト＝チェックくらいの考えでテストをするとチェックの抜け漏れが結構出てきてしまいます。

仕様を理解するのはもちろんのこと、テストをするにはそれなりのテストの知識が必要です。

もし、ディレクターの方でシステムテストをやることになった場合、上記のような点に注意すると良いかと思います。