私が普段やってること
業務システムのテストの仕切りをしていることが多いです。ここでいうテストは、運用が回ることを含め、受入の可否まで担保することを目的とした最終のテストです。
もちろん、自分一人でやってるわけではありませんが、
- 手順・ケース表の作成／データや環境のテスト準備
- テスト中は、ケースに対するテスターの割り振り／テスト中の情報共有
- 後の運用もあるので、現場への教育的なこと
を行っています。
イベント
私は、案件に、テストから入ることが多く、限られたリソースの中、テストを通じて品質をよくすることについては、ずっと気になっていました。
そこで、先日、以下のイベントに参加しました。
ソフトウェア品質シンポジウム（一般財団法人日本科学技術連盟主催）
本会議は、9/11(木)、12(金)ですが、参加したのは、本会議前日の併設チュートリアルです。
新しいソフトウェアテスト ウォーターフォール・モデルからの決別
高橋 寿一（「知識ゼロから学ぶソフトウェアテスト」の著者）
テストについて、本を読んだり、いろんな記事を読む中、「知識ゼロから学ぶソフトウェアテスト」「ソフトウェアテスト手法」が非常にわかりやすかった！
その著者の高橋さんの話が聴ける！というミーハーな思いもあって参加しました。
（実際、知識ゼロから学ぶ〜にサインしてもらいましたw）
以下、講演の内容を含みます。
有料の講演でもあったので、一応、「テストについてまとめた記事をBlogに書いてもいいですか？」と高橋さんに聞いて、その場では、OKをいただきました。
もちろん、公開した後、目に触れて「あれはまずいよ」ということがあれば、記事の削除もしくは、訂正にも応じます。
高橋さんが目指すスタイル
1. TDD(※1)を実践
2. できるところを自動化（主機能に対するスモークテスト）
↓他人に迷惑かけない前提で
3. 探索的テスト(※2)
特に、探索的テストは、手順が決まっているわけではないからなのか、手法という言い方ではなく“スタイル”という言い方をされていました。
※1
wikipedia(テスト駆動開発)
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
TDDについては、読みにくいけど、TDD本（↓）読んでね、ということでしたw
※2
情報マネジメント用語辞典：探索的テスト
（まだまだ探索的テストの記事はまだ日本では少ないとのこと）
探索的テスト
で、探索的テストって何よ？というと「スキルあるテスターがアドホック的にtoo oftenでやる」テストです。ケースをがっつり作って実施するテストではなく、有識者が、自分の知見に基づいてテストを行います。
- 方針（※3）だけ決めて、有識者が実施する。
- 製品の目的、機能の明確化、弱いエリア（※4）を叩く。
テストケース作成に時間をかけるより、わかる人が当たりをつけて実施するほうが効果的という考え方です。ただ誤解があっては、いけないのは、場当たり的なモンキーテストではありません。
※3
講義で例示されていましたが、「XXに従い、正常に動作する」など、かなり漠然としたものでした。
探索的テストに近い形を導入する場合、関係者と要相談となるでしょう。
※4
データ交換／他のソフトウェアと共有／ネッワトーク越しにファイルオープン／エラー、例外からの復帰
実際に、どういった内容を、誰が行うのか、もうちょい詳細に見ましょう。
テスターの要件
- 製品の目的を理解し、弱いエリアが探せる人とのこと。
ソフトウェア工学の知識、ドメインの知識が両方あればよい（日本で且つ規模がない会社だとかなり難しいかな？）が、テストの専門家が雇用できない場合、実装＋ドメイン知識がある人が担当することになります。だから、スキルがない、テストに対して初心者ばかりだと進められないことになります。
また、担当者が責任を持ってやれるか？をしっかり押さえておく必要があります。
（さぼってんじゃないの？とならないように）
テストの終了の条件
- テスターに書いてもらう。（24時間やってハングアップがないこと 等）
- 終了条件を上長がagreeする（ただし、何度でも変更可能）
- 出荷可能かどうかは、テスターのいる部屋のドアをノックして、全員OKなら、出荷可能となる
（というくらいテスターに任されたもの）
実施にあたって注意点
- ドキュメントレス化すると、責任範囲がグレーになるから、担当者は明確にする。
（状態遷移テストAさん、ディシジョンテーブルテストはBさんと明確にしたほうがいい。） - 非機能要件は向かない。
→当たり前だけど、セキュリティは、脅威分析して、テストケースを展開する。
→パフォーマンスも同様。 - テストのサマリレポートの他に、バグ、どういうふうにして、そういう思考に至ったか？を残しておく必要がある。
（これをみんなの前で発表（共有）する場を持つべき）
⇒テスターの教育やテストの練度を上げるため
探索的テストの実施を支える考え方／統計／実積
- 「80%のバグは全体の20%のモジュールから発見され、50%のモジュールにバグは含まれない」
→有識者がテストすることで、重点的にそこを探ることができる。 - 探索的テスト、組合せを利用した網羅的テストの成績を比較すると、どこで統計を取っても、大体、少し探索的テストのほうがいいらしい
- 「システムの複雑度とバグの相関関係はない」
→学術的にもそんな論文ない。 - 「ファイルが長いとバグが多い」
→これは正しい、論文も出ている。 - 「直近で、手が入っているか」
→これも正しい、論文も出ている。
⇒例えば、2年間の間、修正されず、昨日変更された、は対象に含めなくていい。
あるモジュールが、先週修正、先々週も2回修正、は、たぶん要注意。
直近に沢山、変更入ったもの上位5、10だけ単体テスト強化＆レビュー実施というのも効果的。
- 「40%が何らかのやり直しコスト」
→これは、どんなプロジェクトでも統計通りに近い数字が出るそう。
→やり直しコストを減らすため、テストは早めに着手する。モジュールがすべて完成するのを待ってからだと遅い。
まとめ
最初に書いた通り、運用と受入を含めたテストを行っています。
自動化、開発者目線に近い話の中、担当している部分は、マニュアルテストです。
でも、意外とやれてるな、ということは多かったです。
- 要求のブレを後で発見するリスクを減らすための設計前の要件確認合宿
- テストの早期着手
→開発の遅れがあっても、できるところから着手 - ユーザーからのフィードバック
→運用を含めたテストなので、早めに現場に入ってもらって意見を聞いています。 - 無駄なテストケースの実施の回避
→テストケースは全体を作成している（昭和的って言われたけど・・）が、実施ケースはかなり絞って実施。その絞り方は、設計者となる人が選んでいるので、割と不具合発見につながっています。
→更に、あやしい箇所は、手順の多いケースからは切り出して、別担当者にやってもらいます。 - テスターの能力
→該当のケースは、スピードもありますが、まず、実装した人や業務に詳しい人などが実践しています。 - テスターの教育
→テスター専門を育てるわけではありませんが、業務を覚えるという意味合いもあって、ときどき担当者を変更したりして、覚える工夫も行っています。
いい内容でしたけど、鵜呑みするのではなく、自分たちにあったやり方は今度とも工夫して行きたいと思います。また、担当部分はレガシーなコード群を抱えつつも、TDDはやりたいし、運用や受入とはいえ、テストの工数が嵩むところは、自動化もしたいです。
一つのやり方（探索的）に頼るなという言葉もありましたし、今後もいろいろ参考にしながらテストに関わっていこうかと思います。
