バグのないアプリケーションとして何かありますか？
私たちはクライアントに到達する前に多くのテスターを通過するアプリケーションを開発しています。
最後に、クライアントに届くと、さらにバグを見つけて報告してくれますが、これは面倒なプロセスになっています。内部コードのほとんどを変更する必要があるため、個人的には修正できないいくつかのバグがあり、それが機能するかどうかさえわかりません。
質問：
多くのテストを行った後でもバグが報告されるのはなぜですか？それは私たちの要件の問題ですか？
私たちのクライアントは私たちが提供するものに満足していないようです。私たちは何か間違ったことをしていますか？
完全にバグのないアプリケーションを開発した人はいますか？プロセスは何ですか？マイナーなバグのあるアプリケーションをデプロイできないのはなぜですか？私たちは完璧主義者になるはずですか？
現在のシナリオは、開発とテストの正しいプロセスですか？そうでない場合、開発者、テスター、クライアントが一緒に最大の利益を得る効率的な方法は何ですか？
バグのないアプリケーションに最も近いほど、より高価になります。これは、100％のコードカバレッジを対象とするようなものです。同じ時間とお金を費やして、0％から95％、95％から99％、99％から99.9％に到達します。
この0.1％のコードカバレッジまたは品質が必要ですか？おそらくはい、原子炉の冷却システムを制御するソフトウェア製品に取り組んでいるなら。ビジネスアプリケーションで作業している場合は、おそらくそうではありません。
また、高品質のソフトウェアを作成するには、 非常に異なるアプローチ が必要です。ビジネスアプリの作成に一生を費やした開発者のチームに、ほぼバグのないアプリケーションを作成するよう依頼することはできません。 高品質のソフトウェアには、 正式な証明など、さまざまな手法が必要です。ビジネスアプリでは、コストが非常に高いためです。
私の記事 で説明したように：
ビジネスアプリは、生命に関わるソフトウェアに必要な品質をターゲットにすべきではありません。これらのビジネスアプリが時々失敗しても、それは問題ではないからです。おそらくすべての大企業のWebサイトにバグとダウンタイムがありましたが、Amazonだけが例外でした。このダウンタイムとそれらのバグは煩わしく、おそらく月額数千ドルの費用がかかりますが、修正にはかなりの費用がかかります。
コストが第一の焦点であり、実用的に研究されるべきです。 5,000人の顧客に影響を及ぼし、それらの顧客が永遠に去ってしまうほど重要であるバグを想像してみましょう。これは重要ですか？はい？もっと考える。それらの顧客のそれぞれが年間10ドルを支払っていて、バグを修正するのにほぼ10万ドルかかると言ったらどうでしょうか？バグ修正は今ではあまり面白くないように見えます。
次に、具体的に質問に答えます。
なぜ多くのテストを行った後でもバグが報告されるのですか？要件の問題ですか？私たちのクライアントは私たちが提供するものに満足していないようですか？私たちは何か間違ったことをしていますか？
多くのことがうまくいかない場合があります。テストとは、実際の自動テストを意味しますか？そうでなければ、これはそれ自体で大きな問題です。テスターは要件を理解していますか？定期的に顧客とコミュニケーションをとっていますか-少なくとも1回の反復につき1回、せいぜいチームのメンバーなら誰でも現場で顧客の担当者にすぐに連絡できます？反復は十分短いですか？開発者は自分のコードをテストしていますか？
上記のリンクの正しいものの記事と同様に、バグレポートを作成し、このバグが最初に現れた理由とその理由を調べます各テスターがそれを逃したのですか。これにより、チームのプロセスのギャップに関するいくつかのアイデアが得られる場合があります。
考慮すべき重要な点：顧客はバグ修正に料金を払っていますか？そうでない場合、彼は多くのことをバグであると考えるように促されるかもしれません。バグに費やす時間を彼に支払うようにすると、バグレポートの数が大幅に減ります。
完全にバグのないアプリケーションを開発した人はいますか？プロセスは何ですか？マイナーなバグのあるアプリケーションをデプロイできないのはなぜですか？私たちは完璧主義者になるはずですか？
私。先週末、自分用にアプリを作成しましたが、今のところバグは見つかりません。
バグは、報告されたときのバグにすぎません。したがって、理論的には、バグのないアプリケーションを作成することは完全に可能です。それがだれも使用していない場合、バグを報告する人はいません。
現在、仕様に完全に一致し、正しいことが証明されている大規模なアプリケーションを作成すること（上記の正式な証明を参照）は、別の話です。これが生命に関わるプロジェクトである場合、これはgoalである必要があります（アプリケーションを意味するわけではありませんwillバグがないこと）。
現在のシナリオは、開発とテストの正しいプロセスですか？そうでない場合、開発者、テスター、クライアントが一緒に最大の利益を得る効率的な方法は何ですか？
お互いを理解するために、彼らはコミュニケーションする必要があります。これは私が見たほとんどの企業で起こっていることではありません。ほとんどの企業では、プロジェクトマネージャーだけが顧客（場合によっては担当者）と話します。次に、要件についての理解を（時には部分的に）開発者、インタラクションデザイナー、アーキテクト、DBA、テスターと共有します。
これが、顧客（または顧客の代理人）がチームの誰からも連絡可能（アジャイルアプローチ）であるか、またはチームの他の少数の人とのみ通信することを許可し、情報をチーム全体で共有できるようにして、全員が同じ情報を持つようにします。
開発とテストを行うには多くのプロセスがあります。会社とチームを正確に知らなければ、どのケースに適用すべきかを決定する方法はありません。コンサルタントの採用、または十分なスキルを持つプロジェクトマネージャーの採用を検討してください。
すべてのバグが同じように作成されるわけではないので、もみ殻から小麦を選別する必要があります。
期待
多くのバグは、ソフトウェアの機能とエンドユーザーが期待している機能が不足しているために発生します。この期待は、他のソフトウェアの使用、誤った文書、熱心な営業スタッフ、ソフトウェアの使用方法など、多くの分野から生じています。
スコープクリープ
言うまでもなく、配信する数が多いほど、バグの可能性が高くなります。多くのバグは、単に新機能に起因して発生しています。あなたはXとYを提供しますが、顧客はこれの裏側でZも行うべきだと言っています。
問題のあるドメインを理解する
多くのバグは、問題のドメインが十分に理解されていないという単純な理由で発生します。すべてのクライアントには、独自のビジネスルール、専門用語、物事の方法があります。これの多くはどこにも文書化されません-それは人々の頭の中だけにあります。世界一の意志があれば、これらすべてを1つのパスでキャプチャすることはできません。
それで...それについて何をすべきか。
自動単体テスト
多くのバグは、コード変更などの予期しない副作用として導入されています。単体テストを自動化している場合は、これらの問題の多くを回避して、最初からより良いコードを生成できます。
テストは、提供されたデータと同じくらい優れているだけなので、問題のある領域を完全に理解してください。
コードカバレッジ
これは自動化された単体テストと連動しています。実際に可能な限り多くのコードをテストする必要があります。
レッスンを学ぶ
狂気は同じことを何度も何度も繰り返し、異なる結果を期待しています
最後の失敗の原因を理解していますか？あなたは？本当に？あなたは問題の発生を止めたかもしれませんが、真の根源は何でしたか？悪いデータ？ユーザーエラー？ディスクの破損？ネットワーク停止？
なんらかの解決策に向けて前進することなく同じ問題に何度も遭遇するほど、クライアントを困らせることはありません。
ソフトウェア開発の最初から欠陥が存在しています。質問から、欠陥がユーザビリティや機能にどの程度、どの程度の重大度で影響を与えるかはわかりません。
欠陥のないプログラムは存在しますが、重要なシステムのほぼすべてに欠陥があります。
あなたはある種の優先順位付けを決定する必要があり、欠陥の原因-それらが導入された場所の調査を行う必要があるでしょう。単純なQ＆Aの投稿では、そのようなことについて議論するにはあまりに多すぎます。
品質の問題がある組織の因果分析と修正プロセスについての本はすべて書かれています。
だから私の推奨は：（順不同）
- まだ見つけていない場合は、欠陥追跡システムを実装する
- 欠陥の重大度を分類する方法を決定する
- 顧客の期待に応えていない理由を理解する（開発者、QA、顧客など）
- 「5つの理由」のようないくつかの演習について学び、欠陥の原因のいくつかについて同様の調査を行います。
アプリケーションの名称によって異なります。
つまり、リアルタイムの動作が特定の状況下で正確であることを確認する必要があるインタラクティブなプログラムでは、バグがないことを証明することは基本的に不可能です。 停止問題 を解決できれば可能だと思いますが、それはできません。
ただし、「そのような入力によって最終的にそのような最終的な状態がもたらされる」という記述に限定すると、不変を使用できるため、「バグのない証明」が得られる可能性が高くなります。 =。それとそれだけで、正確さの証明をサブ問題に分解することができます。各問題は、残りのプログラムのすべて状況下で正しく動作することが比較的簡単に証明できます（ただし、通常、所要時間とメモリの量についてはあまり正確ではありません）。
このようなテクニックは基本的にどのプログラミング言語でも可能です（ただし、 Malbolge のような難解なものthatを証明しようとします））が、すべての命令型言語では乱雑になります。多くの暗黙的なプログラムの状態を綿密に追跡する必要があるため、非常に迅速です。関数型言語1、証明は見栄えがよくなる傾向があります（ 純粋な言語 、または言語の純粋に機能的なサブセット）。それでも、特に動的型では、どの入力が許可されるかについて多くの要件を書き出す必要があります。これはもちろん、強力な静的型システムの主な利点の1つです。要件はコード内にあります。
まあ、理想的にはそうです。実際には、O'CamlまたはHaskellプログラムでさえ非合計関数を含む傾向があります。つまり、正しいタイプにもかかわらず、特定の入力に対してクラッシュ/ハング/スローする関数です。2。これらの言語は非常に柔軟な型システムを持っていますが、それを使用して何かを完全に制限することはまだ実行できない場合があるためです。
入力 依存型言語 ！これらは必要に応じて型を正確に「計算」できるため、定義するすべてのものが、必要なすべてを証明する型シグネチャを正確に持つことができます。そして実際、依存型付けされた言語は主に証明環境として教えられています。残念ながら、実際にプロダクションソフトウェアを作成している人はいないと思います。実用的なアプリケーションの場合、完全にバグのないに到達できる最も近いのは、可能な限り完全な関数を使ってHaskellで書くことです。これにより、prettyがbug-proofに近づきます。ただし、機能の説明に関してのみです。 Haskellのユニークな処理方法IOモナドを使用すると、いくつかの非常に有用な証明も得られますが、通常、何かが完了するまでにかかる時間については何もわかりません。かなり時間がかかる場合があります。特定の状況では–ユーザーの視点から、プログラムが完全にハングするかのように深刻なバグになる可能性があります。
1または、より一般的には、記述的言語。私は論理言語についてはあまり経験がありませんが、証明に関しては同様にいいと思います。
2それが正しいタイプでない場合、コンパイラーはこれらの言語で決して許可しません。すでに多くのバグが取り除かれています。 （そして、Hindley-Milner型推論のおかげで、実際にはプログラムもより簡潔になります！）