kb84tkhrのブログ

何を書こうか考え中です あ、あと組織とは関係ないってやつです 個人的なやつ

『パーフェクトソフトウェア』

パーフェクトソフトウエア

パーフェクトソフトウエア

 

 

これも図書館で見かけて借りた本
ワインバーグの本では他に『ライト、ついてますか』読んでます
おもしろかったのできっとこの本も面白いだろうと

ライト、ついてますか』もそうでしたが、この本も人間サイドからの視点がメインになります
結局何をやるにも実行するのは人間なので、人間がうまく動けるように考える必要があるんですよね
オッサンな年になってやっとそういうことがわかってきました
といっても人を動かすような立場にいるわけでもないのでただの野次馬視点なんですが

さてこの本はなんの本かというとパーフェクトなソフトウェアをどう作るか、
っていう話ではなくて
パーフェクトなソフトウェアなど存在しない、という本です

製造業だと、テストして不合格なものは出荷せず、合格したものだけを

出荷すればよいってことになるんでしょうがソフトウェア業界でははそうはいきません
テストをいくらやっても完全にバグをなくすことはできない、じゃあどうするの、
という話

そして

テストをするのは、ソフトウェア製品が売れるかどうかを確かめるためだ。

どうやってテストするか、ということではなく、もう一段上のメタな視点なからテストのさまざまな点に光をあてていきます

水面下に隠れた問題を追求しなければ、テストへの投資に見合った価値を引き出すことはできない。私の経験では、テストについて不満を言う人の半数は、テスト結果にかくされた情報をすべて追求しきれていないマネジャーである。

テストは、製品の品質に関する情報を収集するための活動ですが
テスト結果だけを見るのではなくその周辺を含めて観察していくことが必要、
といったあたりがメインテーマです
心理学とか行動経済学的な話も入ってきます

第5章のタイトルが「メタテスト――テストをテストする」となってまして
つまりそういうこと
もっと抽象化すると「それはいったいどういうことだろう」という視点を持つこと

バグトラッキングシステムに1万4000件以上のバグレポートが登録されると
パフォーマンスが低下する、という報告があったとして
バグトラッキングシステムがおかしい、改善する必要がある、というだけではなくて
そもそもそんなに大量のバグがあるのはどういうことなのか
開発プロセスに問題があるのではないか、とか
そこに考慮が及ばないテスト担当者のテスターとしての能力はどうか、とか
さまざまな情報を読み取ることができます
テストチームの成果がバグチケットの数で評価されていて、テストチームがとにかく
チケットを増やそうとしている、ってこともあるかもしれません

そういう話がいろいろ出てきます

しかし、さまざまな理由から、技術レビューに参加したがらない開発者は多い。製品をレビューしたくないという人がいる場合、その人が主張するレビューしたくない理由を明敏なマネージャーが聞けば、おもしろいことに、それだけでたちまち製品のことがよくわかる。

スタッフがこんな感情をもっていたら、簡単なメタレビュー、すなわちレビューシステムのレビューを行うとよい。

とか

あと、大事だよなーと思ったのが「感情の反応に耳を傾ける」ということ
なんかやばい気がする・・・と思ったら調べてみるようにしてます

「2100年は正しく認識されました(うるう年ではない)。1900年は間違えていて2100年は間違いないなんて、どんなふうにコードを書いたのかわかりません。特殊チェックでもしたのでは?〈ゾーッ〉」

「ゾーッ」をそのままにしないことが大切
自分自身痛い目を何度も見ています

ところで
この本に書いてあることは、ウォーターフォール式に開発が行われて
最後にテストフェーズっていうのがガーンとある、みたいなプロセスを想定して
書いてある気がしますが
原書は2008年発行で、そのころはもうユニットテストとかアジャイルとかも
普通に広まってたと思います
著者自身テストファーストは50年前からやってたと言ってますし
そういった視点で見たらどうなんでしょう
さらに今の開発では?

といっても
今でもこの本に書いてあるような人や現場がいっぱい存在してる気はしますが
野次馬を続けていきたいと思います