おや？いつの間にTDD開発をしているのではないか？

ライフイズテックのサービス開発部でQAを担当しているotkyskです。
もう8月が終わり、自身の誕生日を迎える手前での投稿です。

今回は弊社学校プロダクトの開発プロセスについての気づきをつらつら書いていきたいと考えています。

TDDって何でしょうか？

TDDの概要はテストを優先してプログラム実装をすすめるソフトウェア開発手法です。テスト駆動開発を採用することにより、早期にバグを発見できる上に、必要な機能を無駄なく開発できるようになります。

開発的な話を読み解くと、テストコード（テストコードは非常に広義であるが）を書いて、テストコードを通過するよう実装していく開発手法であるとも言われてます。

テストファーストとの差分についても上述したリンクにも書かれていますが、個人的に本質は同じなのでは？と考え、割愛します。

弊社での開発プロセス

弊社学校プロダクトでの開発プロセスは簡単に書くと要件定義→テスト設計→実装＋テストケースを使った動作確認→テスト実行という流れになっています。テストコードではないが、テストケースを使っているところがTDDに近しいのではないか？と考えられました。TDDにしよう！と社内で宣言した訳でもあるまいのにQAに参画して９ヶ月弱、「あ、いつの間にTDDを実行しているんだな？」とも。

弊社で工夫している点としては要件定義→テスト設計の段階で「仕様の曖昧度」、「仕様の抜け漏れ」、「既存機能に対する影響」、「多端末による依存調査」、これらを観点として機能仕様書のレビューをQAである自分がします。POとのラリーが多い時もあれば（この時はMTGですり合わせしてFIXさせる）、ラリーが少ない時もあり、機能仕様書をFIXさせテスト設計に入ります。

テスト設計して出来上がったテストケースをPO、開発にレビューしてもらって、齟齬が無いかを検証・修正反映してテストケースをFIXさせ（仕様変更が入ったら適宜修正・更新）、それから実装・動作確認、テスト実行に入るといった流れになっています。

課題は出てくる

一番は開発メンバーの負荷。実装して動作確認を１ブラウザ（弊社はクラスブラウザテストなので抜き取りで動作確認する）で行う事で負荷は高まります。これはTDDのデメリットとして挙げられます。
また、技術的に実現不可能による仕様変更に伴い、要件定義〜テスト設計までロールバックする事も挙げられます。最近の開発規模では軽微な仕様変更なので要件定義〜テスト設計の修正・更新、もしくは、次のスプリントにスライドするなどと柔軟な対応をして機能開発を進めています。

効果はどうか？

結論から言うとバグ密度（プログラムを実装して何件バグを埋め込んだか？といった指標）は下がっています。やはり、実装していって、いざ動かしてみたら期待値にならないので直そうと繰り返しが行われているおかげか、テスト実行前でのバグ検出数が減ってきているのは確かです。さすがにテスト実行時は、クロスブラウザテストなので他の端末（特にタブレットやスマホ）での特定バグの流出は防げてないのはやむをえないかと考えています。いや、むしろテスト実行時に検出すべくバグなので許容できるかとも考えられます。何故ならテスト実行前にTDDをやる前はつまらない文言ミスやリンク切れをテスト実行時に検出されていたのが、全く出なくなったからです。効果は出ています。

弊社はTDD開発しています！と謳うべきか？

QAの側面から見ると弊社独自のQCD
Q：全ての動作保証環境でテストをできているか
C：決められた予算内でテスト実行できているか
D：決められたリリース日にリリースすべくチケットを処理できているか
これらを満たせているなら開発プロセスがどうであろうと良いと考えています。求人に開発プロセスはTDDです！とか、イテレーション開発です！とか書かれていても、そこを重視する必要ありますか？といつも考えています。
リリース実績が高いと謳うべきだと考えています。よってあまり見ないですし、今後も見ません。

最後に

以上が今回の記事です。また長くなってしまったな、と少し反省しながらも継続して投稿していきます。

ライフイズテック サービス開発部では、今後定期的なカジュアルなイベントを実施しています。
開催予定イベントの詳細はライフイズテックのconnpassからご確認ください。

Life is Tech！ライフイズテック

興味のあるイベントがあったらぜひ参加登録をお願いいたします！