こんにちは。QAリードの丸山です。

今回は、開発あるあるだと思いますが、開発が遅れることでテスト工数を圧迫し、それにより想定していたテストができなくなることがあります。
そういった、想定していたテストができなくなった場合に私がとっているテスト戦略をご紹介します。

テストとは

まず、テストとは何なのでしょうか。
テストの目的としては、テスト対象の品質が高いということを担保することであると考えます。

さて、続いて品質とは何なのでしょうか・・・？

国語辞典、Wikipedia、インターネットで「品質とは」という言葉で検索をしてみると、様々な回答があり、よくわかりませんでした。。。
ここではソフトウェアに対する品質を主として、顧客や利用者の満足度が高いことを前提とします。

いくら仕様通りに作ったからと言って、それが顧客や利用者にとっては満足しないものを作っていたとしたら、それは品質が高いとは言えないでしょう。

では、品質の高いソフトウェアを提供するためには、どういったことを考えないといけないのでしょうか。

開発が遅れテスト工数が減ることはよくある

私はソフトウェアの実装～テストまでを経験したこともありますし、実装メインで携わったこともあります。また、テスト専門で携わったこともあります。その中で共通して言えることがあります。

それは「開発が予定より遅れてテスト期間が短くなる」ということです。

テスト期間が短くなっているにも関わらず、予定していたテストは全てやらないといけないといった、終わるわけがないことをやらないといけない不思議な現象も経験があり、残業時間がすごいことになっていたことも…

テストスケジュールが短くなっているのにテスト工数が減らないことは稀な例ではあるかもしれませんが、テストスケジュールが短くなるのであれば、その分テスト工数を減らす必要が出てきます。

例えば、テストを1人で1人月（20人日）やる予定だったところ、テスト可能日数が15日に縮小した場合は5日分のテストができない、ということになってしまします。

テスト工数が減ったらどうなるのか・・・

テスト工数が減ると単純に「想定していたテストができない」といったことになります。

テスト工数として20人日を予定していたが15人日に縮小した場合、単純にテストケースも予定していた4分の3しか実行できないということになります。

そうなれば、テストできない4分の1に関しては不具合があるかどうかを確かめることができない、品質が良いかどうかもわからない状態になってしまいます。

品質が良いかどうかもわからないものを顧客に提供したとして、それで顧客は満足するのでしょうか？

しませんよね。

品質の高いモノを顧客に提供するため、テスト工数が減ったときに考えないといけないことが、限られた工数の中でいかに効率的に品質を高めるのか、品質を担保するのかということを考えないといけません。

限られた工数の中で効率的に品質を高めるには

今回はテスト工数がゼロ、または、ゼロに近い状態で明らかに品質を担保できない場合は対象としておらず、テスト工数が4分の1減ってしまう場合、4分の3のテストは実施できる場合を例にご紹介します。

当初予定していたテストケースを全て行うことができなくなった時に考えないといけないことは、限られた工数の中で品質を高める、顧客が満足する品質にするためにはどのようにテストを進めたら良いかということに意識を向け、テスト戦略を立て直す必要があります。

例えば、テストシナリオが4本あり、それぞれのテストシナリオでテストパターンが10パターンずつあった場合、総テストケース数は40件になります。

品質を担保するためには40件のテストケースを確認する必要があります。しかし、テスト工数が4分の3になってしまいました。

このような場合、あなたならどのようにテストを進めますか？

①  テストケースを上から順に消化する

テストケースを上から順に消化した場合、テストシナリオが4本、テストパターンがそれぞれ10本ずつで合計40テストケース存在していることから考えると以下のようなテスト消化が可能です。

この場合、未着手のシナリオDの中に障害があるかもしれないし、ないかもしれません。障害の程度もシステムを停止させるほどの重大で大規模影響を与える障害かもしれませんし、デザインの配色が違う程度の軽微な障害かもしれません。

このような品質でシステムをそのままリリースした時、どんなリスクがあるでしょうか？

・サービスの利用者からクレームが入るかもしません
・企業にとって損害を与える障害が発生するかもしれません
・サーバーがダウンし、一時的に利用できなくなる可能性があります

何もテストしていない以上、どんなリスクでも考えられます。こんな状態でQAエンジニアとして品質を担保できた、品質の高い状態です、とは言えないでしょう。

そこで品質を担保するためにとる手段が②です。

②まんべんなく重要なところから消化する

テストシナリオから重要なところからまんべんなく通った場合、40テストケースあるうち30ケースしか消化はできませんが、1シナリオあたり7～8テストパターンを消化することができます。

全てのシナリオをテスト実行することで、すべてのシナリオの品質が良いか悪いかの推測ができるようになり、障害が多数発生しているシナリオでは、未着手のテストケースに障害が潜んでいる可能性が高いと推測することができます。

また重要なところ、発生頻度が高くや影響規模が大きいなど、ビジネスリスクが大きいところを先に確認することで、障害が残った場合のビジネスリスクを最小限にすることができます。

図に表すと以下のようになると考えています。

見ていただくとわかるように、行き当たりばったりの上から順に消化に比べ、重要なところからテスト実行を行うことで、途中でのビジネスリスクを下げられると考えています。

この方法でテストを進めることができれば、この部分は障害が多かったからまだテストできていないテストケースに障害が潜んでいる可能性がある。しかし、利用頻度や影響規模も少なく、リスクは小さいといったことを顧客に報告することができます。

どういった障害が潜んでいる可能性があり、どういったリスクが想定できるのかがわかることで、顧客はその状態でリリースしても良いかの判断ができるでしょう。

テストで全ての障害を見つけることはできない

テストをした結果、「もう障害はありません。」と言える状態になることは一生ありません。

ということは、障害が潜んでいる可能性があり、品質が低い（顧客や利用者の満足度が下がる）状態になる可能性があるということです。
なぜなら、今日は障害が発生しなかったが明日の日付だったら障害が発生するかもしれない、年が変わったら障害が発生するかもしれない、日本以外のタイムゾーンで実行したら障害が発生するかもしれない、新しいスマートフォンやOSで実施したら障害が発生するかもしれない、そんなことだってありますので「もう障害はありません。」と言える状態になることは一生あり得ないということです。

その中でQAとしてやらないといけないことは、顧客の満足度が高くなるように品質を高めることです。

年が変わることで障害が発生するかもしれない、というリスクが潜んでいたとしても、現在が11月なので年が変わるまで1か月以上あり、障害が発生するかもしれない日まで猶予があります。

であれば、年跨ぎで障害が発生するリスクがあったとしても、現時点ではリリースしたとしても当分は品質として十分であるということができ、リリース後、年末を迎える前に年跨ぎのテストを行い確認をしておく、という手段を取るという方法をとることもできます。

まとめ

テストで全ての障害を見つけきることはできません。
その中でQAエンジニアとして、限られた時間で品質を確認し、潜んでいる可能性がある障害やそれに伴うリスクを正しく報告をすることだと考えています。

特にテスト工数が減ったとき、方法をとることで品質を高められるのかを考え、少しでも品質を高め、リスクを少しでも減らすような工夫を、私はすべきだと考えています。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/