…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。
今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。
しかし現実は単体テストレベルのバグがわんさか…1日50個とか…出ています。
設計書やテストケース等、ドキュメントが古かったのが原因の内容もありますが(これはこれで構成管理の問題がありますが)。
このプロジェクト規模はトータルで50～70人月です。
テストフェーズでバグが出ること自体は良いのです。
＃テストフェーズでは品質の向上が目的ではなく、あくまで品質レベルの確認をするだけです。品質を作り込むのは上流工程とよく言われています。
問題はその内容や傾向、テスト消化件数、バグ件数が「見える化」されておらず、管理されていないことです。
「どの機能にバグが集中しているのか？」や「内容には傾向があるのか？」等が分かれば、手の打ちようがあるのですが、それが分からない状態です。
もう1つの大きな問題は、不具合修正とテスト実施を同時に行い、パスしていたテストケースがパスしなくなる…デグレード(orレグレッション)が発生していることです。
さらに怖いのは回帰(退行)テストをしてデグレードが見つかったわけで無く「偶然」見つかっていることなんです。
回帰テストができない理由は、テストの自動化を行えておらず、手作業で回帰テストが出来る程リソースがないからだと思います(私自身、途中からの参加＆そういう立場でも無かったので「なぜか？」は分かりませんが)。
で、上記2つの根本的なところとして、テストマネージャー的位置付けなロールがいないのです。
その結果、見える化が出来ず、テスト計画も行き当たりばったりな感じなのです。
実際はテスト消化件数等数字は出るようになっていたのですが、それはQMS等への報告用でしかなく、それを使って何か対策を打つまでは出来ていなかったのです。
テストをしながら、私が数年前に参加したプロジェクトは全く違っていたなぁと思い出しました。
そのプロジェクトでは単体テストフェーズに入ると、それこそコメントであれ、一切プログラムを修正しないをルールとしていました。修正すれば影響範囲を見極めた上で再テスト(これが回帰テストです)を行うという運用でした。
＃この影響範囲の見極めも、早めにテストケースを上げて、それにそって実装していたのでやりやすかったというのがあります。
当たり前ですが、バグ管理、グラフによる見える化を行っていて、先手先手で再テスト、ソースコード見直し等を行っていました。結果、デグレードは発生せず、リリース後の不具合もほぼ0件の稀にみるプロジェクトでした。
数年前から「システム開発のキモは上流工程」と言われ続けていますが、このプロジェクトも結局は上流工程の要件定義や基本設計が遅れていきました。
その結果、本来テスト計画をしないといけない時期にも出来ず、それが今の状況になっています。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: rgieseking via Visualhunt.com / CC BY
コメント