ソフトウェアテストプロセスの改善: 最前線からの教訓

この記事はPeter G Walenによるゲスト投稿です。

テストチームは、より短い期間でより良いソフトウェアをデリバリーし、テストをいっそう徹底させ、テストのカバレッジと品質を上げ、どのようなテストが必要かを見極めるとともに、どうにかしてテスト自動化の方法を考えなければならないという、高いプレッシャーにさらされています。テストマネージャー、リーダー、テスト実務者は、これらの改善を実現するため、テストプロセス自体を見直すことがよくあります。テストが「良い」場合でも、「じゅうぶんに良いか」という疑問が生じます。これは適切な疑問でしょうか？

どんなプロセスを改善するときでも、私がとるアプローチは同じです。問題があるかもしれないとき、症状を個別に叩くのではなく、全体として症状が何であり、問題を特定する方法があるかどうかを調べます。

テストプロセス改善に目を向けてみた場合、一般的に、記述される問題は症状であり、本当の問題ではありません。問題の核心に対処せず、症状をひとつひとつ潰しているということがあり得ます。何か別の症状が現れるまで、問題はふつふつと静かに沸きつづけるでしょう。

通常、「問題」の表現はいくつかに絞られます。

テストに時間がかかりすぎる。
テストのコストがかかりすぎる。
開発の後期またはテスト環境外で見つかる欠陥が多すぎる。

もちろん、バリエーションはほかにもありますが、私が見てきたかぎりでは、たいてい上記の症状のいずれか、またはいくつかの組み合わせに分類できます。

これらに対する簡単な返答は「何と比べて？」ということでしょう。

よりバランスの取れた返答は、次のようなものかもしれません。「何が期待されているのか、もっとよく理解できるよう、『長すぎる』、『多すぎる』、『遅すぎる』というのはどういう意味だか説明してもらえますか？たいていの場合、テストの作業量や期間の見積もりは、プロジェクトの初期に、まだ不明点が多い段階でプロジェクトに必要だと判断したものを基にしています。作業の進捗につれて、より多くのことがわかってくると、修正された作業見積もりや実際の期間にも影響が出ます。私たちは与えられた指示や、どの重要なプロセスを検証すべきかという命令に従って作業しています。これを再検討する必要があるのかもしれません」

これは「何と比べて？」を長々と言っただけかもしれませんが、多少、受け入れられやすいようです。

しかし、ボスタイプの人がこういうことを言ったとき、私が思うのは、「それは症状なのか問題なのか？」です。私たちが予定とコストを超過しているのは、まずい見積もり以外のもののせいなのでしょうか？テストのせいで「締め切り」に間に合わないのでしょうか？一連の欠陥が顧客による新規リリースの利用を妨げているのでしょうか？

何か別のことが起きていて、これらは問題の症状というよりは、問題の認識なのでしょうか？

自己分析
プロセス
目的、ミッション、チャーター
テストプロセス改善
課題

自己分析

たいていの人が難しいと思うことがいくつかあります。ひとつは観点を変えて、他人が見るように自分自身を見ることです。もうひとつは、はるかに困難です。それは、自分自身を真摯に見つめ、自分が実際にどのように行動しているかを確認することです。

自己分析を行うということになると、たいていの人はできるだけ避けようとします。ちっぽけな嘘や作り話を言い、いろいろな策を弄して行動を正当化します。しかし、そういったものをはぎとってしまうと、何が残るでしょうか？

それが、どんな形のプロセス改善においても困難な部分です。個人としてであれ、集団としてであれ、自分自身を見つめるときの課題は、自分がやっていたらと思うこと、やっていると考えたいことを脇に置いて、自分自身の実際の行動に集中することです。

実際のプロセスと公式のプロセスが違っている場合、「なぜ？」と自分自身に尋ねる必要があります。

たしかに、ありのままの自分を見ること、あるいは他人が見るように自分を見ることは、直面したくないイベントであるかもしれません。しかし、それなくして改善はあり得ません。

プロセス

ソフトウェアとテストをめぐっては、次のような主張があります——「プロセスがないなら、プロセスが必要だ。プロセスがなければカオスであり、カオスは良くない」。ただ問題は、「プロセス」というとき、たいていは「プロセスモデル」——つまり、誰もが従うべき公式の、定義されたパスを意味していることです(この記事では簡潔にするため、「プロセスモデル」の意味でプロセスを使います)。

プロセスを持つことは特効薬ではありません。プロセスがあるだけで、混沌とした環境が魔法のように片付くわけではありません。「テスター」の正義の帽子を被り、品質の騎士の甲冑を着込むことで組織にプロセスを押し付けようというなら、どうぞ頑張ってください。私が見てきたカオスに支配されているところは、たいてい、古参の、あるいは影響力の大きい人物がそういうやり方を好んでいたからです。

プロセスがあっても、誰も従っていないとしたら、なぜ？という点を問題にするべきです。

あなたやあなたのグループがやっていることをじっくり眺めて、行われたことがプロセスの指示することと違っているとき、なぜそのような違いが存在するのかを確認しなければなりません。

結局のところ、それは妥当性の問題になるのではないでしょうか。おそらく、公式のプロセスは、しなければならないことのコンテキストにおいて妥当ではないのでしょう。一回限りのことであれば、プロセスを少し調整してもよいかもしれません。毎回のことであれば、プロセスの価値が怪しくなります。プロセスがうまくいっていないなら、なぜうまくいっているふりをするのでしょうか？なぜわざわざプロセスがあるのでしょうか？

仮定するに、ある時点ではプロセスが妥当だったのが、導入後に状況が変わったのかもしれません。だとしても、変わらないものはありません。変化は不可避です。プロセスも折々に変更する必要があります。

目的、ミッション、チャーター

何かを行うとき、チームが達成すべき目的に注意しましょう。あなたの存在理由は何でしょうか？あなたのチャーターは何でしょうか？あなたのミッションは何でしょうか？あなたにはミッションがあるでしょうか？

たとえ意識していなくても、必ずあるだろうと思います。

はじめに、経営層の期待に注目しましょう。ボスタイプの人がテストプロセスの改善が必要だと言っているなら、話をしましょう。何の改善が必要だと思うか、何が足らないと思うかについて話し合いましょう。それがグループのチャーターの基礎になるかもしれません。

何が「壊れて」おり、修正が必要だと考えているのでしょうか？

「顧客が見つける欠陥が多すぎる」ということなら、具体的な例があるかどうか尋ねましょう。経験上の知見からでも説得力のあるストーリーを描くことはできますが、具体的な例がなければ、厳然たる事実を見出すことはけっしてできません。問題はただの直感なのでしょうか、それとも具体例があるのでしょうか？欠陥はテストで発見されるべきものだったのでしょうか、それとも顧客がまったく予想外の操作を行った結果なのでしょうか？

アプリケーションのその部分に対して、意図したものとは異なる動きを顧客が期待しているという可能性はないでしょうか？そうだとしたら、理由は何でしょうか？何がそのようなコミュニケーションや期待管理のミスにつながり、ずれが発生したのでしょうか？結局、テストの根拠にした設計と要求には、完璧に一致していたのです。

テストプロセス改善

こういったことが全体としてのテストプロセス改善に意味を持ちます。

テストプロセス改善(TPI)は、しばしばそれ自体が目的とみなされます。しかし、TPIが問題なのではありません。TPIは最終目的ではありません。TPIは本当のゴール、つまりテストからより大きな価値を引き出すための一歩でしかありません。

理由は次のとおりです。

多くのTPI活動は、直線的な、あるいは循環的な自己参照プロセスモデルに注目します。問題は、ほとんどの人間の思考は直線的ではないという点です。特に、私が問題に取り組むときはそうではないというのを、私は知っています。

私が直線的に思考していたなら、表面的には問題を示唆するものは何もないにもかかわらず、「正しい」と感じられなかったためにテスト対象を詳しく調べるなどということは、とっくにやめていたでしょう。そういう、正しくなさそうだという感じがしたとき、私はメモを見返したり、アプリケーションのログ（きちんとフォーマットされたものではない、生のログ）を見たり、データベース周りを探ってみたりします。何もないこともあります。何かが見つかることもありますが、そういう場合の「何か」は非常に重大であるケースが多いものです。

テスターとして報われたと思うのは、こういうときです。非常にわかりにくいが、ユーザーや顧客の嘆きの種となり、ひいては会社の嘆きの種となるような何かを見つけたのです。

こういったことは、まったく直線的には説明できないものです。私には、どう説明していいのかわかりません。説明できたらと思います。そうできれば、どっさりお金を稼いで、残りの人生を悠々自適に暮らすことができるでしょうから。

現実としては、それはあまりに有機的です。「有機的」というのは、Jerry Weinbergが言ったような意味ですが、これを始めて見たのは次のコンテキストでした: Becoming a Technical Leader