要件定義とテストのあいだ――TEF東海の勉強会に行ってきました
こんにちは、第3バイオリンです。
先週わたしは夏休みで実家に帰省し、ひさびさに家族旅行に行ってきました。旅行の最終日に実家に戻る家族と別れ、その翌日にTEF東海の勉強会に参加してきました。
今回は、TEF東海の勉強会で学んだことをお話しします。
■TEF東海とは
TEF（Testing Engineer's Forum：ソフトウェアテスト技術者交流会）とは、テストに関する情報交換や技術向上を目指した、テストエンジニアのための交流会です。ソフトウェアテストに携わっているエンジニアであれば誰でも無償で入会可能です。
主な活動はメーリングリストによる情報交換、テストの勉強会や研究会です。
TEFの中には、地域ごとにいくつかの部会が存在しています。そのうちの1つがTEF東海です。その名の通り、東海地方在住のTEFメンバーが中心になって活動しています。
■勉強会参加のきっかけ
実はわたしはTEFには入会していません。そんなわたしが、どうしてTEF東海の勉強会に参加したのか、そのいきさつからお話ししましょう。
きっかけは、WACATEで知り合った、関西在住のテスト友達から「帰省のときに会おう」というお誘いを受けたことでした（わたしの実家が関西にあるので）。
そのテスト友達と会う予定だった日に家族旅行が重なったこともあり、会う場所は名古屋になりました。それならいっそのこと名古屋周辺にいるほかのテスト友達も誘おうと思ってTwitterで呼びかけたところ、勉強会の主催者の方から「その日は豊橋でTEF東海の勉強会があるのでよろしかったらどうぞ」と、逆にご招待されました。
というわけで、関西のテスト友達と一緒にTEF東海の勉強会に参加申し込みをしたのです。うーん、当初の予定からだいぶ話が大きくなりましたが、それもまた楽しいものです。
■テストエンジニアが知って得する要件定義技法
8月15日、わたしと関西のテスト友達は名古屋で待ち合わせて、勉強会に参加する名古屋在住の別のテスト友達と3人で豊橋に向かいました。
勉強会の参加者はわたしも含めて15名、その中にはWACATEで知り合った方も数名いらっしゃいました。東海という地域の特色でしょうか、参加者は組み込み系の業務に携わっている方がほとんどでした。
この日の勉強会のテーマは「テストエンジニアのための要件定義入門」。講師はTISの鈴木三紀夫さんでした。
近い将来、テストエンジニアが上流工程に関わる場面は増えてくるはずです。そのとき、上流工程で何が行われているか、知っておくことは必ず役に立つ、というお話から始まりました。
■要求のレベルとトレーサビリティ
要件定義のためには、まず顧客の要求をヒアリングするところから始まります。
この要求には、大きく分けて3つのレベルがあります。下位レベルにいくほど、要求は詳細になっていきます。
1. ビジネス要求
対象のビジネスが達成するべき要求。システムに依存しない形で表現する。
2. システム要求
ハードウェア・ソフトウェア両方を含むシステム全体の要求。システムが提供するサービスや状態がこれに相当する。
3. ソフトウェア要求
システムを動かすソフトウェアの要求。ソフトウェアの機能、入出力の方法などがこれに相当する。
レベルがあるということは、各レベル間にはトレーサビリティがあるということです。つまり、システム要求、ソフトウェア要求も、元をたどれば必ずビジネス要求につながっていくということです。裏を返せば、どこにもつながらない要求はそもそも不要な場合が多いということです。
このことは、テストをする際の優先順位付けにも役立ちます。各テストケースがどの要求と紐付けされているかを考慮すれば、要求の優先順位に合わせてテストケースの優先順位を決められるからです。
また、要求に関するドキュメントは、レベルごとに分かれていることがほとんどです。各ドキュメントの関連を知るためにも、レベル間の関係を考えることが重要なのです。
わたしはこれまで、要件からテストケースまではずいぶん離れていると思っていました。しかし、それでも確実にすべてがつながっていることを実感できました。
■柔らかい要求を固めるためのプロセス
最初のうち、要求は柔らかいものです。言い換えると、最初のうち、顧客のリクエストはしょっちゅう変わります。最初から固まっていることはあまりありません。
しかし、顧客の言うことが変わっても、顧客がやりたいこと、求めるものはほとんど変わりません。分かりやすく例えると、水蒸気が冷えて水になり、さらに冷えると氷になるようなものです。見た目の状態は変化していますが、本質的には同じものです。
テストエンジニアは普段、それなりに固まった仕様をもとにテストをしています。そのため、このような要求の性質を知らずにいきなり要件定義工程に飛び込むと「顧客の言うことが変わる＝要求が変わる」と思い込んで、戸惑うことになってしまいます。
柔らかい要求を固めるためには時間がかかります。なぜなら、要求はウォーターフォールのような一直線のプロセスで作ることはできないからです。良い要求を作るためには、プロセスを何度も繰り返すことが大切なのです。
テストエンジニアであるわたしにとって、普段の業務からは意識しにくい要件定義のお話はとても興味深いものでした。
現在のところ、わたしが要件定義工程に携わる機会はまだありません。そのため、すぐに業務に応用することは難しいと思いますが、この勉強会で要件がどのように定義されていくのか、そのプロセスを垣間見ることができたことは良かったと思っています。
■忘れちゃいけない懇親会
勉強会のあとは懇親会です。会場近くの居酒屋に移動し、参加者の皆さんとテスト談義で盛り上がりました。
わたしにとっては、初めてのWACATE以外の勉強会だったのですが、楽しくて有意義な時間でした。参加者の皆さんも気さくに接してくださって、本当に参加してよかったと思いました。
また機会があれば、TEF東海の勉強会に参加したいです。さらに、ほかにももっと、いろいろな勉強会にも参加してみたいとも思いました。
コメント
インドリ
おっしゃる通りで仕様要求とトレーサビリティは重要ですね。
実務で活かすには次の点に注意すればいいと思います。
自分がテスト時に注意している点について簡単に書きます。
・ビジネス要求とテスト
お客様の立場で、システムが実際に役立つか考えます。
例えば、ユーザーインタフェースは適切でしょうか？
個々の機能はどの業務と結びついていますか？
その機能はその業務を正しく補佐するのかテストする必要があります。
そういった使用者側目線のチェックをします。
ビジネス要求にも、変化しやすい部分と変化しにくい部分があるので、注意が必要です。
・システム要求
システムの耐久性などをチェックするとよいかと思います。
最繁時にシステムがダウンする事が多いので要注意です。
多くのエンドユーザーの業務は、最繁時間と最繁気節があり、忙しい時とそうでない時の負荷に大差があるので、忙しくない時のデータで耐久テストすると、エンドユーザー泣かせのシステムとなってしまいます。
ACID特性も重要です。
ACID特性をちゃんとチェックしておかないと、奇妙な現象が多々おきる事になります。
・ソフトウェア要求
十分に知っていると思いますので省略します。
あと、各工程のトレーサビリティが、適切かどうかもチェックするとよいでしょう。
失敗するシステムは、トレーサビリティがないシステムが多いと思います。
厳密に言うとこれはテストエンジニアだけではなく、全員がチェックするべき事です。
各工程がぶつ切りになったら、システム開発は失敗する可能性が高いと得ます。
話しはちょっと変わりますが、テストエンジニアからも、SEとプログラマにテストの事を考えろと言うのがよろしいかと思います。
テストの事を考えずに、仕様書を書いたり、システム要求されたら効率が悪くなって困ります。
システム開発は、常に全行程を考える事が重要ですので、エンジニア間の交流が活発になるといいですね。
第3バイオリン
インドリさん
コメントありがとうございます。
インドリさんがコメントくださった要求とテストの注意点、
とても参考になりそうです。ありがとうございます。
>話しはちょっと変わりますが、テストエンジニアからも、SEとプログラマにテストの事を考えろと言うのがよろしいかと思います。
そうですね。
「テストしやすい設計、実装を心がける」というのは大切なことだと思います。
私の会社の新人研修でも、毎年テスト演習というものを新人さんに受けてもらっています。
同じ部署の先輩が講師を務める演習ですが、毎年新人さんからは
「設計、実装の段階でテストのことを意識して、
テストしやすいプログラムを作りたい」という感想が寄せられます。
現場に配属されてからも、この気持ちを忘れないでほしいと思います。
（私が新人だった頃は、このテスト演習がなかったんですよね。今の新人さんたちがうらやましいです）
>システム開発は、常に全行程を考える事が重要ですので、エンジニア間の交流が活発になるといいですね。
品質はテストだけでなく、すべての工程で作りこむものです。
テストしてバグを見つけても、いい加減な修正を加えると別のところに不具合が出て、
品質という面については改善されない（むしろもっと悪くなる場合も）ことがあります。
自分が携わる工程のことだけ考えて、後は知らないというのではもう通用しないと思います。
テストエンジニアも要件定義や設計、実装のことを知るべきですし、
プログラマやSEもテストや運用・保守のことを知るべきだと思います。