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

投稿元：

レビューを見る

テスト技法についての書籍は数多くあるが、この本は技法の前に意識すべきノウハウも詰まっている。テストをするときに無意識に使っていた技法をあらためて学びたい方、技法を学んだがなかなか実践できていない方、より効果的な技法を使いたい方、いろいろなレベル、そしてテストエンジニアにもプログラマーにとっても有意義な内容だと思います。
第1章はテストという活動に対してポリアの「いかにして問題を解くか」のエッセンスが調合されていて、とてもためになる内容です。
第3章、第4章は少し難しい内容でもありますが、ツールの紹介があったり、今まで書籍で解説されることが少なかったCFD法の解説・使い方も載せられています。

投稿元：

レビューを見る

勉強会「みんなに役立つ「テスト」を学んでみよう！」にてオススメ頂いたので購入。
この本をテーマに、数回にわけて社内で勉強会を開いた。演習問題があるので、そういう用途に向いている。テスト担当者ではなく開発者だが、開発者テストを設計するときや、テスト担当者と会話をするにあたって、勉強しておく知識だと思う。

投稿元：

レビューを見る

表5.2の内容が一部間違っている模様。
表5.1の状態遷移表のとおり、終了状態から動作中（針は進む）に遷移するので、前状態の初期状態と終了状態は同じになるとのこと。

投稿元：

レビューを見る

ここまで簡潔に各テスト設計技法のツボを抑えている本はないのではなかろうか。次元を増やしていくという技法のグルーピングが秀逸。

実際にテスト設計に携わっている技術者であれば、必ず読んでおくべきだと思う。

同じようなコンセプトの書籍に。Rex Black氏の「ソフトウェアテスト実践ワークブック」があるが、個人的にはこちらのほうをお勧め。こちらのほうがより良いと私は感じますが、「ソフトウェアテスト実践ワークブック」も良い本ですので、時間が許せば両方ともあたることをお勧めします。

投稿元：

レビューを見る

本書を使ったTEF東海の勉強会に参加しました。

スイッチの話で、行列の掛算をすると分かることについての記載がありました。

状態方程式についての説明があると分かり易かったかもしれません。

入力行列×状態行列＝出力行列

ということを理解していると、状態試験がうまくいくかもしれません。

SPIN, SMV, Uppaalなどを使う話もあるといいかも。

投稿元：

レビューを見る

プログラマでも読んでおくといいと思います。前提知識はとりあえずなくてもなんとか読めます。(四章は調べながらになると思うけど。)

投稿元：

レビューを見る

ソフトウェアのテストの基本から大きなものにへと少しずつ大きな面でとらえいく方法へと解説が進む。

最後の章にたどり着く頃には「どうすればいいんだよ！」みたいな気持ちになります。網羅できなくなるので、最後の章は自動テストで行われているような網羅性を諦めた場合の方法についての考察が入ります。複雑なところは上手く切り出して、網羅的なテストをしつつ統合したテストは狭く具体的に当たるしかないなぁ。と思うのでした。

機能同士が影響しないような設計もまた大事だと思いました。

投稿元：

レビューを見る

練習問題があって、現場にも活かせそう。こういうの読むと、テストにもいろんな知識が求められるから「テスト技術者」という専門職があるのも納得できる。

投稿元：

レビューを見る

本書では、ソフトウェアテスト技法の話を書いているのですが、

　・ 自分が役に立った経験があり使っている技法に絞る
　・ 役に立つフリーのツールがあれば紹介する
　・ 日本人が考えたことも紹介したい
　・ 誰が読んでもわかる
　・ 実践できる

といった本にしたいと思って書きました。

そのために、例えばCFD法について書きたかったので松尾谷さんにお願いしたり、鈴木三紀夫さんに三色ボールペンのところを直してもらったり、加瀬さん、鶴巻さん、判谷さんにツールの了解を取ったりしました。

とても驚いたのですがみなさん「どんな本なの？」とか質問もすることなく「いいですよ！」と二つ返事でOKを出してくださったのです。テスト業界の人ってみんな優しいなぁと思いました。

本書の目次は、

　第1章　点に注意を向ける
　第2章　線を意識する
　第3章　面で逃さない
　第4章　立体で捉える
　第5章　時間を網羅する
　第6章　多次元の品質

となっています。
順番に例題19問、演習問題12問の計31問を解きながら読み進めることによってテスト技法を身に着けることができます。

投稿元：

レビューを見る

本気で実践的な手法が書かれている説明書。
材料工学や精密機械の世界でのテストでは、タグチメソッドに代表されるような直交表を利用したテストパターンを使っているのだが、ソフトウェアの世界においても直交表と同じ概念で利用されたテストパターンが利用されていることを知り、やはり有効であるとのこと。
ソフトの世界では、HAYST法による直交表を推奨しているようだ。概念としては共通で、各パラメータが独立である場合、全組み合わせを試さなくても網羅性が保証されるという考えに基づき設計されている。特に、ソフトのエラー調査では、材料工学における強度の計算とは異なり、異常処理を発生する要素が1つでもあれば異常として弾けるので、更に大幅に簡略化出来る。
UMLに代表されるようなモデリング図やシーケンス図、ユースケース図などの図も説明あり。

投稿元：

レビューを見る

内容が盛りだくさんのに薄いすばらしい本です。
テスト技法の本は翻訳ものが多いのですが、これは日本事情も踏まえて書かれているので理解しやすいと思います。

投稿元：

レビューを見る

非常にわかりやすいテスト設計技術書。
点、線、面、立体、時間の概念とテストの技法を結びつけ、わかりやすく解説してあるのがありがたかったです。

投稿元：

レビューを見る

同値分析、境界値、ホワイトボックスにブラックボックス・・・　といったあたりのことを、私たちは自然と意識してテストケースを書くわけですが、

「テストケースを書く観点って、本当にそれだけなの？　他にないの？」　って思ったことありませんか。

その疑問にピンときた人には、この本はとてもオススメです。

例えば、Aという入力項目に１０種類、Bという入力項目に２０種類の入力が可能だとして、それに対応するアウトプットの結果をテストしようと思ったら、

本来１０×２０＝２００通りのテストをしないといけない。

これに更にCという項目（５種類の入力が可能）が加わったら、さらに５をかけて１０００通りのテストをしないといけないけど、

本当にそれ毎回全部テストするのか？というと、たぶんしない。　
ある程度のところでくくってケースを減らすけど、じゃあ、それってどういう根拠に基づいて減らしているのか？　

その根拠は業務上の重要性であったり、システムのつくり上あやしげなところだったり、するわけですが、

何をもって　「業務上重要」　とみなし、　何をもって　「あやしげ」　と考えているのか？　　
そもそも、それ以外に考えていることもあるんじゃないか？
考え足りていないこともあるんじゃないか？

そのあたりのことを　「なんとなく」　で済ませている限り、　テストのことを後輩に教えられないのももちろんだし、同僚が書いたテストケースをレビューすることも、　自分が書いたテストケースをレビューしてもらって、その指摘を受け入れるべきかどうか判断することも、できないんじゃないか。

・・・と、私はそんな問題意識を持っていたときにこの本に出会い、読んでみてスッキリした部分がかなりありました。

一部、HAYST法やペアワイズといった手法がなぜ有効なのかを統計・数式的に説明しているところがあり、そこは深くは理解できませんでした＞＜

でも、考え方の部分で参考にできるところはたくさんありました。
これからも手元において、ちょくちょく読み返しつつ、理解を深めていきたいなと思える本でした。