第2回 境界値バグは上流で潰したい | gihyo.jp
ソフトウェアテストの最も基本の技法といえば、境界値分析と、同値クラス分割の名前が挙がります。今回はその境界値のお話しです。 境界値分析はテストの際の基本中の基本ともいえる考え方です。なぜか。実際境界値付近は「バグ多発地帯」だからです。 さて、G.マイヤーズが、古典的名著『ソフトウェアテストの技法』の中で、同値クラスと境界値（限界値）テストの有効性を高々と掲げてから、はや30年以上が経過しました。にもかかわらず、今なお、境界値近傍が「バグ多発地帯」であり続けているはなぜでしょうか。いい加減、根本的な対策法が開発されて、いいようなものなのに。原因を1つに絞り切ることはできませんが、やはり大きな原因は「人間の側」のミスがあとを絶たないからだ、と思います。 ソフトウェアテストの本を読んでいても、『境界値付近はバグが多い。なぜならif文の条件で「＜」や「≦」などを取り違える可能性が高いからだ』と書
「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
第1回 テスト計画（前編） | gihyo.jp
柏田マネージャー： 5年前に新規事業としてソフトウェアの検証事業を自ら企画し、以来ずっとソフトウェアテスト関連事業を統括している。無類の釣り好き。 初めてのテスト計画！？ 中山君は入社5年目の若手テストエンジニアです。入社以来ずっとソフトウェアテストを担当し、主にテスト実施者として経験を積んできました。本人もテストについてはだいぶわかってきたと自信を持ち始めており、そろそろ大きな仕事もしてみたいと希望を持っています。 そんな中山君、ここ数ヵ月担当していたテストの作業が終わり、仕事がひと段落。次の仕事に備えて今までの資料の整理を行っていました。 中山君： 「ふぅ、ようやく片付いたぞ。なんだかんだで大変だったなぁ。でも、以前に比べてずいぶん仕事をこなせるようになってきたなぁ。そろそろ大きな仕事もしてみたいな…」 自分が仕事を始めた頃を思い出して感慨にふけっていたところに、同じ部署の大塚先輩がや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
