質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
プログラミング言語

プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。

Q&A

解決済

10回答

3487閲覧

プログラムソース不具合が原因の再発防止策

tomoyuki123

総合スコア273

プログラミング言語

プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。

1グッド

2クリップ

投稿2018/12/10 02:44

不具合が発生したときに、その原因がプログラムソースの1行であった場合の再発防止策をどう書けばいいのか悩んでいます。
テストケースが不十分であったから、次回からテストケースを十分に記載して実行すればいいのではと思ってるのですが、ただその場合も結局は人が作るし十分に記載といっても人によって解釈が違うので、再発防止策とは言えないと思います。

どなたかこういう場合は再発防止策の案をいただけないでしょうか?

ai_2013_dev👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答10

0

ベストアンサー

その原因がプログラムソースの1行であった場合の再発防止策

記述してる内容は、ただの事象なので、原因をもう少し追求して見る必要があります。

一般的には、
・テスト漏れ
・設計間違い
・レビューをかいくぐった
等々、「本当の原因」を確認した上で対策を練ります。

投稿2018/12/10 03:12

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2018/12/10 03:14

「テストケースを十分に記載して実行」これを追求するのが近道だと思いますが、一度整理したほうが良いです。 この場合は「その原因がプログラムソースの1行であった場合の再発防止策」なんて表現にはなりません。
guest

0

一行でも何行でも不具合は不具合。
原因が少なければそれで重さが変わるというとそういうものでもありません。
影響範囲、影響度合いによっても違います。
それによって再発防止策も変わります。

質問内容を読む限りあなたは同じ不具合を必ず起こします。

一行だったからー
テストケースが不十分だったからー

これは単なる言い訳です。なんの解決にも防止策にもなってません。

たまたま一行で済んだだけかもしれない。実は潜在バグの一端だったかもしれない。となると今後もっと大きい不具合にぶちあたるかもしれない。

車の免許とるとかに「だろう運転はダメ。かもしれない運転で」って教わりませんでした?
事故とは得てして当人の「大丈夫だろう」という一瞬の甘い認識や判断から生まれるものです。

「テストケースが十分である」という保証は誰がいつどのように判断するのでしょうか?
それでOKが出たとして「本当に十分か」は誰にもわかりません。それでは再発防止策にはなりませんよね。それは書かれている通り。

ここは既に回答にある通り誰とも知らないネット上で質問するより参画しているプロジェクトやグループの先輩やリーダーなどに指導を仰ぐべきものです。
具体的な回答を得たとして、それがあなたのグループで通る保証はそれこそどこにもないですよね。要件によっても違うのだから。
その要件は外に出せないもののはず。

つまり、こんなところで聞いてる時間と手間が不具合の解決と再発防止を遅らせますよ。

投稿2018/12/10 04:13

m.ts10806

総合スコア80765

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

始末書の書き方なら先輩に教わってください。

バグを混入させないための再発防止策ではなく、同じミスを防止するものですから、どう書けばいいのからケースバイケースです。

ミスを防止するために先人たちはデザインパターンを作ったりライブラリを作ったり構造化を進めたりツールを使ったり様々なテクニックを使って読みやすく保守しやすいコードの書き方を研究してきました。

先輩が十分な経験を積んでいれば「こんな時はここに気をつけて書くといいよ」というものを教えてくれると思いますから、それを書いてください。

テストケースが不十分であるといった場合には、関数が肥大化し過ぎていて複雑になりすぎていることが考えられます。テストケースを増やすのではなくモジュール化を進めて小さな部品をテストするようにするのが良いと思います。

投稿2018/12/10 03:21

Zuishin

総合スコア28656

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

こんにちは。

不具合が発生したときに、その原因がプログラムソースの1行であった場合の再発防止策をどう書けばいいのか悩んでいます。

本稼働中に発生する不具合のそこそこ多くは、ソースのちょっとしたミスですね。
有名なものにロケットが落ちた原因になったとの噂の不具合があります。
例えば、この問題の再発防止策は何が考えられるでしょう?

この問題は構文チェックの厳しいプログラミング言語を使う案が結構有力と思います。
後から言語を変えるのはかなり厳しいですが、最初からなら可能です。とはいえ、未だにプログラマのミスに寛容な(というか指摘をサボる)言語は多く、しかもメジャーですね。(例えば、JavaScriptとか)
信頼性はそこそこで生産性を重視する分野で使われますし、それは妥当な使い方と思います。
生産性が高く、学習難易度が低く、かつ、バグ検出力のより高い言語はなかなかないので選択肢はかなり限られますから。

さて、このようなケースでの再発防止策はなんでしょう?
個人的にはテスト戦略を明確にして、無駄なテスト(例えば膨大な単体テストとか)をせず、実使用上問題となるバグの検出に特化したテストを的確に行うことだろうと思います。
医療機器や銀行システムなどの超高信頼性を要求される分野でなければ、割り切るもの手です。掛けることができる費用の上限は低めですから、費用の範囲内でバグ流出を可能な限り削減するのが良い筈です。

投稿2018/12/10 04:20

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

テストケースが不十分であったから、次回からテストケースを十分に記載して実行すればいいのではと思ってるのですが

確かにこの考え方は一理あります。
例えばアメリカのWeb系はこの思想が一般的であり、一芸に秀でたサービスだけどバグ多い、でも開発者に連絡したら明日にはもう直ってるみたいなサイクルでサービスを育てています。

ところが売り切りの製品で全国に出回った製品を全て回収するコストが発生するケース、
1箇所の誤動作で大勢の人が死ぬかもしれない軍事兵器のケースで同じ事言えますか?
このように時と場合で問題は大きくなったり小さくなったりします。
日本だとお金出す方が強いので、客の声がやたらデカく、小さい問題でもやたら責められるみたいな事もあるので、極端だと思うなら転職も視野に入れて下さい。

さて、再発防止策に移ります。
再発防止としては、1行だけに着目するのではなく、何故そんな正しく動作しない1行が単体テストをすり抜けてしまったに着目しましょう。
言い訳や上司のせいみたいなものを含めると色々出てくると思います。
もう思い浮かばないなら、悪い奴らの悪口を全てノートに書き出してもいいと思います。

  • 結合テストの前日に仕様変更で足された機能だった
  • そもそもシナリオテストで使われないような隠し機能的存在だった
  • 複数のバグが打ち消し合ってたまたま動いているように見えてしまった
  • Aのバグを直した事で依存先のモジュールの動作が変わってバグが発生してしまった
  • カバレッジ取ったら割合が低かった、納期の問題で引き上げる時間が足りなかった

何故こうなったのかをまずは洗い出してみて、ノート片手に上司に相談してみましょう。

再発防止策

一般的に再発防止策は建設的なものかつ、システマチックにやりましょう。
「◯◯さんが悪い、処分だ解雇だ!」みたいな魔女狩りみたいにするのではなく、皆悪かった、次からこうしていこうねみたいなものにするのが理想です。
この辺のさじ加減は何度も「再発防止策」を作らないと分からないので、上司に相談するべきでしょう。

投稿2018/12/10 06:09

miyabi-sun

総合スコア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

katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

間違いをしないようにする。これだけです。
できない?なら、あきらめるしかないです

投稿2018/12/10 02:58

y_waiwai

総合スコア87719

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Zuishin

2018/12/10 03:23

できませんが、それで諦めたら何も作れません。
y_waiwai

2018/12/10 03:28

それでもみなさん作ってますぜ。 バグ発生防止策がないのにもかかわらず。
Zuishin

2018/12/10 03:35

諦めてないからではないですか? 対策はそれぞれとっていると思います。
y_waiwai

2018/12/10 03:42

対策はとっている、でもバグはなくなりませんね。 まあ、しょせんはその程度のものだってことで。 問題は、質問くん(あるいは上司?)がその認識があるのかってところでしょうかw
Zuishin

2018/12/10 03:51

極めて小さなプログラムならバグを無くすことは可能です。 小さなプログラムに分割しようというモジュール化や、人が間違えてもそれを指摘するシステムがあるのはご承知の通りです。 プログラムが複雑になればなるほど全ての間違いを無くすことは困難ですが、「間違えなければいい、それができないなら諦めろ」というアプローチではなく、バグを無くそうという努力のもとにプログラムは作られます。
think49

2018/12/10 04:06

> 間違いをしないようにする。 これは「結果」であって、結果に至るまでの「経過」が問題なのだ思います。 少なくとも、私は「結果を出せ。方法は問わない。」というスタンスの上司の下には付きたくありません(信頼している部下への指示は除く)。 方法論は人それぞれですが、「結果が伴えば、何をやってもいい」に行き着きかねない指示は危険です。 部下は何もいわれなければ、自由意志で決めます。
bochan2

2019/01/17 12:15

僕はy_waiwaiさんに賛成です やはり小手先の技術よりも、あらゆることに対してミスがないかを確認することが大事なんだと思います。
Zuishin

2019/01/17 12:18

ミスがないように確認するのは大前提です。そこから先の話をしています。
guest

0

人力で行うには以下のレビューを綿密に行うしかないかと。

  • 設計書・・・要求仕様どおりか、要求仕様に現れていないことまで考慮されているか。特に異常系の処理は要求仕様に現れていないことが多いです。
  • コード・・・設計どおりか
  • テスト仕様書・・・テストパターン不足はないか
  • テスト結果・・・要求仕様どおりか

修正箇所に精通した人、そしてまったく関係のない第三者にも見てもらうと、関係者とは違った観点で見れるので、思わぬバグを防ぐことができるかもしれません。

これだけやってもバグは出るときは出るので、あとは個々人の能力を高めていくしかないかと。

投稿2018/12/10 05:58

ttyp03

総合スコア16996

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

やったことはないけれども

  1. 実装者が仕様、実装方針などメンバー全員にプレゼン。
  2. 実装者がソースコードの説明。メンバー全員でレビュー。
  3. 実装者が修正(改善)、コミット。
  4. バグが発生したら「1.」へ(バグの原因と改修方法の周知。)

投稿2018/12/11 10:42

o8q

総合スコア18

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

素人ですが。この質問自体に不安を感じます。
ソースの1行が原因で、という言い方では分かりません。
様々な方法は知ってらっしゃると思います。
「機械的な方法」では見つけるのが難しい(しかし、致命的な)エラーもありますね。というか、その方が厄介です。
その場合は、質問でその一行を(差し支えがあるなら関数名や変数名を書き換えるなどして)提示して、どのように再発防止が難しいか、を示して質問することになると思います。
何故このような質問になったか?がそもそも問題かと思います。

投稿2019/01/17 11:30

編集2019/01/18 10:36
myoon

総合スコア100

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問