タグ付けされた質問 「bug」

バグに関するメタタグ。これは使わないでください。

21
テスターが見つけるためのコードに意図的なバグを残す
弊社ではこれを行っていませんが、友人の一人が、プロジェクトマネージャーがすべての開発者に、製品がQAに移行する直前に意図的なバグを追加するように依頼したと言います。これがどのように機能するかです: 製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。 テスターに​​もこのことが通知されます。バグが存在し、それらを見つけられないことは無能の兆候と見なされる可能性があることを知っているため、彼らは一生懸命テストします。 バグ(意図的またはその他)が見つかった場合、それらは開発チームが修正するために報告されます。開発チームは、製品が第2レベルのQAに移行する直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考えるべきであり、変更が行われたセクションに新しいバグがあることを期待すべきだと言います。 まあ、これはそれがどのように行くかです。彼らは、このアプローチには次の利点があると言っています。 テスターは常につま先を向いており、狂ったようにテストします。これは、開発者が修正できるように、隠れた(意図しない)バグを見つけるのにも役立ちます。 テスターはバグをフィードします。バグを見つけられないと、彼らの士気に影響します。ですから、彼らに見つけやすいものを与えることは彼らの士気を助けるでしょう。 これらの意図的なバグの1つが最終製品に同梱されるシナリオを無視する場合、このアプローチの採用を検討する前に考慮すべきその他の欠点は何ですか? いくつかの説明: ソース管理で元のコードを適切にバックアップします。 テスターが意図的なバグを見つけると、開発チームはそれを無視します。テスターが意図しない(元の)バグを見つけた場合、開発チームは最初に意図的なバグが原因かどうかを確認します。つまり、開発チームは最初に元の作業コードでそれを再現しようとし、可能な場合は修正しようとします。 QAと開発チームの関係の問題を無視してください。私は、ワークプレイスではなくプログラマーにこの質問を具体的に尋ねました。QAと開発チームの間には良好な関係があり、勤務時間後には一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、両方のチーム(Godsend)をサポートする準備が常にできている、素晴らしく、年配の紳士です。

16
バグをより速く解決する方法はありますか?私はちょうど上司から警告を受けました[終了]
上司から、月曜日にパフォーマンスに関する否定的なレビューを受けると言われました。彼は、なぜ私がそんなに遅いのか、そしてなぜ私のバグ修正率がそんなに低いのかについて私に話したいと思っています。 私はプログラミングと問題の解決が大好きですが、実際に仕事は本当に難しいと感じています。 私は実際に約10年間プログラマーです。しかし、これは私の最初のマルチスレッディング組み込みLinuxの仕事です-私はここに2年来ましたが、私がまだ苦労していることは誰にとっても明らかです。そして、私は非常に士気を失い、社会から疎外されたと感じているので、仕事を始めたときの多くの火を失いました。 誰も同じような状況に陥ったことはありますか?また、バグ修正率をどのように上げますか? 更新:レビューがありました。私は3か月間の「従業員開発プログラム」(Dunkが言及したタイプの)に参加しました。これを好転させることができるかどうかわからない。しかし、先に進まなければならない場合でも、この経験から多くのことを学びました。 別の更新 最初のレビューから約6週間です。同じ状況に直面している人への私のアドバイスは、批判を受け入れ、あなたの過ちから学ぶのに十分謙虚であることです。そして、愚かに見えることを恐れないために。たくさんの質問をしてください。あなたが学ぼうとしていることを人々に知らせ、理解するまで尋ね続けます。しかし、うまくいかないように準備してください。私はコードのポートフォリオを構築しています...そしてそれをベストショットにします。 さらに別の更新 将来の雇用者に私のstackoverflowプロファイルを参照することができないのではないかと心配しているので、これをここに置くのをためらっています...しかし、とにかく、この質問を読んでいる人にとって興味があるかもしれませんが、実際には数週間前の仕事。私は必要なすべてのスキルを磨く最中です-ここで与えられたアドバイスから多くを取りました。

11
「goto」ステートメントはどのようなバグにつながりますか?歴史的に重要な例はありますか?
ループに入れ子になったループから抜け出すために保存することを理解しています。このgotoステートメントは回避され、バグが発生しやすいプログラミングスタイルとして悪用され、決して使用されることはありません。 代替テキスト: 「ニール・スティーブンソンは自分のラベルに「dengo」という名前を付けるのはかわいいと思っている」 オリジナルのコミックを参照:http : //xkcd.com/292/ 私はこれを早く学んだからです。どんな種類のバグがgoto実際につながるのかについての洞察や経験は本当にありません。ここで何を話しているのか: 不安定? 維持不能または読み取り不能なコード? セキュリティの脆弱性? 完全に何か他のもの? 「goto」ステートメントは実際にどのようなバグにつながりますか?歴史的に重要な例はありますか?

9
ソフトウェアのテスト中に、ユーザーがソフトウェアに対してこのような愚かなアクションを実行しないと想定できますか?
例:Webアプリケーションでフォームの機能テストを実行しているときに、異なる種類のランダムな入力値を入力してフィールドをテストします。 一般に、Webアプリケーションのユーザーとして、フィールドにランダムな値を実際に入力することはありません。 このような問題が本番環境で発生する可能性がはるかに低い場合、バグにつながる可能性のある/そうでない可能性のあるすべてのテストケースを組み込むことの使用は何ですか? 注:上記の例はサンプルケースにすぎません。このような問題は、あらゆる種類の機能/モジュールで発生する可能性があります。 この質問は、標準的な慣行が続くかどうか、または製品、ドメイン、その他すべての要因に完全に依存するかどうかを知るためだけに行っています。

15
大規模なソフトウェアでバグの絶対的なゼロ状態に到達することは可能ですか?
たとえば、Autodesk Mayaの規模と複雑さのコード、2千万から3千万行以上のコードについて話しています。 必要に応じて開発をフリーズした場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか?バグのないシステムの存在に対する賛否両論は何ですか? 修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。 バグとは、UIの最も単純なタイプミスから、回避策のないより深刻な予防バグまでを意味します。たとえば、特定のスクリプト関数は法線を正しく計算しません。また、回避策がある場合でも、問題を解決する必要があります。したがって、提供された関数を使用する代わりに、この特定のことを手動で行うことができますが、その関数はまだ修正する必要があります。

17
診断して修正する前にすべての欠陥を再現することを主張するのは合理的ですか?
私はソフトウェア製品会社で働いています。当社の製品を実装する大企業のお客様がおり、サポートを提供しています。たとえば、不具合がある場合は、パッチなどを提供します。つまり、かなり典型的なセットアップです。 最近、製品のクラスター化された実装での同時データベースアクセスに関係するログファイルでお客様が発見した例外に関してチケットが発行され、私に割り当てられました。したがって、このバグの発生には、この顧客固有の構成が重要になる可能性があります。顧客から得たのは、ログファイルだけです。 私がチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することでした。ただし、バグを再現する必要はありません。過度に時間がかかり、VM上のサーバークラスターをシミュレートする必要があるため、彼らは私のアプローチに同意しません。私のチームは、単純に「コードをたどって」スレッドおよび/またはトランザクションに対して安全でないコードがどこにあるかを確認し、単純なローカル開発で動作する変更を行うことを提案します。バグの起源。 私にとっては、目に見える形の顕在化(実行時の再現)ではなく、抽象的な設計図(プログラムコード)で作業するのは難しいようです。そのため、一般的な質問をしたいと思いました。 すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか? または: 私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、マルチスレッドコードを読んで、すべてのユースケースシナリオでそれが何をするかについての心構図を作成できるはずです行ごとにコード?または、私はそのような作業環境を要求するのに貧弱な開発者ですか? sissisのデバッグはありますか? 私の意見では、インシデントチケットに対応して提出された修正は、可能な限り元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか?それは、エアバッグが実際に機能することを実証するためにダミーで衝突試験することなく、車両の新しいモデルをリリースするようなものです。 最後になりますが、私に同意する場合: 私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか?

19
コンパイラはどうしてそんなに信頼できるのでしょうか?
コンパイラは、その正確性が与えられているかのように日常的に使用しますが、コンパイラもプログラムであり、潜在的にバグを含む可能性があります。私はいつもこの絶対的な堅牢性について疑問に思っていました。コンパイラ自体のバグに遭遇したことはありますか?コンパイラ自体に問題があることをどのように認識しましたか? ...そして、どのようにしてコンパイラを非常に信頼できるものにしますか?

12
どのプログラミング言語が最も見つけにくいバグを生成しますか?[閉まっている]
あなたの意見では、平均的なプログラマーが見つけにくいバグを最小限に抑えて機能を出力できる言語は何ですか?これはもちろん非常に広範な質問であり、私は非常に広く一般的な答えと知恵に興味があります。 個人的には、JavaおよびC#プログラムの奇妙なバグを探すのにほとんど時間を費やさず、C ++コードには明確な繰り返しバグのセットがあり、Python / similarにはコンパイラによって検出される一般的で愚かなバグのセットがあります他の言語で。 また、完全に機能的なコードで書かれた大きくて複雑なプログラムを見たことがないので、この点で関数型言語を検討するのは難しいと感じています。ご入力ください。 編集:見つけにくいバグを完全にarbitrary意的に明確化:再現するのに15分以上かかり、原因を見つけて修正するのに1時間以上かかります。 これが重複している場合はご容赦ください。ただし、この特定のトピックについては何も見つかりませんでした。

10
schrödinbugとは何ですか?
このWikiページは次のことを示しています。 schrödinbugは、ソースコードを読んだり、異常な方法でプログラムを使用したりした場合に最初に動作するはずのないことに気づいた後にのみ現れるバグです。Jargonファイルには、「…これは不可能に思えますが、起こります。一部のプログラムは潜在的なシュレディンバグを長年にわたって隠していました。」 話されていることは非常にあいまいです。 誰かがschrödinbugがどのようなものであるかの例を提供できますか(架空/現実の状況のように)?
52 bug 

8
バグ修正タスクのストーリーポイント:スクラムに適していますか?
ストーリーポイントをバグ修正タスクに割り当てる必要があるかどうかだけを考えています。私たちの問題追跡ソフトウェアであるJIRAには、バグタイプの問題のストーリーポイントフィールドがありません(StoryおよびEpic専用です)。 ストーリーポイントフィールドの該当する問題タイプにバグ問題タイプを追加する必要がありますか?長所と短所は何ですか?スクラムに適しているでしょうか?
50 agile  scrum  bug  user-story 

1
トリアージされていないバグとは何ですか?
私はコンピューターサイエンスの学部生です。いくつかのプロジェクトにバグを報告しようとしたとき、私は多くのトリアージされていない分類に出会いました。Web検索では、これが何を意味するのか実際には説明しませんでした。 トリアージされていないバグとは何ですか?

13
ストーリーポイントを平均より4〜5倍増やしていますが、バグの発生率は半分です。グラフによれば、それはさらに2倍のバグだという。
そのため、トップレベルのプログラマーは、平均的なピアよりも1 桁以上優れたコードを生成できると一般に受け入れられています。 また、プログラマーにとって、コードで発生するエラーの割合は比較的一定であることも一般的に受け入れられています。 代わりに、コードの作成時およびコードの作成後に使用されるプロセスの影響を受ける傾向があります。(私が理解しているように)人間はかなり一定の割合で間違いを犯す傾向があります-優れたプログラマーはそれらの多くに気づくだけで、より迅速に修正します。 上記の両方の主張は、Steve McConnellによるCode Completeからのものであることに注意してください。したがって、異なる観点の問題ではありません。 だから私は最近、私のコードでこれを見始めました。私は、(チームが推定したストーリーポイントで測定して)同程度のコードの約4〜5倍のコードを、より高い品質(パフォーマンスメトリックとチェックイン後に行われた変更の数に基づく)で打ち出すことができます。しかし、私はまだ間違いを犯します。優れた単体テストと、コードが何をしているのかをよりよく理解し、コードレビューを行う際の問題に対するより良い目との間で、4〜5倍の数のバグを生成していません。 しかし、QAが発見したバグは、チームの他の開発者の約2倍です。ご想像のとおり、これはメトリック測定を行う技術者以外の人々にいくつかの問題を引き起こします(私のボスを読んでください) 私は、ピアの半分の割合でバグを生成している(そして2倍修正している)ことを指摘しようとしましたが、2倍のバグを生成しているというグラフがあると、それは大変な売りです。 それでは、生産性の向上がバグの増加につながるという事実にどう対処するのでしょうか?

9
コードのメンテナンス:コードにコメントを追加するのか、それともバージョン管理に任せるのか?
バグの修正/ CRの実装の一環としてコードに加えた変更ごとに、開始タグ、終了タグ、説明、解決策などのコメントを追加するよう求められています。 私の懸念は、これが付加価値を提供するかどうかです。現状では、バージョン管理履歴にすべての詳細があります。これは、すべての変更を追跡するのに役立ちますか? しかし、私のリードは、コメントを「良い」プログラミング手法として主張しています。彼らの議論の1つは、CRのスコープを変更/変更する必要がある場合、コメントがないと面倒になることです。 変更は主にコードの中間にあると考えると、私たちが行うすべての変更にコメントを追加することは本当に役立つでしょうか?バージョン管理に任せてはいけませんか?

14
バグを修正するか、顧客がバグを見つけるのを待ちますか?
他の人はバグを見つけたときに修正しますか、それともクラッシュ/データ損失/人が死ぬまで修正を待つのですか? 例1 Customer customer = null; ... customer.Save(); コードは明らかに間違っており、回避方法はありません。null参照でメソッドを呼び出しています。Saveインスタンスデータにアクセスしないため、クラッシュしません。静的関数を呼び出すようなものです。しかし、どこでも小さな変更があれば、クラッシュしないコードが突然クラッシュする可能性があります:クラッシュを開始します。 しかし、コードを修正することも考えられません: Customer customer = null; ... customer = new Customer(); try ... customer.Save(); ... finally customer.Free(); end; かもしれない紹介クラッシュ。完全に網羅された単体テストと手動ユーザーテストでは発見されなかったもの。 例2 float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2); 物理学を知っている人は、それが分母のR 2であることを認識するでしょう。 コードが間違っている、それは絶対に間違っている。また、速度を過大評価すると、レトロロケットの発射が早すぎて、宇宙船のすべての乗員が死亡します。 しかし、速度を過大評価して別の問題を隠している可能性もあります。シャトルの動きが速すぎるとエアバッグが展開できません。突然コードを修正した場合: float speed = …
35 code-quality  bug 

7
誰が修正/バグを支払うべきですか?[閉まっている]
だから、デスクトップ/ Web開発と、すでに私の仕事を受け入れているこのクライアントの両方でフリーランスを開始しました。バグなどを見つけるたびに私に戻ってきます。無料です。これで大丈夫ですか、それともサポート料金の請求を開始する必要がありますか? 受け入れられ、完了したと思われる作業の修正に対処する最良の方法はどれですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.