はじめに

開発の現場では偉大な先人達による「教訓」のようなものが存在すると思います。

QAの界隈でも同様に、ソフトウェアテストの7原則というものがあり、その中に「原則3：早期テストで時間とコストを節約」があります。
端的に言い換えると「開発工程の早い段階で欠陥を発見・対処できれば、手戻りにかかる時間とコストを抑えることができます」ということです。

多数の方は「テスト」を「機能に対するテスト」とイメージされていると思いますが、今回は非機能テスト(負荷テストやセキュリティテスト)を早期に実施しなかったことにより、後悔したお話をしたいと思います。

非機能テストが後回しになった理由

当時、私は某開発プロジェクトにQAエンジニアとして初期から参画していました。

参画初期には品質保証方針の策定やテスト計画を進めており、品質確保に向けて非機能テストはなるべく早期に実施しておきたいと考えておりました。
ですが、PMから提示された開発スケジュールは、全ての機能を開発し終わってからテストするものでした。

PMに相談を持ちかけたものの、当の私自身も頭ではわかっているものの「早期にテストを実施する意義」を説明しきれず、スケジュールは自身の責任範疇外ということもあり、提示されたスケジュールの通り進めることとなりました。(※原因1)

全ての機能を開発し終わってからテストを実施するスケジュールのため、テスト工程に入ると機能テストに追われる日々となり、非機能テストの段取りも後手後手となりました。(※原因2)

原因まとめ

1. QAエンジニアとして「早期にテストを実施する意義」を説明しきれなかった

2. 機能テストに追われ、テスト工程内でも非機能テストが後回しになった

非機能テストを後回しにして起きたこと

なんとか非機能テストの実施にこぎつけたのですが、性能問題、セキュリティの問題が散見され、多くの手戻りコストが発生しました。
性能問題やセキュリティの問題は、通常の機能テストで検出される問題とは異なり、以下のような特徴があり、より多くの手戻りコストが発生します。

• 仕様通り動いているプログラムに手を加えなければならない

• 改修の際、デグレードのリスクを負う

• 対応によってはプログラムだけではなくDB構造にも影響が及ぶ

非機能テストを後回しにしないためにできること

今後は具体的な回避策として、以下の点を心がけていきたいと思います。

• QAエンジニアとして「早期にテストを実施する意義」を説明したうえでスケジュール策定に加わる、また、スケジュール策定の際は必要機能を絞って、優先順位づけをする

• 仮にテスト工程に入るまで非機能テストができなかった場合であっても、単体テスト工程で非機能面を考慮したテストを実施する

最後に

開発の現場には様々な教訓がありますが、頭ではわかっているつもりでも、後回しになってしまうケースが多々あると思います。
今回の後悔をナレッジとしてまとめることにより、私と同じように後悔する方が少なくなれば幸いです。