不具合が発生したときに、その原因がプログラムソースの1行であった場合の再発防止策をどう書けばいいのか悩んでいます。
テストケースが不十分であったから、次回からテストケースを十分に記載して実行すればいいのではと思ってるのですが、ただその場合も結局は人が作るし十分に記載といっても人によって解釈が違うので、再発防止策とは言えないと思います。
どなたかこういう場合は再発防止策の案をいただけないでしょうか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答10件
0
ベストアンサー
その原因がプログラムソースの1行であった場合の再発防止策
記述してる内容は、ただの事象なので、原因をもう少し追求して見る必要があります。
一般的には、
・テスト漏れ
・設計間違い
・レビューをかいくぐった
等々、「本当の原因」を確認した上で対策を練ります。
投稿2018/12/10 03:12
退会済みユーザー
総合スコア0
0
一行でも何行でも不具合は不具合。
原因が少なければそれで重さが変わるというとそういうものでもありません。
影響範囲、影響度合いによっても違います。
それによって再発防止策も変わります。
質問内容を読む限りあなたは同じ不具合を必ず起こします。
一行だったからー
テストケースが不十分だったからー
これは単なる言い訳です。なんの解決にも防止策にもなってません。
たまたま一行で済んだだけかもしれない。実は潜在バグの一端だったかもしれない。となると今後もっと大きい不具合にぶちあたるかもしれない。
車の免許とるとかに「だろう運転はダメ。かもしれない運転で」って教わりませんでした?
事故とは得てして当人の「大丈夫だろう」という一瞬の甘い認識や判断から生まれるものです。
「テストケースが十分である」という保証は誰がいつどのように判断するのでしょうか?
それでOKが出たとして「本当に十分か」は誰にもわかりません。それでは再発防止策にはなりませんよね。それは書かれている通り。
ここは既に回答にある通り誰とも知らないネット上で質問するより参画しているプロジェクトやグループの先輩やリーダーなどに指導を仰ぐべきものです。
具体的な回答を得たとして、それがあなたのグループで通る保証はそれこそどこにもないですよね。要件によっても違うのだから。
その要件は外に出せないもののはず。
つまり、こんなところで聞いてる時間と手間が不具合の解決と再発防止を遅らせますよ。
投稿2018/12/10 04:13
総合スコア80765
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
始末書の書き方なら先輩に教わってください。
バグを混入させないための再発防止策ではなく、同じミスを防止するものですから、どう書けばいいのからケースバイケースです。
ミスを防止するために先人たちはデザインパターンを作ったりライブラリを作ったり構造化を進めたりツールを使ったり様々なテクニックを使って読みやすく保守しやすいコードの書き方を研究してきました。
先輩が十分な経験を積んでいれば「こんな時はここに気をつけて書くといいよ」というものを教えてくれると思いますから、それを書いてください。
テストケースが不十分であるといった場合には、関数が肥大化し過ぎていて複雑になりすぎていることが考えられます。テストケースを増やすのではなくモジュール化を進めて小さな部品をテストするようにするのが良いと思います。
投稿2018/12/10 03:21
総合スコア28656
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
こんにちは。
不具合が発生したときに、その原因がプログラムソースの1行であった場合の再発防止策をどう書けばいいのか悩んでいます。
本稼働中に発生する不具合のそこそこ多くは、ソースのちょっとしたミスですね。
有名なものにロケットが落ちた原因になったとの噂の不具合があります。
例えば、この問題の再発防止策は何が考えられるでしょう?
この問題は構文チェックの厳しいプログラミング言語を使う案が結構有力と思います。
後から言語を変えるのはかなり厳しいですが、最初からなら可能です。とはいえ、未だにプログラマのミスに寛容な(というか指摘をサボる)言語は多く、しかもメジャーですね。(例えば、JavaScriptとか)
信頼性はそこそこで生産性を重視する分野で使われますし、それは妥当な使い方と思います。
生産性が高く、学習難易度が低く、かつ、バグ検出力のより高い言語はなかなかないので選択肢はかなり限られますから。
さて、このようなケースでの再発防止策はなんでしょう?
個人的にはテスト戦略を明確にして、無駄なテスト(例えば膨大な単体テストとか)をせず、実使用上問題となるバグの検出に特化したテストを的確に行うことだろうと思います。
医療機器や銀行システムなどの超高信頼性を要求される分野でなければ、割り切るもの手です。掛けることができる費用の上限は低めですから、費用の範囲内でバグ流出を可能な限り削減するのが良い筈です。
投稿2018/12/10 04:20
総合スコア23272
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
テストケースが不十分であったから、次回からテストケースを十分に記載して実行すればいいのではと思ってるのですが
確かにこの考え方は一理あります。
例えばアメリカのWeb系はこの思想が一般的であり、一芸に秀でたサービスだけどバグ多い、でも開発者に連絡したら明日にはもう直ってるみたいなサイクルでサービスを育てています。
ところが売り切りの製品で全国に出回った製品を全て回収するコストが発生するケース、
1箇所の誤動作で大勢の人が死ぬかもしれない軍事兵器のケースで同じ事言えますか?
このように時と場合で問題は大きくなったり小さくなったりします。
日本だとお金出す方が強いので、客の声がやたらデカく、小さい問題でもやたら責められるみたいな事もあるので、極端だと思うなら転職も視野に入れて下さい。
さて、再発防止策に移ります。
再発防止としては、1行だけに着目するのではなく、何故そんな正しく動作しない1行が単体テストをすり抜けてしまったに着目しましょう。
言い訳や上司のせいみたいなものを含めると色々出てくると思います。
もう思い浮かばないなら、悪い奴らの悪口を全てノートに書き出してもいいと思います。
- 結合テストの前日に仕様変更で足された機能だった
- そもそもシナリオテストで使われないような隠し機能的存在だった
- 複数のバグが打ち消し合ってたまたま動いているように見えてしまった
- Aのバグを直した事で依存先のモジュールの動作が変わってバグが発生してしまった
- カバレッジ取ったら割合が低かった、納期の問題で引き上げる時間が足りなかった
何故こうなったのかをまずは洗い出してみて、ノート片手に上司に相談してみましょう。
再発防止策
一般的に再発防止策は建設的なものかつ、システマチックにやりましょう。
「◯◯さんが悪い、処分だ解雇だ!」みたいな魔女狩りみたいにするのではなく、皆悪かった、次からこうしていこうねみたいなものにするのが理想です。
この辺のさじ加減は何度も「再発防止策」を作らないと分からないので、上司に相談するべきでしょう。
投稿2018/12/10 06:09
総合スコア21158
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
テストの設計をする。
参考情報
- 3つのテスト設計技法
https://webrage.jp/techblog/three_types_of_test_design_techniques/
- テスト設計で大切な2つの視点とは?
https://qangaroo.jp/info/point-of-view-of-test-design
正常動作だけなく、想定外のパラメータ値が入って来た場合、マルチスレッドで動作させた場合、ネットワークエラー, ファイルアクセスエラー, メモリー不足, ディスク不足 などのエラーが起きた場合のこともテストする。
少なくとも全部の行がテストで通過したかを確認する。
とはいっても十分にテストしたつもりでも、予期せぬことは起こります。
エラーが起きた場合、後から解析ができるようなログ出力やエラーメッセージを出すようにしておくことも大事です。
また、フェイルセーフ (障害が発生した場合、常に安全側に制御すること)にしておくことも大事です。
(自動販売機が故障したときに、お釣りや商品が余計にでるようになってしまってはまずい。故障した場合はお釣りや商品が出なくなるようしておく)
投稿2018/12/10 15:22
総合スコア22324
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
間違いをしないようにする。これだけです。
できない?なら、あきらめるしかないです
投稿2018/12/10 02:58
総合スコア87719
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/12/10 03:28
2018/12/10 03:35
2018/12/10 03:42
2018/12/10 03:51
2018/12/10 04:06
2019/01/17 12:15
2019/01/17 12:18
0
人力で行うには以下のレビューを綿密に行うしかないかと。
- 設計書・・・要求仕様どおりか、要求仕様に現れていないことまで考慮されているか。特に異常系の処理は要求仕様に現れていないことが多いです。
- コード・・・設計どおりか
- テスト仕様書・・・テストパターン不足はないか
- テスト結果・・・要求仕様どおりか
修正箇所に精通した人、そしてまったく関係のない第三者にも見てもらうと、関係者とは違った観点で見れるので、思わぬバグを防ぐことができるかもしれません。
これだけやってもバグは出るときは出るので、あとは個々人の能力を高めていくしかないかと。
投稿2018/12/10 05:58
総合スコア16996
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
素人ですが。この質問自体に不安を感じます。
ソースの1行が原因で、という言い方では分かりません。
様々な方法は知ってらっしゃると思います。
「機械的な方法」では見つけるのが難しい(しかし、致命的な)エラーもありますね。というか、その方が厄介です。
その場合は、質問でその一行を(差し支えがあるなら関数名や変数名を書き換えるなどして)提示して、どのように再発防止が難しいか、を示して質問することになると思います。
何故このような質問になったか?がそもそも問題かと思います。
投稿2019/01/17 11:30
編集2019/01/18 10:36総合スコア100
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/12/10 03:14