Brandnewdays | SEコラム

システムエンジニアのためのコラムです。
プロジェクトを結成して、比較的大きなアプリケーションを作成する人を対象にして書いています。

システム開発をやる上で、避けては通れないフェーズが「テスト」。おそらく「テスト」と聞くだけでげんなりする人も多いかと思います。今回は、最も初期に行なうテストである「単体テスト(UT)」について、実施する目的や方法、品質面で考慮することなどを書いてみます。

大抵のプロジェクトでは、プログラマは「設計書に書かれた日本語」を頼りに実装を進めます。多くの場合、設計者の意図は正しくプログラマに伝達されるのですが、設計書に少しでも曖昧な表現が紛れ込んでいた場合、正しく伝達されるとは限りません。

前回は単体テストについて書きましたが、今回は次のフェーズである「結合テスト」について、テストの目的や観点、テスト計画を立てる際の方針などを書いていきたいと思います。

こうした仕様の劣化コピーは、どのようにして防げば良いのでしょうか？設計書の品質向上、設計者とプログラマのコミュニケーション増加など、「劣化」の度合いを小さくする手段はいくつか考えつきます。

今日は「会議」の話です。ただ、あまりにも当たり前の話なので、「そんなのわかってる！」という人は読み飛ばしてください。しかし、世の中にはそんな当たり前のことも出来ない人がいるわけで……。今日はそんなお話です。

とあるプロジェクトで、SEとプログラマ(PG)が言い争いをしています。 SE「このプログラム、バグってるんじゃないか？」 PG「だって、設計書どおりに作ったんですよ？」

まず、設計フェーズです。 SEはユーザと打ち合わせを重ね、決定事項を設計書にまとめます。この時点で仕様を把握しているのはSEだけであり、プログラマには何の情報も渡されていません。

ご相談、お見積もりは下記よりお願いします。