やぼったい開発 > ウォータフォールモデルによる開発手法の基礎 > 単体試験の基礎(UT) > 試験項目作成のこつ

試験項目作成のこつ

試験づくりに慣れてくると当たり前ですが、 最初、ちょっとしたことでも躓くことがあります。 そんな時、このぺーじに書いてあることを前もってしておくと あとから効果が実感できます。

だいたいは、ちょっとしたことです。それを実行するだけで効率は良くなります
問題は、心理的な壁かもしれません。

なかなか、試験項目作成が始められないときは

その工程の最終成果物を明確にする

いろいろ原因がありますが、 ホントの初心者の場合、何をしていいかわからない時があります。
そういう時になかなか試験を作り始められない場合は、過去の試験項目書を見せてもらいます

どんな仕事でもそうですが ゴールをイメージできると、作業がやりやすくなります。

何をしていいかわからない

タスクリストも作れないぐらい、もやもやしているときは
作業範囲や対象機能等を明確にした上で やらなければならないことをリストアップします。

試験計画書や INPUTとなる 仕様書を明確にします。
メッセージや 設定が書かれた仕様書や、ファイル仕様書、DB仕様書など必要なものを具体化します。

そして、何を知らなければならないのかが見えてくると TODO リストが作れるようになるはずです。

できる人の価値のある試験項目の作成方法

UTの目的にあるとおり、仕様・機能を理解する事が大事です。 まずは対象部分の全体について、目を通します。 関連する周辺機能やシステムについても概要ぐらいは理解しておきます。

全体を把握したら次に、実際に今回の開発内容を深彫りしていき、必要な詳細レベルまで理解します。

気になるパターンや状態がいくつか出てくると思うので、その場合推測や自分なりの考えを添えて、機能担当者に質問してみます。

レビュー前に自分なりに不安なところを解消しているのがプロの仕事ぶりです。

甘えのある人や優秀でない人は、上記の作業がことごとくされていないことが多いです。

効率のよい進め方(チームパワーを使う)

初めての人がいる場合はフォローしましょう。
サンプルをみんなで共有すると、UT作成の立ち上がりが早くなります。

自分は関係ないと言って工程を進めてしまうと、 結局その人の遅れをチームでカバーしなければならなくなり、時間がない中で遅れをリカバリーするくらいなら、時間のあるうちにその人のパワーを使って仕事をしている状態の方が、結局みんなのためになります。

「情けはひとのためならず」や「All for one , One for all」って言葉もありますしね。

類似コンテンツ

結合試験とは

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

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


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

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