アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その6
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその6になります。
前回は「第18章 コーディングとテスト」のうち、バグの取り扱いについて書きました。
今回のエントリですが、予定を変更して「第18章 コーディングとテスト」のうち、リグレッションテストについて学んだことを出力していきます！
リグレッションテスト
（P429 18.9 「リグレッションテスト」より）
ビルドを「緑」に保つ
プログラマはコードをチェックインする前にxUnit系の単体テストツールで「緑」の状態、つまりはテストが全て成功している状態にしておく必要がありますが、開発が進むにつれ何らかの要因で成功しない場合があります。 たとえば、ローカル環境では通っていたが、CIで毎ビルドする際には失敗してしまう・・・といったことです。こういった事態が発生した場合は、最も優先度をあげてビルドが成功するよう、修正することが必要です。
ビルドの失敗や、いま直している！というステータスを示すのに以下のような方法が例示されています。
- ビルドのあとに結果をメール通知する
- ぬいぐるみをビルドを壊した人の机においておく
- 失敗時に信号を点灯させる
- アンビエントオーブを使う
- GUIのビルド監視ツールを使う
私たちの現場ではJenkinsで状態がわかるようになっているので、そこからSlackでお知らせといった感じになっています。お知らせは人力なので自動化の余地ありだなと思いました。 それにしてもアンビエントオーブとは何だろうと思ったのですが、↓こういうのがあるみたいですね。
The Orbならわかるのですが・・・q(^^)p
ビルドを早くする
ビルドに対してはなるべく早くフィードバックしたいものですが、ビルドの時間が長すぎるとテスト実施までの時間も伸び伸びになってしまいます。 XPのガイドラインでは10分以内にビルドが完了するのが望ましいとされています。長時間かかってしまう場合はまずそこを目指しましょう。 著者は以下の方法を例としてあげています。
- データベースのアップデートを含むテストをはずす
- 単体レベルでの機能テストをはずす
- GUIのテストスクリプトをはずす
といったものです。これらは実施しなくて良いのではなく、別プロセスで行われるのが良しとされています。
リグレッション環境を作る
既存のリグレッションテストを自動化したり、新規に自動化されたリグレッションテストを追加するなどした際は、プロダクションコードと同じリポジトリでバージョン管理されるべきです。 また、追加するリグレッションテストは素早くフィードバックできるように選定する必要があります。
上記のように追加したリグレッションテストは開発を推進するものでなく、新しいバグを見つけるためでもありません。これらを実施する目的は予期せぬ変化やシステムの副作用を見つけるためです。
大きな視野を持つ
前述のように追加したリグレッションテストですが、これらを過信してしまうことも望ましくないとしています。場合によっては手動による探索的テストが適切であるという可能性も考慮して、視野を大きくもっておくのが良いでしょう。
まとめ
さて、今回のアウトプットは以上となります。
- 効果的なフィードバックをするために、適切なリグレッションテストを頻繁に実行できるよう、ビルドプロセスに組み込んでいく
といったところでしょうか。
次回予告
次回は引き続き「第18章 コーディングとテスト」の反復指標について学んだことをアウトプットしたいと思います。
ではまた！
