テストのプロが語る、ソフトウェアテストの心得とは？

――バルテスの第三者検証サービスが担当するのはどの工程？

単体テストはプログラマー自身が行うことが一般的で、我々は結合テストやシステムテストを担当することが多いですね。欧米ではテスト工程をアウトソーシングすることが常識になりつつありますが、日本ではすべてのソフトウェアテストを自社で行っている企業が、まだほとんどではないでしょうか。

――なぜ日本企業はソフトウェアテストをアウトソーシングしないのか？

日本では「自分のことは自分で」という考えが美徳な部分があって、「自分が作ったものは自分で責任を持ってテストするもの」という考えが根深いように思います。リリース前のシステムを、部外者に切り出すことにも抵抗があるようですね。特に、小規模なプロジェクトではプログラマー1人がすべて背負わざるをえないため、ソフトウェアテストの質が属人化してしまうおそれもあります。

――大規模プロジェクトなら、ソフトウェアテストの負荷はある程度分散される？

一概にそうとも言い切れません。システム開発は要件定義、設計、プログラミングを経て、ようやくソフトウェアテストの工程となります。ほかの工程が遅れても納期は動かせないため、すべてのしわ寄せがソフトウェアテストにやって来るわけです。規模の大小にかかわらず、あらゆるプロジェクトが「限られた時間しかなくて、その中で抜け漏れなくチェックする」という矛盾を抱えているといえるでしょう。

ソフトウェアテストはネガティブに捉えられがち。でも、本当はクリエイティブでおもしろい

――企業がバルテスに第三者検証サービスを依頼するのは、どのような状況が多い？

――依頼を請けてプロジェクトに加わった後は、具体的にどういう動きをする？

まずは、どのような不具合が傾向として多く出ているのか、分析して整理を行います。不具合の傾向は内部のエンジニアがうすうす気づいていることもありますが、「ソフトウェアテストをやり直しましょう」とはなかなか言いづらいものです。第三者が客観的に評価することで、プロジェクトを方向転換しやすくなるのです。

また、炎上中のプロジェクトの場合は時間や予算が限られていますので、「どこを優先的に改善すべきか」を切り分け、最大限品質が上げられるソフトウェアテストを提案することになります。

――開発者自身が行うテストと、第三者検証サービスで実施するテストには、どのような違いがある？

第三者検証の特徴は、「仕様書に書かれていないこと」もソフトウェアテストの対象としていることです。
例えば、ECサイトの仕様書に「9時から18時まで販売できる」と書いてあったとします。仕様書を読めば「18時以降は買えないのだな」と予想できますが、これだけだと情報が足りません。18時以降は購入ボタンが押せなくなるのか、時間外のメッセージが出て買えないのか、仕様書にまったく書かれていないわけです。

私は自分の人生の半分である25年ほどソフトウェアテストの現場にいますが、仕様が100％網羅されている仕様書は一度も見たことはありません。せいぜい30～40％程度でしょうか。

――仕様書に書かれていない部分を、どのようにしてテストするのか？

私たちはソフトウェアテストを通して数多くのシステムにふれてきた経験から、「このシステムはこういう動きをしなければならない」という観点を複数持っています。仕様書に書かれていない"行間"を読み、完成形を想像しながら、足りない部分を補うようソフトウェアテストを作り上げていくのです。

すでに動作しているものから仕様を固めるという意味では、「リバースエンジニアリング」の側面もあります。ソフトウェアテストは「面倒でやりたくないもの」というネガティブなイメージがつきがちですが、本来は非常にクリエイティブで、おもしろい仕事ですよ。

プロジェクトが炎上！現場では何が起きているのか？

――これまで遭遇した現場で、特に多い炎上理由は？

炎上の理由として多いのは、何年も前に作られた既存システムに手を加えるケースですね。開発時の担当者はすでに辞めており、仕様書は残っておらず、ソースコードを見てもよくわからない。そんな状態のまま新機能を追加すると、今まで動いていた機能が動かなくなる「デグレード」が発生してしまいがちです。大局を見ず、「とりあえず動くもの作って」という考え方が炎上を引き起こしてしまう。

反対に、プロジェクトをうまく回せる人は、設計や実装の段階から「何ができればOKか」というテストファーストな発想を持っていることが多いですね。

炎上したプロジェクトは、プロジェクトマネージャ（PM）が各所から責められ、つるし上げられてしまう側面があります。だからといってPM一人を責めても何も解決しません。本来は、会社側が開発プロセスを定義したり、ソフトウェアテストのトレーニングを施したりといった施策をする必要があるのです。

そうした施策のひとつとして、バルテスがPMO（Project Management Office）としてPMを補佐するケースも増えてきました。PMOの役割は、品質面やテスト面で足りない部分をチェックし、PMに提言することです。PM一人の能力に依存しない体制を作ることができます。

――若手はどのような形でソフトウェアテストに向き合えばいいか？

若手はプログラミングのスキルもないままソフトウェアテストを任され、苦労している人が多い印象があります。経験が浅いと仕様書に書かれていないところまで想像力が及ばないので、どこまでテストすれば十分なのかわからない。結局、先輩や上司のやり方を見よう見まねでやるしかなく、属人的になりやすい。それなのに「抜け漏れなくチェックしろ」と言われるわけです。

――やり方がわからないのに「抜け漏れなくやれ」と言われる。そのような状況から抜け出すために、若手にできることは？

早期の問題解決がコストメリットを生む

――これまで自社で済ませていた作業を外注するとなれば、コスト面で難色を示す経営層もいるのでは？

ソフトウェアテストは、利益を直接生む部分ではないことは確かです。しかし、着目すべきは、問題発生時の「手戻りコスト」です。手戻りとは、開発工程を戻って修正すること。

プログラミング前のレビューで不具合を発見したときの修正コストを「1」とするならば、単体テストで不具合を発見したときの修正コストは「10」に膨らむと私たちは考えています。さらに、結合テストまで進んだ場合の修正コストは「40」、システムテストまでいくと修正コストは「60」。クライアント先で不具合が見つかった場合の修正コストは「100以上」になります。

システムによっては、社会的インパクトを与える事件になってしまう場合もあるでしょう。早期に問題を発見し、手戻りコストを抑えることは、十分にコストメリットがあるのです。

――ソフトウェアテストのアウトソーシングに抵抗がある場合、どのように説明する？

いきなり大規模プロジェクトに導入されるのは双方にとってリスクでもあるので、「ちょっと新しいやり方をしてみませんか？」と、スモールスタートで始める方法もよく使います。アプリケーションの単機能や画面単位から始められるお客様もいらっしゃいます。事前にを受講して、バルテスという会社の考え方を知った上で依頼してくださるお客様も多いですね。

我々の第三者検証サービスは、単純に用意された項目のテストをこなすのではなく、仕様書の"行間"を読んでソフトウェアテストを作り上げます。繰り返しになりますが、ソフトウェアテストは本来非常にクリエイティブな作業です。たとえ仕様書に記述がなくても、ユーザーにとって使いやすく、快適で正しい製品を作れているのか確認する。これは長年ソフトウェアテストに携わってきた私たちだからこそ、提供できる価値だと考えています。