Category Archives: software test

単に、どんなにうまく運営されている組織でも、影響の大きな意思決定のうち相当の数が、後になって間違っていたと判明することになるという事実を認めることである。 これが否応のない人生の現実である 。 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだであったような欠陥分析をする上で、人は一定確率で失敗するという大事な前提があります。一方で、それはどれほどなのか、経験的なものではなくちゃんと研究としてどこまでされているのか気になっていました。 そんな中、『ヒューマンエラー 完訳版』を見つけたので読みました。そのメモなどをつらつら。 ソフトウェアは人工物です。そのため、ソフトウェア開発は人の組織や認知と如何に関わるかというところが大事な要素を占めてきます。(ソフトウェアテストを学んでいると多くの人は行き着くことな気もしますね) この本では、主に原子力発電という安全性が最重要とされる情報をもとに、ヒューマンエラーに関して研究をまとめています。ここら辺は、安全性が重要な要素である航空関係、医療関係でも使われていることでしょう。たとえば スライスチーズモデル なんかで。一方で、 スライスチーズモデル の考え方なんかは、実は程度はどうであれそこ以外の分野においても有益な情報が多分にあります。 学術的な箇所は端折ってメモ。 GEMS(Generic Error-Modeling System)に沿った定義でエラーを主に扱っている 実行上の失敗: スリップ(しくじり)、ラプス(手抜かり) 計画が不適切: ミステイク(mistake) この中で、計画が不適切であるエラーの方がより見つけにくい。(ソフトウェア開発だと、仕様がそもそも誤っているというところですね。) 人の活動は、 SB: skill base RB: rule base KB: knowledge base の3つで構成されるとしている。それぞれの特徴は省略(本書のP.82付近)。この中でSBで発生するエラーは、主には 監視の失敗 によっている。RB、KBは問題解決能力が大きく関係してくるエラーに対する活動。 人は、 頻度の高いものほど認知/推論しやすくなる 。逆を言うと、そうでないものはエラーを認知することが難しくなる。5章ではそんな人の認知のロジックをモデルに落とし込み、模倣した研究が添えられている。つまり、人の正しいが、時折間違えるという状態がモデルとして扱われ、それを計算機により表現している。 第6章の数値は面白かった。データベースアクセス、更新などのある作業が エラーなくできたか、エラーが発生した時に正しく対処できたか を、SB/RB/KBで対策した時の差を計測結果として残している。 これによると、 SB ほどエラーが発生しやすいが、同様にSBの人ほどエラーが発生した時に正しく対処できる可能性があることを示している。 つまり、プロセスなどを整備することによるリスク低減と、人のスキルが成熟している状態を作ることができれば、低いリスクで万が一にも備えることができる状態を作り上げることができる。 ただ、いずれの活動に置いても、 手順の飛ばし、抜け、漏れは検出することができなかった。つまり、 手順の抜け漏れを探すようなことは、人は苦手。 エラーを検出するためには、 自己監視過程 なんらかの環境の手がかりに気づく 誰か他の人が発見する が大事。特に、ほかの人による発見は複雑でストレスの高いものほど効果が高い。つまり、 気をつける 、…More