忍者式テストを二週間くらいやってみた感想です。
忍者式を見習って毎日一時間手動受け入れテストの時間を確保してみた。
— ぎゃばん (@ledsun) 2014年6月27日
「受け入れテストを徐々に増やしていく」感覚が新鮮。
「受け入れテストはテストフェーズの最初に一度に作るもの」は思い込みだった。
忍者式テストとは
那須のKent Beckと呼ばれる隠者が発明（発見？）したテスト手法。 特徴をあげると
- 毎日、手動でテストを行う
- テストをペア作業で行う
- 実施のたびにテスト項目を見直す
- テスト項目の粒度は受け入れテスト
初めてこの手法を知ったのは2005年だったと思います。 当時、自社開発ソフトウェアの結合試験の真っ最中でした。 「バグの発見漏れは減るだろうけど、どうやって導入すれば？？？」と、 使えそうなのに手が出せなく、もどかしい思いをしました。
導入方法の謎
何年経っても導入方法が分からなかったので、金にものを言わせて本人に聞いてみました*1。
「最初からチームで始めた」は誤解でした。 最初は隠者が一人でやっていたそうです。
やってみた
一人プロジェクトで、テストの作戦が決まっていなかったので、やってみました。
前提条件
- 一人プロジェクト
- フロントエンドJavaScript、フレームワークは使っていない
- UIが細かい
- 自動テストが無い
- 機能追加もリファクタリングもする
実施形態
- 毎日、17時からテスト開始
- テスト項目はWiki*2で管理
- その日、追加した機能のテスト項目を追加
- テストを行いながら
- 分かりにくい表現を修正
- 新しい項目を思いついたら追加
- 一緒に行った方が良いテストをグループ化
- バグを見つけたテストグループは一番上に移動
- 面倒くさくてバグが見つからないテストは簡略化
感想
- 忍者式テストは本当にあった
- バグの見逃しは本当に減った
- その日のうちにバグが見つかるのは安心
- レアなバグが次の週に見つかったりもする
- テスト実施回数が増えると、レアバグがゲットできるのはTDD（自動テスト？）っぽい
- テスト項目を一回で完璧にしない、徐々に育てていく感覚が新しい
- 向いてなさそう
- 趣味のプログラミング
- 一回の作業時間が20分ではテストに割く時間がない
- 早い段階で自動化する方がいい
- 三ヶ月で作って納品みたいなプロジェクト
- テスト項目の育て甲斐がなさそう
- 趣味のプログラミング
- よくわからない
- 今後、機能が増えても回るのか不安
- 他の人を巻き込んだときにどうなるのか不安
- ほんとに千里だった
（かあちゃんえらい（自画自賛））たかしへ たかしの忍者式テスト感想文を読みました。チームの成熟度が違いすぎて腰を抜かしましたね。千里の道も一歩から、目標として心に留めしっかり足元を見ましょう。自分のチームが直面している問題を一つずつ解消していけば、那須のKentBeckとは違うでしょうが、たかしの道が開けます。
— ぎゃばん (@ledsun) 2012年3月5日
ExtremeProgramingを越えたと言われているチームは、一体どれだけ先に進んでいるんだろうか・・・？
おわりに
隠者の知恵を金で買うチャンスは今もある。みんなもやるといいとおもうよ。
*1:http://togetter.com/li/266752 これが2012年の話と言う事実に驚愕している・・・・
*2:https://github.com/pubannotation/textae/wiki/userAcceptanceTest
