システム開発定跡研究室−テスト #01− 「テスト前には リセットを・・」
ちょっとした思いつきでまとめていきたいことが出てきたので、新しい内容で書き始めようと思います。よろしくおねがいします。
なぜ「定跡」？
内容に入る前に、なぜ「定跡」か？というところを、ごく簡単に。
プロジェクトとか組織とかで、ルールとか標準とかを定義していることがよくあります。それ自体良いことです。
ただ、ルールや標準があることによる弊害も少しばかりですがあります。
ルールや標準が作られた意図が理解できていない
ルールや標準が変更されず重要でないものが多く残っている
この、特に1.のほうの改善を図りたいと思い、将棋の定跡のようなものができれば、ということを考えました。
将棋の定跡のいいところは、いくつかパターンがあることと、なぜこの手順に行き着くのかの解説がのっている点です。これをたどることで自然と意図が理解でき、定跡を組み合わせた応用やそこから新たな定跡を生み出す、といったことも可能となります。
こういったことを目的として考えています。
テスト前には リセットを
では、本題です。
テストフェーズというのは細かいところから全体的なところまで様々ですが、今回は特に、プログラムを作ったあと自分でそれが正しく動くかテストする、というときの話です。
プログラミング後の単体テストのときなどで、「特に問題なかった」という報告を受けたあとの結合テスト段階で、単純なミスが見つかることがあります。
もしプログラミング担当者から「あれ？そんなはずは」「確認したはず」といったような言葉がもれてしまうと、さらに不信感が生じます。
これは、
確認したというのにミスっている
＝確認してない
＝確認したという言葉は当てにならない
という公式が成り立ってしまうからです。なので、動作確認したのか、してなかったのか、違うケースでは確認していたのか、データによって挙動が違ったのか、等々をきちんと分析して、報告したほうがいいです。
また、なぜこういったことが起こりやすいかというと、プログラムを作っているときはうまく動くように考えていって、それが全てできたので完成、ということで、誰しも完成した瞬間は「間違っている箇所がない」という心理になっています。
※もし間違っている箇所がわかっているなら完成していないことになるので。
まずは、誰でも陥ってしまうこの心理について理解し、その上でどういった工夫をするか、というところです。
結論
なので、テストに入る前にはいったん「完成した」という満足から離れることが大事です。加えて、完成したプログラムを巣立たせて、子離れすることも、です。
なので、1日あいだをおいたり、違う作業をあいだに入れたり、といった工夫をします。また、設計書を読み返して理解していた内容を再構築するのもいいと思います。システム全体の要件だったり概要だったりに立ち返ってみるのも良いことだと思います。
そうやって、いったんこれまでの理解をリセットしてから、プログラムが正しく動くかをテストしてけば、不要な不信感も生じなくなります。
初回なので、あとがき
今回のは定跡というよりは格言っぽかったですね。あと、普通に当たり前、そんなこと当然でしょ、みたいな内容になってしまいました。。。
（内容はともかく）こんな調子で、できればタイトルは記憶に残りやすいように七五調、内容は毎回1000字以内＋図くらいでできればなぁと思っています。
（今回は初回の前置きとかがあったので、文字数増えてしまいました。。）
ご意見等あればコメントお願いします。