厳しい市場競争から製品の開発期間が圧縮される中、品質管理部門の多くでは開発者自身がテスト設計を行っています。テストに割けるリソースがないこと、また開発者が仕様を一番理解していることなどが理由にあげられますが、それではユーザ視点に欠けテストは往々にしてバグの発見や修正などの機能面に偏りがちとなります。結果、使い勝手や拡張性などにかかわる「非機能要件」の抽出が疎かとなり、想定外の不具合によりユーザからのクレームが生じるケースも少なくありません。
従来、ソフトウェアの品質は「機能要件」が重視されていましたが、ソフトウェアの品質特性を定めた「ISO/IEC9126」(※文末参照)をきっかけに「非機能要件」の重要性が認識されるようになっています。
「非機能要件」は、製品が提供する機能のうち、使いやすさや性能、信頼性、拡張性、運用性、セキュリティ等に関するものであり、製品品質を考えるうえで機能要件とともに必要不可欠な要素となります。機能要件の確保が当たり前となった現在、「非機能要件」が製品の市場優位性を左右しているといっても過言ではありません。
しかし「非機能要件」は、ユーザからはっきりとした要求があるわけではないため根拠や優先順位付けが難しく、仕様書に明記しにくいのが現状です。
たとえば、あるシステムの「電源ONから操作可能状態にいたるまでの所要時間」について。5秒がいいのか1分以内であれば問題ないのか、それはユーザの利用環境によって異なります。このような「非機能要件」を仕様として定めるためには、“実際の利用環境”から利用者が不満を持たない上限値を定める必要があります。
株式会社ヴェス(以下ヴェス)は、第三者検証専門会社としての豊富なノウハウから「非機能要件」を漏らさず仕様化・実装します。
対象製品の姉妹製品や類似製品、他社の競合製品などから抽出した「非機能要件」に対し、機能や過去の不具合、ユーザ視点をもとに根拠付け・優先順位付けを行い、仕様書を作成します。さらに仕様が確実に実装されていることを検証するため、緻密な計画の後に「非機能テスト」を実施します。
ヴェスの「非機能テスト」は、前述の「ISO/IEC9126」が定義する品質特性(機能性、信頼性、使用性、効率性、保守性、移植性)をベースにカテゴライズしたもので、8項目のテストによって“非機能要件”が実際に製品に実装されているかどうかを検証します。
「非機能テスト」の項目 |
|
---|---|
1.性能(パフォーマンス)テスト |
性能要件に定義された効率性(時間、資源)で動作することを確認します。 |
2.負荷(ストレス)テスト |
過負荷状態においても仕様通り動作することを確認します。 |
3.ボリュームテスト |
テスト対象に限界レベルの最大容量データを与えても仕様通り動作することを確認します。 |
4.高頻度テスト |
データを連続に処理させ、仕様通り動作するかを確認します。 |
5.累積稼働(ロード)テスト |
同一、または複数の処理を繰り返し、長時間にわたって動作させ、累積稼働状態における安定性や、処理の組み合わせによる不具合が発生しないことを確認します。 |
6.障害対応テスト |
障害が発生した場合、その影響が局所的なものに抑えられているか、または致命的なものにならないか、発生した障害を回復する手段が用意されているかなど、発生する可能性のある障害に対応できることを確認します。 |
7.セキュリティテスト |
テスト対象が、プログラムやデータ等について規定された機密保護レベルをクリアしていることを確認します。 |
8.ユーザビリティテスト |
テスト対象のユーザ・インターフェースについて、視認性と操作性の良否を評価します。 |
次頁では、この「非機能テスト」が実際に製品開発の課題を解決した、いくつかのケーススタディを紹介したいと思います。
対象プロダクト:VOD(ビデオ・オン・デマンド)のSTB(セット・トップ・ボックス)メッセージ通知システム
A社では、STBのシステムが利用ユーザにメッセージを通知する際に、ユーザ数(~数千人、~数万人)に応じてどの程度の遅延が生じるか性能の限界を把握したいと考えていました。
システムキャッシュの状態・設定で性能が可変するので、本番に近い環境でキャッシュの状態を把握しながらテストを行いました。結果、性能が設計時のベンチマーク指標を満たしていないことが判明。すみやかに改良・再検証を行い、システムの有効性を確認しました。
対象プロダクト:リスティング広告関連ツール
検証の結果、想定していたデータ量の一括投入は不可能であることが判明しました。そこで、データの投入手順を原因分析からテストデータ加工までを含め再度検討するとともに、本番環境でのシステム動作や不具合を発見するため、ボリュームテストを繰り返し実施。最終的に、ツールを正常に動作させながらデータを投入する手順を確立しました。
対象プロダクト:VOD視聴システムと他システムの連携
C社が開発中のVOD視聴システムは、他システムとのスムーズな連携がポイント。システム同士の連携時には、STBの番号から顧客のIDを検索するメッセージ送信が行われるため、メッセージ送信要求の頻度に対するシステム負荷を把握する必要がありました。
一つのシステムの不良動作により別のシステムが次々と影響を受け、大きなトラブルにつながるケースが多いため、設計された要求水準の10倍量のメッセージでテストを実施し、“非定常状態”におけるシステムの挙動を確認しました。結果、サーバのCPU利用率は定常に比べ最大で5%増加することが判明。この負荷であれば、想定量を超えるメッセージが来たとしても既存のシステムに影響を及ぼさず対応できることを確認しました。
対象プロダクト:流通業向けPOSシステム
ラボ環境において商用環境と同等の負荷を長期間(2週間程度)かけ、商用稼働の前にシステムの安定性を判断したい。
お客様の協力を得てラボ内に商用相当と思われる状況をセッティングしテストを実施。結果、新規開発部分のリソースリークやデータベースのデッドロック発生等の可能性を未然に確認でき、手戻りを防ぐことで運用チームの負荷軽減につながりました。
対象プロダクト:金融系サービスの基盤システム
システムはデータベースとキャッシュを組み合わせたものであり、どちらか片方がダウンしてもサービスを継続できるようにしたい。そのためには、障害発生時にサービスを継続しながら復旧する手順を確立する必要があります。
実際に障害を発生させ正しく機能するかどうか実証するため、システム環境やソフトウェアの仕様を細かく把握したうえで検証プロセスを構築。結果確認だけでなく復旧手順確立から動作検証までテストを実施しました。結果、キャッシュのみがダウンしたケース、データベースのみがダウンしたケースそれぞれにおいて障害発生後の手順を確立することができ、サービスダウンなしでシステムが単一障害から復帰できることを確認しました。
対象プロダクト:スクリプト言語を動作させるためのPaaS環境の新規構築サービス
PaaS環境の新規サービスについて、セキュリティ脆弱性診断が必要。
セキュリティ検査はお客様自身で行う予定でしたが、対象となっているのはPaaS上で実装されたアプリケーションのみだったため、PaaSを含む管理用ポータルサイト全体に対するセキュリティ検証を提案し、実行しました。結果、セキュリティ脆弱性を10件検出。セキュリティインシデントを未然に防ぐことができました。
対象プロダクト:オシロスコープ
市場が飽和状態にある中、競合他社との差別化によるシェア拡大を目指していたG社は、従来あまりユーザビリティを考慮してこなかった製品について非機能テストを決断。
利用者が限定的であり、これまで機能重視でユーザビリティがほとんど考慮されていなかった製品のため、デザインやシステム効率性において開発側の独善に陥っている部分が多々あり、視認性や使いやすさ等にいくつもの向上の余地があることが判明しました。数多くの指摘が最終製品のユーザ・インターフェースに取り入れられ、ユーザを想定した使い勝手の良い製品開発につなげられました。
以上、非機能テスト各項目のケーススタディを紹介しました。
いずれのケースも、“仕様化した非機能要件”が正しく製品に反映されていることを検証するため、本番に近い環境でテストしたことに意味があります。本番環境での想定外のシステム動作や不具合を未然に防ぐとともに、仕様通り非機能要件が製品に正しく実装され、機能することを実証しました。
2020.4.16