Facebook x

ジャンル

"プロに訊く"シリーズ
"プロに訊く"シリーズ 2023.09.14
x hatenabookmark

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

執筆: Qbook編集部

ライター

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

システム開発には、テストの工程が欠かせません。しかし作る作業である開発に対して、正しく動くか確かめるテスト工程は、多くのエンジニアから「面倒」「やりたくない」といった、ネガティブな印象を持たれています。また、ソフトウェアテストをパスしたにもかかわらず、炎上するプロジェクトが後を絶たないのも事実です。

多くのプロジェクトがソフトウェアテストで陥りがちな問題とは何か、そしてどのような解決の糸口があるのか。テスト専門会社でソフトウェアテスト業務と、社内外のエンジニア教育に携わる石原一宏が、お客様からよく聞かれる質問に答えながら、ソフトウェアテストの心得を解説します。

今回話を伺ったプロ

石原 一宏
石原 一宏

バルテス株式会社 R&C部 部長 兼 上席研究員

年間1,200名を超える開発エンジニアにテスト・品質を教えるセミナー講師。 ソフトウェアテスト・品質技術の研究開発、社内/社外の技術研修やセミナーの講師、コンサルティングなどを担当する。

著書に『いちばんやさしいソフトウェアテストの本』、『ソフトウェアテストの教科書』。 PMI認定プロジェクト・マネジメント・プロフェッショナル(PMP)。 JSTQB認定Advanced Level テストマネージャ。

もくじ
  1. 「限られた時間の中で、抜け漏れなくチェックする」という矛盾
  2. ソフトウェアテストはネガティブに捉えられがち。でも、本当はクリエイティブでおもしろい
  3. プロジェクトが炎上!現場では何が起きているのか?
  4. 早期の問題解決がコストメリットを生む

「限られた時間の中で、抜け漏れなくチェックする」という矛盾

――「ソフトウェアテスト」という言葉は、いったい何を指す?

ソフトウェアテストには、いくつかの段階があります。例えば、自動車を作るにしても、パーツごとのテストがあり、パーツを組み合わせたエンジンなどのテストがあり、最終的にすべて組み上げた自動車そのもののテストがありますよね。ソフトウェアテストも同様に、各モジュールの動作を確認する「単体テスト」、各モジュール同士を組み合わせた機能を確認する「結合テスト」、すべての機能を含むシステム全体の動作を確認する「システムテスト」に大きく分かれます。

V字モデル2 (1)

システム開発の流れを表した図。(1)で設計と事前のレビューを行い、(2)で単体テスト、(3)で結合テストとシステムテストを行う

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

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

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

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

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

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

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

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

img_ishihara_01

「前回の失敗を踏まえた対策」としてお声掛けいただくことが多いですね。

前回のプロジェクトで大きな不具合を出し、抜本的な対策として次のプロジェクトから「ソフトウェアテストのプロを呼ぶ」というケースです。また、まさに今炎上しているプロジェクトに飛び込むこともあります。

最近は、エンジニア教育や社内プロセス改善の依頼も増えてきました。

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

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

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

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

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

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

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

img_ishihara_01

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

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

img_ishihara_01

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

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

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

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

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

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

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

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

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

img_ishihara_03

若い人にソフトウェアテストのことを話すときは、よく「ソフトウェアテストには基本の型がある」と伝えています。

スポーツでも習い事でも、最初は「基本の型」を身につけるところから始めますよね。
ソフトウェアテストも同様で、基本的な考え方や技法を身につけることが成長への近道です。どんなにいいツールが出ても、その人の能力以上の結果は引き出せませんから。

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

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

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

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

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

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

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

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

"プロに訊く"シリーズ
x hatenabookmark

執筆: Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。