【書評】「ソフトウェアテスト技法練習帳」を読んで、体系的なテスト技法の知識を身につけよう

はじめに

弊社ソニックガーデンの中でも「この本、面白そう」と少し話題になった「ソフトウェアテスト技法練習帳」を買って読んでみました。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

このエントリでは本書を読んだ感想をざっくりまとめておきます。

本書の概要と目次

最初に、本書の概要と目次を技術評論社の書籍ページから引用します。

この本の概要

新人や経験の浅いテストエンジニアにとって，座学で学んだ「ソフトウェアテスト技法」を実務に活かそうにも，どのように適用したらよいかわからないというのが悩みです。そこで，本書では実践的なシチュエーションを想定した問題を繰り返し解いていくことにより，テスト技法の知識定着を目指します。個々のテストエンジニアのスキルアップや，企業における新人研修の教材としてもご活用いただけます。

目次
Part1　同値分割法と境界値分析
1.1　温度によって表示を変えるペット用室温計
1.2　キッチンスケールの動作検証
1.3　畳の枚数から面積を計算するWebシステム
（以下略、全13問）
Part2　デシジョンテーブル
2.1　1杯目のビールの価格
2.2　銀行ATMの引き出し手数料
2.3　紳士服店の割引率
（以下略、全10問）
Part3　状態遷移テスト
3.1　ストップウォッチの動作
3.2　スマホ決済アプリの決済処理
3.3　エアコンの運転モード切替
（以下略、全6問）
Part4　組合せテスト
4.1　美味しい組合せ
4.2　BUG QUEST★冒険のはじまりの旅支度
4.3　合コン会計用アプリの検証
（以下略、全8問）
Part5　総合問題
5.1　スマートフォンの料金プランと料金計算
5.2　BUG QUEST★隠しアイテム探し
5.3　ミュージックプレーヤーのシステムテスト

技術評論社の書籍ページにはサンプルページも載っているので、中身が気になるという方はこちらもどうぞ。

gihyo.jp

それでは以下が本書を読んだ僕の感想です。

良かったところ

• 例題が親しみやすく、かつ実践的。「あー、こういうテストケースあるよねー」と思えるものがたくさんあった。
• 各例題のゴールはあくまで「提示された仕様に対応するテストケースを作成すること」なので、特定の言語やフレームワークの知識が不要。
• 勉強会とかでみんなでワイワイガヤガヤとテストケースを考えたりすると面白そう。
• 似たような仕様のプログラムを作る機会があれば、本書の回答がテストケース作成の良いリファレンスになりそう。
• ペアワイズ法を知らなかった。この本を読んで初めて知った。

少し惜しかったところ

• 完全に「問題集」に振り切っているため、テスト技法そのものの説明がない。テスト技法については事前に別の本で学んでおく必要がある。（なので最初の1冊としては不適）
• ペアワイズ法もほとんど説明がないのでネットで調べないといけなかった。
• 問題をもう少し減らして、テスト技法に関するオリエンテーション的な解説があってもよかったのではないか？
• テストの例題として出てきた架空のゲームの中に、「仲間の性格＝むっつりスケベ」というキーワードが出てきたが、なんというか、いろんな意味で「時代にそぐわないな」と思ってしまった。

あと、おそらく「問題を読んでいる途中に解答例が目に入らないように」という考慮から、空白のメモページがたびたび挿入されます。

（画像は https://gihyo.jp/book/2020/978-4-297-11061-1 から引用）

解答例が目に入らないのはとてもありがたいのですが、まっ白なページが何ページも挿入されると、本を買った側としては「なんかもったいな」という気が少しします。
なので、代わりにコラム的な読み物か何かが入っていたら良かったのになー、と思いました。（コラムにするとそれはそれで「例題を解いているときに気が散ってしまう」という問題あるかもしれませんが・・・）

本書を読む前に読んでおきたいテスト技法の本

前述の通り、本書にはテスト技法そのものの説明はないため、「同値分割法とはなんぞや？境界値分析とはなんぞや？？」という人は先に別の本で勉強しておく方が良いです。
本書の中では推奨図書として、「ソフトウェアテスト技法ドリル」が紹介されていました。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

僕は「ソフトウェアテスト技法ドリル」は読んだことはないので、僕が代わりにお勧めするなら「はじめて学ぶソフトウェアのテスト技法」がいいんじゃないかなーと思います。

はじめて学ぶソフトウェアのテスト技法

ちなみに、このエントリを書く前にあらためて「はじめて学ぶソフトウェアのテスト技法」に目を通してみたのですが、「ペアワイズ法を知らなかった」とか言いながら、この本の中でほぼ同じ内容が「ペア構成テスト」として紹介されていたことに気づきました。
以前読んだはずなのに頭に入ってないのはダメですね・・・反省😓

まとめ

というわけで、このエントリでは「ソフトウェアテスト技法練習帳」を読んだ感想を書いてみました。
「惜しかったところ」のボリュームが少し増えてしまいましたが、それでもこんなふうに「テストケースを考えるための問題集」というのは今まで見たことがなかったので、本書はとても貴重な一冊だと思います。

フレームワークやライブラリの最新トレンドを追いかけることもそれはそれで楽しいし、大事なことではあるのですが、こういったテスト技法の知識も重要です。
テスト技法のような知識はスポーツで例えると、基礎体力作りや筋トレにあたるんじゃないかなーと僕は考えています。
派手さはないし、学ぶときは少し退屈なんだけど、コードを書くときは言語やフレームワークを問わず役に立つので、エンジニア人生全体にわたって長く使える知識になります。

作ったプログラムをテストするときは、毎回「勘と経験」がよりどころになっているという人は、ぜひ本書（と、テスト技法の解説書）を読んで、体系的なテスト技法の知識を身につけてください！

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

はじめて学ぶソフトウェアのテスト技法

あわせて読みたい

テスト技法と同様に、「少し地味だけど、エンジニア人生全体にわたって長く使える知識が学べる本」をまとめたエントリです。
こちらもあわせてどうぞ。
blog.jnito.com

迷惑電話が大っ嫌いなあなたに！パナソニックの迷惑電話ブロック機能付き電話機を1年使ってみた感想

はじめに

今回は我が家で使っている家電の紹介です。
我が家ではパナソニックのVE-GD66DL-Wという電話機をかれこれ1年ぐらい使っています。

パナソニック コードレス電話機(子機1台付き)(ホワイト) VE-GD66DL-W

現在（2020年1月時点）は後継機のVE-GD67DL-Wという電話機が発売されているようです。

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

なぜこの電話機にしたのかというと、迷惑電話ブロック機能が付いているからです。

迷惑電話ブロック機能は以下のような仕組みで実現されています。

• トビラシステムズという会社が提供している迷惑電話データベースから1日1回、データを自動ダウンロードする
• このデータベースに登録されている電話番号から電話がかかってきたら、自動的に着信を拒否する（呼び出し音も鳴らない）
• データは電話回線を使ってダウンロードするので、1ヶ月あたり「1回10円x31日＝310円」の電話代（＝サービス利用料）が発生する

迷惑電話ブロック機能の詳細については以下のページを参照してください。

迷惑ブロックサービスとは？ - ファクス - Panasonic

今回のエントリではこの電話機の迷惑電話ブロック機能を1年ほど使ってみた感想を書いてみます。

迷惑電話をブロックしたかった理由

迷惑電話をブロックしたかった理由は、迷惑電話がイヤだったからです・・・だと、そのまますぎますね😅
なので、もう少し詳しく言うと、以下のような理由があったからです。

• 僕は在宅でプログラミングの仕事をしており、難しいロジックを考えているときに電話が鳴ると、集中力が切れてしまうから
• 最近は携帯電話にかかってくることがほとんどで、自宅の固定電話に掛けてくるのは学校の先生ぐらい。なので、固定電話が鳴ると「えっ、子どもたちに何かあったのかな？」と心配になるから
• いつでも手元に置いてあって、さっと応対できるスマホとは異なり、固定電話だと子機や親機のところまで歩いて取りに行く手間が発生するから
• ただでさえ上記のようなマイナスポイントがあるのに、電話に出たらしょうもない塾の勧誘電話だったりすると、「せっかく出たのになんやねん！！💢💢💢」と怒りの感情がこみ上げてくるから

上記のような理由をひとことでまとめると、「精神衛生上、完全に害悪でしかないから」ということですね。

迷惑電話がかかってくるのはせいぜい月に1〜2回程度なので、決してそこまで頻度が多いわけではありません。
ですが、UX（ユーザーエクスペリエンス、ユーザー体験）の観点からすると1つ1つが最悪のUXだと言えます。

で、迷惑電話ブロック機能って実際どうなの？

そして、気になる迷惑電話ブロック機能のブロック精度ですが・・・100点満点でいうと、70点から80点ぐらいですね。
結局のところ、「ブラックリスト判定方式」なので、かけてきた相手の電話番号がブラックリストに入っていない限り、迷惑電話はかかってきます。
感覚的には「月に1〜2回」から「1ヶ月に1回あるかないか」程度に下がった感じです。

ただし、減点主義で考えれば「なんだ、やっぱり取りこぼしがあるのか」と思われるかもしれませんが、逆に加点主義で考えれば「何件かの迷惑電話をブロックできただけでも万々歳」と考えることもできます。
先ほども述べたように、迷惑電話は1つ1つが最悪のUXなので、「1つでも最悪のUXを未然に防ぐことができた」と考えれば、その点は大きく評価できます。

ブロックできた件数を見るのは気持ちがいい

ちなみに、迷惑電話がブロックされると、本体にブロックした件数が記録されていきます。

たまにこの件数をチェックして、件数が増えていると「おお、ブロックできてる〜❤️」とハッピーな気分になれます。
これは非常に良いUXです😊

自分で着信拒否の番号追加もできる

迷惑電話ブロック機能で阻止できず、迷惑電話を受け取ってしまった場合は、着信履歴からその番号を今後拒否することもできます。
簡単な子機のボタン操作で登録が完了するので、迷惑電話がかかってきたら、電話を切ってすぐにその番号を拒否設定に追加するようにしています。

電話機の説明書から抜粋

まとめ：迷惑電話が大っ嫌いな人には個人的にはオススメ

というわけで、今回は我が家で使用している迷惑電話ブロック機能付き電話機を紹介してみました。

「迷惑電話がゼロにならないと意味がない！」という人にはお勧めできませんが、「少しでも減ってくれれば、それだけでもありがたい」と考えている人には十分お勧めできます。
少なくとも僕個人は「買って良かったな」と思っている電話機です。

迷惑電話に困っている方は今回のエントリを参考にしてみてください！

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

プログラミングを学ぶにあたって詰まったこと 〜ソニックガーデンの伊藤さん編〜

Twitterとかを見てると、最近「プログラミングを学ぶにあたって詰まったこと」というテーマのブログ記事をよく見かけるので、僕もちょっと書いてみます。

僕が今まで「プログラミングを学ぶにあたって詰まったこと」と言えば・・・う〜ん、これと言ってぱっと思いつかないんですよねえ、プログラミングの学習自体においては。

この理由としては、

• 辛い思い出は全部忘れた
• 少しずつ階段を上ってきたので苦労しなかった
• 苦労を苦労と感じなかった
• 簡単なことしかやってないので実は何もスキルが付いてない
• 実は天才だった

のどれかなんじゃないかと思います。はい。

強いて言うなら、SIer時代に「次はJava案件をやるからオブジェクト指向を勉強しといて」って言われて、Javaの本を買って読んだけど本を読んでもオブジェクト指向が全然ピンと来なかったことぐらいでしょうか？

しかし、この件も今思えば、「オブジェクト指向を勉強しといて」と言われた割には、結局その案件の中身はVBの焼き直しみたいなコードばかりで、オブジェクト指向の知識はさほど要求されませんでした。なので、別に何も困らなかったんですよね。

オブジェクト指向に関してはその後、めっちゃ面白いJava案件に2つほど巡り会い、優秀な先輩プログラマの手ほどきを受けながら楽しく勉強できました。
そこで「オブジェクト指向、めっちゃ面白い！」となったので、それからは自分でオブジェクト指向関連の本をめっちゃたくさん読みまくって「オブジェクト指向、完全に理解した」っていうぐらいになりました（笑）。
僕はこんな感じでオブジェクト指向を習得したので、「大変だった」「苦労した」という記憶はあまりありません。

ところで、先ほど半分ふざけたような「理由」をいくつか挙げましたが、これってふざけているようで実はホントなんじゃないかと思ったりします。

辛い思い出は忘れた

まあ、これは文字通りです。
もしかすると苦労してた時期もあったのかもしれませんが、今となっては「これ」という記憶が思い出せません。

少しずつ階段を上ってきたので苦労しなかった

最初に入ったSIer時代は「ちょっとずつ難しい課題」を与えられていた気がします。
そのぶん、成長の上昇カーブは緩やかだったかもしれませんが、ひいひい言いながら階段を上るような苦労をした記憶はありません。

苦労を苦労と感じなかった

プログラミングって楽しいんですよね。
新しい知識を学ぶのも面白いし、「よっしゃ動いた！」っていう感覚を味わうのも楽しいし。
僕は昔からプログラミングをクイズを解く感覚でやってきているので、「わかった！」とか「解けた！」っていう喜びを感じると、それまでの苦労はすべて吹っ飛ぶのかもしれません。

簡単なことしかやってないので実は何もスキルが付いてない

これは少しネガティブな理由ですが、ちょっと当てはまってるかもしれません。
コンピューターサイエンスとか、機械学習とか、そっちのガチの数学の知識が必要になりそうな領域はほとんどやってないんですよね。
もしそういう知識を習得しようとすると、「楽しい楽しい」ばかり言ってられなくなるかもしれません。

実は天才だった

一番ふざけた理由ですね（笑）。
まあ、天才は言い過ぎだと思いますが、でも僕は昔から学校の勉強は得意な方だったんで、プログラミングの学習もまあまあスムーズにできてるんじゃないかなーと思うことはあります。
学校の勉強をこなす感覚でプログラミングの学習を進められているというか。
ただし、文系出身なので、さっきも言ったように理系レベルの数学の知識を要求されると刃が立ちません😅

プログラミングの習得以外で苦労したこと

上で述べたように、プログラミングの習得ではあまり苦労した記憶はないのですが、これまでの仕事を振り返ると「いやあ、あれは大変だったなあ」と思うことはあります。
たとえば、こんな感じです。

• 最初に入ったSIerで体験したデスマーチ案件（毎日ほぼ終電、土日も出勤が何日も続いた苦しい思い出w）
• たちの悪い💩コードを量産しまくるくせに、自分の書いたコードに対してどこまでも自信満々で非常に扱いづらかった前職の同僚
• ソニックガーデンに入って周りのプログラマに追いつけるようになるまでの2〜3年間

このように、大変だった思い出はいくつかあるのですが、あまり技術的な問題ではありません。
ソニックガーデンに入って大変だった思い出も「ソニックガーデンのプログラマに要求される総合力」が不足していたのが原因であって、「プログラミングそのもの」がボトルネックになってたわけじゃないんですよね。

もちろん、RailsやRSpecの知識が不足していて大変だった、という記憶はありますが、それはあくまで知識量の問題であって、Railsの○○○がなかなか理解できなくて苦労した、というわけではありません。
フレームワークやライブラリのクセに振り回されて実装に時間がかかった、という記憶もありますが、それも結局知識量や経験値だけの話だと思います。

もしこの先プログラミングで苦労する可能性があるとすれば

もうこの年になると「プログラミングはほとんど理解した」と言ってもよい・・・と思ったのですが、「いや、こういうのは苦労しそう」というトピックをいくつか思いつきました。
ひとつは先ほども言ったように、コンピューターサイエンスや機械学習など、数学的な知識やセンスが要求されそうな分野です。

あとは、関数型プログラミングのモナドやC言語のポインタなんかも現時点ではほとんど理解していません。
もしこの先、こういった知識が必要になると、「うおー、プログラミング、わからん！！」と頭を抱えたりするかもしれません。

楽しくできればそれでええやん、という開き直り？

その一方で、コンピューターサイエンスや機械学習、ポインタ等をがんばって今から覚えたいか？って言われると、そうでもないんですよね〜。
もちろん、できて困ることはないし、むしろできた方が絶対良いというのは理解できるんですが、「自分の好きな領域か？」とか「お金を稼ぐため、もしくは自分の中のコンプレックスを克服するため以上のモチベーションが果たしてあるか？」と自問自答すると、「うーん・・・」っていう感じなんですよね。
RubyやRailsは大好きで、（これでご飯が食べられるなら）このままずっとやり続けたい！！って思うんですが。

年齢的にも「この先プログラマとしてどう立ち振る舞っていくか」っていう将来のプランをそろそろ考えなきゃいけないなーと思っているので、ちょっとこのあたりはまた時間があるときにじっくり考えてみたいと思います。

ただひとつ言えるのは、自分の好きなことをやっているときは楽しいし、人から見れば苦労に見えることでも本人は苦労と感じない、ということです。
これはこれで、プログラマの仕事をやっていく上で大切にしなければならない観点のひとつなのではないでしょうか？（と言って、自分がRubyやRailsを続けたい理由を正当化してみるw）

まとめ

というわけで、このエントリでは僕自身の「プログラミングを学ぶにあたって詰まったこと」を書いてみる・・・つもりが、後半はなんかちょっとあさっての方向に議論が飛んで行ってしまいました。

まあ、どこを切り取っても僕の個人的なポエムですが、何かみなさんの参考になる点があれば幸いです😅

2019.1.22追記

そういえば、過去に僕が詰まったことを2つ思い出しました！（やっぱり忘れてたw）
その話を追記しておきます。

Rubyのブロックがわからなかった

僕が一番最初にRubyの勉強をしたのはウサギが表紙のRuby本です。
当時は仕事でRubyを使う予定はなく、個人的な趣味としてこの本を読んでいました。

プログラミングRuby―達人プログラマーガイド

この中にたしかこんなコードがブロックのサンプルコードとして載っていた気がします。

3.times do
  print "Ho! "
end
#=> Ho! Ho! Ho!

しかし、これだけ見ても「ブロック」が何なのかよくわかりませんし、それまでJavaでfor (int i = 0; i < array.length; i++)みたいなコードばかり書いていた僕は、このコードがループ処理になっていることすら想像が付きません。
しかも出力しているのが"Ho! Ho! Ho!"で、そもそも「"Ho! Ho! Ho!"って何やねん？いったい何がしたいねん？？」というところから意味がわかりませんでした。（これがサンタクロースの笑い声だと知ったのは、これよりあとの話です）
結局この本は最初から最後まで「ブロックがようわからん」と思いながら読んでいた記憶があります。

・・・という思い出があるので、僕が「プロを目指す人のためのRuby入門」（通称チェリー本）を執筆したときは、当時の自分でも理解できるようにブロックについてできるだけ詳しく説明しました！！

「プロを目指す人のためのRuby入門」4.3.2項より抜粋

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

RailsのルーティングとRESTの概念がわからなかった

僕がRailsを使って初めてのサンプルアプリを作ろうとしたときの話です。
何かデータをCRUDする画面を作ろうとしていたと思うのですが、

• 新規登録はcreateアクションで、HTTPメソッドがPOST
• 更新はupdateアクションで、HTTPメソッドがPUT/PATCH
• 削除はdestroyアクションで、HTTPメソッドがDELETE

という関係になっていることがわからず、「えっ、えっ、どうしたらデータを更新できるの？？世の中にはGETとPOSTの2種類しかないんじゃないの？？」「えっ、REST？RESTって何？？」といろいろ混乱した記憶があります。

しかもRailsのルーティングって、これだけでCRUDで使う5つアクションを定義できちゃうんですよね。

resources :users

これにもビックリ、というか、「routes.rbを見ても何が定義されているのかさっぱりわからん！！」と思いました。

それまでずっとStrutsを使っていて、StrutsはRESTの概念がない＆アクションの定義はすべて明示的に行うWebフレームワークだったので、いろんなことが暗黙的に決まってしまうRailsの考え方に、なかなか付いていけなかった記憶があります。

あと、このエントリに書いた「僕があまり苦労しなかった理由」をもう一つ思いついたので、それも書いておきます。

わからないことはそれが必要になるまで後回しにしていた

これは比較的最近のアプローチなのですが、何かを新しいことを学ぶときに2〜3回考えてもよく理解できないことがあれば、諦めてさっさと次に進む、ということもよくやっています。
で、実際にその知識が必要になったときに、もう一度そのポイントを勉強し直します。
必要に迫られたときが一番モチベーションが高く、学習効率が良くなるので、遅延評価もしくはJust in Time（JIT）方式で勉強するのも意外とオススメです。

この学習方法については以下のエントリで詳しく説明しています。
blog.jnito.com

今回の追記は以上です！