テスト勉強会第2弾「テストを知ろう」

はじめに

以前行った初回となる勉強会「テストとは」に続き、2回目の勉強会になります。

(前回の記事↓)

tech.88oct.co.jp

 

今回もDeNA SWETグループの平田さんを講師にお招きして、開催して頂きました!実際に勉強会で見せてくださった資料と共に紹介していきます。

 

目的

今回の勉強会の目的は「『テスト』について『まず』知ること」です。普段何気なく口にしている「テスト」とういうものについて再定義を行うことで

  1. プロダクトを作るにあたってのより良いものを作れる
  2. 共通語彙により意思の疎通ができる

という2つを達成しようという狙いがありました。

 

結構な人数が集まりました。この人数なら別のスペース確保しておけば良かったとも・・。

f:id:yohei-fujii:20191018202050p:plain
 

内容

まずは前回の復習からです。

  • テストというのは「現在の状況」を教えてくれる
  • テストがあるから品質がよくなる訳ではなく、プロダクトをよくするのは我々であるということ
  • 知っておくと良い品質良識(狩野モデル・VerificationとValidation・CheckingとTesting)
  • テストの分類(ブラックボックステストとホワイトボックステスト、動的テストと静的テスト)

改めてテストの意義と分類について整理しました。

 

そして今回のテーマは「テスト技法を知ろう」です。さまざななテスト技法がある中で、今回はその中でも2つを取り上げていただきました。

 

同値分割・境界値分析

1つ目が、「同値分割・境界値分析」です。

f:id:yohei-fujii:20191018130405p:plain

聞きなれない言葉ですが、意味を理解すると難しくはありません。何気なく普段からテストで行っていることを言語化しただけとのことです。

f:id:yohei-fujii:20191018130409p:plain

連続性の説明と注意点です。確かに、ここにあるように、お金と言っても米ドルのような通過になってくると、一概に連続性の単位が同じである訳ではないので気をつけなければなりませんね。

そしてなぜ境界値に気をつけなければならないのかという点ですが、日本語の難しさも絡んできます。

f:id:yohei-fujii:20191018130835p:plain

 

むむ。これ見ると確かに!と感じるかと思います。人によっては認識がズレる箇所でもありえます。

 

ここで平田さんが、わかりやすい図を出してくださいました。例として、パスワード登録をあげてくださっています。

 

f:id:yohei-fujii:20191018131937p:plain

テスト結果によってグループ分けされた値の集まりを「同値クラス」と言うそうです。そしてその中でも、有効であるものと無効であるものがあります。

 

上の例では、4文字未満、そして16文字以上である場合に、パスワードとしては無効になってしまいますので、「無効同値クラス」と呼ばれます。また使用禁止である「@」が入っている場合ももちろん無効となりますね。

 

そしてこの情報を元に、「同値クラステスト」と「境界値クラステスト」を行います。

f:id:yohei-fujii:20191018152827p:plain

「同値クラステスト」では、「有効」「無効」それぞれのクラスから代表値を、「境界値クラステスト」では、境界値と境界値の1つ上と1つ下を選ぶんですね!

 

テストケースの例として以下のようにわかりやすく説明されています。

f:id:yohei-fujii:20191018195121p:plain

 NGのケースで、2つ目に挙げられているのがポイントですね。2つの要因を組み合わせないということ。確かに同時にやると、何が原因でテストが落ちるのかわかりにくくなります。この考え方は、普段実装する上で、不具合やエラーを探す時の考え方としても大切だと感じました。

デシジョンテーブル

そして2つ目が「デシジョンテーブル」つまり「意思決定表」です。

条件が複数ある場合に利用されるテスト技法です。

 

 「ソフトウェアテストの教科書」にあった例を参考に、説明して頂きました。

f:id:yohei-fujii:20191018195644p:plain

遊園地の乗り物などは、身長制限や年齢制限があったりもします。その際には、どのようにテーブルを作るのでしょうか。

f:id:yohei-fujii:20191018195739p:plain

まず、このように枝分かれした図をイメージします。今回は3つの条件があり、それぞれに対して、YesとNoがあります。つまり、8通りのケースが考えられます。

 

そしてそこからこの8パターンをテーブルに落とし込みます。

f:id:yohei-fujii:20191018200303p:plain

1番の人、つまり3つの条件を全てクリアした人が乗れる人ということになります。 

 

本来であればもっと複雑化していくと思います。他の例だと、会員種別やお金の割引率に関するものも紹介して頂きました。(「因子」や「水準」といった話も出てきましたが、長くなりますので割愛させて頂きます)

 

この説明を行いながら、このデシジョンテーブルを作るには仕様を把握していなければならないということを指摘されていました。。つまり「副次的効果として仕様確認ができる」という点がデシジョンテーブルにはあるということです。

 

テストケースの整理にもなるし、仕様把握の確認にもなるし、便利ですね!

さいごに

今回挙げてくださったテスト技法は、どのテストにおいても有効なものだということで、ご紹介頂きましたが、確かにわかりやすく、知っておいて良かったなと思うものでした。

 

最後に参考図書として、3つを挙げて頂きましたが、社内図書にもあるので、一通り読んでみようと思います。

  1. ソフトウェアテストの教科書
  2. はじめて学ぶソフトウェアのテスト技法
  3. ソフトウェアテスト技法ドリル