テスターが要件定義のレビューからプロジェクトに参加する現実について

最近、ソフトウエア開発にて、テスト技術者が要件定義からレビューに入る件について、いろいろ話を聞いたので、まとめておきます。

これは、ちょっとかっこよく言うと「Wモデル」という、テスト担当者の作業と開発の作業を同時並行で行っていくVモデルの進化した開発モデルが目指すゴールの一つです。ただ、話をしてくれた人は、Wモデルという言葉を知っているわけではありません。

その人の組織では、1980年代後半から、独立したテストを行っているとのことです。開発したものの統合テスト以後のテストだけを請け負うテスト専門部隊です。

Windowsが出る前はCOBOLで作った会計プログラムを対象にしていて、それがWindowsが出たころに全てWindowsアプリになり、それが今では全てWebアプリになり、クラウド上で動くようになっているという感じです。今では、そこの組織では、要件定義の段階からドキュメントをテストチームが全てレビューすることになっているそうです。開発の規模は関係なく、全てです。

前置きはここまでで、その時聞いた話の要点を以下にまとめておきます。

テスト設計時のもやもやを解消する

独立したテストチームが必要になる理由として、工数が足りないので作業分担をするってことが挙げられます。納期に間に合わせるために、開発者はテストのところを別の人にお願いするわけです。テストをお願いされた人は、開発者の依頼通りにテストをします。設計、実装している人がなんでも知っていて、テストする人はそれに比べたら何も知らないからです。

けど、テストを他の人にやってもらうってことを２，３年も続けると関係も変わってきます。テストする人たちもいろいろ分かってきます。「開発者から言われたとおりとは違うことをするとバグが出る」とか。「言われたとおりにやると終わらなくなるから、もっと業務を知って、どう使われるかってところから考えて何を先にテストしたほうがよいか考える」とか。

この話を聞いた人のテストしているのは、財務、税務系のアプリ開発の話なのですが、そこのチームであれば、日商簿記を取るとか、税理士試験を受けるとかして業務を理解したそうです。会計事務所で働いていた人を中途採用するってこともしたそうです。

テストチームのメンバも、1年以上その中で働き、ある程度知識を持った人は、テスト設計の段階でも、いろいろ分かってくるので気になってくるんです。これはなんでこういう仕様なんだろうとか。こういうのが気になるとテスト設計中も悩みだしてしまいます。他にも、日本語が論理矛盾しているとか、「てにをは」をいつも間違える、とか。まぁピンきりで。

そして、「誰かに質問しようか、どうしようか」とか悩みだすと気になってテスト設計に入れなくなり、生産性がぐーっと下がってしまいます。常にもやもやした気持ちでテスト設計しなければならないのも辛いんですね。気持ちの切り替えが必要ですが、それも難しいです。

なので、開発者とのQ&Aができるようにします。そうすると、みんな質問しだします。これで品質が上がるか？というとそんな単純ではなく、開発者からしたら、「はっきり言ってどうでも良い」と思うような質問もどんどん上がってきます。これが、テスト設計の段階、つまり設計書や仕様書が完成した後に起きると、今度は開発者が「いまさら、あーだこうだ言われても修正できないよ。どうせ言うなら最初から言ってくれ！」って思うわけです。テストチームの質問にちゃんと回答しているとすごく時間も取られるので、「仕様です」で済まされたり、「今その対応をするとリリースが間に合わなくなります」と言われたりしてしまいます。（けど、本来やることの時間がこのやりとりで奪われるので仕方ないと思います。）

テストチームだって、テストをちゃんとやるからには意見を言いたい、これは自然なことです。これで、開発者が「は？今言いますか？それ。」って言われちゃうと、テストチームもやる気が無くなります。これがJSTQBのALTMのL.Oにも出てくる「テスト担当者のモチベーション」ってやつですね。

TM7.5.1（K2）テスト担当者のモチベーションを上げる要因、および下げる要因について、例を挙げて説明する。

テスト実行が滞り無く進む

けど、事前に不明点のやりとりをちゃんとやっておくと、作ったテストケースの期待結果も明確になるので、テストチームもスッキリしてテスト実行に専念でき、「テスト実行がサーっと進む。すごく順調。」となります。

テスト設計中にもやもやしていたものが、実際にテスト実行するとやっぱり動きがおかしかったのでそのタイミングでインシデントレポートを書くってなります。1日にインシデントレポートを1件書くだけで、少なくとも30分、下手したら２、３時間がテスト実行とは違う時間に割かれます。開発者にとっても同様です。デバッグや修正の工数がちゃんと見積もられていなければ、必要であることは重々承知していたとしても、「余計な作業が舞い込んできた」ってなってしまいます。また、テスト対象のことをよく知らない人のインシデントレポートは、何がいいたいかわからないものになってしまうことも多く、お互いの時間を浪費することになります。

早い段階から準備して、テスト対象について理解を深め、テスト実行者の配置とか必要な工数も決めたうえでテスト実行を始められるのでスーッと行くというのもあります。

蛇足ですが、この効果は、私がコンサルした多くの現場でも体験しています。テスト実行で予実が前倒しになり、予定の何日も前に終わってしまう。って現象です。

開発チームの人たちにとっても、実はものすごい安心感があります。なぜなら、テストチームの質問に全部回答しているし、テストチームの質問内容で、「この人達わかってるな。ちゃんとやる気があるな！」ってことが分かるからです。テストチームが、この要件、仕様の内容は理解してテスト準備したので、テスト実行は順調にできますって言ってくれることの安心感です。けど、この関係は直ぐにできるわけではないです。何年もの間一緒に仕事をして、関係が積み重なっているからこうなります。

そういう信頼関係がないと、テストチームのテスト実行が順調だとしても、ちゃんとやっているか不安になってしまうこともあるわけです。

では、品質は向上するのか？

上流でテストチームがレビューをするといい欠陥が見つかるかどうかはわかりません。いい欠陥を見つけるのに向いたタイプの人がいます。誰でも出来るわけではありません。いい欠陥とは、「そもそも観点が抜けている。」「処理に一貫性がない。」という類のものです。仕様書からは読み取れないものを、実務知識を基に推測するのもよい欠陥を見つけるコツです。

こういう指摘が出来ない人たちもいます。誤字脱字や、てにをはの指摘ばっかりする人たちです。あと、一番迷惑なのが、業務、仕様を知らない人が、とんちんかんな指摘（というか質問）をしてくるときです。これを頭ごなしにしてくるテスターがいると開発者はとても迷惑します。

2つの差は何か？というと大きくは、実務を知って、そのアプリがどう使われるかわかるかどうかです。ある意味当然の話ですが、それがないと上流でレビューをしても意味がありません。前述しましたが、テストチームも何年もそのシステムを担当する中で詳しくなります。自分たちで実務を勉強するので、キャリアによっては、開発者よりよっぽど詳しくなります。

ここをわからずに、新しく別の会社がテストに参画してきて、同じように上流で要件や設計のレビューをしても全く役に立たないわけです。実際、それが出来なくて困っている会社もあるそうです。

指摘の仕方も重要

これは、どういう人が上流のレビューに向いているかという話ですが、指摘が頭ごなしなのはよくないです。頭ごなしに話をしていけば、そりゃ人間同士だからイラッときます。指摘するのは短時間ですみますが、話がスムーズに行かず、修正までに時間がかかります。

なぜ良くないのか？とか、なんでこうなるのかを考えた上で指摘を出来る人が向いています。指摘をまとめるのは時間がかかりますが、その後がスムーズです。その一手間が大事です。

同時に、指摘していることが明確なのも重要です。指摘が「一発でズバッといく」とかよく話しますが、何をどう直せばよいかが、開発者にもスーッと入る指摘ができるかどうかです。これは一回の指摘でひとつのことだけ書くようにすることで実現できます。あとは他の指摘との関係をちゃんと説明するというのも重要です。よくないのは、「いろいろ思いついたことを書いてしまい、説明がズバッとしていなく、話が三次元になる（要はズレていくってことです）」指摘です。

テストチームの役割分担

上流からのレビュー、テスト設計、テストケース作成は上手く役割分担があると上手くいく話も教えてもらいました。

上流からのレビューは、細かいことが苦手でも、横との関係とか、要求からみた仕様の妥当性といったように大きく物事を見れる人が向いています。あとは前述しましたが、頭ごなしに話すのではなく、なぜこうなのか？これを直さないとどうなるか？と言った説明ができる人です。

テスト設計、テストケース作成は細部に目が行き届く人のほうが向いています。そして、テスト設計とテストケース作成は別の人にするとテストチーム内のレビュー効果が出て、良いテストケースが作れます。この段階でも指摘はでますが、このレベルで見つかる指摘はたいていリリース直前でも直しやすいものが多いので、この段階に指摘しても構いません。

ここで言うテスト設計とはテスト対象をある程度分割した単位で（ISTQBでいうところのテストアイテムです）、その中で何を確認して、何を確認しない。このテストアイテムで確認しない場合はどのテストアイテムで確認するのか？今回のメインの変更箇所（重点的にテストするところ）はどこか、影響はどこまでテストするか？一回確認すればよいか？バリエーションを全部テストするか？バリエーションは、分散させて合わせて100％になればよいか？バリエーションを組み合わせないといけないか？同値分割のズームインズームアウトはどこまでするか？ということをします。（言葉は、方言がいろいろあるので私が解釈してJSTQBなどの一般用語に代えています）

上記の方針にそって、テストケース（入力と操作と期待結果）を書いていくのがテストケース作成です。テストケースには、そのグループになる単位で、何のためにテストしているのか目的を書いて、テスト設計した人が確認するそうです。目的が上手くかけないときにはテスト設計側にあいまいなところがあるので、それもやり取りの中で、クリアになります。

上記3つの役割のどれをやるにも実務知識は前提です。全員があるわけではないので、それぞれに上手く配分できるとよいそうです。

信頼関係の積み重ね

上流からテストチームがレビューをやることは、リリース後に欠陥が出なくなるかどうかの話だけではないです。確かにその効果が覿面に出ることがありますが、チームの実力次第なので常にどのプロジェクトでも予防効果が出るとは限りません。

ただし、上記でかいたようにテストチームが良い仕事ができるようになるためにも上流にレビューで入ることが大事です。まとめると

・テスト設計時のもやもや（で手がとまる）ことの解消

・やるからにはちゃんとやりたいというテスト担当者のプロ意識の実現

・テスト実行がサーッといく

・開発者への安心感の提供

こういうことは、上流に入ることでちょっとずつ信頼関係を積み重ねた結果にすぎないです。この話をしてくれた人いわく、20年以上かけてこうなったといっています。20年前には、テストチームの話を開発者が聞きたいなんて誰も言わなかったし、考えられなかったけど、今では「この仕様に関して今ではテストチームさんの意見も聞きましょう」ってなっているそうです。これは20年前では考えられなかったことだと言ってました。

いろいろ問題課題もあって、一番は上記のような活動がより経営に近いところに分かってもらえないために起きることだそうです。（これ、その人から聞いてく中の話を私の中でサマった解釈です。）

はっきり書きづらいのですが結局、下で働くのであれば言うことを聞かなきゃいけない。立場をわきまえるって思うテスターも多いわけです。これはテスターのせいではなく、その上の人たちの責任なのです。（これも完全に、私の意見です。）

しかし、最近は自分がちょっとコンサルや管理者というか、本当の最前線の仕事をすることがなくなってしまったので、リアルな話は勉強になりました。きっと、これらの４つがあって、その上での品質の向上なのだと思いました。