TDDD(Test-Design-Driven Development、テスト設計駆動開発)

##1. はじめに
前回デプロイした「[M5Stackと温湿度センサDHT12で始めるTDDと同値分割・境界値分析](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65)」では数十行の室温計プログラムの開発でさえもTDDの実践にはテスト設計をトリガとする工程が前段にいくつもあることを示しました。本稿ではこれらの前工程も含めてテスト設計が開発を駆動すると捉えてTDDをTDDD(Test-Design-Driven Development、テスト設計駆動開発)に拡張し、室温計の開発を題材にTDDDを掘り下げます。

##2. TDDDのプロセス
TDDDは1)何を作るか、2)どう確認するか、3)どう実現するか、を先に決めてから、4)実装し、5)テストする、というプロセスです。

1. プロトタイプ開発
1.1 バリデーション(妥当性検証)
1.2 実現可能性の調査、課題抽出

2. テストのアーキテクチャ設計
2.1 テスト観点(テストすべき事柄)の列挙
2.2 テストを組み合わせて多層化(どのような品質を、どの工程で、どのように確認するかを決める)

3. ソフトのアーキテクチャ設計(フロントローディングやUnit Testをできるようソフトの設計を工夫する)

4. 実装
4.1 テスト技法を用いたUnit Test設計
4.2 Unit Testの実装
4.3 Unit Testがグリーンになるようにプログラムを実装
4.4 結合テストを効率化できるようデバッグ機能を実装

5. テスト
5.1 チェッキング(丸つけ、動作実績の積み上げ)
5.2 テスティング(欠陥の検出)
5.3 V&V(Validation & Verification)

![tddd2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221758/aaea13e0-45c0-def8-ab63-57bcb3e4e877.png)

ダブルVモデルやWモデルにプロトタイプ開発とTDDを組み込んだもののようにも見えます[^1]。

##3. TDDDと室温計開発の対応
TDDDと[M5Stackと温湿度センサDHT12で始めるTDDと同値分割・境界値分析](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65)の記事の章・節の対応を以下に示します。

|TDDD|室温計の開発
|----|----
|1. プロトタイプ開発|[3. 一つの関数にすべてを詰め込んだ実装](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#3-一つの関数にすべてを詰め込んだ実装)
|2.1 テスト観点(テストすべき事柄)の列挙|[4.1 テスト観点(テストすべき事柄)の洗い出し](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#41-テスト観点テストすべき事柄の洗い出し)
|2.2 テストを組み合わせて多層化(どのような品質を、どの工程で、どのように確認するかを決める)|[4.2 どの工程でどのようなテストを行うかを設計する](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#42-どの工程でどのようなテストを行うかを設計する)
|3. ソフトのアーキテクチャ設計(フロントローディングやUnit Testをできるようソフトの設計を工夫する)|[4.3 ソフトウェアの構造を設計する](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#43-ソフトウェアの構造を設計する)
|4.1 テスト技法を用いたUnit Test設計|[6.1 同値分割・境界値分析でテストを設計する](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#61-同値分割境界値分析でテストを設計する)
|4.2 Unit Testの実装<br>4.3 Unit Testがグリーンになるようにプログラムを実装|[6.2 TDDの実践](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#62-tddの実践)
|4.4 結合テストを効率化できるようデバッグ機能を実装|[9. Debug Utilsの実装](https://qiita.com/pbjpkas/items/6a6a85d2c48d4e6c5c65#9-debug-utilsの実装)
|5. テスト|室温計のスクリーンショットをご覧ください

##4. TDDDの感想
室温計の開発はUnit Testを先に作ってからプログラムを作るというTDDのおかげで安心感のある開発ができたのですがTDDをTDDDへ拡張することでさらに以下のようなメリットがあるように思いました。

- プロダクトの出荷に自信を持てる(何を行えば品質に自信を持てるか検討してレールを敷いてから作り始めるため)
- 欠陥検出の多層化
  - 各工程ごとに適したレベルのテストを段階的に組合わせて網羅
  - Unit Testでテストできるモジュールは全体の一部とはいえデグレにいち早く気づく仕組みを持てる
- 欠陥検出のフロントローディングによる早期の欠陥摘出
- テストの効率化を期待できる
  - 早期にテスト設計に着手することでデバッグ機能の開発やテストツール開発に早く取り組める
  - Unit Testの段階で不具合を修正すればシステムテストと比べて圧倒的に短時間で再テストができる(19個のUnit Testにかかった時間は0.051秒)

一方でたった数十行のプロダクトでもTDDDにはいくつもの段取りがあり、「テストすべき」と観点を増やすだけでなく「これは割愛しても自信が揺らがない」と減らしたり「これは工数を投資して自動化し人力では行わない」と省力化する取り組みも必要と思いました。

TDDDを業務に導入する場合は、1)効果の高そうなものから着手する、2)数日～数週間行って段取りよくできるようになってからやることを追加する、3)やってみてイマイチならやることを変える、と状況に応じて柔軟に取り組むのが良さそうに思います。

##5. おわりに
品質保証(Quality Assurance)を平たくいうと「これはとっても良いもの[^2]で安心してお使いいただけます[^3]」と自信をもって顧客に品質を約束することで、そのためにQMS[^4]を回す[^5]のがQAの役割です。プロダクトを作り始める前の工程からQAやテストエンジニアが参画するTDDDは、品質問題に先手を打つ「攻めの開発」ができる期待を持ちました。

[^1]: 参考：[JaSST’12 東京Ｗモデルセッション～パネル形式の質疑応答～](http://jasst.jp/symposium/jasst12tokyo/pdf/D4-2.pdf)
[^2]: 狩野モデルでいうところの魅力品質を備えていること
[^3]: 一元的品質を満たし当たり前品質を備えていること
[^4]: Quality Management System、製品が品質基準に合致しているかを、仕様設計・実装・テストの全ての工程で確認する仕組み
[^5]: 定量的、定性的にQMSの状況を調べ、障害を取り除いて仕組みが滞りなく回るようにし、改善すること