製品を提供する企業にとって、「リリース後の不具合発見」をどうやって回避するかは、大きな課題です。リリース後に不具合が発見されると、開発の工数が膨れ上がるのはもちろん、ユーザー満足度が低下する大きな要因になります。なぜリリースまでに不具合が発見されないのでしょうか。それはソフトウェアテストで見落としがちなあるポイントがあるからです。
IPAの発表した「情報システムの障害状況2019 年後半データ」によると、2019年後半に報道された情報システムの障害は89件となり、これまでにない高い水準になりました。この年は消費税増税による不具合という影響があったものの、それを除いても60件、月平均10件となり、2018年の通年平均件数の約2倍と非常に多くなっています。最近では品質を著しく損なうことにより社会問題になるケースもあり、情報システムの品質に注目が集まっています。
またコロナ禍で経営環境が大きく変わる中、「DX(デジタルトランスフォーメーション)」の取り組みでIT製品を活用して革新を図る企業が増えました。変化の激しい環境に対応していくためには、製品開発にもスピードが求められます。製品のニーズが増え短期間での開発が求められる中、仕様を作りこむ余裕がなく、製品要求があいまいなまま開発が進んでしまうケースも見受けられます。仕様とテストの整合性が取れず製品が当初の要求を満たさないまま、市場に出てしまうことにもなりかねません。
製品要求があいまいなままテスト段階でリソースを手厚く投入しても、効果は上がりません。まずは仕様書の精度を上げて、開発から検証までの評価プロセスを確立する必要があります。そのためには、仕様を策定する上流工程の段階でテストエンジニアを投入し、第三者の視点でテスト設計を行う必要があります。
その上で重要なポイントとなるのが、「テスト要求仕様書」の作成です。テスト要求仕様書とは、テスト設計のもととなるもので、仕様や要件定義の「抜け」や「漏れ」を防止するために必要です。テスト要求仕様書では、製品の要求を一覧化し、インプットとして要求の出所となるもの(製品仕様書や機能ごとのソフトウェア仕様書など)、アウトプットとして要件・仕様・テスト項目を定義。要求仕様書によって、仕様の課題を早期に発見して、次工程に混入するのを防ぎます。
要求仕様書の作成手順は、次の通りです。
各仕様書について、整合性やテスト実現性などを「検証視点」と「ユーザー視点」の両方から確認し、あいまいな部分や考慮もれを洗い出していきます。洗い出したものについて再度検討し、仕様書をメンテナンスします。
製品に関するあらゆるドキュメントから製品要求を抽出して一覧化し、抽出した製品要求とドキュメントを紐づけます。このドキュメントがテスト項目を作成する際のインプットになります。
ドキュメントを精査して非機能要件を抽出します。
テスト要求仕様書は、非機能要件を整理できることもメリットのひとつです。実はこの非機能要件は、非常に見落としやすいという問題があります。非機能テストとは、文字通りソフトウェアの機能以外のテスト全般を指します。非機能テストの観点は、製品の使いやすさや性能、信頼性、拡張性、運用性、セキュリティなど多岐にわたります。例えば性能テストで「ソフトウェアの処理時間は、ユーザーが耐えられる長さか」という検証はとても重要ですが、それを満たしたとしても売上が上がる、新規顧客が開拓できるといったビジネスに直接貢献することはできません。また性能や負荷、拡張性など目に見えない要素多いため、テスト項目としてイメージしにくい面もあります。そのため、ユーザーが具体的に要求するのが難しい領域になっています。
非機能要件を満たさなかった時の影響は、広範囲に及びます。例えば負荷が集中してシステムがダウンすると、全機能が停止してしまいます。機能要件の不具合であれば、部分的な修正で済むことが多いのですが、非機能要件の場合は、システム基盤そのものの見直しが必要となる、全ての機能に影響を与えて大幅な手戻りになる、といった大きなリスクになります。多くの企業では、機能を熟知している開発者がテストを担当しています。開発者は機能を満たすことに集中しているため、ユーザー視点が抜けがちで、非機能テストを見落としやすいということに注意する必要があります。
ご紹介した通り、非機能要件は利用者が具体的な要求を定義するのが難しい領域です。非機能要件は次の観点から抽出すると効率が良くなります。
製品仕様書や機能ごとの仕様書をもとに特徴を抽出します。システムの機能を精査すると、ソフトウェアからのレスポンスを求められるのか、大量のデータを処理するものなのか、ユーザーが混乱しがちなプロセスになっているのか、といった特性が浮かび上がります。
過去に開発したシステムのテスト仕様書、検収業務報告書、不具合情報から抽出します。ソフトウェアは毎回開発するたびに違うものになりますが、基盤構成は類似しているケースも多く、過去の情報は参考になります。
製品の使用感や見た目、操作性などの要求を可能な限り収集し、ユーザーから見た機能はどうあるべきかという観点で要求を抽出します。
現在は、開発する製品に対してスピードが求められるため、製品品質が犠牲になりやすい状況にあります。短期間に必要なリソースを投入するのが難しい場合もあるでしょう。その場合には「第三者検証サービス」を利用するのもひとつの方法です。
第三者検証サービスでは、経験豊富なテストエンジニアが品質評価の抜本的な改革を支援します。蓄積したノウハウをもとに、抜けがでやすい非機能テストも漏れなく抽出し、適切なテスト要求仕様書を作成します。ヴェスが過去に支援したお客様の検証では、リリース済みのソフトウェアからで約100件の不具合を検出した実績もあり、製品の品質改善にも貢献します。
厳しい開発の状況の中でいかに品質を上げるか、悩んでいる方も多いのではないでしょうか。変化の激しい今こそ、品質評価プロセスを見直していくことが不可欠だとヴェスは考えています。
ヴェスは、上流工程から製品・サービスのあるべき姿を品質に落とし込む高い技術力を備えています。不具合の発見はもちろん、要件や設計の漏れを上流で発見することで、開発工数の削減と、製品のユーザー満足度向上に努めています。製品の品質について改めて向き合うために、ぜひ一度ご相談ください。