読者です 読者をやめる 読者になる 読者になる

テストの本、読了!

システム開発

やっと読み終えました。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

最初は、いつものように気になったキーワードをメモしていましたが、293も鉄則があったらとてもメモしてる場合じゃないと。むしろ、メモすることによって思考が途切れていたので、途中からは読むことに専念しました。


メモはしてないまでも、今後活用していきたい部分は以下の2章。

  • 第3章:テストの技法
  • 第5章:テストの自動化

第3章:テストの技法

テスト技法については、オールペア法や直交表はこの本で初めて知りました。「テスト要素の完全組み合わせではなくて2項目間(もしくは3,4…項目間)での組み合わせを網羅することによって、テストケース数を大幅に削減するもの」。ただ、概念は理解できたのですが、どんなときに採用すると効果が発揮できるかはイマイチ。

思ったのは、要素間でまったく関連がないことが判明しているのであれば、要素間の組み合わせテストをやるまでもない。逆に、明らかに関連していることが分かっているのであれば、その組み合わせをテストケースに含めればいいだけのこと。

つまりは、「何となく関連がありそうだけどはっきり断言できない」という状態にこそ効力を発揮するのかな?因果関係が曖昧でかつ全組み合わせのテストケース数が膨大になるときに、効率よくテスト数を間引けるかと。本の中の例では、OSやブラウザを要素として組み合わせる構成テストなどが挙げられていますね。

この辺、門外漢な上にぱっと思いついたことなので、的外れだったらご指摘ください。。。

第5章:テストの自動化

昨日のエントリでも触れたけど、今まさに手がけようとしているところ。昨日はユニットテストの導入までしか触れてないけど、ユニットテストさえ揃えば自動化できる環境は揃っているので。

この章も全部ためになったのですが、あえて挙げるならば↓の鉄則かな。

目的はコストダウンではない、開発プロセスの迅速化だ

ここでは、テスト自動化の目的は、以下のようなものだと述べられています。

  • 不完全なプログラム修正の早期発見
  • 回帰テストによるバグ(デグレード)の早期発見
  • 問題点の早期発見。プログラム修正を容易にする

上の人に説明するときには、どうしてもコスト削減を前面に押し出した説明になりがちだけど、そうではないと。問題点を早めに発見できるので、それに伴って開発時のスピード感が増しますよと。

感覚的には分かるのですが、うまく説明できないなぁ。もちろん、「コストダウン」と「開発プロセスの迅速化」にまったく関連がないわけではないでしょうが。


有益だったけど、ちょっと疲れました。次は、もう少し気楽に読める本で息抜きしようかと。

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)