開発が遅れ、納期までの余裕がなくなったとき、私は利用頻度の低い周辺機能なら細かなテストを省略しても影響は小さいと判断しました。
主要機能の確認を優先し、あまり使われない機能は後から必要に応じて直せばよい。そう考えていたのですが、3日後の負荷試験でシステム全体が停止する事態になりました。見落としていたのは、画面上の利用頻度では分からない、内部のデータや処理のつながりでした。
この記事では、なぜ周辺機能を低リスクだと考えたのか、約2か月の対応につながった原因と、今ならテストを削る前に確認することを書いています。
利用頻度の低さだけでテストを削った
そのプロジェクトは、予定より大幅に遅れていました。
開発項目が想定より増え、修正にも時間がかかり、スケジュールにはほとんど余裕がありません。主要機能のテストは続ける一方で、どこかの確認を減らさなければ間に合わないという状況でした。
そこで私は、利用頻度が低いと思われる周辺機能や、主要な処理への影響が小さいと考えた部分について、細かなテストを省略しました。
当時の頭にあったのは、次のような考えです。
- 主要機能が動けば、致命的な問題にはならないだろう
- あまり使われない機能なら、問題が出ても影響は限られるだろう
- 必要になれば、リリース後に修正できるだろう
今振り返ると、どれも確認した事実ではなく、「そうであってほしい」という見方でした。
周辺機能が本当に単独で動いているのか、内部で主要機能と同じデータや処理を使っていないか、高負荷時にも影響が広がらないか。そこまで確かめず、利用頻度の低さだけで危険も小さいと判断していました。
問題だったのは、テスト範囲を変えたことだけではありません。利用頻度と重要度を同じものとして考え、影響を確認しないまま省略を決めたことでした。
3日後の負荷試験でシステムが停止した
テストを省略すると決めてから3日後、納品前の負荷試験を行いました。
最初は順調に見えました。主要な画面は動き、基本的な処理にも目立った問題はありません。ところが、負荷を上げた段階でシステム全体が停止しました。
最初に疑ったのはサーバーの性能やデータベース。処理量が増えたことで、設備側の限界が出たのではないかと考えたからです。
でも調査を進めると、原因はテストを省略した周辺機能にありました。
通常の操作では目立たなかった処理が、高負荷になると想定以上に資源を使い、ほかの処理へ影響を広げていたんですね。画面上は別の機能に見えても、内部では同じデータや処理を共有していたのです。
私は「利用頻度が低い周辺機能だから、主要部分への影響も小さい」と考えていましたが、実際の危険度は、使われる回数だけでは判断できません。
単独で動かしたときには問題がなくても、複数の処理が同時に動いたときだけ現れる不具合があります。今回の問題も、通常時には見えにくく高負荷になって初めて表面化したものです。
不具合が分かったとき、驚きより先に浮かんだのは、「やはり削るべきではなかったか…」という後悔でした。
危険性をまったく知らなかったわけではありませんし、テストを減らせば見逃しが増えることは分かっていました。それでも納期を優先する理由を考えるうちに、周辺機能だから大丈夫だろうと、危険を小さく見積もってしまったのだと思います。
見つかったのは新しい問題ではなく、確認しなかったために見えないまま残っていた問題でした。
本番稼働前の負荷試験で見つかったのは不幸中の幸いでした。利用者が実際に使い始めた後で同じ停止が起きていたら、影響はさらに大きくなっていたと思います。
省略した時間より長い2か月の対応
不具合が判明してからは、原因の特定、修正方法の検討、再テスト、関係部門への説明が続きました。納品スケジュールも見直さなければなりません。
顧客には、なぜ事前に見つけられなかったのかを説明する必要がありました。テストを省略したという事実がある以上、こちらの判断にも責任があります。
その後、原因調査や修正、再テスト、説明を含め、結果として約2か月にわたる対応になりました。
納期を守るために短くしたはずの工程が、実際には何倍もの時間を奪ったことになります。
つらかったのは、作業時間が増えたことだけではありません。遅れた状況の中でも作業を続けていたメンバーを、もう一度原因調査や修正へ戻らせてしまったことが、本当に申し訳なく感じられました。
顧客から見れば、不具合を直したから元どおりというわけにもいきません。
「ほかにも確認していない部分があるのではないか」という不安が残り、修正後の説明や再テストでは、それまで以上に細かな根拠を求められました。
数日を取り戻そうとして、約2か月を失う。
あのとき省略したのはテスト時間だけではなく、問題を早い段階で見つける機会でもあったのだと思います。
今ならテストを削る前に確認する4項目
すべてのテストを当初の計画どおり実施できるとは限りません。時間や人員に制約があり、確認範囲の優先順位を変えなければならない場合はあります。
ただ今の私なら、「利用頻度が低い」「あまり使われない」という理由だけではテストを削りません。少なくとも、次の4点を確認します。
- ほかの処理と、どのデータや資源を共有しているか
- 複数の処理が同時に動く高負荷時に、影響が広がらないか
- 利用頻度が低くても、停止した場合の影響が大きくないか
- テストを減らすとしても、最低限どの確認を残すか
特に注意したいのは、利用頻度と重要度を分けて考えることです。
あまり使われない機能でも共通データや共有資源に関わっていれば、問題が起きたときの影響は広がりますし、利用頻度が低いことと不具合の影響が小さいことは別に考える必要があります。
テストを減らす必要があるなら、何を省略するかだけではなく、何を残さなければ危険なのかを先に考えます。
たとえば、すべての条件を確認できなくても、共有資源を使う処理や、同時実行時の動きだけは残す。通常時の確認だけで終わらせず、負荷を上げた場合の挙動を限定的にでも見る。そうした最低限の確認方法を考えます。
それでも危険を判断できない場合は、テスト削減以外の方法も検討する必要があります。当時の私は、「予定どおりすべてを出すか、テストを削るか」という二択にしていましたが、提供する範囲や順番を変える選択肢もありました。
「テストを削るしかない」と最初から決めないことがとても重要なんですね。
まとめ
利用頻度が低い機能でも、内部でほかの処理とデータや資源を共有していれば、不具合の影響はシステム全体へ広がる可能性があります。
テストを減らすときに見るべきなのは、使われる回数だけではありません。高負荷時の動きや機能同士のつながりを確認し、どのテストだけは残さなければならないかを考える必要があります。
あのときの私は、「あまり使われない機能だから大丈夫だろう」と考えていましたが、今は内部でどこにつながっているのかを確認できるまでは、利用頻度だけで危険の大きさを決めないようにしています。
コメント