アカウント名:
パスワード:
>プログラム上の不具合で再び表示された可能性があるという事象としてはプログラムの不具合であると判断しても仕方ないが、システム運用開始前に機能試験をしていたのであれば、この事象の発生を把握できていたはず。現時点での「ちゃんとしたプログラムかけよ！」という主張はシステム発注元としては無責任。
でもぶっちゃけ、「システム運用開始前に機能試験をしていたのであれば、この事象の発生を把握できていたはず。」は非現実的な理想主義者の戯言なんだよね。そのうえ、あらゆるバグに対して使える、すなわち情報量０で具体性に欠き改善にまったくつながらない無駄意見でもある。
なんとなくの印象論ですが、この手の問題って、性能/処理量の問題で、過負荷時などのレアケースで問題が起きるようなバグ、といったケースが多いように思います。(ちょっと前の、住民票コンビニ交付の誤発行とか)
そういうバグだったら、個々の機能だけを見る単体テストでは、たとえ全機能をちゃんと網羅したテストであってもバグを見つけることはできません。まあ、負荷テストをしてないのが落ち度だって言われそうですけど、実運用に即したテストって難しいよね。
で、以下は勝手な想像ですが、今回の問題の説明を読んで、「リングバッファにデータを貯め込むような処理フローになっていて、データが多すぎてリングを一周しちゃった」みたいなことだったのかな、という印象を受けました。書き込み側はバッファが一杯だったのでデータの登録をしなかったけど、読みこみ側は発生データ数だけ読み込んだので、1周前のデータを読み込んじゃった、とか。そういうバグなら、リングバッファがあふれないような普通の単体テストでは問題なく動作するでしょうし。
地震計の性質上大量のデータが来る前提で作成されていそうでそのへんは普通考慮済みかも。どちらかというと装置のトラブルで書き込みができずにみたいなケースのほうが大きそう。地震が起きたんだから震度が記録されているだろうで震度だけ見て時刻を見ずに発表してしまいましたなんてやつ。
理想論を言えばちゃんとしたプログラムかけばテスト不要ですからね。
どんなアホでもこれくらいなら言えるし、こう言えば識者っぽい気分になれて気持ちいいんじゃない？
また憶測だけで「ちゃんとテストしていれば見つけられたはず」説か。しょーもない
え機能テストって開発担当の仕事でしよ
ああ開発担当というのはシステム発注元に対してを想定していました。なんでシステムを開発した会社のQA部署も含めて開発担当ですね。実際のところ発注元は無茶振りしたら開発担当の会社にプレッシャーかけて開発を完了させノーチェック受け入れテストを済ませて終わりみたいなイメージ。QAと開発を別会社でやるケースも稀なイメージ。みずほくらい炎上すると全員が強力な一体感に包まれるそうだ。それこそ幼稚園からずっといっしょにいて同じ会社に就職してずっと同じ部署でチーム組んでるレベル。
「無責任なスラド利用者の戯言」って略さずちゃんと書きましょうよ＃総ツッコミワロタ
Yahoo!ニュースのコメント欄なら大量の「共感した」がついたんだろうけどねえ。スラドじゃツッコまれるわな。
まともに作っていれば発生するはずの無い、発生頻度の低いバグを発注側がチェックできるはずが無い発注側はプログラムを自分で作れないから外注するのである現時点では『現時点での「ちゃんとしたプログラムかけよ！」という主張はシステム発注元としては無責任。』という主張は無責任
発注側がチェックできるはずだとか、まともに作っていれば発生するはずが無いとか、不可能なことを人間に期待するのはやめようよ
余計な一文書く前に推敲できなかったのかな
すら土民は多分推敲した結果誤字のほうがいいねってなったパターン。文体からして２チャネラー系統の人って感じ。//推敲したら過激な日の右舷が消えてしまった…
テストは所詮テストでしかないんじゃ、本当に現象が起きたときにしかわからないこともあるってことじゃ。そういう経験、ないかの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
無責任な利用者 (スコア:-1)
>プログラム上の不具合で再び表示された可能性があるという
事象としてはプログラムの不具合であると判断しても仕方ないが、
システム運用開始前に機能試験をしていたのであれば、
この事象の発生を把握できていたはず。
現時点での「ちゃんとしたプログラムかけよ！」という主張はシステム発注元としては無責任。
Re:無責任な利用者 (スコア:1)
でもぶっちゃけ、「システム運用開始前に機能試験をしていたのであれば、この事象の発生を把握できていたはず。」は非現実的な理想主義者の戯言なんだよね。
そのうえ、あらゆるバグに対して使える、すなわち情報量０で具体性に欠き改善にまったくつながらない無駄意見でもある。
Re:無責任な利用者 (スコア:2)
なんとなくの印象論ですが、この手の問題って、
性能/処理量の問題で、過負荷時などのレアケースで問題が起きるようなバグ、
といったケースが多いように思います。
(ちょっと前の、住民票コンビニ交付の誤発行とか)
そういうバグだったら、
個々の機能だけを見る単体テストでは、たとえ全機能をちゃんと網羅したテストであってもバグを見つけることはできません。
まあ、負荷テストをしてないのが落ち度だって言われそうですけど、実運用に即したテストって難しいよね。
で、以下は勝手な想像ですが、今回の問題の説明を読んで、
「リングバッファにデータを貯め込むような処理フローになっていて、データが多すぎてリングを一周しちゃった」
みたいなことだったのかな、という印象を受けました。
書き込み側はバッファが一杯だったのでデータの登録をしなかったけど、
読みこみ側は発生データ数だけ読み込んだので、1周前のデータを読み込んじゃった、とか。
そういうバグなら、リングバッファがあふれないような普通の単体テストでは問題なく動作するでしょうし。
Re: (スコア:0)
地震計の性質上大量のデータが来る前提で作成されていそうでそのへんは普通考慮済みかも。
どちらかというと装置のトラブルで書き込みができずにみたいなケースのほうが大きそう。
地震が起きたんだから震度が記録されているだろうで震度だけ見て時刻を見ずに発表してしまいましたなんてやつ。
Re: (スコア:0)
何も設定していなくてもハード的にリングメモリー。
Re: (スコア:0)
理想論を言えばちゃんとしたプログラムかけばテスト不要ですからね。
Re: (スコア:0)
どんなアホでもこれくらいなら言えるし、こう言えば識者っぽい気分になれて気持ちいいんじゃない？
Re: (スコア:0)
また憶測だけで「ちゃんとテストしていれば見つけられたはず」説か。
しょーもない
Re: (スコア:0)
え機能テストって開発担当の仕事でしよ
Re: (スコア:0)
もちろん、単体テストは当人がやらないといけないが。
Re: (スコア:0)
ああ開発担当というのはシステム発注元に対してを想定していました。
なんでシステムを開発した会社のQA部署も含めて開発担当ですね。
実際のところ発注元は無茶振りしたら開発担当の会社にプレッシャーかけて開発を完了させノーチェック受け入れテストを済ませて終わりみたいなイメージ。QAと開発を別会社でやるケースも稀なイメージ。みずほくらい炎上すると全員が強力な一体感に包まれるそうだ。それこそ幼稚園からずっといっしょにいて同じ会社に就職してずっと同じ部署でチーム組んでるレベル。
Re: (スコア:0)
「無責任なスラド利用者の戯言」って略さずちゃんと書きましょうよ
＃総ツッコミワロタ
Re:無責任な利用者 (スコア:1)
Yahoo!ニュースのコメント欄なら大量の「共感した」がついたんだろうけどねえ。スラドじゃツッコまれるわな。
Re: (スコア:0)
まともに作っていれば発生するはずの無い、発生頻度の低いバグを発注側がチェックできるはずが無い
発注側はプログラムを自分で作れないから外注するのである
現時点では『現時点での「ちゃんとしたプログラムかけよ！」という主張はシステム発注元としては無責任。』という主張は無責任
Re: (スコア:0)
発注側がチェックできるはずだとか、まともに作っていれば発生するはずが無いとか、不可能なことを人間に期待するのはやめようよ
Re: (スコア:0)
余計な一文書く前に推敲できなかったのかな
Re: (スコア:0)
すら土民は多分推敲した結果誤字のほうがいいねってなったパターン。
文体からして２チャネラー系統の人って感じ。
//推敲したら過激な日の右舷が消えてしまった…
Re: (スコア:0)
テストは所詮テストでしかないんじゃ、本当に現象が起きたときにしかわからないこともあるってことじゃ。そういう経験、ないかの？