バグのないソフトウェア開発を確実にするための5つのヒント
公開: 2017-10-24ソフトウェアアプリケーションにバグがありますか？ もちろん、そこにあるすべてのソフトウェアプログラムには問題があり、バグのないソフトウェアの話は神話であるため、そうです。 ただし、いくつかの本っぽいが実用的な削減手法に従うことで、バグ、エラー、およびセキュリティの問題を大幅に最小限に抑えることができます。
バグ追跡に関しては、すべての人にルールを守るように促す必要があるため、多くの規律が関係しています。 特に新興企業やクリエイティブ主導の業界では、非公式なコミュニケーションを思いとどまらせるのはかなり難しい場合があります。 実際、多くの場合、人々はプロジェクトの最も焦点を絞った部分として「バグ追跡」を挙げていません。
バグ追跡とは何ですか？
テクノペディアによると、「バグ追跡は、ソフトウェアの問題と解決策を追跡するために品質保証担当者とプログラマーが使用するプロセスです。 「「
したがって、バグ追跡システムは、報告されたエラーに関するすべての情報を管理し、各バグのステータスを追跡します。 問題を追跡している間、あなたは間違いなく広範な情報の必要性を理解しています。 十分なデータを提供するには、膨大な時間だけでなく、ソフトウェア開発の分野での豊富なスキルも必要です。
バグ分類
ソフトウェアのバグには次の3種類があります。
- 仕様が正しくない
- 実装の欠陥
- 仕様がありません
これらのバグタイプはいずれも、重大な問題として簡単に分類できます（または改善として再分類できます）。 Xolv.ioの創設者であるSamHatoumが使用する再分類ガイドラインのいくつかを先に述べました。
- 間違った仕様は私たちに損失を引き起こしていますか？ たとえば、仕様では、トラックのクリック数を追跡する必要があるのに、バグの再分類に費やす必要があると述べています。
- 実装上の欠陥は無視できますか？ たとえば、Webフォントは、ソフトウェアに埋め込む必要があるときにインストールされます。
- 欠落している仕様は新しい機能を意味しますか？ たとえば、ユーザーはソーシャルネットワークでプロフィールの詳細を共有および編集することはできません。
開発チームは他のすべての作業よりもバグを優先するように指示されているため、製品マネージャーがバグを効率的に分類するための賭け金が引き上げられます。 すべてのバグが削除されるまで、開発者は何もしません。
チームの品質基準の形成
設計および開発チームがアプリウイルスを改善として再分類できるかどうかを決定する場合、その決定プロセスはチームの品質基準を暗黙的に示します。 たとえば、高品質のビジュアルを強調するブランドオーナーは、デザインの不一致に対する許容度が低い場合があります。 代わりに、これらの問題をバグとして再分類します。
一貫性のある再分類システムにより、チームの品質基準を最優先する構造化された配信アプローチを維持しながら、期待と現実を継続的に適応させることができます。
バグの失敗
最近の調査によると、システム障害のほぼ40％はソフトウェアのバグが原因であり、他のセキュリティ問題とプログラムの脆弱性は60％を占めており、一般的なメモリと同時実行性に関連する問題が原因です。 アプリケーションのソフトウェアのバグを減らすことは、ソフトウェアのセキュリティ、安定性、信頼性を高めるための最良の方法です。
バグのないソフトウェア開発を確実にするためのヒント
ロギングツールSmartInspectの開発中、開発者はシステムの品質を高く保つために多くの方法を使用しました。 前述のリストには、彼らが使用したテクニックのいくつかが含まれています。
1.コミュニケーションの余地を作る
バグの検出と報告には、関連情報を特定するスキルが必要です。この情報は、すべての問題レポートに追加されます。 必要な情報を自動的に添付する機能を提供するUsersnapのような多くのバグ追跡および品質保証ツールがあります。 それでも、情報の欠落や誤解の余地は常にあり、適切なコミュニケーションが必要になります。
特定のテストシナリオでは、開発者とテスターの間でそのような開示の余地はありません。 次のような質問：「担当の専門家に連絡するにはどうすればよいですか？」 または「電話または電子メールでフィードバックを求めても大丈夫ですか？」 バグ追跡プロセスの開始時に回答する必要があります。
テスターと開発者に代わって誤解を避けるために、全員を同じページに集めて、両方の当事者の作業が同じように尊重されるフィードバック指向の文化を作成してみてください。
2.一対一で保管してください
プロジェクト会議でバグについて話し合うことは避けてください。 今私を誤解しないでください。 チームとして作業し、バグを再現して修正することは悪いことではありません。 しかし、キャビネット全体との長時間の会議で問題について話し合うことはしないでください。 Usersnap.comの技術ブロガーであるThomasPehamによると、バグを報告し、次の開発の「再テスト」フェーズでそれらについて話し合うのは非常に遅いアプローチです。
実際、1対1で維持する方がはるかに効率的です。 Yegorがバグ追跡の5つの原則に関する記事で書いたように、各バグレポートは、指定者と問題解決者の2人の間でリンクされています。 プロセスに関与する人の数に関係なく、報告された問題を解決するための2つの主要な責任（2つの異なる役割）のみがあります。
3.チームからの賛同を得ることを確認します
チーム全体がそれを使用しない場合、優れたバグ追跡データベースは効果がありません。 まず、すべての利害関係者（カスタマーサービス、品質保証、プロジェクトマネージャー、開発者）にツールを評価してもらい、一緒に意思決定を試みることから始めるのが最善です。 同じシステムを使用して、一貫した方法で欠陥をログに記録して対処します。
人を乗せるのに苦労している場合は、次のことができます。
開発者の場合は、他の方法ではなく、個々のデータベースを介してバグレポートを受け入れる法則を定めてください。 テスターがフィードバック付きの電子メールを送信するときは、代わりに情報システムでレポートを投げるようにテスターに依頼してください。 これは、物事を整理しておくことに加えて、必要なすべての情報を提供し、必要なフィールドを定義することにより、レポート作成にも役立ちます。
より効率的なプロセスを作成する別の方法は、QAを行うか、顧客からのバグの検証をサポートし、開発者に通知される前にデータベースに正確な手順を追加することです。 ソフトウェアの問題を効果的に追跡することは、信頼性が高く一貫性のあるプロジェクト管理フレームワークを持つための最も重要な側面の1つです。
- 優れたデバッガー
Visual StudioやDelphiなどのシステムを使用している場合は、使用する必要のある非常に強力なデバッガーに既にアクセスできます。 開発者が試行錯誤によってバグを排除しようとすることが多いスクリプト環境の場合、このプロセスは問題を特定して解決するための面倒な方法になるだけでなく、コードを完全に理解しておらず、それができない場合は非常に危険です。デバッガーでそれをステップスルーします。 チームに適したデバッグプラットフォームを入手して、自分に有利に働きましょう。ほとんどすべてのデバッガーがあります。
4.「クローズ」バグの意味を理解する
バグを閉じることについての議論に参加したことがありますか？ さて、おめでとうございます、あなたはこれまでに起こり得る最悪のバグ追跡状況にありました。
「バグステータス」について話し合っていることに気付いた場合は、一歩下がって次の質問をすることを検討してください。
- 結果を受け入れるのは誰の責任ですか？
- 受け入れの基準は何ですか？
- 注文を出す責任は誰にありますか？
「閉じた」の意味を見てください。 大多数の開発チームでは、バグはエラーを修正した人によって閉じられます。 Pehamは、問題を報告した人がバグレポートを閉じることをお勧めします。 特定のバグの解決策が開発者によって提案されたら、レポーターはレポートを閉じるように求められる必要があります。 これにより、フィードバックがソフトウェアの混乱に対して十分な解決策となることが保証されます。
5.仮想マシン
可能な限り多くの異なるオペレーティングシステムと環境でソフトウェアのバグをテストするには、VirtualPCやその他の利用可能な仮想化ソフトウェアなどのツールを備えた仮想マシンを使用する必要があります。 仮想マシンを簡単にコピー、共有、リセットできるため、この方法で時間を大幅に節約でき、あらゆる種類の構成でソフトウェアをテストできます。
定期的にテストするすべてのオペレーティングシステム用にさまざまな標準イメージを作成し、それらをファイルサーバーに配置することを常にお勧めします。 何かをテストするために非常に特殊な構成が必要な場合は、オペレーティングシステム、必要なソフトウェア、ドライバーなどをインストールせずに、ベースイメージの1つから始めることができます。
それは新しい概念ではありません
Hatoumがこのコンセプトを思いついたとき、彼はZero-Bugソフトウェアのアイデアが新しいものではないことに気づきました。 実際、忘れられていた昔ながらの哲学の多くと同様に、1960年代から存在しています。
伝説的な品質の専門家であるフィリップ・クロスビーは、マーティン社で働いているときにゼロディフェクトという用語を発明しました。現在知られている「ロッキードマーティン」では、「政府の監査の下でハードウェアの欠陥を54％削減」したと報告されています。
当初、ゼロディフェクト技術は60年代に航空宇宙製造で使用され、1990年代に自動車製造に適用されました。 製造業とソフトウェア配信の間には多くの類似点があります。
たとえば、人気のあるアジャイル管理モダリティかんばんは、トヨタ生産方式に端を発しています。 これが基本的に私たちに伝えていることは、ソフトウェアやアプリの開発における技術的なインスピレーションを得るために、これらの製造プロセスを簡単に調べることができるということです。Zero-Bugはそれらのインスピレーションの1つです。
ただし、基準を満たすための極端なコストは、ゼロディフェクトアプローチに対する大きな批判の1つです。 そして、正しく実装されていない場合、これは確かに真実である可能性があります。 ゼロバグアプローチでは、Hatoumはバグの機能への再分類と大幅な改善を通じてこの問題に直接対処し、チームの品質基準を通じてコストを管理できるようにしました。
今日から始めましょう
技術ユーザーおよび開発者は、前述のシステムを使用して、既存のすべての不具合を調べ、分類することができます。 何十万もの問題があると思われる場合は、それらをバックログして新たに開始する良い機会かもしれません。 心配しないでください。必要に応じて、いつでもアーカイブから現在のドメインにバグを移動できます。
開発チームは、バグの潰しを開始する前に、分類の演習全体が完了するまで必ずしも待つ必要はありません。 いくつかのバグが分類されるとすぐに開始できます。 チームは、すべてのアイテムが「バグフリー」または再分類されるまで、バックログ内の他のアイテムの作業を開始してはなりません。 プロダクトマネージャーに新しい作業に正しく優先順位を付けるように強いるのは、まさにこのルールです。
まとめる
プロジェクトで報告されたすべてのバグは、修正するために追加の時間を必要とします。 したがって、バグ追跡には、バグを追跡する個人からの優れたコミュニケーションスキルと、バグを修正する人からの感度が必要です。 前述の追跡ハックを使用すると、チームは、あらゆる種類の技術またはセキュリティのハードルを報告しながら、生産性を向上させることができます。