【寄稿者】見城コボル
Profile：30代の男性SE。
パッケージをベースにしたシステム導入に携わる。チームプレーをモットーに全力を尽くしている。

SE（システムエンジニア）は自社だけで仕事をするのではなく、他の会社と共同で作業することがよくあります。
色々な会社の人と触れ合うのは新鮮で、いい刺激を受けます。意気投合して飲みに行くことも多いものです。

そんなときに話題になることの１つとして、プログラムのテストの方法があげられます。
「以前の現場はテスター（テスト専門に行う人）をつけて、簡易な機能の修正でも１週間かけてたよ」
というガチガチの管理体制でのテストの話や
「お客に言われた機能ができるかだけを軽く動かして確認し、本番でお客に動かしてもらい、バグがあったらまた直せばいいんだよ」
というあきれるくらい無防備なテストの話もあります。
現場によってやり方は様々なんだと驚かされるものです。

中でも、単体テストの方法が、際立って違います。
単体テストは、IT用語辞典 e-Wordsで以下のように書かれているように、
（http://e-words.jp/w/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88.html）
「仕様書で要求された機能や性能を満たしているかどうかをテストする」
ことが目的です。

加えて、当たり前のことですが、「バグを無くす」ことです。

単体テストでは、大きく以下の３点にで違いがありました。
�．┘咼妊鵐垢鮖弔垢�否か
　※エビデンス……プログラムを動かした画面の動作や印刷物などの出力結果をテストした証拠として保存したもの。
��退行テスト（デグレードテスト）をどこまで行うか。
　※退行テスト……プログラムのバグを修正したことにより、他の機能にバグを引き起こしていないかを確認するテスト。
�Ｊ�数人でのテストを実施するか。
　
　予算のある大企業がマネジメントする現場では、以下の傾向がありました。
�．┘咼妊鵐垢魯謄好肇院璽絞�、全て作成して残す。
�▲丱阿僚だ飢媾蠅離謄好箸世韻任覆�、影響を与えそうな機能や標準的な機能の再テストも行う。
�Ｊ�数人での確認を行う。

一方、予算のない現場では、以下のようにほぼ真逆の傾向になります。
�．┘咼妊鵐垢鮖弔気覆ぁ�テストしたケースのリストも残さない場合もある。
�∈鄒�したPGに任せるため、行わないことが多い。
��作成したPGの確認のみとする。

「機能や性能を満たしているか」という観点では、どの現場でもテストをしています。
満たしていないとお客様がすぐに分かります。さすがにそれを満たさずには納品できません。

しかし、「バグを無くす」という観点でのテストは、現場によって価値観が異なります。バグというのは、納入時にはお客様が気が付かない場合が多いからです。
完璧なシステムを作るのが理想です。しかし、この仕事をして分かるのは「バグは完全になくすのは難しい」という現実です。
プログラムの開発には、与えられた予算と納期があります。
現場の状況により、「バグを無くす」という顧客の要求とは関わらない観点でのテストは、軽視される場合もあるようです。お客様が気が付かないならいいだろうという単純な発想です。万が一お客様が気が付いたら、誤れば済むだろうという考えもあるのでしょう。

でも、そういういい加減なことをしていれば、お客様空の信頼を失います。

ただ、このあたりは会社としての方針であったり、SEとしての価値観にも影響されます。
なので、「バグを無くす」という目的のテストに関しては、冒頭で書いたようにやり方が180度違うものになり、私からすると驚きを感じるのです。

スポンサードリンク