メニュー

外観上のバグと機能上のバグ–何をどのように処理する必要がありますか？

cosmetic functional bugs what has be treated

問題を排除するために楽器を試してください

ソフトウェアが持っているあらゆる種類のバグを発見するために、テスターに​​は常に大きな責任が課せられます。機能やユーザーインターフェイスに関係なく、テスターは不適合がある場合はいつでもバグを発生させる可能性があります。

この記事は、機能バグと外観バグの重要性を理解するのに役立ちます。 さらに、それらに優先順位を付ける際に考慮すべき要素も、ここで理解できる方法で説明されています。 イラストの実例 。

グラフデータ構造c ++

外観と機能のバグ

学習内容：

機能的および表面的なバグの重要性

ソフトウェア開発ではバグは避けられません。したがって、ライブで使用する前に、ソフトウェアを徹底的にテストすることが常に非常に重要です。 ソフトウェアテスト 彼らは識別に役立つので、より重要になる可能性があります 開発者が見逃したバグ 。

これらの未確認のバグは、ライブで非常にコストがかかる可能性があります。したがって、ソフトウェアの品質を向上させるには、適切なテスト計画とテストを実行する必要があります。

図1：

外観上および機能上のバグ

上の図は、ソフトウェアが表示できなかった画像ファイルをアップロードする必要があります。これは深刻な問題であり、ビジネスに深刻な影響を与える可能性があります。

化粧品のバグとその重要性

外観上の要件は、ユーザーインターフェイス、またはソフトウェアのフロントエンドの外観に他なりません。ほとんどの場合、異なるリリース間で変化し続けることがあります。

これは、特にアジャイル手法が採用されているプロジェクトで発生します。ここでは、リリースはスプリントの形で行われます。したがって、これらは通常、スプリントリリースまたは単にSR-xxと呼ばれ、「xx」はリリース番号を示します。

すべてのリリースには、特定の要件セットがあります。一般に、クライアントはユーザーインターフェイスまたはUIのみの変更を頻繁に要求する準備をします。

以下は、化粧品の要件のいくつかの例です。

  • メニューはCalibriフォントとで利用できる必要があります。
  • テキストボックスAは1.2インチである必要があります
  • 生成されるすべてのレポートには、「002522」色のH1サイズのタイトルが必要です。

上記は、発生する可能性のある美容要件のいくつかの例です。これらは主に目的とする要件です ソフトウェアの使いやすさを即興で 。外観上の要件の背後にあるもう1つの理由は、ビジネス目的のためにソフトウェアとその設計を最適化することです。

図2

外観上および機能上のバグ1

上の図では、機能面と外観面の両方の問題があります。 オプション「UseDeathByCaptcha」のチェックボックスのような機能上の問題は表示されません。

外観上の問題は、使用されている統一フォントがないようにここで見ることができます。

化粧品のバグやクライアントからのニーズの優先順位

化粧品のニーズは、クライアントによって少し不可欠であるとマークされています。これは、ソフトウェアの相互作用を非常に単純にすると同時に効率的にして、目標の達成を容易にする必要性に対する懸念のためです。ユーザーインターフェイスに問題がある場合、クライアントは優先度の低いバグでベンダーに連絡します。

一般的に発生するように、ソフトウェアの機能面は、ほとんど影響の少ない領域であるため、外観面よりも開発者が関心を持っています。

ソフトウェアテスターは、クライアントが言及したすべての要件をソフトウェアで利用できるようにしたいのですが、失敗すると当然バグが発生します。そして、すべてが離陸するのはここです。テスターに​​よって設定された優先順位は、クライアントの提案の結果として発生します。開発者の見方は、テスターの見方とは少し異なります。彼らは、バグが機能の中断を引き起こす可能性があるかどうかを常に調べます。

ここにいくつかの繰り返しの議論があり、その結果は、テストチームからの推奨がいつか起こる可能性があります。現在のリリースにない場合は、次のリリースで発生する可能性があります。

実際の例＃1）

クライアントは、クイックロード機能とともにタイトルフレーム内のホームページに会社のロゴを表示するように要求しました。ベンダーは、会社のロゴの読み込みに時間がかかり、ロゴが読み込まれていないと感じているクライアントが顧客のライブの問題を提起するソフトウェアを提供しています。

したがって、これはベンダーにより多くの損害を与えました。問題の根本的な原因は、画像のサイズや画像の性質などである可能性があります。これは機能的な中断はありませんが、これはライブの問題として取り上げられています。

機能的なバグ–重大な優先要因

一般に、バグは、クライアントによって設定された優先順位と、クライアントがビジネスに残す可能性のある影響に基づいて優先順位が付けられていると見なされます。重大度の高いバグに取り組むことは、開発者全体の一般的な信念です。機能的なバグは彼らの仕事を抑制するものであるため、これはより明白です。

そして、優先順位に基づいて、クライアントは同じリリースの機能的および外観上のバグのいくつかに優先順位を付けたいと考えています。重要度の要因は、バグが残す可能性のある影響または潜在的な影響によって異なります。優先順位の要素は、純粋にクライアントとそのニーズに基づいています。

重要度に関しては、機能的なバグを遅滞なく修正する必要があります。表面的なバグについては、クライアントが下した決定に応じることができます

EclipseでJavaプロジェクトを開始する方法

図3

外観上および機能上のバグ2

上の図では、デザインの問題やテキストのオーバーラップなどの機能上の問題と、フォントの問題などの外観上の問題があります。

実際の例＃2）

例1のクライアントには、同じベンダーからの複数のリリースがありました。クライアントは、ベンダーが提供する成果物に満足しています。現在、突然、クライアントが機能していないと特定したビジネスシナリオがほとんどなく、他のいくつかの表示問題のリストもあります。機能的に影響を与える問題はクライアントにとって重要であると考えられているため、ベンダーにできるだけ早く修正するように依頼しました。

また、表示の問題には影響の程度が少ない兆候があったため、クライアントは複数のリリースでそれらを優先しました。クライアントは、いくつかの表示の問題とほとんどの機能の問題を修正して、稼働する準備ができていました。これは、すべての機能がビジネスに影響を与える可能性があり、いくつかの表示の問題が影響を与える可能性があるためです。

ビジネスへの影響

すべてのバグにより、ソフトウェアがクライアントの要件に準拠しなくなる可能性があります。ビジネスへの影響に関して言えば、ビジネスに深刻な影響を与えるに値するのは間違いなく機能上のバグです。外観上のバグはUIのデザインと外観の問題に準拠しているため、ユーザーの使いやすさと外観に問題が生じる可能性があります。

言い換えれば、これらはバグよりも表面的な強化と呼ばれる方が良いでしょう。これらはビジネスに大きな影響を与えることはできませんが、ソフトウェアの使用中にユーザーにいくつかの問題をもたらす可能性があります。

外観上および機能上のバグ3

実際の例＃3）

ベンダーは、モバイルバージョンでソフトウェアアプリケーションの新しいバージョンを提供しています。モバイルアプリには、ユーザーがリンクをより頻繁にクリックする必要のある機能がいくつかあります。これにより、ユーザーの使いやすさが低下したように感じました。ベンダーは、アプリケーションの設計とフローを再検討する必要があります。フローを変更した後、アプリケーションは複数のユーザーにフローを使用させ始めました。

そのようなアプリケーションの多くでは、ユーザビリティが主な役割を果たします。機能的な変更はありませんでしたが、アプリケーションをより強力にする化粧品の変更はほとんどありませんでした

外観上のバグと機能的なバグの比較研究

ソフトウェアテストのライフサイクルの複数の側面で、機能的なバグや表面的なバグなど、バグの分類にはさまざまなバリエーションがあります。それらのいくつかは、両方のタイプの違いとして定式化され、表にされています。

比較エリア機能的なバグ化粧品のバグ
考えられる原因 複数の原因が考えられます。
1.コーディングの問題
2.同期の問題
3.依存アプリケーションの問題
以下が問題の原因である可能性があります。
1.設計上の問題
2.サポートされていないファイルの問題
レクリエーションの程度 機能的なバグの再現は、テスターまたはクライアント自身のいずれかによって行うことができます外観上のバグは、ほとんどUIレベルで識別されるため、レクリエーションに最小限の労力で済みます。
臨界 機能の故障は深刻な形でビジネスに影響を与える可能性があるため、これらは主に重要ですそれらはごくまれにクリティカルになる可能性があります。
優先度 優先度はクライアントによって定義されたとおりです優先度はクライアントによって定義されたとおりです
潜在的な影響 機能の故障は、クライアントのビジネスに深刻な問題を引き起こす可能性があります直接的な影響を与えることはできませんが、潜在的な影響を与えることもできます。
拡張に関する考慮事項 これらのバグは、拡張機能として推奨または検討することはできません。これらのバグは、拡張機能と見なすことができます。
固定されていない場合のコスト ライブソフトウェアで問題が見つかった場合の高コストあまり費用がかからない

化粧品のバグのイラスト

外観上のバグは、ソフトウェアに会社のロゴやパートナーシップの画像があるが、正しく読み込まれていない場所で影響を与える可能性があります。これらは機能しないバグですが、深刻になる可能性があります。次の図を理解して、見た目のバグの重要性とその重要な役割を理解しましょう。

ケーススタディ

ソフトウェアAはベンダーBによって開発されています。クライアントへの成果物のモードは、基本バージョンのリリースが行われた後、毎月1回コードドロップの形式になっています。提供された製品から、クライアントは、重要度と優先度に基づいて、すべての問題、バグ、拡張機能を一覧表示します。

優先順位は次のようになります P1、P2、P3、およびP4。
臨界は次のようになります 重度、メジャー、高、低。

現在、クライアントは、すべての重大、メジャー、P1バグが30週目に修正されることを期待しています。同様に、高、P2バグは35週目に修正されます。低、P3バグの修正は、40週目に期待されます。最後に、P4バグは週に修正されると予想されます。 40.修正のすべてのリリースの間に、クライアントは3日間のバッファー期間をブロックします。

ここで、次の観察が非常に重要になります。

  • パイプラインモードとして計画されているため、遅延が発生すると、後続の計画に大きな影響を与えます。
  • 優先順位はクライアントによって形成されるため、クライアントは希望する期間にリリースする予定です。
  • 優先度の低いバグの遅延により、優先度が低いものから高いものにアップグレードされる可能性があります。
  • わずかな遅延はビジネスに深刻な影響を与える可能性があり、低いバグと小さなバグが大きな問題になります。

テスターと開発者が出会う

「孵化する前に卵を数えないでください」–この行は開発者とテスターに​​適用されます。ソフトウェアが開発され、テストの準備ができたら、テスターは上記の行を考える傾向があります。テスト後、開発者はテスターに​​行を綴る番です。 以下はそれらの間を流れる考えです：

  • テスターは、開発者があなたのソフトウェアで捕まえることができる非常に多くのバグがあると言います。したがって、あなたの仕事は終わっていません。
  • テストフェーズが完了し、多くのバグが発生した後、開発者は、あなたがこれ以上バグを提起したとは思わないと言います。私たちは、あなたが提起した本物ではないバグのほとんどを拒否する適切な理由を見つけます。

したがって、それは常にテスターと開発者の間を行き来する一種の議論の余地のあるアプローチです。プロジェクトの成果物全体が同期していることを確認するには、問題を解決できる中間者（プロジェクトマネージャー）が、成果物が最適化され、欠陥が漏れることなく絶対的になるようにすることが不可欠です。

結論

上記の記事はすべてを説明しているに違いありません 表面的なバグの避けられない重要な側面と、それを機能的なバグと比較する方法 。上記の記事では、機能的なバグと比較した場合の外観上のバグの処理方法についても説明しています。

機能的なバグの重要度は表面的なバグの重要度よりも高いですが、後者はクライアントから優先順位を取得する際に独自の場所を確保します。ソフトウェアとすべてのバグの解決策のバランスを取るために、 一般に、重要度、優先度、およびクライアントの推奨事項を理解してバグを処理することをお勧めします。

著者について： ナガラジャンが書いた記事です。彼は、手動と自動化の両方の観点から、銀行、航空会社、電気通信などのさまざまな機能分野で6年以上のテスト経験を持つテストリーダーとして働いています。

外観と機能のバグについてどう思いますか？以下にご意見をお聞かせください。

推奨読書

^