ソフトウェア開発者の日常

こだわりなく書きたいことを書いていきます。

テスト内容の充実具合は、どれだけ発想できるかで決まる

スポンサーリンク

自分で作成したプログラムをテストする機会、同僚が作成したプログラムをテストする機会の両方があります。
どちらの機会でも、テスト内容に相違が無いように、チェックシートやテスト仕様書を作成します。
チェックシートやテスト仕様書に沿ってテストをすれば、誰がやっても一定水準のテストを行って、プログラムの動作検証ができます。

簡単な修正内容になると、チェックシートやテスト仕様書を書くまでもないと思って済ませたくなります。

文字の表記だけの修正であれば、不要だと思います。
選択肢が4個から5個に変わっても、増えた影響は選べる数が変わるだけなら不要だと思います。

テスト
unsplash-logoBen Mullins

簡単な修正でも、チェックシートやテスト仕様書が必要そうなケース

入力項目において、最大の文字数内で入力されているかチェックをしていました。
依頼元からの要望で、

  • ある項目の選択肢Aを選んだ場合は、最大の文字数内で入力されているかチェックをする。
  • ある項目の選択肢Bを選んだ場合は、最大の文字数内で入力されているかチェックをしない。

という仕様になりました。

修正は簡単で、ある項目で選ばれているのが選択肢Aの場合だけ、チェックを行うようにすれば終わります。

このような修正を同僚にお願いして、修正できたというので、試してみたら、

  • 選択肢Bを選んで、選択肢Aを選んだ場合の最大の文字数以上を入力し、入力内容確認画面に進んでもエラーとしてチェックはされないことを確認。戻るボタンを押して入力画面に戻ると、なぜか選択肢Aを選んだ場合のエラーメッセージが表示される。
  • 選択肢Bを選んで入力内容確認画面に進むと、入力内容確認画面に文字数を表示していたのが、表示しなくなっている。

といった不具合を指摘していました。


1点目は、項目を選び間違えて入力内容確認画面に進み、戻って修正するという可能性を思いついて試していました。
2点目は、選択肢Aを選んだ場合の最大の文字数より1文字多く入れたから、その1文字多い数字が表示されるだろうと思って試していました。

プログラムを見て、発生するのではないかと試したわけでもなく、どうなるだろうという思いつきで試した結果です。
決まった通りの動作をするのは当たり前ですが、修正による影響がどのようにでるのかの想像をしながら試していき経験を積むと、自分自身の能力の向上にもつながります。