アカウント名:
パスワード:
趣味ではなくて仕事である以上
多分分かっていて書いているのだと思うのですが。。。仕事だからこそ、QA (品質保証) は重要なのではないかと思われます。
お金との兼ね合いを考えるからこそ、必要十分な品質を保つ為に、どこまでを保証するのかを明確にした上で、明確にした範囲で確実にテストが行われなければ、後々瑕疵の修正に伴う予定外の出資が多発してしまうのは想像にたやすいわけで。。。最近の M$ さんのようにね。
つまり、ご質問へのお答えは、ごく普通の会社であれば、 お金くれるならやってもいいよ ということになります。
重大な勘違いをしていますね。設計ミスもテストで防げるのです。
もちろん、テストの結果判明した設計ミスを、どかんと修正する側へ傾けるか、放置する側へ傾けるかは、その仕事全体の責任者次第ですが。
むぅ。。。個人的には、設計に則ってテストを突き詰めることによって、設計上の欠陥や矛盾を見つけられることがそれなりにあったので、このように書いたのですが。。。テストは作るときから既に、テストは始まっているって考え方っすね。
でもテストを作ることによって、テストを作る人間がテストされているって側面もあるからなぁなんちて (^_^;;;;A 。
レビューはおいらも当然重要だと思います。そもそも品質保証を行う上で、複数の異なる角度からの検証と見解の取りいれは絶対条件なわけで。テストは一人でやってはいけない。まぁテストに限らないんだけどね。。。
命題を履き違えてはいけません。極力欠陥が無いように作られるべきであることは当然のことですが、「極力欠陥が無いように作る」などとは、設計仕様として記述しないでしょう? 欠陥があるから安全性が損なわれるのです。欠陥が無いように作られなければならない。
ならば、欠陥が無いように作られるようにするにはどうすればよいでしょう?
そもそも思うのですが、開発者 (ここでは作業員というべきでしょうか? 設計者も含めて) が行なうテストは、企業としては品質保証の一環として捉えるべきなのです。どんなに優れた、経験豊かな設計者であっても、一発で十分な設計 (完璧な、じゃないですよ) が行なえるとは限らない。それを補うための検討であるはずです。もちろん、スケジュール上の枠組みで捉えるならば、テスト以前の段階でその検討が十分に行なわれることがむしろ望まれるわけですが、作業が進行するにつれて、浮き彫りになる問題点というのも少なからず出てくるでしょう。その問題点を如何にして補足し、なるべく早い段階で大本の設計に反映できるかは、テストという概念の捉え方、体制のあり方でも随分変わってくるものであるはずです。
親スレッドで取り上げられている回転ドアの事故については、この記事 [asahi.com]がかなり参考になるっぽいです。そもそも回転ドアを採用した段階で安全性に劣るという観点もあり、確かに微妙っぽいのですが (安全に作りたいなら回転ドアなんか使うなと)、安全性に公的基準が無いことや、速度や開閉力の調整はメーカーに任せられていることなどから、やっぱりテストから設計へのフィードバックにも不足はあったのかなぁとも思います。
しかしおいらなんかはテスト作成もテストの一環であると考えていたりするわけですが、この辺の言葉の使い方も話をややこしくしちゃってるのかもしれませんです。テスト作成はテストではなくてあくまで検討である、という言い方であれば、実は見解にそれほど大きな差異は無かったりするものなのかも。
どちらも QA であることに変わりは無いんですけどね。。。
端的に (大雑把に?) 言えば、用件に必要十分なものを完成させることです。仕事で求められているのは、理想とされる完璧なものを作り上げることではなく、与えられた条件の中で運用上極力差支えの無いレベルのものを作り上げることだと思っています。で、そのための QA であって、そのためのテストでしょう? てことです。
安全である以前に、ものがものとして機能するもので無ければ意味ないですからね (人間が怪我しないように軟らかい素材使ったら、すぐに壊れちゃった、とか)。たしかに、六本木ヒルズのビルの扉が回転ドアである必要があるのかと言われれば、「？」ですが、そういう要件があった以上、作る側としては、回転ドアとして運用上十分な品質の物を作る社会的義務がある訳で。
もっとも、その社会的義務の持ち方も結局は金次第、ってのは、まったくもってその通りなんですけどね。。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
テストとコスト (スコア:1)
工数とは、そのまんま「人件費」です。
人件費は減らしたい、というのが客先の第一の要望です。
人件費は減らしたい、というのが開発会社の第一の要望です。
よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の１つになります。
つまり、ご質問へのお答えは、ごく普通の会社であれば、
お金くれるならやってもいいよ
ということになります。
趣味ではなくて仕事である以上、お金とのかねあいを考えないシステム開発は不毛ですから、こういうことになるのが普通だと思います。
Re:テストとコスト (スコア:1, すばらしい洞察)
なんて考えを持っている発注側はもちろん、受注側にも大きな問題があるのでしょうねぇ。
本来外すことの出来ない工程を外すことを許容してるんだから。
なんなら、開発工程もさくっと削減してもらえませんか？
Re:テストとコスト (スコア:3, 興味深い)
「お金は払うから*ちゃんと*テストしてくれ」
ってのが偽らざる本音。 いや、正確に言うと
「何テストしたんだか教えれ」
って事でしょうか。
どぉぉぉぉ考えてもテストしてたら出ないだろそんなバグ、という「不具合」をポロポロと発見するにつけ、「やっぱ単体レベルのテスト仕様書も見せて欲しいなァ」と思う今日この頃。
あとサーバサイドのプログラムで（想像するに）if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると、頭を抱えざるを得ないです。テスト全項目通してもそんなに時間食わないだろうによ。
あー、みなさんのトコって客先に納品する時、テスト内容ってどの程度開示しているんでしょうか？ 激しく気になります……。
Re:テストとコスト (スコア:2, 参考になる)
>「お金は払うから*ちゃんと*テストしてくれ」
>ってのが偽らざる本音。 いや、正確に言うと
>「何テストしたんだか教えれ」
発注仕様書に納品資料として提出するよう記載すればいいだけでは？
#最近、仕様書にきっちり書くことを学んだので。
#しかし、打合せで仕様を決めようとすると後で打合せの内容を
#覚えていない業者の多いこと。おまえらメモとれー。
Re:テストとコスト (スコア:2, 興味深い)
＞いうことがさっぱりかかれていないんですよねぇ。
それははっきり言うとテスト項目が甘いだけ。
「誰がテストしても同じ結果が出る手順を並べたもの」が試験項目表だよ。
試験した人が後から理由を書かなきゃならない項目表は項目表としての品質が低い。
低い品質のものを使っても低い品質のものしか生まれないから。
試験項目表さえシッカリ作る事ができれば、
それこそ試験要員なんてパンチャーレベルでも問題ないんだけどね。
＃まあ、大体の人は「結果が1になること」が試験項目だと思ってるようだけど。
＃「○をして×をすると結果が１になること」としっかり提示できなきゃ、
＃「×を2回して○をやって結果が1になったからOK」と言われても文句が言えない。
Re:テストとコスト (スコア:1)
ホントに手順書どおりにやってんのかゴルァということもありますね。
いずれにしても、手順書どおりに実施することもできないようでは、
そもそも手順書自体も甘々ってとこでしょうねぇ。
Re:テストとコスト (スコア:1)
>いうことがさっぱりかかれていないんですよねぇ。
事前に試験内容と手順を確認する必要があります。
そうでない場合には、もう仕様書にこれこういうテストを
こういう手順でやってこういう結果がでたらOKと書く必要があります。
で、危なそうな所ならさらに測定ログやテスト記録・写真などの全データをテスト環境・条件含めて提出させます。
どちらにしても、手放しでお任せはまずいかと。
Re:テストとコスト (スコア:2, おもしろおかしい)
>単体レベルのテスト仕様書も見せて欲しい
こういうお客さんに巡り会いたい(T_T)
＃会えてないのでG7
結局、「小難しい。なにいってんだか判らん。
そんなもんはいちいち見せるんじゃねえよ」なんていうお客は
自分の首を締めてるんだよね。
てか、確実に理解できる保証なんてものは無視して、
とりあえず「多め」に情報を納めさせるほうが、
絶対に有利であるはずだ。お客にとって。
だって理解できなくて「困ったら」、誰か理解できる人を掴まえて読ませりゃいいだけなんだもん。
でも情報そのものを納めさせていなけりゃ、永遠に読めない。
幸いにして現在は、多めの文書を仕舞っておく場所には(電子データなら)苦労しないんだしさ。
ただ、
>if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると
それは、アーキテクチャ(の不味さ)次第では、なんぼでもありえることです(T_T)
逆にいえば、作りかけの時点でも観察することは、
お客にとっても利益(つーか損害を無くす)のために重要だと思う。
「技術的負債」を抱えまくった開発を受注者がやってんじゃねーの？ってのを
建築^H^H開発途中にも頻繁に査察したほうが良い、と俺は思うっす。
＃無理の有る査察のしかただと困るけど、ね。
あ。そういう意味でも、XPは旨いよな。
Projectはお客に、常時査察されてるようなもんだもん。
>どの程度開示しているんでしょうか
ウチの社長が何考えてるかはともかく、開発者たる個人としての俺は(^^;、
相手が吐き気催すまで出すのもヤブサカじゃないですよ。
ほら。ここでのカキコみたいにさ(藁
＃最近、ソースごと納入な仕事ばっかりしてる気がするんだが、
＃お客がそのソースだのなんだのといった情報を有効活用してるのを、見た験しがないのでG7
Re:テストとコスト (スコア:1)
「調査した結果、何々となる事が判りました。」
で、その何を調査したかは説明してない。結果だけ。
良くわかってない上司とかはそれを分かり易いとか言って鵜呑みにしてしまうけど、
それではミスや調査不足があっても判らないし、その後それに基づいて改良しようとしても
何を調べて、何を試してないのか判らないから、同じ事をやる羽目になるという事が判っているのか...。
Re:テストとコスト (スコア:1)
あ。それ有る有る。
判りやすくするためには2つの方法が有って、1つは文字通り判りやすく「する」こと、
そしてもう1つは、判りにくい(説明がしんどい)部分を削るだけっていう奴(笑)。
で、元々「判りやすい」ってのは相対評価だから、ヤバイんですよね。
なんぼ下手くそな削り方をしてしまった(=情報量スカスカなドキュメントにしてしまった)としても、
「情報量スカスカである」ことを知るための情報自体が無くなっている(笑)ので、
そのドキュメントの不味さは、読み手に伝わらないんです。
それと比べると、見た目が「判りやすくない」かどうかは、読めばすぐ判るんで、
そこを「評価」するのは簡単なんだよね。
まあ、だからこそ、ああいう人々は見た目の判りやすさばかりを評価するんだろうな。
情報が足りないかどうかは評価のしようがないわけだ(^^;
>同じ事をやる羽目になるという事
「後で役立てる」という発想をそもそも採用していないのではないかと。
積読するためだけに作らせてる、と。
「効果的にバグを報告するには」 [unixuser.org]みたいな境地は、遠いです…しくしく。
まあ、肝心の納入ソフトすら積読する企業は珍しくないようなのでね。
＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
＃バグレポが2年(!)後に来たから何かと思えば、初めて評価したのが先週だったというオチ…などなど。
＃＃AprilFoolじゃないのでG7(T_T)
で、結果的にソフトにとって「どんな情報をどう伝えれば」役立つのか？っていうパターンって、
それなりに有るわけじゃないですか。
だけど、そういうのは門外漢(だよな)なお客とかにはしばしば「小難しく」映るらしい。
で、そういう真に有意義なパターンを正に「禁じ手」扱いしてくれちゃったりするのな。
つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
わざわざ作ってくださる。
Re:テストとコスト (スコア:1)
>そのドキュメントの不味さは、読み手に伝わらないんです。
私は結論からその根拠を文章中に探したときに何も説明していないことに気がつきました。
書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。
>＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
ほんとにデバックしたしたかと思うほどバグバグな物を納期に納めてくれたりして
それを受て開発する予定がずるずると延びて、納期ってなんなのて思った事もありました。
>つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
>わざわざ作ってくださる。
どう仕様書を書けばその様になるのは解りませんが、
文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。
Re:テストとコスト (スコア:1)
>書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。
あはは。なるほど。
そういう…これも一種の「論理的思考」っていうのかな…考え方を、
理解する人間と、しない人間が、居ますよね世の中には。
＃論理思考の苦手な人間は、少なくともソフト受注者や「発注者」には成らないほうが良いと思うのでG7
＃受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に説明できないようじゃ駄目です(コッチが対応しようが無いので)。
>>＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
>仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
状況によりけりなんでしょうけど、
「真のエンドユーザ」からの声が来ない状況ってのに出くわして、困ったことは有ります。
客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」してたんですが、
ここで情報の欠落(伝言ゲーム)や遅滞が起きるんですね。
おかげで、ユーザが実際に困っている事柄が、正確かつ迅速に、伝わってこない…
>>つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
>>わざわざ作ってくださる。
>どう仕様書を書けばその様になるのは解りませんが、
フォーマットの問題です。
「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
＃そうすれば「正確に」伝わる、と先方は思ってらっしゃるらしい。
ところが、そのフォーマットには、実用上困ってしまうような過不足が色々有って。
「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っていう事態が頻発しまして。
そういう場合、そのフォーマットに従えば従うほど、情報は欠落するわけです。
結局、備考欄しか役に立たなかったりする。それなら最初から備考欄(フリーフォーマット)だけでいいじゃん…
>文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
>最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
>人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。
あー。「相手が知りたいこと」と、こちらが用意する「結論」とは、一緒じゃない可能性が結構あるんですよね。
結論も、こちらが用意する限り、あくまで「知らせたいこと」の範疇でしかないのです。
結局、アジャイルが最強なんじゃないか？という気がしています。
つまり、フォーマットはあまり気にせずラフに書き始めて、
その代わり要求を随時フィードバックしてバンバン改訂してく、という奴ね。
＃ただし、「フォーマットをきちんとしてくれ！」という要求は、聞かないほうが良さそうですが:-)
言い換えると、「まず結論を書いて…」みたいな、結局は書き手側の発想でしかない方法論は、
古典的な書籍みたいに改訂をやりにくい環境に「特化」した方法論なんじゃないか？と思っています。
改訂できないという制約のもとで最高なものにしようとしたら、
仕方ないから自分が言いたいこと(の核心)を最初に相手にぶつけるというスタイルしか無い、という。
で、仕様の打ち合わせみたいなものってのは、
もともとそんな制約とは無縁であるはずです。
製品の仕様を向上させるのが目的であって、
前述の制約を守ることが目的ではないから、です(笑)。
つまり便利な媒体は随時選べばいいし、
まして現代なら電子媒体が情報の改訂し易さを大幅に援助してくれる。
つまり、「たまにしか会えない」ことを前提にしちゃ、
駄目なんだと思うんです。
Re:テストとコスト (スコア:1)
>理解する人間と、しない人間が、居ますよね世の中には。
特に作業報告書などはやった事とそこから得られる結論を書けばいいのに、
何故か、やった事を書こうとしないのですよね。
「調査した結果」とか適当な言葉でお茶を濁しているのですよね。
理数科系の職業のハズなのに～とか思ってしまうのですよ。
>＃受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に
>説明できないようじゃ駄目です(コッチが対応しようが無いので)。
それは耳が痛いなと思いつつ。
私も顧客から受注して、その一部を外注に投げている身なので、
発注者／受注者、両方の立場なのですが、
「曖昧な仕様を確認、明確化させるのも仕事の内」なのではないかと。
私の場合、殆ど仕様書なし。お客から聞出してこっちが書くものと成っているの
で。
仕様書が出てくるだけましかと。もっと色々仕様を書いてくれー。
>客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」
>してたんですが、ここで情報の欠落(伝言ゲーム)や遅滞が起きるんで
よくあります。相手先の営業が間に入って理解しないまま適当な事をしたりとか、
担当者として紹介された人と話したはずなのに、実際にはその人の部下に丸投げとか。
ちゃんとしたところは質問票を作って確認してきますね。
うちの会社ではレビューで顧客に確認したかという事をしきりに聞かれるのですが
他の所ではやってないのですかね。
>「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
>「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っ
ていう事態が頻発しまして。
昔、発注先から要求された事がありましたが、結局破綻しました。
問題や質問があると新規項目に書くのですが、説明になっていない説明で
終了させようとするので、全然意味がなかったですね。
>あー。「相手が知りたいこと」と、こちらが用意する「結論」とは、一緒じゃない可能性が結構あるんですよね。
>結論も、こちらが用意する限り、あくまで「知らせたいこと」の範疇でしかないのです。
相手の質問に対して回答するような形式だと、そうですね。
そういった場合、これ(ここ)はどうするつもりなのかと、逆に考えを問うてみて
相手の思考の枠を広げるという事も必要でしょう。
>言い換えると、「まず結論を書いて…」みたいな、結局は書き手側の発想でしかない方法論は、
>古典的な書籍みたいに改訂をやりにくい環境に「特化」した方法論なんじゃないか？と思っています。
>改訂できないという制約のもとで最高なものにしようとしたら、
>仕方ないから自分が言いたいこと(の核心)を最初に相手にぶつけるというスタイルしか無い、という。
それは一面にしかすぎない。会話にも使える話ですよ。
書くのも話すのも、結局相手にどう伝えるかに尽きると思います。
その時に相手の立場に立って伝えられるかどうかで、
同じ内容を伝えるのでも伝わりやすさが全然変ってきます。
判断して貰うのであれば、選択肢を提示するなど、
これを怠ったり、無意識に片方の選択肢を捨てているために
後で問題になるんですよね。
>で、仕様の打ち合わせみたいなものってのは、
>もともとそんな制約とは無縁であるはずです。
同意。
>つまり、「たまにしか会えない」ことを前提にしちゃ、
>駄目なんだと思うんです。
ソフトウェアの技術者にメールで済まそうとする人が多いですよね。
ずぼらな人はメールすらしない。
やはり、コミュニケーションが重要という事ですね。
Re:テストとコスト (スコア:1)
問題は、「納品される側の人」と「納品されるモノを使う人」が違うことでしょう。
使う人はきちんと出来てないと困るに決まってるんだけど、
お金の計算をする立場の人は
「それくらいどうでもいいから安くあげよう」
と決めてしまいがちです。
--------------------
/* SHADOWFIRE */
Re:テストとコスト (スコア:0)
A4用紙にして１万枚以上……。
evidence（証拠）を出せと言うなら、納品先の会社から
Re:テストとコスト (スコア:1)
なんなら、テストを省こうなどという、顧客/開発会社/エンジニアもさくっと削除ですね。
# あー、そういう日は何時来るのだろうか
お任せ下さい (スコア:0)
世間一般ではそれを「丸投げ」といいます。
直接受注者において開発工程を極限まで削減する事です。
テストの削減と同様、クオリティには期待出来ませんが、
それでも宜しければ、コストは大変お安くなります。
Re:テストとコスト (スコア:1)
えーと…
>人件費は減らしたい、というのが開発会社の第一の要望です。
>よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の１つになります。
貴方は「テストによって結果的に工数が削減できる可能性」の検討すらしてないということですか？
コスト云々を言うならリスクマネージメントの観点を抜かしていては、やらなくてもいい一か八かの勝負しか出来ない、
結果的に火だるまなプロジェクトを生み出す要因だと思いますが…
ジェネラリストばかりではよっぽどシェアを握るとか参入障壁があるとかいう業界で無い限り利益は薄くなるのではないでしょうか
（って自分も痛いな、これ。）
Re:テストとコスト (スコア:0)
えっとですね、要は「そのような位置にいない」ということなんではないかと。
作業員には関係ない話と言ってしまえば、言えてしまいますのでね。
Re:テストとコスト (スコア:1)
それともバグ改修は貴方でない誰かが代わりにやってくれているのですか？
Re:テストとコスト (スコア:1)
多分分かっていて書いているのだと思うのですが。。。仕事だからこそ、QA (品質保証) は重要なのではないかと思われます。
お金との兼ね合いを考えるからこそ、必要十分な品質を保つ為に、どこまでを保証するのかを明確にした上で、明確にした範囲で確実にテストが行われなければ、後々瑕疵の修正に伴う予定外の出資が多発してしまうのは想像にたやすいわけで。。。最近の M$ さんのようにね。
むらちより/あい/をこめて。
Re:テストとコスト (スコア:0)
趣味でなく仕事である以上、ごく普通のプロであればテストを省く危険性を伝え、お客様とプロジェクトを守ります。
Re:テストとコスト (スコア:0)
作られていったのでしょうか。
あれもテスト漏れとしか思えません。
見た目だけ主義(納期線引き優先、「何も発生しなしない事が
前提の」コスト優先)の産物が危険だとなぜ気づかないのでしょうか。
Re:テストとコスト (スコア:2, 興味深い)
回転ドアの件は設計ミスだろ。だって、センサに死角があることは事前に知っていたんだし。ついでに言えば、実運用に入った後も何件も事故が発生してたわけで。設計にミスがあることが判っていて、その上運用でも問題が出ているのに問題を放置したという、どうしようもない例。設計上、センサに死角があったことのだから、試験をやったとしても、今回のようなテストケースは出てこなかった可能性が高い。
Re:テストとコスト (スコア:2)
あの手の反射式のセンサーは、対象物の色で作動距離は変わる（産業機器で使っていて、誤動作防止のために透過式のセンサーに取り替えたことも何度かある）。
白と黒ではまったく作動距離は違う。これをカバーするために「地面から80cmも上で動作するように設定している」はず。
80cmも取っているのは、地面の反射率が変わると地面を対象物として拾ってしまうから。
白ならば地面から50cmでも拾うんじゃないの？
泥棒やスパイの映画やアニメで、赤外線スコープを使えば、線に見えるのが透過式で、シャワーの様に見えるのが反射式。
反射式は対象物の反射率や光の拡散などの要素に大きく左右されるし、センサーに砂埃が付けば感度は落ちる。
で、テストの話をするけど、セロテープをセンサーに貼るだけでも砂埃状況を再現出来るし、色や環境によって作動距離が変化するのは分かっていること。
その為に地面から80cmのマージンとっているのだから。
ついでに、セキュリティーは1ではなく2重にかけるべき。
機器は壊れたりするもの。セキュリティーホールが存在するのと一緒。
挟まれれば大怪我をする可能性があるものならば尚更。
Re:テストとコスト (スコア:1)
重大な勘違いをしていますね。設計ミスもテストで防げるのです。
もちろん、テストの結果判明した設計ミスを、どかんと修正する側へ傾けるか、放置する側へ傾けるかは、その仕事全体の責任者次第ですが。
むらちより/あい/をこめて。
Re:テストとコスト (スコア:2, 興味深い)
テストは確かにテストを行った部分に関しての問題のあぶり出しと通った結果による品質保証を行いうことができます。ですが、何をテストするかということについては何も保証されません。ようするにテスト漏れについてはテストでは解決しないのです。テストケースの充当性・正当性について、テストはできないのです。
今回はテストについての議論なのであまり触れられていませんが、レビューの効果も非常に大きいものがあるのではないでしょうか。もちろん、レビューですべてが解決するわけではありませんが、自分が気づかなかったことでも他人が気づくことがあるわけです。
ちょうどレビューについては今月の日経コンピュータで取り上げられているようですね。
それから、このスレッドで問題になっている森ビルの件については設計ミスだと思っています。今回の問題が起こり得るということを認識できなかった、もしくは認識していたが無視をしたかどちらかでしょう。
無視したのは論外として、認識できないということは非常に難しい話です。なんせ、当事者には問題が起きるかもしれないと想像することができなかったのですから。人は自分の想像の範囲内でしか思考することができないのです。だからこそ、自分以外の多くの人の意見を聞く、つまりレビューを行うべきだと私は思います。
Re:テストとコスト (スコア:1)
むぅ。。。個人的には、設計に則ってテストを突き詰めることによって、設計上の欠陥や矛盾を見つけられることがそれなりにあったので、このように書いたのですが。。。テストは作るときから既に、テストは始まっているって考え方っすね。
でもテストを作ることによって、テストを作る人間がテストされているって側面もあるからなぁなんちて (^_^;;;;A 。
レビューはおいらも当然重要だと思います。そもそも品質保証を行う上で、複数の異なる角度からの検証と見解の取りいれは絶対条件なわけで。テストは一人でやってはいけない。まぁテストに限らないんだけどね。。。
むらちより/あい/をこめて。
Re:テストとコスト (スコア:1)
そうであれば、テストでは通る、つーか責任者の考え方次第だから、
いわんとすることは同じかもしれないけど。
Re:テストとコスト (スコア:1)
それは正確ではないですね。正しくは、「設計ミスをテストで防げる＊かもしれない＊」ですね。
そもそも、設計に「安全」という条件が入っていないなら、「安全」に関する試験をするとは限りません。と言うか、仕様に入っていないことは試験しないのが普通でしょう。たまたま、試験を行なっていて「安全」というのが仕様・設計に含まれていなかったことに気づくかもしれませんが、それは単なる偶然。開発中・建設中にだって、安全性が低いことに気づく場合だってあるでしょう。しかしだからと言って、「開発・建設で設計ミスを防ぐことができる」というのは間違いですね。せいぜい「開発・建設で設計ミスを防ぐことができる＊かもしれない＊」程度でしょう。それと同じ。
試験に期待しすぎでしょう。
Re:テストとコスト (スコア:1)
命題を履き違えてはいけません。極力欠陥が無いように作られるべきであることは当然のことですが、「極力欠陥が無いように作る」などとは、設計仕様として記述しないでしょう? 欠陥があるから安全性が損なわれるのです。欠陥が無いように作られなければならない。
ならば、欠陥が無いように作られるようにするにはどうすればよいでしょう?
そもそも思うのですが、開発者 (ここでは作業員というべきでしょうか? 設計者も含めて) が行なうテストは、企業としては品質保証の一環として捉えるべきなのです。どんなに優れた、経験豊かな設計者であっても、一発で十分な設計 (完璧な、じゃないですよ) が行なえるとは限らない。それを補うための検討であるはずです。もちろん、スケジュール上の枠組みで捉えるならば、テスト以前の段階でその検討が十分に行なわれることがむしろ望まれるわけですが、作業が進行するにつれて、浮き彫りになる問題点というのも少なからず出てくるでしょう。その問題点を如何にして補足し、なるべく早い段階で大本の設計に反映できるかは、テストという概念の捉え方、体制のあり方でも随分変わってくるものであるはずです。
むらちより/あい/をこめて。
一人補足。。 (スコア:1)
親スレッドで取り上げられている回転ドアの事故については、この記事 [asahi.com]がかなり参考になるっぽいです。そもそも回転ドアを採用した段階で安全性に劣るという観点もあり、確かに微妙っぽいのですが (安全に作りたいなら回転ドアなんか使うなと)、安全性に公的基準が無いことや、速度や開閉力の調整はメーカーに任せられていることなどから、やっぱりテストから設計へのフィードバックにも不足はあったのかなぁとも思います。
しかしおいらなんかはテスト作成もテストの一環であると考えていたりするわけですが、この辺の言葉の使い方も話をややこしくしちゃってるのかもしれませんです。テスト作成はテストではなくてあくまで検討である、という言い方であれば、実は見解にそれほど大きな差異は無かったりするものなのかも。
どちらも QA であることに変わりは無いんですけどね。。。
むらちより/あい/をこめて。
Re:テストとコスト (スコア:1)
Re:テストとコスト (スコア:1)
端的に (大雑把に?) 言えば、用件に必要十分なものを完成させることです。仕事で求められているのは、理想とされる完璧なものを作り上げることではなく、与えられた条件の中で運用上極力差支えの無いレベルのものを作り上げることだと思っています。で、そのための QA であって、そのためのテストでしょう? てことです。
安全である以前に、ものがものとして機能するもので無ければ意味ないですからね (人間が怪我しないように軟らかい素材使ったら、すぐに壊れちゃった、とか)。たしかに、六本木ヒルズのビルの扉が回転ドアである必要があるのかと言われれば、「？」ですが、そういう要件があった以上、作る側としては、回転ドアとして運用上十分な品質の物を作る社会的義務がある訳で。
もっとも、その社会的義務の持ち方も結局は金次第、ってのは、まったくもってその通りなんですけどね。。。
むらちより/あい/をこめて。
Re:テストとコスト (スコア:1)
(誤)用件→(正)要件ですね。それならば、私とあなたの間に「命題」に関して齟齬はありません。
しかし、であれば、「設計ミスもテストで防げ」るかどうか、定かではありませんね。試験は要件に従って設計しますから。もし防げたとしても、それは単なる偶然です。
ただし、k 2 yさんが言われている通り、レビューのような「静的試験」を行えば設計ミス、あるいは要件確定ミスを防ぐことは、十分可能です。なぜなら、そのようなミスを発見することがレビューの目的の一つだからです。一方、上で言う(動的)試験はそうではありません。
Re:テストとコスト (スコア:1)
一般語なのでいろいろな定義があるでしょうが、仮にここでの大雑把な定義として
・要件(製品が満たしているべき機能や性能など)
・仕様(要件を満たす製品の挙動/外形など)
・設計(仕様を満たす製品の構造/材質など)
・開発(設計に沿った実製品)
・製造(実製品の量産)
としたとき、それぞれに対応する試験があるわけです。
要件に対する試験を実施していれば、
「安全性を考慮していない要件」というのは検証可能(な場合がある)でしょう。
その試験は、机上あるいはレビューなどの静的試験になります。
Re:テストとコスト (スコア:1)
私もそう書いているつもりです。
> その試験は、机上あるいはレビューなどの静的試験になります。
レビューを試験と言うのなら、そのとおりでしょうね。ただ、 T.MURACHIさんも私も、レビューを試験は別けて議論していると思います。つまり、「試験」を動的試験の意味で使っています。
Re:テストとコスト (スコア:1)
そんなことはないんじゃない？だって、センサーの感知範囲は、普通人が通るところとではないのだから。しかも、センサーは、ドアが柱にある程度以上接近したときにしか稼動状態にならないんでしょ？死角がなくても十分実用になるんじゃないかなぁ。そりゃ、死角がある場合に比べれば、誤作動する場合は増えるだろうけど、実用上問題になるほどのものなのかどうか。少なくとも、死人が出る危険性に勝るものではないと思います。
> 文化的にも歴史的にも回転ドアは馴染まないでしょう。
それはそうかもしれませんね。
Re:テストとコスト (スコア:0)
思うのは自由ですが、おそらく違うでしょうね。
センサーが働いてから止まるまで20メートルとか上部センサーの届かせる距離がいくらとか
具体的な数値がちゃんと出てますから。
問題は運用効率のみでやっちゃったとこかなぁ。
もっとも、飛び込んだガキ(と親の管理責任)が根本的な問題なんですけどね。
Re:テストとコスト (スコア:0)
あんた6歳のガキ飼ったことないだろ。
一般の人が出入りするようなところにあんな縦型ギロチン設置したのが根本的な問題だよ。
＃ 一定の力がかかれば、ドアの端が折れ曲がるように出来ないんかな。
オフトピなのでAC
Re:テストとコスト (スコア:0)
縦型ギロチンがなかったとしても、件の子供は道路に飛び出したかもしれませんし、
遮断機の降りてる踏切を渡ろうとするかもしれません。
やはり、根本というか自衛の意味も含めて本人の問題と認識しておいた方がよいでしょう。
＃6歳児が全員挟まれたわけでもないしね
Re:テストとコスト (スコア:0)
Re:テストとコスト (スコア:0)
>一般の人が出入りするようなところにあんな縦型ギロチン設置
回転ドア（世の中の全ての）を縦型ギロチンだと単純に言っているわけじゃないですよね。
Re:テストとコスト (スコア:0)
> 回転ドア（世の中の全ての）を縦型ギロチンだと単純に言っているわけじゃないですよね。
すんません、釣りました。
でも、生身の人間が接触するかもしれない機器が、接触した本人が自力で止められるような設計になってないのは、設計の根本が間違ってるとしか思えないです。
＃ 実物は見たことないけど、エスカレータに付いてるような非常停止装置はあるのかな？昨年の事故 [infoseek.co.jp]でも近くにいた警備員は
Re:テストとコスト (スコア:0)
> もっとも、飛び込んだガキ(と親の管理責任)が根本的な問題なんですけどね。
いや、安全というのはフールプルーフが基本であるものだが、
そういう視点に欠けていたことと、それが欠けていたとしても
過去の
Re:テストとコスト (スコア:0)
電車の窓から子供が頭を出したら吹っ飛んで死にました
回答：窓をなくします
ふざけた子供がホームから線路に落ちて吹っ飛んで死にました
回答：全ての線路に立ち
Re:テストとコスト (スコア:0)
よく停止するし、こうなることを予測できた人は結構いるんじゃないかな？
茶々 (スコア:0)
> 回答：全ての線路に立ち入り出来ないようにします
一部実現してるところがありますな。ゆりかもめとか都営三田線とか。
>玄関のドアを勢い
Re:茶々 (スコア:1)
馬鹿な先生が校門を勢いよく閉めて、女生徒を壁と門の間で
圧殺した事件がありましたね。
Re:テストとコスト (スコア:0)
タダでするのです
本来必要のない工程なんですから費用請求なんてできるわけが
ありません