2010年読書:44冊
=================================
ソフトウェア検証に携わって、すでにxx年目?の私。自分でガリガリ検証を進めるわけではなく、PM的にスケジュール管理や???な事象が出たときの切り分けなど。結果的にはOJTで「ソフトウェアのテストとはこんなもんだ」と習ってきましたが、それなりに正しいやり方/ポリシーでやって来たようです。
さて、本書は私のようなソフトウェア検証技術者は是非読んでおくべき良書です。特に何となく検証作業をやっている、上から『全パターンをやれば?』など言われ『いやぁ〜、スケジュール的に、モゴモゴ』となってしまう若手の皆様にはよい刺激になると思います(私自身も痛感です)。業務を通じてそれなりに、経験を積んできたので、普段の業務と本書を照らし合わせることもでき、改めてソフトウェア検証の重要性、難しさを再認識できたと思います。常々思うのが、just enoughtな線引きで、(人も時間もお金も)無尽蔵にあるならば十二分に時間をかけて検証することができるけど、現実的には限られたリソースで最も効果がでると思う方向で進むしかない。確率論的な不具合なんて、検証作業で検出するのは難しいし、
『なんで検証で見つからなかったの?』
『(上流工程で検出すべき問題で)100時間連続した場合に1回でるような不具合はムリです』
と言いつつも、『それでは、他xxxにも展開して少しでも"確率"を上げるようにします』と提案を。
実際、開発をやればやるほど検証作業の重要性が身にしみるようになります。ほんと、最初から問題ないソフトウェアなんて見たことないし、IOSなんて版数が上がるほど。。。まあ、個人的にはそこが楽しいところでもあるので、前向きに頑張ります。
↓特に気になった章です。終盤に入り、グダグダ感がでてきましたが、ソフトウェア検証技術者にとっては必読の1冊です。
第3章:全部テストしたらいいのでは?
第4章:テストとデバッグはどう違う?
第9章:テストに関するおもな誤謬
第17章:テスト詐欺
⇒魔法のツール売ります・デモは詐欺である・お客様は何もする必要はありません
2010年10月25日
この記事へのコメント
コメントを書く
この記事へのトラックバック