新人プログラマー必見!?単体テスト仕様書を作成する時の注意点

こんにちは^^仲ちゃんです。

新人プログラマーでなくても、単体テスト仕様書を作成する場面と言うのは多々あります。

 

仲ちゃんがプログラマーからシステムエンジニアの仕事をしていたときも、要件定義や設計はもちろんですけど、プログラミングやテストも、運用保守もしていたので、それに関するドキュメントは作成していましたよ^^

 

今回は、単体テスト仕様書を作ったことがない新人プログラマーの貴方に、仲ちゃんから、単体テスト仕様書の作成方法と注意点をご紹介しますね!

 

作成方法といっても、イチから作るわけじゃないので、仲ちゃんが作ったサンプルを元に、説明していきますね!

 

Sponsored Link


 

単体テスト仕様書の作成方法

こちらは、仲ちゃんが最後に参画したプロジェクトで使用していた単体テスト仕様書のフォーマットを思い出して、作ってみたものです。

※もちろんマネできるところがあれば、ご活用ください。


文章ばかりだと、わかりづらいと思うので、サンプル仕様書を見ながら、読み進めて行ってください。

正直ですね、現場によって、仕様書のフォーマットも違うし、項目も微妙に違うかもしれません^^;

 

ただ、新しくイチから作る必要はなく、既存のフォーマットが必ずあるはずなので、その仕様書に合わせて、作成していってください。

※仲ちゃんが作ったテスト仕様書が欲しい場合は、個別にコメント頂ければ、ファイルをお渡しします。

 

フォーマットは違っても、必須項目には、ほとんど差がなく、検証内容、確認項目、想定結果、実施手順、合否判定、エビデンスNoなどは必ず入れておきたい項目かなと。。

 

では、単体テスト仕様書を作成するにあたり、注意点をいくつかお伝えしますね。

 

単体テスト仕様書作成時の注意点!

 

1.単体テストの目的を知ろう

 

これから、検証を行うプログラム(機能)は、一体どんな役割をするのか、今一度考えてみましょう

目的を知ることで、どんなことを検証しなければならないかわかってくるので、仕様書作成前に考えておきましょう!

何を確認できれば、テスト完了なのか?ということです。

 

例えば、出力された、CSVファイルのデータを見て、○○に変換されていたらおしまいなのか?

 

想定していた、データ件数がテキストファイルに出力されていれば、それでオッケーなのか?

 

作ったシステムでその処理を動かして、ステータスが正常終了であると確認出来たら、それでオッケーなのか?

 

など、ひとつひとつのテスト項目が、何をもって合格なのか、知ることは大切です。

 

さて、どんなことを検証しなければならないのかわかってきたら、具体的にテストケースを作成します。

 

2.テストパターンを洗い出して、表にしてみよう!


 

さて、実際に具体的な検証内容を洗い出してみましょう。

 

ここはちょっと、仲ちゃんから簡単に説明してみたいと思いますが、

 

例えば、社長、部長、課長、社員の内緒の手当額を計算するとします。

それぞれ、内緒の手当金額を算出するには、内緒のランクによって振り分けられます。

内緒のランク:社長⇒A、部長・課長⇒B、社員⇒C

内緒の手当の金額は、ランクごとに、

A:50,000円、B:30,000円、C:10,000円とします。

 

結果としては、社長の手当ては、50,000円、部長と課長の手当ては30,000円に、社員の手当ては10,000円にセットされてたらオッケーなわけですよね?

 

となると、テストケースは以下の通りです

 

テストケース1:ランクAの従業員は(社長)の手当額が、50,000円になっていること

テストケース2:ランクBの従業員は(部長・課長)の手当額が、30,000円になっていること

テストケース3:ランクCの従業員(社員)の手当額が、10,000円になっていること

テストケース4:ランクなしもしくは、異常値(DとかEとかw)が設定されている場合は、手当額が0であること

 

テストケース4では、たまに例外が起きる場合があるので、これを想定したテストも必要です。

システム開発では、ありえない!と思っていることが、ある日起きたりしますwなんでこうなった!?って^^;

なので、ランクにはA、B、C以外の値は入らない!と思っても、誰かの入力ミスで、変な値が入ってくる可能性もあるんですw

Dランクの場合は、手当0ですけど、もし10,000とか金額が設定されていたら、プログラムのミスなので、そういったミスを事前に見つけるという目的もあるんですよ^^

ですから、そういった予期せぬ事態があっても、結果が正しくなるよう、単体テストでは、これらすべてを確認しなければなりません。

 

3.レビューの前に、誰かにチェックしてもらおう!


全てのテストケースを洗い出し、単体テスト仕様書に反映させたら、リーダーや設計者の方とレビューを行います。

その前に、お近くに仕事が出来て、話しやすそうな優しい人がいたら、こっそり昼休みとかに、聞いてみてもいいですよ。

何かしら、先輩から、仕様書の書き方から、テストケースに漏れがないかなど、チェックしてくれるはずです。

恥ずかしいかもしれませんが、不安なままレビューするよりはずっといいです。

新人のころは、誰かに話しかけるのも戸惑ったりしますよね。。

仲ちゃんは、なかなか自分から話しかけるようなタイプではなく、いつも不安ばかりで、億劫な性格だったもんですから、隣の先輩に聞くことさえも、ためらっていました^^;何も進まないのにね笑

 

けど、わからないものはわからないんです!不安なものは不安なんです!

恥をかいてもいい!と割り切れたらいいんですが、これだけは最初の1歩。。あなたの勇気だけです。

 

なので、今このような状況な場合、ぜひ仲ちゃんにコメントしてください。お悩み、不安、思う存分ぶちまけてください。

他に、単体テスト仕様書の書き方なども、アドバイス出来たら親切、丁寧をモットーにさせて頂きます!それではまたです!

 

 

 

 

 

 

Sponsored Link

ABOUTこの記事をかいた人

仲ちゃん先生の最終学歴は、高卒(県立)です。 田舎から東京へ行き、フリーターを2年経験。 21歳の時、未経験で正社員のプログラマーに!! 正社員として2年半、その後転職して フリーランスとしてシステム開発の仕事を6年半。 合わせて9年間行ってきました。 要件定義~納品。運用保守まで担当。 主な言語は、PL/SQLです。 現在は、理由(ブログでご覧ください)があって サービス業に従事(薄給ですw) もし、現在の仕事(ITでもサービス業でも)で 悩んでいることがあればお気軽にコメント、ご相談ください^^ 経験者として少しはお役に立てるかと思います。