あるプロジェクトで、障害やQAの後にもテストを書くと、安心感が増すなと思ったのでまとめたいと思います。

テストはないがQAはあるプロジェクト

少し前に、副業でバックエンドの開発をしていました。
プロダクトの性質上、品質保証が重要なためQAメンバーやリリースフローはありますが、肝心のコードはテストが何もなく目視チェックでデプロイしQAメンバーが保証すると言う状態になっていました。

問題は、テストがないため頻繁にバグが再発しQAメンバーが疲弊していくことです。

テストで動作を保証してないので、バグ修正してデプロイしても、罰のバグが再発することに気がつかないことが頻繁に起きました。
そしてそのバグを発見するのは大体QAなのです。

このため、エンジニアとQAでコミュニケーションが増えるし、QAは同じバグを報告することが延々と続くことになりました。

担当していたプロジェクトは短納期のだったので、テスト対象は適切に選択する必要がありました。
その上、慣れてない言語だったのでテストの導入にも時間がかかり、全てのテストケースをカバーするのは難しい状況でした。

QAの結果からテストすればいいんじゃね？

ふと思ったのは、QAのテストが全てpassすればよく、QAの全てでユニットテストを書く必要はありません。

であれば、QAをさっさと通して結果からテストを追加していけば、一度起こったバグはテストで保証されるので効率的なのでは？と考えました。

なので、以下の方法を取りました。

これで、一度起こったバグはテストで保証されていくので、数を重なるたびに信頼度は高まっていきます。
エンジニアも、影響範囲やバグの原因を絞り込むのが容易になるので、修正速度が上がっていきます。

と言うわけでこれで回してみました。

結論から言うと結構うまくいきました。
一度直したバグを潰せていることは、後戻りがないということなので、QAとエンジニアで同じバグに悩むこともなくな精神的に安定して作業が行えるようになりました。

QA中に、エンジニアがリファクタするときも、テストで補償されてるので安心感があります。

このアプローチはQAに限らず、障害にも使えるなと感じました。
TDDの文脈では回帰テストと呼ばれるそうです。
ポストモーテムのTODOに入れるなどしていきたいです。

それでは良きテストライフを