バグを毎日見つけられない場合、QA チームはソフトウェア開発で何をしますか?

公開: 2023-01-27

品質保証 (QA) エンジニアは、次のようなことをよく耳にします。

「あなたのチームは昨日 20 個のバグを検出しましたが、今日は 1 個もありません!」

このスタンスは、一見妥当に見えるかもしれませんが、ソフトウェア開発における品質保証の目的と目標そのものと矛盾しています。

QA はソフトウェア開発で正確に何をしますか?

この記事では、ITRex の QA ユニットの副責任者である Andrey Gilyov が、バグが少なくても QA チームが怠けていない理由を説明します。 また、ソフトウェア エンジニアがコードをテストする代わりに、QA エンジニアを常に雇って社内または外部委託の IT チームを補強する必要がある理由も学びます。

QA の目標と、それがバグ追跡に限定されない理由を理解する

構築しようとしているソフトウェア ソリューションの種類と複雑さによっては、パートタイムの QA スペシャリストまたはプロジェクトに割り当てられた専任の QA チームが必要になる場合があります。 彼らの責任は、バグを特定してプロジェクト マネージャーや開発チームに報告するだけではありません。

特に、品質保証の目標は次の範囲に及びます。

  • エラー防止。 最近の調査によると、ソフトウェア エンジニアは時間の約 20% をバグ修正に費やしています。 その時間を平均的なソフトウェア エンジニアの時給で掛けると、欠陥のあるコードが会社にどれだけの損害を与えるかがわかります。 エラーを修正するコストも、ソフトウェア開発ワークフローの時間とともに指数関数的に増加します。セキュリティの脆弱性、カスタマー エクスペリエンスの低下、評判の低下など、バグの多いソフトウェアを本番環境にリリースすることの長期的な影響は言うまでもありません。 そのため、ソフトウェア開発における品質保証の主な目的は、重大な損害が発生する前にバグを見つけることです。 この偉業を達成するために、QA チームは、ソフトウェア ソリューションを手に入れるずっと前に、テストの準備をします。 これらの準備作業には、テスト ドキュメントの確認、テスト計画とテスト ケースの作成、適切なテスト ツールの選択、およびテスト環境の構成が含まれます。
  • ソフトウェア ステータスの追跡と評価。 ソフトウェア プロジェクトで十分な情報に基づいた意思決定を行うために、プロジェクト マネージャーとクライアントは、作業中のソフトウェア製品に関する最新情報を必要とします。 品質保証の目標には、とりわけ、ソフトウェア プロジェクトのタイムラインに沿って任意の期間にこの情報を提供することが含まれます。 ただし、品質保証エンジニアは、ソフトウェア ソリューションを稼働させるのに最適な時期を選択しないことに注意してください。 代わりに、最終決定を下すのはお客様です。 QA チームに相談したクライアントは、文書化されたバグやエラーを含むソフトウェア ソリューションを展開することさえ決定する場合があります。 たとえば、製品をリリースするための時間枠が比較的タイトで、競合他社をしのぐか、重要な機能を有効にするかという報酬の間のトレードオフが、マイナーなバグで製品をリリースするリスクよりも大きい場合に、このような決定を下すことができます。 いずれにせよ、これらのバグを検出し、文書化し、優先順位を付ける必要があります。これは、QA チームの目標の 1 つでもあります。
  • 要件の検証。 ソフトウェア開発における QA の主な役割は、ソフトウェア ソリューションが期待どおりに機能し、ソフトウェア要件仕様 (SRS) ドキュメントで定義されたすべての基準を満たしていることを確認することです。 品質保証スペシャリストが手動または自動テストを実行してバグを特定する場合、開発チームのために Jira や ClickUp などのバグ追跡ソフトウェア システムでチケットを作成します。 開発チームがエラーを修正すると、テスト サイクルが繰り返されます。 したがって、バグを見つけることは品質保証の目的ではありません。 むしろ、これは QA 活動の副産物です。

QA チームがバグを見つけられないことがあります。 そして、それは大丈夫です

QA の目標と目的について理解できたので、この記事の冒頭で提起した質問に戻りましょう。

バグレポートに何日も欠陥が含まれていない場合、QAチームはソフトウェア開発で何をしますか?

QA スペシャリストがソフトウェアのバグを見つけられない理由はいくつかあります。

  1. ソフトウェアは徹底的にテストされています。 ソフトウェア ソリューションが徹底的にテストされている場合、QA サイクルが繰り返されるときや製品が生産に移行するときにバグが存在する可能性は低くなります。
  2. ソフトウェアはシンプルなデザインです。 限られた機能セット、統合、および単純なユーザー インターフェイスを備えたアプリケーションは、より複雑なアーキテクチャとパフォーマンス要件を持つソフトウェアよりもバグを含む可能性が低くなります。
  3. ソフトウェアは、ベスト プラクティスを使用して構築されています。 クリーンで十分に文書化されたコードを記述し、コーディング標準に従い、バージョン管理を使用するソフトウェア エンジニアリング チームは、多くの場合、エラーの少ないソフトウェア製品を提供します。 これらのバグは、テスト プロセスの早い段階で検出および修正され、後の段階でそれ以上の欠陥が現れることはありません。
  4. テスト プロセスは、より包括的であった可能性があります。 時間、リソース、またはスキルが不足していると、QA スペシャリストがソフトウェア ソリューションを完全にテストできなくなる可能性があります。 その結果、一部のエラーが見落とされる可能性があります。
  5. バグは再現できません。 エラーが一貫して発生しないため、QA スペシャリストがバグを見つけられない場合があります。 ソフトウェアの複雑さ、サードパーティ ライブラリの使用、または外部依存関係の存在など、さまざまな要因がこのような状況につながる可能性があります。

原因が何であれ、ソフトウェア開発における QA の重要性を過小評価してはなりません。開発者がコードをテストできるようにするという考えをもてあそんではいけません。

誤解しないでほしいのですが、開発者が機能横断的なアジャイル チームで自動化されたテストを作成して実行することは問題ありません。 または、ソフトウェアを手動でテストすることもできます。

ただし、プロジェクトの役割が共有されることが多いこのようなチームでは、主な目標は、動作するソフトウェアまたは機能をより迅速にリリースし、価値実現までの時間を短縮し、早い段階でフィードバックを収集することです。 ここでは、前のセクションで説明したリスク対報酬の問題を扱っている可能性があります。 そのため、プロジェクトに技術的負債が蓄積され、将来的にパフォーマンスの問題や大幅なデバッグ コストが発生する可能性があります。

専任の QA スペシャリストを採用するその他の理由は次のとおりです。

  • コーディング方法を知っていることは、潜在的なエラーについてコードを確認する方法を知っていることと同じではありません
  • 開発者はめったにテストを楽しみませんが、QA の専門家はそうします
  • ソフトウェア エンジニアの時給は、通常、品質保証スペシャリストの時給よりも高くなります。
  • 通常、開発者と QA エンジニアは異なるソフト スキルを持っています。 QA では、細部への注意、複雑なシステムを分析する能力、およびマルチタスキングが主役になります。 一方、ソフトウェア エンジニアは共同作業環境で作業し、一度に 1 つのタスクに集中することがよくあります。

そのため、QA チームが今日バグをまったく発見できなかったとしても、品質保証の専門家を解雇したり、テスト タスクを主要な開発チームに任せたりしないでください。 このアプローチは短期的には給料を下げる可能性がありますが、ソフトウェアのパフォーマンスの低下やバグ関連のサイバー攻撃が原因で顧客を失うコストは何倍にもなる可能性があります.

また、ソフトウェアが適切に機能し、SRS または技術的ビジョンで指定されたすべての要件を満たし、ビジネス目標の達成に役立つことを検証する支援が必要な場合は、ITRex QA の専門家にお問い合わせください!

2023 年 1 月 20 日に https://itrexgroup.com で最初に公開されました。