テスト設計が学べるオンライン講座を受講して学んだものをアウトプットする記事(1/3)

こんにちは。Azukaritai の村穂です。

もしこの記事をデバッカーの方や、テスターの方が読んでいたら質問してみたいのですが、テストのスキルどうやって磨いてますか？会社によっては OJT があり、先輩が教えてくれたり研修が行われたりしてテストのスキルを学べるのかもしれません。また情報集めながら我流のテストスキルを磨いている方もいるかもしれません。

Azukaritai が活動する UNIBA INC.では、テストへの取り組み方はみなそれぞれ異なっていました。そのためテストに関する共通言語が少なかったり、テストの成果が人によって変わるといったことがありました。共通言語が少ないと引継ぎが大変だったり、コミュニケーションにかかる時間も長くなってしまいます。テストの成果が人によって変わるのもイマイチです。そのような問題を解決するべく、テストに関して共通理解の構築と知識の底上げのため ProAcademy という株式会社ProVision さんが提供するオンライン学習サービスを Azukaritai の何名かで受講してみました。

本記事ではその時学んだことをアウトプットし、学んだことの復習と、この記事を読んで下さった方に有益となる情報がお伝えできればと思い書いております。

テスト設計が学べるオンライン講座 ProAcademy の内容

この項では ProAcademy ではどのようなことがどのように学べたのか、簡単に紹介したいと思います。ちなみ ProAcademy の内容は JSTQB のシラバスと関連しており、JSTQB の試験に合格したい方にも有益な講座だと思います。

1.インプットフェーズ
ProAcademy は最短1ヶ月、最長6ヶ月の研修です（Azukaritai 受講当時）。Azukaritai は6ヶ月の研修に取り組みました。研修はインプットフェーズとアウトプットフェーズに分かれており、最初の3ヶ月は座学によるテストの基礎的な知識をインプットするフェーズでした。

ちなみにこの講座の対象は、非エンジニアや JSTQB の受講をめざしている方のようです。情報技術者試験などに合格された方はインプットフェーズで学べる内容に少々物足りなさを感じるかもしれません。

2.アウトプットフェーズ
後半の3ヶ月は、インプットフェーズで得た知識をもとに、実際に手を動かすアウトプットフェーズに取り組みました。講師が用意した仕様書をもとに、テストケースの元となるテスト観点表の作成を行いました。

テスト観点表作成後は、受講生同士のレビューが行われ、その後講師にレビューしてもらいます。テスト観点表の可読性や網羅性もチェックされますが、なぜその観点を見るのか？というところもしっかりチェックされました。合計3種類の仕様書のテスト観点表を作成し、受講生全員が書いたテスト観点の項目数は合計で1000を超えていました（多ければ良いというものでもないと思いますが。これまでに作成したテスト観点もしくはテストケースの平均的な項目数や多い時の項目数などをコメントでご紹介してくださる方がおられると嬉しいです）。

学んだことをアウトプット

インプットフェーズで学んだこと、テスト観点表をいくつか作成して気づいたことなどを紹介していきたいと思います。非常に長い記事になるので、いくつか投稿を分けて公開したいと思います。今回はソフトウェアテストの7原則について紹介したいと思います。

ソフトウェアテストの7原則

JSTQB の勉強をされた方にとってソフトウェアテストの7原則は基礎の基礎だと思われるかと思います。ソフトウェアの7原則について、それぞれ紹介したいと思います。

原則その1.欠点があることしか示せない
テストは欠点があることは示せますが、欠点がないことは示せません。テストで不具合が出なかったとしても、それは単に見落としている可能性があるのです。テストの結果はそういった性質を持つので、テストで不具合が出なかったからといって安心はできません。これは原則その7.バグゼロの落とし穴でも説明します。

原則その2.全数テストは不可能
全数テストとはソフトウェアに入力しうる全てのパターンをテストすることです。
例えば自動販売機をテストするとしましょう。投入するお金の種類や順番。飲み物がない時の操作。お釣りが切れている時の挙動。あらゆる操作や状態のバリエーションを全てテストしようと考えた時、その項目数はとんでもない数になります。これら全てをテストするのは現実的ではありません。テスト設計技法を用いて最適なテストを選出する必要があります。

原則その3.初期テスト
バグを早く見つければ、遅く見つけたときよりも修正にかかるコストを減らすことができます。初期テストは要件定義や基本設計の段階から用いることができます。テストは早く取り組んで、早くバグを見つけることが望ましいです。

原則その4.欠点の偏在
ソフトウェアの欠点は、全体に平均して分布しているのではなく、一部に偏って存在しています。この偏りは機能の複雑さの違いや、開発者の違いなどで生まれます。偏りの傾向を見つけることでより最適なテスト粒度を決めることができます。

原則その5.殺虫剤のパラドックス
よく聞く話に、殺虫剤が効かないゴキブリがいるというのがありますよね。殺虫剤を使いすぎたことでゴキブリが耐性を持ち、効かなくなる。ソフトウェアのバグも同じことが言えます。バグを報告すると開発者は報告されたバグが発生しないよう意識して機能を設計、実装していくためです。効果のないテストを繰り返し行っても仕方がないので、様子を見ながらテストケースの内容を更新し、新しいバグを見落とさないように気をつけましょう。

原則その6.テストは条件次第
テストの内容はテストするものの条件によって変化します。ユーザの個人情報を管理するシステムと管理しないシステムではテストをする観点が変わります。不具合が出るとまずいポイントが異なるためです。同じシステムだったとしても、全体に修正を加えた後のテストと一部の機能を修正した後のテストでは内容が異なります。効果的なテストを実現するためには条件の理解が必要です。

原則その7.「バグゼロの落とし穴」
すでに述べたように全てのバグを修正することはできません。全てのバグを見つけることは難しいからです。バグがないことは素晴らしいことですが、それよりも大事なのはプロダクトがユーザに価値を届けることができているかです。そこを意識せず、ただバグをなくすことを目標にすることは誤った選択をしてしまう恐れがあります。

次回は「テスト種別・テスト設計技法」について書こうと思います

ソフトウェアテストの7原則についての内容が長くなってしまったので、続きは次回の記事に書こうと思います。また今回の記事で紹介する内容はProAcademy で学べることの一部です。もっと詳しく知りたいと思った方は ProAcademy の受講を検討されてみてはいかがでしょうか。

ではまた次回の記事も読んでもらえると嬉しいです。