ソフトウェア・テストPRESS(Vol.2) の商品レビュー

情報・通信・コンピュータ

2012/05/01

Vol.1も良かったんですが、Vol.2はさらに面白かったです。

細川宣啓さんの特急は、書いてある内容よりも、細川さんにレビュー会に来ていただきたいという想いでいっぱいになりました。インスペクションをリードする人、社内に作りたいなぁ。

高橋寿一さんの特集は、これまでの経験がにじみ出ていてマジ参考になります。うんうんとうなずくことが多かったです。

大西さんの「テストチームの立ち上げ・運営に役立つ基礎知識」ですが、分類の仕方が整理されていて良かったのですが、「じゃあ、どういうケースではどの組織形態がおすすめなの？」とか「そーいう人にはどう対処したらいいの？」という部分でちょっとフラストレーションが溜まりました。
全く書いていないわけではなく、書いているんですが、さらに深いところが知りたい…ということでVol.3での続編をリクエストしておきます。

ものものさんの三色ボールペン。カラーページでうらやましかったです…というのは冗談ですが、仕様書に書き込みながらテストケースを作るというのは私もやっているのですが、効果大ですよね。ものものさんの方法、定番になるかも。
私の場合は水性ゲルインキの赤ペン（Pilot G-3の0.5mm）を使っています。

和田さんの記事はTPSの入門には最適と思います。また、とても読みやすい（この技術誌の中で一番読みやすかった）です。

それから、榊原さん…バックスラッシュモデル、そうとう気に入ってるんですね。^_^;

他の記事もみなここでしか読めないものが多く、これは売れる！と思いました。

ところで、Amazonにアクセスしたら何故か「ネットワークセキュリティExpert」の画像が張ってありました（２枚目の画像がそれです）。昨日まではちゃんとしていたのに。へんだなー。

2011/09/22

仕様書を何のためにかくのかを解らずに書く人がいることに驚いたことがあります。
自分が作るものを明確にするために書くのであって、他人のために書くのではないという意識が持てないのなら、書かない方がいいかもしれません。
プログラミング言語で書いた仕様書を認めない人もいますが、それはその人がプログラミング言語で書いたものを、他の言語で書き直して確認したいからだとしたら、その人に書いてもらうのも手かもしれません。
仕様書の欠陥を見つけるには、何を作りたいかを明確にしていくことになるので、嬉しいと思います。ただし、完璧な仕様書を作ってからプログラミング始めるのがいい場合と、手遅れの場合とがあることは、、、、
#プロトタイプのコードは捨てるようにという話題が、IPA/SECのプロセス改善ナビゲーションガイドにあったような気がします。

2009/10/04

ソフトウェアテスト専門誌のvol2。個人的にはこの本で直交表/HAYST法に触れたことが今のソフトウェアテスト技術者への道のはじまりだったかも。