はじめに

本題に入る前に、近年のソフトウェアの立ち位置について触れておきます。

ご認識ある方もいらっしゃると思いますが、ソフトウェアはより重要性を増してきています。

電車やバスといった交通系インフラから、金融や医療に至るまで、私たちの生活に関わる多くのものがソフトウェアで制御されています。

しかもそれらは年々複雑になり、規模も大きくなっています。

複雑なソフトウェアによって社会は便利になりましたが、反対にソフトウェアがきちんと動く状態を作り上げるハードルは高くなる一方です。

f:id:aqui_jasmine:20220201125056p:plain

そのため、テストの重要度もあがっています。
作って終わりではダメなのです。

なぜテストをするのか？

前項で述べた前提について、十分理解している方は多いかと思います。

しかし、それでもテストは面倒に感じてしまいませんか？
ダメ出しはするのも、されるのも辛いという印象があるかもしれません。

それではその "ダメ出し" という認識を変えましょう。

そもそも、テストとは「対象のソフトウェアが、その時々でどのようにふるまうかを理解・確認し、関係者と共有するために行う活動」です。

つまり、ダメ出しを行うためにするものではないのです。

理解した結果と実際に確認した動作が異なれば、それはいわゆる「バグ」ですし、目的に適っていない動作をすれば、それは「使いにくさ」と呼ばれるものです。

ただ、それらは発見されるだけではほとんど意味がありません。
発見された脆弱性や予期せぬ動作を、関係者が対処・修正されて初めて意味を成すものなのです。
この時点でテスト＝ダメ出しではないことが分かりますね。

もちろん、バグを減らすことは重要です。
しかし、バグがないことはどうやっても証明できないため、「バグをなくすこと」を目的にしてしまうと、延々とテスト沼から抜け出せなくなってしまいます。

f:id:aqui_jasmine:20220201153544p:plain

そのため、「ソフトがどのように動いているのかを理解し、それが期待値とどのくらい近いのか確認・共有する」ことを目的として活動するのが大切です。

そしてテストをしっかりこなした結果、開発は障害で夜起こされることもなく、営業は自信を持ってサービスをお客様に紹介でき、お客様は使いやすく、みんなが幸せな世界になるという訳です。
こんなソフトウェアを目指したいですよね😊

ちなみに、テストをしないとどのようなことが起きるでしょうか。

まず前提としては、何事も早期発見が大事だということです。
その上で、リリース後にバグ等が見つかった場合、様々なものが失われることは想像に難くないですよね。

特に信用は取り戻すのが大変なため、とても大きな損失になってしまいます。
このようなことを避けるためにも、日頃からテストという活動を通して、品質を維持することが重要になるのです。

さて、実際にテストをする際に必要なのが、テスト計画です。

どの種別のテストをどのレベルでどのくらいやるのか、の計画をたてましょう。

具体的には、自分のテストしたい対象にあったテストを考えます。

例えば、自分だけが使うツールであれば、バグが発生しても自身が困るのみで、自身で直せばいいだけですので、綿密なテストは不要です。
しかし、車であれば多くの人命に関わり、万が一リコールとなれば巨額の損害が発生します。これを防ぐにはきちんと網羅されたテストが必要になるでしょう。

つまり、どんなテストをいつまでにどれくらいやるか、それを考えるのがテスト計画です。

テスト計画に必要な項目は、以下の通りです。

テスト対象
テスト対象が何のために作られたのかを考えます。
それを元に、テスト対象に必要な品質を明確にします。
テストの範囲
テスト対象となる機能の範囲を明確にしておきます。
特に連携システムがある場合は要注意です。
担当範囲を明確にしておきましょう。
テスト設計／戦略
目的を達成するためにどんなテストをどのくらいするのか考えます。(単体・機能・性能・セキュリティなど)
ツールの選定なども行います。
終了基準
どうなったらテストを終わっていいのか決めておきましょう。
基準はピンポイントではなく「許せる範囲」がどの程度か決めておくのがよいです。（スケジュールの都合で早期終了しないといけなくなった場合、どこまで許せるのか決めておくとなあなあにならずに済みます。）
スケジュール
何人でどのくらいの期間やるのかを決めておきましょう。