テストプロセスでギャップ分析を使用して、開発者とテスターを整列させる

開発者とテスターがチョークやチーズのように乗ることは広く信じられています。 開発者はしばしばテスターを見下ろし、バグチケットに明確な詳細を提供できない新しいコードの開発に柔軟性がなく、役に立たないドラッグと見ています。 同様に、テスターは、コードの変更を通知しないことや、テストサイクル中に新しい変更をプッシュすることに対する刺激を開発者に見ています。 このため、QAテストプロセスにおけるギャップ分析は、開発者とテスターの両方を整列させるために特に有益です。

このビューは外典かもしれませんが、開発者とテスターがうまくコミュニケーションを取らないことがよくあります。 多くの場合、通信は管理(プロジェクトマネージャーとラインマネージャー)またはJiraのチケットを介してのみ行われます。 その結果、テストはしばしば不十分であることが判明します。 特に、あまりにも頻繁に新しいコードが不十分にテストされているか、まったくテストされていません。 調査によると、このテストされていない新しいコードが将来のバグや失敗の最大の原因であることが示されています。 これはテストギャップの分析の概念が演劇に入って来るところである。

このブログでは、テストギャップ分析とは何かを探り、テストする必要があるコードを特定するのにどのように役立つかを示し、このアプローチが開発者とテスタの間のギャップを埋めることができる万能薬であるかどうかを探ります。

テストギャップ分析とは何ですか?

最初にソフトウェアシステムを開発するとき、システム全体をテストしていることを確認するのは簡単です。 テスターは、コード仕様を取得し、計画テストと探索テストの組み合わせを使用して、コードベースのすべての可動部分をテストすることができます。 しかし、ほとんどのソフトウェアは静的ではありません。 企業は、長寿命のコードのモノリシックな定期的なリリースを行うか、またはある程度の継続的な統合と継続的な展開(CI/CD)を採用しています。 いずれの場合も、コードベースは常に変化しています。 しかし、テストケースが同じ速度で更新されないことがあまりにも頻繁にあります。 時には、テスターは単にコードの変更が行われたことを知らないことがあります。 それ以外の場合は、特定のテストセットが実行された直後にコード変更がプッシュされます。 これらのテストは合格したように見えますが、コードの変更によってそれらが壊れている可能性があります。

テストギャップ分析は、新しいコードが展開されているが、まだテストされていないこれらのギャップを識別するプロセスです。 これには、すべてのコード変更の静的解析と、現在のすべてのテストの動的解析の組み合わせが必要です。 これらの2つの分析を比較することで、ギャップがどこにあるかを簡単に確認できます。 つまり、適切にテストされた新しいコードの領域です。 通常、これは、コードが機能ブロックに分割され、各ブロックの下に構成クラスがあり、その下に実際のメソッドと関数があるツリー図の形式を使用してコードをプロットすることによって行われます。 階層内の各レベルで、ブロックの相対サイズはコードの量を示します。 コードの変更を示すツリーとテストの現在の状態を示すツリーを重ねることで、テストカバレッジが欠落している領域を簡単に見つけることができます。

開発者とテスターの間のギャップを埋める。 テストギャップ分析は解決策ですか?

変更されていないコード(灰色)、テストされている改訂/新しいコード(緑)、テストされていない改訂されたコード(オレンジ)、テストされていない新しいコード(赤)を

なぜテストギャップ分析がテストプロセスで重要なのでしょうか?

2013年の論文で、ミュンヘン工科大学の研究者は、テストされていない新しいコードと将来のソフトウェアバグとの相関を調べるための研究を行った。 彼らはミュンヘンRe(大規模な保険会社)と協力し、2つのリリースを通じて長寿命のITシステムを監視しました。 リリース中、彼らはどのコードが新しいかを確立し、どのコードがテストされ、どのコードがテストされていないかを調べました。 その後、彼らは長い間システムを監視し、報告されたすべてのバグを元のソースに追跡しました。 彼らは二つの重要なことを発見しました。 まず、すべてのコードの約3分の1がテストされていない状態でリリースされていました。 第二に、彼らがバグを追跡したとき、彼らはすべてのバグの70と80%の間で全体的に発見したバグはテストされていないコードにありました。 下のグラフは、これをより明確に示しています。

開発者とテスターの間のギャップを埋める。 テストギャップ分析は解決策ですか?

ご覧のように、古いテストされたコードにはバグはありませんでした。 新しいテストされたコードにはバグの22%から30%があり、残りのバグは新しいテストされていないコードと古いテストされていないコードの間でかなり ただし、新しいコードはコード全体の15%しか占めていないため、テストされていない新しいコードが不釣り合いに多くのバグを占めていることがわかります。

テストギャップ分析は、このテストされていない新しいコードを識別するように設計されています。 しかし、それはまた、他の方法であなたを助けることができます。 たとえば、テストしているものを監視するため、古い既存のコードの領域を識別する可能性があります(たとえば、まだテストされていますが、実際にはコー また、テストリソースを集中する必要がある領域を強調表示することもできます。 定期的に実行することで、管理者はテスト計画を改善し、新しいコードのテストに焦点を当て、テストカバレッジを確実にしようとすることができま

テストギャップ分析によって調整された開発者とテスター

テストギャップ分析は明らかに強力な概念です。 しかし、すべてのチームがそれから均等に利益を得るわけではないことも明らかです。 最も恩恵を受けるチームは、定期的なモノリシックリリースで長寿命のコードベースを維持している人です。 長寿命のコードベースでは、開発者は他の人によって書かれたコードに取り組んでいることがよくあります。 テスターは、前にいくつかのバージョンを生成したテスト計画に依存することができます。 これらの要因を組み合わせると、どのコードがテストされているのか、そのコードがシステムの他の部分とどのように相互作用するのか、誰も明確ではな ここで、tgaはテスターがどのコードが変更されたかを正確に見ることができ、これに焦点を当てることができます。 また、テストされていない既存のシステム内のコードを識別することもできます。

CI/CDを使用しているチームは、テスターが変更されたコードを正確に迅速に識別し、それに集中できるようにするため、このアプローチの恩恵を受けるこ また、コードの一部がテストされた直後に変更され、テストされていない変更でリリースされるという上記の問題を回避することもできます。

一方、新しいコードや短命のコードに取り組んでいるチームは、定義上、ほとんどのコードは最初はテストされないため、利益は少なくなります。 ここでは、テストが良好であることを確認するために標準的なテスト方法論を使用することが重要です。 ただし、そのようなチームがTGAを使用してテストカバレッジの監視を開始すると、将来の問題を回避できるため、有用である可能性があります。

潜在的な問題は何ですか?

TGAにはいくつかの問題があります。 最大のものの1つは、コードベースでどのコードが積極的に呼び出されているかを伝えることができないという事実に関連しています。 開発者は、多くの場合、将来のリリースの準備のために新しいコードを追加しますが、これは非アクティブであるため、テストスイートはそれを呼び出 その結果、このコードは常にテストされていない新しいコードとして表示されます。 同様に、多くの大規模なコードベースには、古いコードまたは孤立したコードのブロックが含まれています。 これらは定期的にクリーンアップする必要がありますが、再びこれらは、テストギャップ分析のための画像を歪めます。

もう一つの重要な観察は、コードがテストされているからといって、そのコードが他の場所でバグを引き起こすことを妨げないということです。 最悪のバグのいくつかは、コードの一部の小さな変更が完全に無関係なコードブロックで関数またはメソッドが失敗する原因となるバグです。 したがって、探索的テストと回帰テストの両方を継続することが不可欠です。 TGAができることは、回帰テスト中に適切にテストされていない既存のコードベース内の領域を特定することです。

他にどのような選択肢がギャップを埋めるのに役立ちますか?

テストギャップ分析は間違いなくいくつかのチームにとって便利なツールです。 ただし、テスターがテストしている内容とコーダーがコーディングしている内容の不一致を回避する方法は他にもあります。 一つの方法は、フロントエンドだけでなく、重要なのはバックエンドの両方で、物事がいつどこで変更されたかを識別することができる、よりインテリジェントなテスト自動化を使用することです。 ここFunctionizeでは、私たちのテストは、機械学習と自己修復と組み合わせたインテリジェントな指紋を使用して、テストの保守を削減します。 これにより、テストはフロントエンドの変更に積極的に適応するだけでなく、サーバーコール、応答時間、ボタン/機能が実際に表示されているかどうかなどの これは、バックエンドコードの変更やフロントエンドレイアウトを変更するデザイン/CSSの変更によってテスターが捕まることがないことを意味します。

私たちのインテリジェントシステムは、ユーザーがシステムとどのように対話しているかを監視することによ これにより、テストカバレッジのギャップが少なくなります。 私たちの最新のツールの一つは、あなたが平易な英語で新しいテストを書くことができます。 これらは自然言語処理ツールによって解析され、使用可能なテストに変換されます。 これは、開発中に、開発者は通常の英語を使用してテストする必要があるものを単に指定することができることを意味し、このように二つの分野の間のギャップをさらに埋めることができることを意味します。

結論

テストギャップ分析は、テストされていないリリースされているコードを特定するのに役立ち、テストリソースをより効果的に集中させるのに役立 当然のことながら、テストされていないコードにはバグが含まれている可能性がはるかに高いため、このコードが適切にテストされていることを確認 しかし、私たちが見てきたように、TGAは既存のベストプラクティスを補うことしかできません。 回帰テストと探索的テストを維持することが不可欠です。 Tgaの利点の多くは、インテリジェントなテストツールを使用することによっても達成できます。 しかし、全体的に、避けるべき主なことは、テストチームを開発者の作業から分離することです。 古い格言を誤って引用するには、左手が右手が何をしているかを知っていることを確認する必要があります!

Leave a Reply