ソフトウェアテストの基礎:ソフトウェアテストの7原則
その第1回目として、これまでなんとなくテストに接してきた方にとっては新鮮、かつ考えさせられる、ソフトウェアテストという技術分野の持つ7つの原則についての紹介と、それぞれの原則に対して実際に現場ではどのような対策を取れば良いのかを考察してみたいと思います。
1.テストは欠陥があることしか示せない
あまり直感的ではありませんが、厳然たる事実です。司法の世界における「悪魔の証明」とほぼ同じ命題で、ある消極的な事象が「ある」ことを示すにはその一例を発見すればよいのに対し、「ない」ことを示すにはその事象が関連するすべての領域を精査する必要があるからです。さらには「欠陥」(=エラー、バグ)という定義の限りない広さも、この原則を成り立たせる要因といえるでしょう。
この原則は技術の適用や努力では「動かせない」タイプのものですから、契約や要件定義等、プロジェクトの最初期の段階でステークホルダーに対して、この原則を前提としたテスト計画やレポートになることを承知してもらう必要があります。昨今は発注者側のリテラシーも向上しており、以前のように「どんなバグも許さない」とする”無茶な”姿勢を示されることは少なくなってきていますが、はじめてITシステムの導入を検討されるお客様の中には、このような特性をご存知ない方もおられるかも知れません。決して声高に主張すべきではありませんが、判例としてITシステムに欠陥が含まれることをやむなしとした事例がありますので、紹介しておきます。
東京地裁平成9年2月18日判決
いわゆるオーダーメイドのコンピュータソフトのプログラムで、本件システムにおいて予定されているような作業を処理するのであれば、人手によって創造される演算指示が膨大なものとなる。人の注意力には限界がある。そのため総ステップに対比すると確率的には極めて低い率といえるが、プログラムにバグが生じることは避けられず、その中には、通常の開発態勢におけるチェックでは補修しきれないものも生じる。よって検収後システムを本稼動させる中で初めて発現するバグもあり得るのである。
もちろん、基本的なテスト工程の不備や要件漏れ、はたまた致命的な速度性能の未達等によって、ベンダ側の瑕疵とされた判例も数多くあります。
2.全数テストは不可能
ソフトウェアが取り得る全ての状態、入力条件の組み合わせをテストすることは、仮にスーパーコンピュータを用いた自動テストシステムを用いたとしても時間的に不可能です。
先日、日本科学未来館がYoutubeに投稿した「フカシギの数え方」という動画が国内外で話題を呼びました。2x2などの四角形から構成される四角形について、左上から右下までたどる道筋がいったい何通りあるのか、構成する四角形を増やしながら実際に数えていくといった内容のものですが、6x6の時点で既に5億通りを超えてしまいます。経路探索という一部の事情ではありますが、この原則を成立させる事情の一端は感じとれるかと思います。
この原則に対しては、まさにこれから本サイトで取り上げられるテスト分析、設計の技法が正対した解となります。いきなりコードを書き始めた結果、機能同士やエラーハンドリングの整合性が取れずあとで帳尻を合わせる、という徒労は、ある程度の規模のソフトウェアを開発した方なら一度は経験したことがあるでしょう。テストの場合は、この組み合わせ数の爆発という形で現れます。
事前にテストすべき領域の定義やその網羅の方法、適切な間引きの方法について検討しておくことが、テストを成功させる第一歩となります。
3.初期テスト
ここでいう「テスト」とは、いわゆる開発されたテストの実行ではなく、分析、設計、実装、実行、等々を含む「テストの活動」全てを指しています。いわゆる「テストケース」を用いたテストは動作するソフトウェアが既に存在することを前提としていますが、テスト分析、設計、実装、及び静的テスト等の「テストの活動」は、要件定義や基本設計を行なっている段階から適用することが可能です。
実際、この初期テストの原則を開発プロセスモデルに昇華させたものとして「Wモデル」があります。
The W-MODEL Strengthening the Bond Between Development and Test by Andreas Spillner
組織や定義によって「W」の左側の開発アクティビティ毎にテスト分析、設計、あるいはその両方を適用する事で、要件定義やアーキテクチャ自体の欠陥を検出しようと試みるもの、または単に静的技法を適用する、などさまざまな形が存在します。しかし、そのどれも品質コストの概念から考えれば予防コストに近い性質を持つため、妥当なアプローチといえるでしょう。
4.欠陥の偏在
リリースをブロックするような重大なバグはある特定のモジュールに多数存在する、というソフトウェアテスト版の「パレートの法則」です。
これは経験則として知られており、実際筆者もこの法則がデータとして現れる様子を何度も経験しています。バグをあらかた出し切ったあと、結果としてそうなることは多々ありますが、それを事前に予測してテスト計画を最適化するのは中々に技術と度胸が要ります。具体的なアプローチとしては、定義されたテストウェアの集合全体から、テスト観点の網羅率を保ちながら粒度を大きくしていき、1/10ぐらいの工数を当ててサンプリング、実行します。ヒットしたところから粒度を小さくしていく手法などが挙げられます。ただし、テストには対象物の品質を保証するという側面もありますので、今は欠陥を見つけるべきか、網羅して保証すべきかの適切な判断が必要になります。
5.殺虫剤のパラドックス
同じテストを同じ製品に適用し続けると、いずれ欠陥の検出能力が落ちてくる、というとても直感的かつ頷ける法則です。同時に「どうすれば良いのか?」を考えて運用するのが、とても難しい厄介な法則でもあります。
ある観点に沿って設計、実装されたテストケースの集合が一定の欠陥を検出し終えた段階で、変更が意図しない箇所に影響を与えていないかをチェックしたり、一度定まったはずの品質を再確認するためにテストスイートへとその役割を変化させる必要があります。
この「チェック」を実行するのに、初回と同じだけの工数を見込んでいないでしょうか。確かにテスト手順のFIX具合やオペレータ自身の習熟など、単純に同じ工数が掛かるわけではありませんが、それでも実行工数を50%以下に抑えることは難しいはずです。そこで、既に手順と確認方法が判明しているテストケースについては自動化を検討し、節約できた実行工数を「テストを進化させる」コストにあてる、というのが本原則への素直なアプローチとなります。
ここで注意すべきなのは、自動化で削減できるコストはテスト分析、設計、実装、実行、結果分析と連なるテストプロセスのうち「実行」のみであることです。先の例では既に分析、設計、実装が終わっているテストについて自動化を見込むため実行コストの削減が図れますが、これらの活動が十分でないテストスイートについては、初回と同等、いえ、実装については初回以上の工数が必要となります。
6.テストは条件次第
ここでいう「条件」とは、ISTQBの定義でいうところの「テスト条件」ではなく、プロジェクトや会社を取り巻く環境全てを指しています。
ISTQBの「テスト条件」とは
”コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。
たとえば、機能、トランザクション、品質特性、構造要素など。”出典: ソフトウェアテスト標準用語集(日本語版)Version 2.0.J02 (2011年04月19日)
と、テスト設計や実装の前提、値としての「条件」を思い浮かべた方にとっては、かなり広義にわたる定義が示されていることがおわかりかと思います。この原則における「条件」は更に広いです。
プロジェクトの状況や製品が属するドメインによって、テスト分析や計画が前提とできる品質のレベルやコスト、期日感が変わってきます。例えば人命や財産に関わるソフトウェアのテストと、プロモーションのために期間限定で配布されるスマートフォンアプリでは、求められる品質の次元が全く異なります。前者であればテスト分析、設計の粒度、精度もさることながら、ソフトウェアの作り方自体、プロセスの品質も考慮する必要がありますが、後者において、プロジェクト単位でプロセスの品質まで見ていては明らかにコストに見合わないでしょう。
一部テストマネジメントのノウハウも含まれますが、常に最大限コストをかけたテストを実現すべきでないことを、原則レベルでも訴えていることを念頭においておくべきでしょう。
7.「バグゼロ」の落とし穴
バグがないことが高品質なソフトウェアである、という現場がよく陥るワナです。
バグがないこと、すなわち高品質であることを示すには、品質を十全に網羅した完璧なテスト分析、完璧なテスト設計……と続き完璧なテスト実行と報告、修正、リリースが必要になります。ここまで挙げたもののうち、ひとつでも「完璧」であると胸を張って主張できるものがあるでしょうか? 筆者は尻込みします。
製品は一般的にバグと表現される機能の未達のみならず、性能や信頼性等の指標によってもその価値が大きく左右されます。例えば、機能一覧は完璧に満たしているが、起動するのに10分掛かるソフトウェアを常用するのは困難です。きっと「バグとは言い切れないが許容できない」というフィードバックを頂くことでしょう。また、検収を通過したとしても、使用性や運用性に著しく劣る製品であれば、早々に刷新の対象となってしまいます。
これを避けるには、テスト分析の段階から「バグ」が表す範囲、裏を返せば対象が持ち得る品質特性を広く俯瞰した上で、その製品が重視するものを選択していく必要があります。全てを重視することは現実的ではないので、任意の品質モデルの中から優先度を設定して上位のものから設計を検討していくことをおすすめします。一度ステークホルダー間で俯瞰することができれば、パフォーマンスやセキュリティなどBTSに簡単に登録できる欠陥だけがバグではないことの総意が取れるはずです。
いかがでしたでしょうか。これらの7つの原則は、テスト分析、設計技法のほとんどが前提としているものであり、依然として現場での課題になっているものでもあります。これからソフトウェアテストを学んでいかれる方が、常にこれらの原則を頭の隅においておくことで、先行者の二の轍を踏まず、スムーズに技術の現場への導入と、成功を重ねられることを願ってやみません。
参考文献:
テスト技術者資格制度 Foundation Level シラバス 日本語版
© International Software Testing Qualifications Board VER2011
© 日本語翻訳版Japan Software Testing Qualifications Board Version 2011.J02,ソフトウェアテスト標準用語集(日本語版)Version 2.0.J02 (2011年04月19日)
International Software Testing Qualifications Board 用語集作業班
執筆者プロフィール しんすく(け)さん(@snsk)
NPO法人ソフトウェアテスト技術振興協会(ASTER)会員 / JaSST Tokyo実行委員 / Android テスト部 副部長。組み込みブラウザのテスト担当、マネジメントを経て本社研究開発部門の品質保証セクションの再構築及びそのフレームワーク開発を担当。現在、某社品質保証責任者。ソフトウェアを楽しく素早く創るための最重要技術としてソフトウェアテストを学ぶ。