やぼったい開発 > ウォータフォールモデルによる開発手法の基礎 > 単体試験の基礎(UT) > よくある試験作成ミス(アンチパターン)

よくある試験作成ミス(アンチパターン)

初心者だからと行って甘えられるのも最初のうちです。
まだ許されるうちにいろいろ学んでおきましょう。 ダメ人間にならないように。

  • とりあえず作った。数が多いだけの試験項目
  • 中身を理解せずに、ソースをなぞっただけの試験項目
  • ほぼ正常系だけしかない試験項目
  • パターンが 1パターンしかない、パターン考慮のない試験項目
  • 役割、作業分担が違う(対象モジュールが不足、試験データの作成もひつようだったなど)
  • 試験観点しかない試験項目
いずれも共通するのは、仕事として価値が低いということです。
中途半端な仕事をしても、残作業も多くなり結局追加でしなければいけないことが増え、やった仕事の成果が半減してしまいます。

言われたことそのもののみをやるのは、 バイトや空気の読めないひとだけです。

職業としているのであれば、せめてそのレベルぐらいはクリアしましょう。

実際リストラを先にされるのは、そういう仕事ぶりの人からです。 (リストラされる人がそういう人、という意味ではないです)

とりあえず作った。数が多いだけの試験項目

工数がかかる割に、抜けが多く、ほぼ全やり直しになる可能性が高いです。

そもそも理解するところが全然足りてないどころか、仕事自体も全くしていません。

中身を理解せずに、ソースをなぞっただけの試験項目

なんかできてそうですが、本質的には抜けがあります。

上と基本的には同じですが、チェックは多少深く見ないと気付けないです。

こういう仕事ぶりの人には、フォローする人を付けないといけなくなり、コストがかかります。

理解させたり、報連相の徹底が必要です。

ほぼ正常系だけしかない試験項目
パターンが 1パターンしかない、パターン考慮のない試験項目

開発初心者に多いミスです。
異常系は多少頭をつかうので、慣れが必要であったり、理解力が必要であったりします。

うまくいく場合だけを考えているのが問題です
ファイルがあるのか、ないのか、1回目の起動なのかそうでないのか、 タイミングがずれたのかずれてないのかなど、状態を厳密に想定し、具体的に動作に問題ないのかを確認します。

また設計書に深く書いていないこともあり、新規参加メンバーには見えない部分があるため、既存メンバーのフォロー・チェックが必要です。

役割、作業分担が違う(対象モジュールが不足、試験データの作成もひつようだったなど)

具体的に指示されない時もありますが、ある程度範囲を明確にして、 作業にとりかかります。

作業に取り掛かったあと、具体的にタスクの全貌が見えるはずなので、その時にまだ不明点があれば、明確に(具体的で詳細に)確認しておきます。

作業が完了してから、確認してしまうと時間が取り戻せないですから。

ただ、他にも重要な問題がココには、はらんでいます。。。

試験観点しかない試験項目

試験手順を省くと、試験実施できるかどうかが分からなかったり、試験実施タイミングまで試験手順考慮の作業を後回しにしているため、後々時間がかかり、一層大幅なスケジュール遅れが発生します。

類似コンテンツ

結合試験とは

単体試験と機能試験の違い

JUnitの役割はどこまで? 試験工程内で 単体テストのできることとできないこと


ウォータフォールモデルによる開発手法の基礎 > 単体試験(UT)

http://www2.ocn.ne.jp/~cheerful/develop/
since 2001/3/3
http://www2.ocn.ne.jp/~cheerful/develop/index.html