バキバキQAチャンネル Advent Calendar 2025 の 15日目の記事です。
https://adventar.org/calendars/11367
ポエムです。私見MAXです。
ちなみにタイトルはこういう形で書いていますが、私自身が開発者であった時期が大半であるため、自戒も込めています。
なぜ開発者によるテストは見落としが多いのかを考える
体感寄りの話ですが、開発者として経験から考えてみます。
対象と考えているスコープが狭かった！
簡単な改修と思っていて気軽に変更したら、実は他の機能やインターフェースに問題が出てしまうパターン。 割と大きめのプロダクトを触っているときはこのミスをいっぱいしてきました。大きいシステムは、大変。
ロジックの分割やドメインの分割をしている場合も要注意ですね。 ソースコードに対して参照箇所がないか、しらみつぶしに探しておきましょう。 テストコードがしっかりと書かれているプロダクトの場合は、テストコードの実行でも見つかるかもしれませんね。ただしテストコードが通るからと言って影響がないと言い切れないのが怖いところですが…。
やっぱりありがちなのが、その機能に対してのテストは書いて実行していくのですが、意図していない影響については当然テストできていないので問題が起きたりします。 コードレベルの話は開発者にしか意識しずらい問題ところなので、開発者がしっかりと見なければいけない箇所だと思います。
抑えるべきテストケースが足りていなかった！
ビジネスロジックを突き詰めていくと、この問題が起きがちかなと思います。 分岐とかそもそも増えていくと見直しが増えますよね。
と言うわけで、見落としによってテストケースが作成されないことにより意図してない状態が生まれてしまい、そのままとなることもあります。
元々の要求や背景から考えて仕様をよく疑うのも大事かもしれません。
例外処理
正常系や意図した異常系のみしかカバーできていないパターンで見落としてしまうパターンもあります。
特に達成したい目的としては正常系のくだりはしっかりと要件整理、仕様設計される印象がありますが、異常系やエラーハンドリングに関しては後回しになる傾向が強く、気がついた時にはもうリリース前、ということもあります。
目的としていることを達成するのも大事ですが、意図している道から逸れてしまった場合にどうフォローするかも大事であり、その点もテストでカバーしたいところですね。
開発者以外の関わる方についても
仕様の抜け漏れや、例外処理といったところは後から気がついて直すというケースもよくあるように思います。この点は思ってる以上にテストしてるから大丈夫、などで抜けていってしまう傾向にあると思います。
今一度、背景や要件、要望、仕様についてもよく全員が理解した上でテストしていくことが大事なのかも、と思います。
開発者でないと気が付きにくい点もあれば、普通に使っておかしいと気づく点もあります。 そういった点を意識していくこともまた大事ですね。
まとめ
良いものを作るには一人の努力や専門性だけではどうにもならないところがあります。 もちろん意識していくことを増やして自然にやれるようにしていくことは大事ですが、一人の開発者のテストの抜け漏れを他の人がレビューなどでフォローできる体制が理想だと考えます。
なのでみんなで良いものを作ろう、それが一番大事ですね。
