@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

忍者式テストをやってみた

忍者式テストを二週間くらいやってみた感想です。

忍者式テストとは

那須のKent Beckと呼ばれる隠者が発明(発見?)したテスト手法。 特徴をあげると

  1. 毎日、手動でテストを行う
  2. テストをペア作業で行う
  3. 実施のたびにテスト項目を見直す
  4. テスト項目の粒度は受け入れテスト

初めてこの手法を知ったのは2005年だったと思います。 当時、自社開発ソフトウェアの結合試験の真っ最中でした。 「バグの発見漏れは減るだろうけど、どうやって導入すれば???」と、 使えそうなのに手が出せなく、もどかしい思いをしました。

導入方法の謎

何年経っても導入方法が分からなかったので、金にものを言わせて本人に聞いてみました*1

「最初からチームで始めた」は誤解でした。 最初は隠者が一人でやっていたそうです。

やってみた

一人プロジェクトで、テストの作戦が決まっていなかったので、やってみました。

前提条件

実施形態

  • 毎日、17時からテスト開始
  • テスト項目はWiki*2で管理
  • その日、追加した機能のテスト項目を追加
  • テストを行いながら
    • 分かりにくい表現を修正
    • 新しい項目を思いついたら追加
    • 一緒に行った方が良いテストをグループ化
    • バグを見つけたテストグループは一番上に移動
    • 面倒くさくてバグが見つからないテストは簡略化

感想

  • 忍者式テストは本当にあった
    • バグの見逃しは本当に減った
    • その日のうちにバグが見つかるのは安心
  • レアなバグが次の週に見つかったりもする
    • テスト実施回数が増えると、レアバグがゲットできるのはTDD(自動テスト?)っぽい
  • テスト項目を一回で完璧にしない、徐々に育てていく感覚が新しい
  • 向いてなさそう
    • 趣味のプログラミング
      • 一回の作業時間が20分ではテストに割く時間がない
      • 早い段階で自動化する方がいい
    • 三ヶ月で作って納品みたいなプロジェクト
      • テスト項目の育て甲斐がなさそう
  • よくわからない
    • 今後、機能が増えても回るのか不安
    • 他の人を巻き込んだときにどうなるのか不安
  • ほんとに千里だった

(かあちゃんえらい(自画自賛))

ExtremeProgramingを越えたと言われているチームは、一体どれだけ先に進んでいるんだろうか・・・?

おわりに

隠者の知恵を金で買うチャンスは今もある。みんなもやるといいとおもうよ。

dRubyによる分散・Webプログラミング

*1:http://togetter.com/li/266752 これが2012年の話と言う事実に驚愕している・・・・

*2:https://github.com/pubannotation/textae/wiki/userAcceptanceTest

広告を非表示にする