今日はテストについて考えていたので、テストについて書いてみます。
唐突ではありますが、ここ最近受託、自社問わず開発や制作をしていると確認作業というものは絶対必要で、これが結構厄介です。

テストをしたことない人にざっと確認だけしてもらうと、どうしても漏れが出てきます。
それは確認不足というより、「分からない」のでチェックしようがない、という場合が多いようです。

ですので、テストする人にお願いするにしても、どういうチェックをして欲しい、ということを伝えないと抜け漏れは出てくるものです。

そこで、誰かにテストを頼む時どういう部分を簡単ではありますが、自分の再認識の意味も含めて、テストのポイントをまとめてみました。
きちんと 試験項目票を作るべきだとは思うのですが、短期間の制作だと人員と時間がなかったりします。

誰にテストしてもらうにしても、ポイントはおさえておきたいものです。

1.　仕様に沿った正常ルートのテスト

仕様書があれば、、、の話しになってしまいますが、どういう機能がどういう動きをするのが正解なのか、すべての動作を確認します。
少々面倒ですが、登録したり編集したり削除したりして、本当にきちんと普通に確認しないといけません。

「この機能が動かない」という状況は避けたいものです。

2.　はじかれるべきエラーのテスト

たとえば入力必須とか文字数制限などがある場合、ちゃんと指定条件以外でエラー扱いされるかの確認です。
エラー処理も規模によっては沢山あるのでくまなく確認しておきたいところです。

3.　セキュリティーチェック

データベースを使用したサービスなどであれば、SQLイジェクションとかクロスサイトスクリプティングとか、そういったセキュリティー面に関してのテストです。概念についてはWikiなどで調べれば結構出ているので、専門的に感じますがディレクターであれば把握しておいた方が良いかと思います。

こういうテストはテストデータの定義だけしっかり作っておけば結構簡単なテストなので、しっかり確認しておきたいものです。

4.　内部的な処理テスト

たとえば、画像投稿機能であれば、ちゃんと削除した画像が消えているのか？編集した前の画像が残っていないかなど、ユーザーから見たときに見えない部分の動作確認です。
こういう内部的なものはエンジニアが処理忘れしていたりする時もあるので、突っ込んで確認しておきたいところです。

5.　クライアントに確認してもらう際のテストデータ

これが結構重要なのですが、テストデータにちょっと面白いおかしいデータをあげてテストしたりする人がいます。
（私もそのひとりではあるのですが。。）
それはそれで人様に見られなければ良いのですがクライアントに見られたりしたら大変です。

こういうテストデータについては、誰かに見せるとき必ずきちんとしたテストデータにしておく必要があります。

——-

で？誰がやるの？

ということになるのですが、Web系の開発や制作に関して言えば、テスターの方がいれば最高なのですが、恐らく確認作業というとディレクターの方がやったりすることが多いと思います。

結局バグがあって怒られるのはディレクターだったりするので、覚えておいた方が良いでしょう。