inomata@qaです。
最近はテストでいかにバグを見つけるかよりも、いかにバグを出さない開発プロセスにするかという事を考えています。私はバグを見つけることに喜びを感じるクレイジータイプのテストエンジニアではないです。どちらかといえば
今回は、バグを見つけないテストを目指すという話です。
「何言ってんだコイツ」とお思いでしょうが、まあ最後まで見てやってください。
まず前提として
シャノンの開発チームはアジャイルプロセスのスクラムで開発を行っています。スクラムのチームは開発者とQAが同じチームに属し、仕様を考えるところからリリースの手順作成まで（リリース作業自体は別の担当者）を一緒に作業します。仕様の提案や決定は一緒に行いますが、実装は開発者、テストはQAという役割に分かれています。また、開発するのは主にSMP（webアプリケーション）です。
これらを念頭において見ていただければと思います。
バグを見つけないテストとは？
バグを見つけないテストとは、開発時から品質を上げ、テスト時にはバグがないコードを相手にしようという試みです。テスト時にバグを検出しなければ、早く開発が終わり、それだけリリースが早くなります。これはもう、良い事しかありません。決して、薄めに薄めたカルピスのようなテストケースを作るということではありません！
どうすれば・・？
まず、シャノンの開発プロセスはざっくりと以下のようになっています。- チームに要件（ユーザーストーリー）が降ってくる
- 要件をもとにチームが仕様を考える
- 開発者が機能開発する
- QAがテストする
- 開発対象の機能性テスト
- ほかの機能との動作、使用性の整合性
- メモリ使用やレスポンスといったパフォーマンス
- 影響する既存機能
- ISO9126の品質特性
仕様の決定とテストの設計が終われば、開発者は実装に入ります。なので、このテスト設計の成果物を開発者に共有します。つまり、「オレ、ここテストするからバグとか出さないように作っておけよ」という事を先に言っておくわけです。
テストは開発より後の工程になるので、つい”後出し”になってしまいがちですが、こうすれば先に開発者のほうでバグを入れないコードを開発できるという狙いです。
シャノンの場合（？）、機能を新規開発するとその機能はしっかりできている反面、既存機能への影響が大きく出てきます。これは開発者がどうのという話ではなく、今まで重ねてきた負債が悪さをしているという結果になっています。
一方、ユーザー目線だったり他の機能との整合性といった、システム全体を俯瞰する目線というのは、開発者よりQAのほうが得意な傾向にあります。
この方法は、そのシステムを俯瞰し、品質を意識した目線を開発の方へ早く回してやるということです。
最後に
これは、開発者とQAが同じチームで情報を共有し合い、またリスペクトしあえる、アジャイルならではの手法と思っています。ちょっとプロセスの順番を工夫するだけでテスト時のバグ減り、リリースが少しでも早くなるのであればやらない手はないです。プロセスには正解など無く、いかに目的に向かって良い活動ができるかということを、自分たちで改善していく事が重要です。今回は、どうすれば少しでも早くリリースができるかという事を考える中での活動の一環でした。
それでは！
