この記事はCalendar for ソフトウェアテスト | Advent Calendar 2021 - Qiita15日目の記事です。
昨日（14日目）は@RyomaMaedaさんのバグバウンティプログラムとは何か？3分で理解する | Test-Hack | 3分で理解するIT/テスト技術でした。
はじめに
TDDのように開発者が自動化された単体テストを作成し、できるだけ小さい単位で品質を高める開発手法（この記事では開発者テストと呼ぶこととします）が良く知られています。自分の関わるプロジェクトで開発者テストを普及させようとしましたが、最終的に上手く運用できませんでした。本記事は、その経験から今後に生かすために個人的なふりかえりをまとめたものになります。
できるだけ早く検証する
VUCAの時代*1といわれるとおり、昨今のビジネスは複雑化していて予め結果を予測することが難しくなっています。また、リーンスタートアップにおけるMVP*2のように、小さい単位で早期に作って検証のサイクルを早く回すことがVUCA時代におけるビジネスの成功パターンとして知られています。
ソフトウェア開発も同様に品質を高めるために、できるだけ早期にテストをする手法が広まっています。テストファースト／TDDに代表される開発者テストもソフトウェアの品質を高める手法として知られています。
背景
開発者テストをプロジェクトに導入しようと試みたときに、開発者テストに対して慣れていないメンバーも多いため、テストフレームワークを用いた実装方法をレクチャーしてサンプルも準備をしました。しかし、「できればテストを書くようにしたい」として進めていましたが、結果として開発時に十分なテストを揃えることができずに上手く回りませんでした。自身の反省も含めてうまく開発時にテストができなかった理由を考察したいと思います。
- テストデータをどう使えばいいか分からない
- 計画時間内では実装するまでで精一杯
- 何をすればいいか分からない
テストで使用するファイルをどう管理すればいいか分からない
状況
テストデータとして画像などのファイルを使用する場合がありますが、ファイルを用意した場合にどのように管理すればいいのかが分からない。
分析
開発後に行うテストの場合は別途テスト用ファイルの保管場所を用意しますが、自動化された単体テストに使用するテスト用ファイルはソースコードと同様に構成管理に含める必要があります。
テストコードは構成管理に入れることを想定していましたが、テスト用ファイルについては失念していました。また、テスト用ファイルはサイズが大きいものもあり、できるだけ使いまわしたいため、テストコードとは違った考えで管理する必要がありました。
そのため、テスト用ファイルが必要なテストケースを作成する場合、開発者はその管理方法について考える手間が追加されていました。
考察
準備をしていたつもりでしたが、実際に運用してもらうと事前に考えきれなかったところが負担になっている個所がありました。事前に想定しておければよかったですが、そういった運用上の負担をできるだけ早く拾い上げて改善していく必要があったと感じます。
計画時間内では実装するまでで精一杯
状況
作業計画では「実装に加えて、できればテストを書こう（開発者テストが定着していないので）」の方針で進めていたが、計画内では機能を実装するので精一杯であり、テストを十分に書く時間が取れなかった。
分析
「テストを書くための工数を十分に確保できなかった」というのも理由の一つとして明らかです。しかし、「開発者テストを十分にした方が最終的なソフトウェアの品質が高めやすい」という話を知っているにも関わらず、開発者テストを書くための工数を用意できませんでした。「マイルストーンが決まっており、それまでに動くシステムを用意する必要がある」のもありますが、「一連の機能が動くシステムを早く確認する」ために「時間をかけて開発者テストが充実した状態」よりも「最低限動く機能が早めに作れる状態」を優先した、と感じています。
考察
自分のなかでは「利用者に価値のあるものを提供する」を優先していますが「開発スキルとして開発者テストを拡げたい」という考えもありました。現実的なテスト方針に対して考えが浅いと感じました。
何をすればいいか分からない
状況
そもそも実装で何をすれば分からない部分が多く、テストまで考える余裕がない。
分析
新規要素が多く「どのように実装すればやりたいことが実現できるか」を考えるのに開発者は多くの時間を費やす必要がありました。その状態では、開発している機能の異常系について考えを巡らせることが難しく、実際に起こりやすい異常系ですら考慮されていないケースなども出てきました。適切なストレスがあると人間はパフォーマンスを出しやすくなりますが、今回のケースでは過度なストレスによりパフォーマンスが発揮できない状況だと言えます*3。
考察
開発者テストが定着していない環境において、新しく開発者テストを学ぶことは負荷になります。開発者テストも学んでほしいと思いますが、開発においても学ぶことが多い中で、チームとして優先することを定める必要性を感じました。
おわりに
開発者テストを普及させようとした中で、上手くいかなかった要因を探るために「なぜ開発者テストができなかったのか」に着目して分析をしてみました。「できない」がその人にとってどうだったのかを深掘りすることで、普及活動の課題や無茶筋を気付くことができたように思います。あくまで私の経験の一例なので、異なる環境であれば違った「できない理由」が見つかると思います。
