ソフトウェアテストの7原則（前半）

Last updated at 2023-12-25Posted at 2023-12-20

京セラコミュニケーションシステム株式会社
技術開発センター ICT技術開発部先端技術開発課の要谷（かなめや）と申します。
チームでは主にXRに関するソリューション開発を担当しています。

ちなみに京セラコミュニケーションシステム（以下、KCCS）には中途で入社しており、執筆時点で2年目となります。

はじめに

XRソリューション開発とは別に、私の社内での取組みの1つとしてソフトウェアテストに関する社内勉強会を実施しています。

KCCSに入社する前まではSIer企業でSEをやっており、不具合に悪戦苦闘していました。
このままではマズイと品質の世界に足を踏み入れたのがソフトウェアテストを知るきっかけでした。

ソフトウェアテストとひとことで表してもとてつもなく深く、果てしなく広い分野ですので、ソフトウェアテストにおける7原則をJSTQB-FL¹のシラバス²に沿って簡単にご紹介したいと思います。
*引用する内容は日本語版Version 2023V4.0.J01のシラバスを参考にしています。

まずは7原則の一覧はこちらです。
ちなみに、5、6、7についてはシラバス改訂で表現が変わったようなので補足しておきます。（今後の追加改訂などで表現が見直されるかもしれません。）

＃	原則	旧シラバスでの表記
1	テストは欠陥があることは示せるが、欠陥がないことは示せない	-
2	全数テストは不可能	-
3	早期テストで時間とコストを節約	-
4	欠陥の偏在	-
5	テストの弱化	殺虫剤のパラドックスにご用心
6	テストはコンテキスト次第	テストは状況次第
7	「欠陥ゼロ」の落とし穴	「バグゼロ」の落とし穴

一度に7つ全部を説明すると長くなってしまいますので、今回は1、2、3について見てみようと思います。

シラバスに書かれている内容を引用します。

テストにより、テスト対象に欠陥があることは示せるが、欠陥がないことは証明できない。
テストにより、テスト対象に残る未検出欠陥の数を減らせるが、
欠陥が見つからないとしても、テスト対象の正しさを証明できない。

システム開発では、様々なテスト活動を通してシステム上の問題を見つけて修正します。
これを繰り返すことで品質を向上し、よりよいシステムを提供することができるようになります。

とはいえ、テストした範囲では欠陥を見つけることができますが、テストされていない範囲についてはまだ問題があるかもしれません。

テストを実施する際には、想像力を駆使してありとあらゆる可能性を考慮し、テストを行う必要がありますが、これはなかなか難しいことです。

シラバスに書かれている内容を引用します。

すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である。
全数テストの代わりに、テスト技法、テストケースの優先順位付け、
リスクベースドテストを用いて、テストにかける労力を集中すべきである。

開発規模がある程度のシステムになると、入力項目も多く、利用される条件も複雑になっていきます。
それらすべてのパターンを考慮したテストを行うのは時間的な制約もあり難しいことが多いです。

たとえば生年月日を入力する欄があったとして、
過去100年分の範囲をカバーするような条件の場合、入力値のパターンは以下のようになります。

年：1924年から2023年までの100通り
月：1月から12月までの12通り
日：1日から31日までの31通り（注：28もあれば31もあります）
トータル：100×12×31=37200通り

たった3項目でも1つずつの値とその組み合わせを考えると、3万を超える入力チェックが必要となります。

住所氏名などを入力する項目が増えたりすると、文字や文字数のチェックなどが発生して際限がなくなってしまいます。

今後、別の投稿で書かせてもらうと思いますが『テスト技法』と呼ばれるテクニックなどを駆使して、効率よくテストを行う必要があります。

私はこの原則が一番気に入っているのですが、
まずは、シラバスに書かれている内容を引用します。

プロセスの早い段階で欠陥を取り除くと、
その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。
SDLCの後半に発生する故障が少なくなるため、品質コストは削減される。
早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである。

SDLCは、Software Development Life Cycleの略語です。

一般的に開発の後工程の作業中に、前の工程までの欠陥が見つかるとやり直しに時間がかかります。
もし、システムをリリースした後にお客様先の環境などで発覚すると、社内でのテストのやり直し、場合によっては謝罪や賠償など余計にコストがかかってしまいます。

早め早めにテストに取り組むことで手戻りや余計にかかってしまうコストを抑える効果がありますので、システムを動かして確認する動的なテストとは別に、要所要所でレビューのようなシステムを動かさずにできる静的なテストを行うことも品質を高めるために必要な取り組みとなっています。

今回はソフトウェアテストの7原則の内、原則1～3までをご紹介いたしました。
原則4～7については次の機会にご紹介したいと思います。

長崎 Innovation Labでは、IT技術を活用して、工場などものづくりの現場で活用できるシステムの開発に取り組んでいます。自由な発想でこれまでにない社会に役立つ製品・サービスを生み出し、長崎から発信していくことを目指しています。