what is technical debt
技術的負債 は、金融で債務問題に遭遇する可能性があるのと同じように、ソフトウェア組織が過去のプロジェクトやバージョンリリース/スプリント中に未完成の作業の蓄積で同様の問題に遭遇することを主張する比喩的なアイデアです。
技術的負債とは何ですか？
これは、アプリケーションがリリースされたときにコードに残っている問題/欠陥を修正するために必要な作業を表しています。簡単に言うと、期待されるものと提供されるものの違いです（バグの観点から）。
残念ながら、開発チームがプロジェクトの作業とバグの修正に忙しいと、多くの新しいバグが発生します。から これらは、修正されたものもあれば、後のリリースで異なるものもあります。このような問題の違いが増えると、ある時点で問題なく製品を時間どおりにリリースすることが非常に困難になります。これはの最悪の結果です 技術的負債 時間通りに取り組まなければ。
この記事では、技術的負債とは何か、QAチームがそれについて懸念する必要がある理由、そして最も重要なのはそれを管理する方法について学びます。
画像 ソース
ウォードカニンガム 、ウィキソフトウェアの創設者、 このアイデアを思いついた 1990年代にさかのぼると、不良債権が金融業界に与える影響と類似しており、文字通り、ローンの不履行後に過剰な利子を支払わなければならないという不快な経験をほのめかしています。
Javaでグラフを実装する方法
スプリントごとに技術的負債を増やすという課題は、図1で視覚化できます。
ここで言及する必要があるのは、技術的負債（コード債務または設計債務とも呼ばれる）の意味が、金融の世界における対応するアナロジーとわずかに異なることです。前者は、 抽象的なアイデア 、関心が実際にどのように蓄積されるかを視覚化するための数式はありません。
図1：スプリント全体での技術的負債のスケーラブルな増加の視覚化
学習内容：
QAチームが技術的負債のために最も苦しむ理由
典型的なソフトウェアの設計と開発のサイクルでは、「 技術的負債 」のような状況– 不適切なドキュメント 、 不十分なテスト とバグ修正、 調整の欠如 チーム間、 レガシー コードと 遅延リファクタリング 、不在 継続的インテグレーション およびその他の制御不能な要因。
例えば、コードの複製作業は、 25 に 35％ 残業。
Webアプリケーション用のオープンソース自動化テストツール
しかし、どこにもありません QAテストよりも明らかな技術的負債による課題 テストチームが予期しない期限を守らなければならず、すべてがギアから外れる可能性があります。
予期せぬことに、配達マネージャーが来て、テスターに次のように言った最後の瞬間に、テスターが苦境に直面した頻度はどれくらいですか。 1週間以内に製品を展開する必要があります。これを間に合わせることができず、申し訳ありません。デモの準備ができるように、すべてのテストタスクを早急に終了してください。」
基本的に、失敗したテストまたは「後で解決する」アプローチは、問題のような技術的負債につながる可能性があります。 テストカバレッジの欠如 、特大のユーザーストーリー、短いスプリント、および配信圧力による「コーナーの削減」の他の例は、QAプラクティスにおける技術的負債の蓄積の背後にある大きな役割を果たします。
実際の例
複数のウェブサイトやモバイルアプリで大きな存在感を示している米国を拠点とするオンライン小売業者は、テストメッシュの複雑さが新しいものごとに複雑になり始めたときに、現実の「技術的負債」の課題に直面しました。 スプリント 。
これは、テストするモバイルデバイスの数が急増し、複数の言語がサポートされ、6つ以上のソーシャルネットワーキングサイトが活用されるために発生しました。
自動化カバレッジが40％未満の場合、 技術的負債の課題は、次のように表示されます。
- リリーステストでの過度の時間消費 –テストスプリントごとにブラウザー、デバイス、およびスクリプトの数が増えると、リリースサイクルが遅れ続け、市場投入までの時間が失われます。
- 雇用コストの増加 –プロジェクトをサポートするために必要なテスターの数は、ほぼ2倍になり、50万ドルの追加コストになりました。
- プロジェクトの複雑さ –プロジェクトの複雑さが増すにつれて、テストケースとバグを追跡することが課題になりました。
- 誤検知を追跡するのに時間がかかりすぎる –繰り返しになりますが、プロジェクトの複雑さの増大による影響です。
- テスト開発の労力が最大60％増加 –それは領土に行きます
QAプラクティスにおける技術的負債管理
ほとんどのQAマネージャーは、技術的負債を現在のスプリントだけに全力を注ぐことの合理的な結果と衝動的に見なします。これにより、手動でテストカバレッジを達成し、自動化を完全に無視します。
これは、 迅速で汚いアプローチ これは、著者のMartinFowlerによるブログで取り上げられています。 技術的負債象限 。
アジャイルの原則は、技術的負債の問題を支持し、満たすことができないこととして視覚化することを指示しています QAベンチマーク 。
実際には、 調査に基づく 米国国立標準技術研究所（NIST）によると、不十分なテストツールと方法は、米国経済に毎年コストをかけています。 $ 22.2 そして 595億ドル 、このお金の約半分はソフトウェア開発者による追加のテストに費やされ、約半分は失敗を避けるためにソフトウェアユーザーによって費やされました。
インシデントが発生したときに障害に対応する代わりに、プロアクティブなアプローチは、測定可能なすべてのアクティビティまたはタスクの後に欠陥を特定することです。すべてを手動で行うことができますが、平均的なプロジェクトの何千ものテストケースシナリオを考えると、自動化されたテスト制御が必要です。
明らかに、 効果的なテスト 技術的負債との戦いで深刻な地盤を築くのに役立ちます。それで、それは基本的にどういう意味ですか？これは、システムがアプリケーション全体の欠陥を特定するのにどれだけ設備が整っているかを意味します。
上記の式が示すように、顧客が見つけた欠陥（つまり、製造後の欠陥）の数が、テストカバレッジの各段階で見つかった欠陥の数に正確にマッピングされていれば、テストケースの有効性は理論的には100％に近づく可能性があります。
欠陥が忍び寄るとすぐに正確に測定できる、適切に設計されたテストベッドを用意するには、自動化が前提条件です。
ユーザー受け入れテスト（uat）
自動化のテスト 結果を報告し、以前のテスト実行と比較することで、実行されるスクリプトの数を最小限に抑えることができます。自動化を実行するために使用されている方法またはプロセスは、テストと呼ばれます オートメーション フレームワーク 。
典型的な例は、Selenium、MonkeyTalk、などの市販または無料のツールです。 ロボット 、Borland SilkCentral、HP Quality Center、および IBM Rational Rose 。
これまで、QA /テストは、組織とそのソフトウェアチームによって、より重要なビジネス成果物へのサポートアクティビティと見なされることが多く、コアで専用の焦点を必要とするそれ自体の規律ある実践ではありませんでした。実際、QA /テストへの非中核的なアプローチは、そもそも技術的負債の継続的な課題につながったものです。
過去10年間に発生したQA /テストスキルの急速な進化を考えると、組織はスキルと能力を現在の業界ベンチマークに従って必要な最小レベルにアップグレードするのに非常に苦労しています。
実際、テスト自動化の最も熟練した専門家に他ならないという業界の傾向が高まっています。これは、テスト/ QAのエリートコマンドのようなものです。彼らはテスト中のソフトウェアエンジニアとして知られています（ 以来 ）およびテスト中のソフトウェア開発者（ SDiT ）。これらの専門家は、選択された業種（eコマースなど）または特定の専門家カテゴリでの豊富な経験により、高い需要があります。
現在お話ししているように、ほとんどのソフトウェアおよび製品開発会社は、納期の短縮に直面して、必要な適格な技術リソースを見つけるのに苦労しています。この課題の解決策は、SDiT / SEiTリソースの適切なプールでスキル不足に対処できるオフショアQA自動化プレーヤーと提携することです。
QA /テストにおけるアウトソーシングプレーヤーのその他の望ましい属性には、プロジェクト実行へのアジャイルで統制のとれたアプローチ、再利用可能な自動化フレームワークとテストケースへの実践的なアクセスを含む十分な業界経験、そして最後になりましたが、明確な意図が含まれます。クライアントが請負業者を管理するための余分な作業に負担をかけないように、リモートチームの課題や文化的な衝突に対処する能力。
結論
他の債務と同様に、技術的債務は企業の悩みの種であることが証明される可能性があり、その蓄積の根本的な原因は、自動化のすべてのバックログを取り除くプロアクティブなQAプラクティスの実装の失敗です。
著者について： これはeInfochipsチームによるゲスト投稿です。彼らはと呼ばれるユニークなアプローチを考え出しました 技術的負債ゼロ これは、QA /自動化活動における技術的負債を徐々に解消するための最も構造化された効率的な方法の1つです。技術的負債についてもっと知るために、 このビデオを見て 技術部門を削減するためのアプローチについて。
技術的負債とは何かについて明確な考えが得られることを願っています。それに関連する質問がある場合、または実際にそれを管理する方法をお知らせください。
推奨読書
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- 間もなく288億ドルに達するグローバルソフトウェアテストビジネス
- 初心者テスターのためのソフトウェアテストのアドバイス
- ソフトウェアテスターでモチベーションを維持する方法は？
- Zenとソフトウェアテストの芸術
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- 2008年の最高のソフトウェアテスト記事
- ソフトウェアテストQAアシスタントジョブ