昨今のソフトウェア開発において、開発期間が益々短くなりプロジェクトの人数も少なくなってきている。そうすると、品質にしわ寄せがくるわけであり、「テストの自動化」の表紙に引かれ購入した。内容としては満足できるものであり、テスト自動化ツールをただ導入すれはいいと言うものではなく、その弊害に対しても突っ込んで書いてありためになる本であった。
<br />
<br />あと、タイトルにあるようにマインドマップをテスト設計に使うと言う記事が面白かった。たしかにテストの項目を挙げるというのは経験によるものが多く、新人に作らせた場合はCLのレビューにより漏れを指摘して項目作成の勘所を伝授して行くだけであった。
<br />そこに記事のような手法で項目のマインドマップを作らせて、それを元にレビューを行うと作成者の新人だけでなく、レビューする側も発想の可視化によって、より内容の濃いレビューが行えるのでは？と思えた。これは是非とも実践せねば。
<br />
テストケースの管理どころか、障害管理、ファイル管理、ソースコード食わせればUMLはくわというお高い化け物のような統合開発プラットフォームIBM社のRationalがあることは知ってはいるけど、んなもん、買えるか！！
<br />といういうプロジェクトの悩みを解決できないかと購入。
<br />みんな苦労してるんだね。ちょっと安心。
<br />
<br />フリーウエアはやはり、イマイチ。どうやって外付けで運用するかって話しでもあるのでしょうが、自動で同値テストや境界値テストを設定してくれるツールも、そのテストが妥当なの？ってこととか、抜けはないのってことは、所詮人間が見極めること。
<br />それがはっきり書いてあるのがカイ。
<br />
<br />ツールを使うことは確かに仕様変更やバグ修正の度にUT仕様書をWordで書きましょう！ってな話しのプロジェクトから見れば格段に工数節約にはなるのですが、テストケースを設定するという行動自体が、自分の設計やコーディングの漏れ等を客観的に評価する作業なんで、技術者を育てるという観点からみたときに、どうなんでしょうね？。
<br />テスト自体は楽になるし、生産性はあがる。でも、本来自分へのフィードバックがもっとも多い工程をツール化することの弊害まではだれも触れていないのが気になる。
<br />
<br />お題目だけの業界誌とことなり、このシリーズの強みの実際の運用例が載っていることは評価しますが、どうなんだろうね。
この雑誌もＶｏｌ．３まで出版されてきました。
<br />テスト技術者の方、テスト技術者になろうとする方には必読本になると思います。テストレビュー方法やテスト技術者の育成方法もあります。
<br />テストの自動化は非常に難しい問題であるにもかかわらず、非常に分かりやすく記載されています。筆者の技術力の高さがよく分かります。
<br />マインドマップを利用した３色ボールペンの活用方法もすばらしいです。とにかく、全章において読み応え抜群だと思います。
<br />ある程度の経験がないと分からない部分もあるかもわかりませんが。
<br />良書であるのは間違いないです。
