実践アジャイルテストを読んだ読書メモです。
- 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド - Janet Gregory
開発者以外の視点を手に入れるために、読んで見ました。テスターの人は連日自分のバグを洗い出してくれるので、私は感謝と憎悪そのたもろもろの、複雑な思いをテスターのひとたちに抱いている今日このごろです。
ディベロッパーよりは、テスターのための本。単体テスト、結合テストの上位に位置するテストについて書かれた本です。
また、Fitnesseがたくさん紹介されているらしいという口コミをきいたので、読んでみました。
受け入れテスト用フレームワーク「Fitnesse」導入手順のまとめ | Futurismo
正直にいうと、あまり深くは読んでいないです。流し読み。ただ、テストコードが本に一回も現れないため、スラスラ読めます。珠玉のアイデアを発見できたので、忘れないようにメモしておこうと思います。
ウォーターフォール型テスト vs アジャイルテスト
ウォーターフォールテストでは、長期間の中盤から最後にかけてテストを実施する。
アジャイルテストでは、まず機能テストを書く。テストファースト。短い開発期間の中で、シナリオテストを区切りにして、イテレーションを繰り返していく。テストが開発を駆動する点では、TDDとも言える。
どこでテストを書くかという点が異なる。最後にテストをするのがウォーターフォール。最初にテストをするのがアジャイルテスト。
アジャイルテストマトリックス
アジャイルテストは、4つの象限に分類できる。
|
機能テスト 第２象限:手動と自動テスト。 |
探索テスト シナリオテスト ユーザビリティテスト
第３象限:手動テストが必要。 |
|
単体テスト 結合テスト
第１象限: 自動テスト |
パフォーマンステスト ～性テスト
第４象限:ツールでのテスト |
アジャイルとつくからには、自動化できることは自動化しようという意図が裏にある。
第１象限
単体テストや結合テストといっているのが、いわゆるxUnitフレームワークを利用した、開発者が実施するテスト。
第２象限
機能テスト。顧客テスト、ストーリーテストとも呼ばれる。顧客が求めている機能が満たされているかをテストする。
第３象限
シナリオテストや探索的テストがここに入る。
シナリオテストは、機能を組み合わせたワークフローのテスト。自動化できたりできなかったり。
探索的テストは、バグってそうなところを経験と推測で試行錯誤しながら探していくテスト。詳しくは以下。
想定外の、げっこんなことやるのかよと、ぞっとするのがココ。
第４象限
製品を批評するテストがここに入る。観点のテスト。非機能テスト。例を以下に列挙。
- パフォーマンステスト、負荷テスト、ストレステスト。
- セキュリティ
- ユーザビリティ
- 保守容易性(mentainability)
- 導入容易性（Installability)
- 信頼性（reliablirity)
自動化テストのピラミッド
４つのレベルに分類できる。
| 手動テスト | 努力 |
| GUI/CLIてテスト | Selenium,expect・・・ |
| 受け入れテスト（APIレイヤのテスト） | Fit,Fitnesse |
| 単体テスト・コンポーネントテスト | xUnitフレームワーク |
ここで新しく知ったのが、APIレイアのテスト。GUI/CLIなどの直接外に見えるI/Fの裏側のテスト。APIを直接テストすることで、よりテストを網羅的に、高速に実施することができる。
そして、そのためのツールがFitnesse。
まとめ
この本は膨大な分厚さ(500Pくらい！）で、流し読みではなくて何度読んでもそのたびごとに発見があると思われる本。品質保証のすべてが網羅的に書かれている良書。
単に、技術的な手法の紹介ではなくて、アジャイル開発に対してテストはどうあるべきかという思想が随所で書かれている。
機会があればまた読みなおしたい一冊。