mhlyc -presentation

僕が書きたいことをひたすらに書き綴る、自己満足のブログです。

ソフトウェアテスト技法ドリル 第2章 線を意識する(1)

アドベントカレンダー22日目 第2章 線を意識する(1)

こんにちは。リリカルです。前回の続きでWACATEの予習です。少し間が空いてしまいましたが、めげずにやっていきます。

WACATE2016 夏 満員御礼!と 予習内容について - WACATEブログ

第2章 線を意識する

ここでは、連続して変化する数値や、文字コードなどについてテストする方法が取り上げられています。

同値分割と境界値分析

おなじみの技法ですね。ここでドリル本の例題を引用します。

例題2.1

 スーパーでりんごを売っています。販売個数に応じて価格が異なります。

  ① 1個〜4個:単価 200円

  ② 5個〜9個:単価 170円

  ③ 10個以上:単価 160円

 同値クラスに分けて境界値分析を使用してレジのソフトウェアの購入時テストケース(テストすべきりんごの数)を作成してください。

「ソフトウェアテスト技法ドリル テスト設計の考え方と実際」p.20 より引用

 

これまたおなじみの問題ですが、せっかくなので絵を描いて考えてみようと思います。

 

f:id:mhlyc:20160614064230j:plain

 こうして図示することで、「そうか、個数が増えるほど金額が安くなるんだな」というのが視覚的にわかります。この「視覚的に」というのがとっても大事です。例えば、以下のような仕様があったとしたらどうでしょうか。

 

・りんごの販売個数と価格

 りんごは販売個数に応じて価格が異なる。以下にその個数と価格を示す。

  ① 1個〜4個:単価 160円

  ② 5個〜9個:単価 170円

  ③ 10個以上:単価 200円

 

一見、「そうなんだ〜」と流してしまいそうになりませんか?

でもこれは、仕様書レビューの場であれば「売れた個数が増えれば増えるほど金額が上がっているけど、本当にこの価格でいいんだっけ?」といった指摘が出そうです。

このように、図で見れば一見して当たり前にわかることであっても箇条書きや番号付きリストの表現だけでは注意して読まないと気づかないということがあります。なので面倒でも図にしてみるというのは非常に大切です。

ドリル本の中でも、仕様書の問題点を発見するには、仕様書からいきなりテストケースに変換するのではなく、上記のように図を作るとか何か別の形に変換するのが大切だと述べられています。 

その他感想

最近、いろいろ本のまとめや要約をして気づいたことなのですが、本の内容をそのまま書いても意味がないし、やめたほうがいいです。わざわざ本の写しを読むのではなくて本を読めば済む話ですし、何より、引用の範疇を越えてしまったら著作権の侵害になります。

「本を読んでいて自分が引っかかったところはこんなことだよ」「大まかに言うと、こんな内容が書いてある本で、〜〜な人は読んだ方がいいよ」「自分の経験だと、こんなことが当てはまると思ったよ」など、本には直接書かれていない情報を書くことがとても大事です。それが要約やまとめ、感想の価値だと思います。

人の言葉を借りて語るのはやめて、自分の体験をもとに語れる人でありたいです。

 

しかし、このペースだとWACATE開始までに間に合わないなあ… どうしようかな。

ひとまず次も、ドリル本を読んでいきます。