Edited at

【要約】日経SYSTEMS 2019/9号


1. はじめに

以下雑誌の要約。


  • 題名:日経SYSTEMS 2019/9号


2. 今日から役立つ!テストの小ワザ

ソフトウエアテストには、ちょっとした工夫で効果を上げる小ワザがある。テスト専門コンサルタントが日ごろ実践しているテスト設計のテクニックを以下に記載する。


2-1. テスト設計の小ワザ


2-1-1. 「なぜこの値を入力するのか」を明確にする


  • ECサイトのテストで商品購入の機能をチェックするとする。このとき、テスト条件に「購入する商品:商品A」としか書かれていないことがある。これではなぜ商品Aを選択しなければならないのかが読み手に伝わらない。

  • 意図が読み取れないと、妥当性が不明なテストケースが出来上がる、テストケースのレビューの効率が落ちるといった事態が発生する。

  • こうした事態を防ぐため、入力値の持つ意味を書いておく。例えば、「購入する商品:翌日お届けが可能な商品(商品A)」「購入する商品:翌日お届けが不可能な商品(商品B)」
    といった具合。こうすれば読み手に意図が伝わり、手戻りや誤解を避けられる。


2-1-2. 期待値に「処理が正しいこと」と書いてはいけない


  • 期待値でよく見かけるのが、「処理が正しいこと」「問題がないこと」といった表現である。これらの表現は、読む人によって様々な意味に捉えられてしまう。もし、テストケース作成者とテスト実行者とで、想定している正しい処理に食い違いがあれば、トラブルにつながる。

  • 例えば、エラーメッセージの扱いである。テストケース作成者は、エラーメッセージが表示されることを想定して「処理が正しいこと」と記載したとする。しかしテストしたところ、何のエラーもなく処理が完了してしまった。テストケース作成者の意図としては、この場合は「誤った処理」なのだが、期待値の欄に「処理が正しいこと」としか書いていなければ、テスト実行者は「正しい処理」と判断してしまう。

  • 期待値で誤解を生まないためには、期待される処理の内容を具体的に書くべきである。先ほどの例では、「"在庫切れのため購入できません"とエラーメッセージダイアログ画面が表示されること」といった内容にする。こうすれば、何が正しい処理なのか読み手に誤解を与えにくい。


2-1-3. 仕様書に「~できる」を見たら「~できない」を連想する


  • 仕様書に「管理者ユーザーは、システム管理画面にアクセスできる」という記載があったとする。多くの人は「管理者ユーザーのアカウントでログインしてシステム管理画面が閲覧できることを確認する」といった内容のテストケースを作る。

  • しかし、このケースを作っただけならば不十分である。なぜなら、実は全ユーザーがシステム管理画面にログインできてしまうかもしれないからだ。つまり、「管理者ユーザーなのにシステム管理画面にアクセスできない不具合」は見つけられるが、「一般ユーザーなのにシステム管理画面にアクセスできる不具合」は見逃してしまう。

  • この場合は、「管理者ユーザー以外のアカウントでログインしたときは、システム管理画面にアクセスできないこと」を確認するテストケースもセットで作らなければならなかった。

  • 仕様書から、表面的な文章だけを参考にしてテストケースを作ると、暗に示された内容についての検証が漏れてしまう

  • そうならないため、「〇〇の場合、××できること」を確認するテストケースを作ったら、セットとして「〇〇ではない場合、××できないこと」を確認する必要があるかどうか、を必ず考えるべきである。


3. ダメージ広げる「二重帳簿」 問題を共有し解決に当たる

プロジェクトで問題なのは、遅れが発生することそのものでなく、遅延が可視化されていないことである。関係者の介入を恐れて本音と建前を使い分ける「二重帳簿」状態になれば、問題解決は絶望的になる。言いにくいことでも本音で問題を共有し、プロジェクトチーム全体で解決に当たるべきである。

QCD(品質、コスト、納期)に関するトラブル、鎮火方等を以下に記載する。


3-1. ストーリー

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

プロジェクトマネージャー ・・・ 野比
顧客 ・・・ 骨川
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

・野比「はい、大丈夫です。間に合わせます」

プログラムは仕上げられる。単体テストは終えられる。結合テストも大丈夫。
いや、厳密に言えば、製作と検証に多少の遅れが出ている。
でも、作業は管理できている。みんなで一丸となって頑張れば、絶対やり遂げられる。

・骨川「本当に、来月からユーザー受け入れテストをスタートできるんですかね?」
・野比「勿論大丈夫ですよ。進捗報告の通り、結合テストに遅れは出ていますが、環境設定の不備は解消しています。」
・骨川「本当なら昨日、操作説明会を実施頂くはずでしたが、ドタキャンになりましたよね。大丈夫なんでしょうね?」
・野比「大丈夫です。先ほどご説明したように、結合テスト環境の不備のため、説明会をできなくなり申し訳ないと
    思っています。不備解消のめどは立っていますから、すぐにでも説明会は実施できる状況です」
・骨川「あれ?環境不備は解消したんじゃないんですか?」
・野比「えっ?」
・骨川「先程、不備は"解消した"と言いましたよね。今、"解消のめどが立った"と言ったので、どっちなのかと」
・野比「ああ、設定まで終わってるんで、解消と言ったんです。テストツールはこれから動かします、という意味です」
・骨川「大丈夫ならいいんですがね。報告書によれば、テスト開始には問題なく間に合うってことですよね?」

問題はあるし間に合いそうにない、という言葉を野比は飲み込んだ。結合テストどころか、出来上がっていないPGもある。
テストツールがまともに動くかどうかも未知数だ。バグらしき事象もちらほらと出ている。
今週末はみんなで出勤してキャッチアップしようとしているのだが、どこまでリカバリーできるか。
でも、ここは言い切るしかない。お客様の前で、遅れているなどとは口が裂けても言えないのだ。

・野比「はい、大丈夫です。間に合わせますから(震え声)」


3-2. トラブルの要因


  • 「遅れそうだ」と予測し、遅れが現実になる前に対策を講じる。それでも遅れたらリカバリー策を講じた上で結果をトレースする。というPDCAサイクルがうまく回っている場合は安心できる。

  • ところが、当事者が可視化したがらない場合がよくある。「遅れている」「うまくいっていない」という状況を共有すると、顧客や上司が介入してきて面倒なことになるからと、遅れや問題を公にせずに自分たちの中だけで何とか解決しようしてしまう。

  • 最悪なのは、この事例のような二重帳簿である。現実の計画と実績とは別に、公式報告上の計画と実績が存在する状態、いわゆる本音と建前が乖離している状態を作ってしまうと、リカバリーは絶望的になる。


3-3. 鎮火法


3-3-1. 告白する


  • まずは二重帳簿をやめて、本音と建前を一致させるべき。「嘘をついていたのか」と言われ、顧客や上司との信頼関係が損なわれるかもしれない。

  • 嘘をつき続けるのと一度カミングアウトするのと、どちらのダメージが大きいのか。一般的に言って「ステルスリカバリー」の難易度は相当高い。そして、もしもうまくいかずに遅れが累積していけば、今よりはるかに深刻なダメージが生じる。

  • 他者の意見や考え方に理解を示すオープンマインド相互に協力して、プロジェクトの問題を解決するというスタンスを明確にして、問題を共有することが、相互の利益につながる。

  • 当然だが、タイミングが早ければ早いほど、幅広く対策を打つ余地が大きい。遅れれば遅れるほど、打つ手は限られてくる。だから、告白するのは善は急げである。


3-3-2. プロジェクトとして原因を分析し対策を講じる


  • 対策に入る前に、原因分析は欠かせない。場当たり的に追加要員の投入などの対策を講じても、遅れや問題の原因を除去しておかないと、同じことが繰り返される。

  • 大事なのは、プロジェクトとしてというところである。遅れには、様々な原因が考えられる。担当者のスキルの問題だけでなく、当初の工数見積もりに問題はなかったのか、割り込み作業や追加タスクが担当者の時間を奪っていないか、遅れにつながる問題の検知遅れはなかったかなど、幅広く検討する必要がある。


3-3-3. 結果をトレースして対策を見直す


  • 対策を立案実施したら、結果をトレースして、改善したこと、しなかったことを識別する。対策の変更や追加対策が必要になることもある。常にPDCAサイクルを回すことが重要。


3-4. 発生防止策・軽減策


3-4-1. バッファーを持つ


  • プロジェクト活動では、飛び込み作業や追加タスクが多く発生する。従って、タスクの組み換えや優先度の低いタスクの変更・延期・廃棄などでWBSを機動的に見直すことが必要になる。

  • しかし、どれも必須タスクで組み換えも難しい、という状況もある。タスクがあふれて即計画破綻、という事態を防止するためには、あらかじめバッファーを持つべきである。

  • そんな余分な工数やスケジュールが認められるわけないと思う人もいる。それなら言い方を変えて、変更に備えておく。ベースラインが確定した後で、必須機能の漏れが見つかることはよくある。一定量の変更に備えておくのは、それほどおかしなことではない。

  • 予備工数などと呼ぶと角が立つか場合があるが、変更に備える、リスクに備える、品質管理の工数を見込むなど、通常発生し得る程度のタスクは組み込んでおくとよい。


3-4-2. 可視化の仕組みを作る


  • 追加タスクがプロジェクトから見えなくならないように、WBSへの即日実績反映、要員ごとの工数把握など、日々の作業状況を可視化する仕組みを作っておくことが必要。

  • 例えば、WBSに反映せずに追加タスクを実施した場合、日々の工数実績が矛盾すれば、すぐに検知できる。


3-4-3. 第三者チェックを入れる


  • 当事者は、WBSの更新が面倒だったり、こんなタスクはすぐに終わるという希望的観測にとらわれたりして、柔軟な対応をしがち。第三者が工数実績やWBSを精査して、矛盾や不整合があれば見つける役目を担うのもよい。

  • また、相互チェックという手もある。忙しいプロジェクトほど、自分の目の前のタスクだけに集中しがちだが、検証工程などに入ると、他のメンバーの遅れが自分の作業に直結してくる。レビュアーだけでなく、担当者間でも、他のメンバーのWBS実績に目を光らせるとよい。