2022年DevOpsにおけるテストの状況

2022年度版 「DevOps におけるテストの実態調査報告書」は、ソフトウェア開発、ソフトウェア品質管理、エンジニアリングリーダーなど品質の専門家560人のインサイトに基づいています。回答者の大半(約72%)が何らかの形で品質関連の職務に就いており、DevOpsにおける品質とテストの進化における実態を高精度で把握できました。またDevOpsと品質の現状について、開発者やエンジニアリングリーダーから多岐にわたる実態を包括的に知る機会を得られました。

回答者の組織規模の内訳は、小規模企業＆スタートアップ、従業員500名までの中規模企業、2000名までの中堅企業から2000名超の従業員を抱える大企業まで、ほぼ均等に分散しており、品質戦略とDevOps採用があらゆる規模の組織を変革していることが伺えます。従業員数が2000人以上の大企業の数は、小規模企業＆スタートアップとほぼ同数で、回答者の28%を占め、従業員501〜2000人の中堅企業が最も少なく回答者全体の21%でした。

回答者のほぼ半数(43%) がソフトウェア、ハードウェア、先端技術業界に従事しており、金融サービス、銀行や製造業などのデジタルトランスフォーメーションが普及している業界からの回答者も多く見られました。保険とメディア＆エンターテインメント業界の回答者が全体の4%を占め、小売、運輸、政府期間、旅行＆ホスピタリティ、エネルギー業界が3%となっています。他に、非営利団体、通信、不動産、建設、農業に従事している回答者もいました。

回答者の役割や所属する企業の規模や業界は多岐に渡り、DevOps採用の現状を把握できています。

あらゆる規模の組織が自動化したパイプラインを備えたDevOpsの完全採用に向けて動いていますが、その進捗状況は企業規模により大きく異なっていました。大企業はDevOps採用と成熟度で群を抜いており、40%が自動化されたパイプラインを備えてDevOpsを完全に採用していると回答しています。多くの大企業がDevOpsをほぼ採用している、またはDevOpsトランスフォーメーションに移行中であると答えた一方で、DevOpsを完全採用していると答えた中堅企業はわずか11%、中規模企業は22%でした。

興味深いことに、小規模企業の1/4以上(27%) がDevOpsを完全採用し、開発パイプラインを完全に自動化していると答えたものの、その半数以上(51%)がDevOpsの進捗状況にわからないと回答しています。一方で、DevOpsの進捗状況に疑問を持つ大企業はわずか18%、中堅企業では20%、中規模企業では10%でした。大企業(31%) 、中堅企業(27%) 、中規模企業(29%)の約1/3は組織がDevOps移行中であると考えており、どの規模の企業もDevOpsトランスフォーメーションへの移行に強い関心を示していると伺えます。 

2021年と2022年を比較すると、DevOpsトランスフォーメーションの各段階における企業の割合はほぼ変化がありません。自動化パイプラインを用いてDevOpsを完全採用したと考える組織の数はわずかに増加したものの、一方で「ほぼ採用」および「移行予定」とする組織の数が減っています。両年で安定した数を保っていたのが、トランスフォーメーションへの途中である「移行中」の組織でした。

DevOps採用の核となる部分は、パイプラインの自動化です。当然ながら、アンケート回答者が属する組織の自動化の採用は、DevOps採用率と密接に関連しています。

「移行予定」と答えたDevOps採用の初期段階にある企業は、パイプラインの一部しか自動化されていない傾向が強く、うち51%がパイプラインのワークフローをほぼ自動化していないと報告しています。DevOps移行中の企業は、主要なワークフローの一部のみを自動化している可能性が最も高いという結果になりました。DevOpsプラクティスを成熟させ始めている組織では、パイプラインがほぼ/完全に自動化している傾向が高くなっています。DevOpsをほぼ採用しているとする企業の45%ではパイプラインの大部分が自動化されており、DevOpsの完全採用が完了している企業の41%ではパイプラインが完全に自動化されています。DevOpsを完全採用している組織で自動化されたワークフローがほぼないと答えたのは、わずか11%に過ぎませんでした。今まさに自動化はこれまで以上にDevOpsの採用につながっているのです。

では、企業がDevOpsの可能性を最大限に引き出す阻害要因は何でしょうか？変化のプロセスの遅さ (26%) 、優先順位付けの欠如(15%) 、リーダーシップの欠如 (14%) などの文化的要因は、DevOpsを実際に行う人々のフラストレーションの元になっています。技術的な制限(18%)と予算の制約 (17%) は、DevOps採用を妨げてはいますが、回答者はそれよりも人とプロセスが大きな要因であるとしており、65%が文化的な課題が主な障害としています。(なお、DevOps採用の阻害要因を広く理解するために、このセクションは複数回答可としています)

企業規模によって阻害要因の分布は多少違うものの、いくつかの共通点も見られました。

回答者の85%は、DevOpsが自社の優先事項であるとしながらも、変化し続けることが採用の最大の課題であると答えています。変化のプロセスの遅さが、大企業、中堅企業、中規模企業の課題となっており、予算への懸念と社内における専門知識の不足を上回っています。100人未満の小規模企業とスタートアップは例外で、優先順位付けの欠如が DevOpsの大きな障害であると答える傾向があります。 

企業規模に関係なく、リーダーシップとチェンジマネジメントは、引き続きDevOpsトランスフォーメーションの最大の阻害要因となっています。

DevOps採用の阻害要因が過去1年間でどのように変化したかを見てみると、いくつかの楽観的な兆しがあります。まず、予算の制約に対する懸念は、2021年には21%と2番目に多かったのですが、2022年には17%に下がっています。また、多くの回答者が、社内政治と変化の遅さ、とりわけ変化の遅さが依然として問題であるとするものの、2022年には、さほど大きな問題ではなくなっていると答えています。

2022 年には、回答の選択肢に「リーダーシップの欠如／社内の専門知識の不足」を追加したところ、4番目の阻害原因として、「優先順位付けの欠如」と並びました。2021年と同様に2022年にも、DevOpsにとって大切なのは技術的要素ではなく人的要素であると分かりました。昨年同様、回答者の72%が、技術的な制限はDevOpsトランスフォーメーションの阻害要因ではないと述べています。つまり、DevOps の最大の障害や課題となっているのは、より良いプロセスを通じてどうやって人に力を与えるか、ということになります。 

回答者の75%が全体的なデプロイ頻度の増加を報告しています。それはDevOpsトランスフォーメーション、自動化の採用にどう関係があるのでしょうか？ DevOps開発プラクティスでパイプラインを高度に自動化している企業は、過去1年間、自動化したワークフローがほぼない企業に比べるとデプロイ頻度が倍になっています。 つまり、パイプラインの自動化がデプロイの加速化につながっているのです。

DevOpsを完全採用した組織は、1日に複数回デプロイする傾向が5倍以上高く、そのうち年1回または半年に1回のデプロイを行なっている企業はありませんでした。対照的に、意欲的なDevOpsチームは、完全なDevOpsチームよりも四半期単位でデプロイする可能性が3倍高い結果になりました。多くの企業が2022年にデプロイ頻度を増やしています。DevOpsプラクティスが成熟し、より多くのパイプラインが自動化されるにつれて、より多くの企業が毎週または毎日デプロイできるようになるでしょう。

過去3年間を見ると、デプロイ頻度に対する新型コロナ感染拡大の影響が明らかとなっています。2020年に毎週または毎日デプロイをする組織が急増しており、デジタルファーストな顧客体験が標準となるにつれて、多くの組織がデプロイサイクルを調整したことを示しています。対面でのコミュニケーションが日常に戻りつつある中、デプロイ頻度も変わりました。2022 年には、4社に1社が少なくとも週1のデプロイを、 18%のチームが隔週のデプロイをしています。ただし、多くの企業は、未だに月毎か四半期毎のデプロイというスケジュールを保っています

データによると、移行がまだ初期段階であっても、DevOpsの採用はデプロイ頻度の増加に大きな影響を与えることがわかります。DevOpsへの移行を進めているチームは、これからDevOpsへの移行を始めるチームに比べて、1年間のデプロイ頻度が4.75倍も高くなっています。デプロイ頻度を上げることは、デジタルファーストの顧客エクスペリエンスに対応でき、顧客満足度向上につながるので、DevOpsの成功を測るための重要な指標といえます。

デプロイ頻度が上がることで可能になるアジリティ(俊敏性)は、高い顧客満足度との相関性が高いと分かっています。デプロイ頻度を維持した企業のわずか13%が高い顧客満足度を得ています。デプロイ頻度を 50〜100% 増加させた企業では、否定的なユーザー感情よりも、肯定的な顧客体験が報告される傾向が約2.5倍ありました。

デプロイ頻度を25%以上増加させた回答者のほとんど (64%) が、パイプラインの一部または全体を自動化しています。一方で、デプロイ頻度を50~100%以上増加させたと回答したチームでは、パイプライン自動化の有無はほぼ均等となりました。しかし、昨年デプロイメント速度が2倍以上になったと回答したチームでは、全てを自動化／大半を自動化されている割合が1.5倍になっています。パイプラインの自動化が明らかにデプロイ頻度の改善に役立っています。

言うまでもなく、デリバリーサイクルを加速化している企業にとって、確実な品質でのデプロイは成功を左右する大きな要素です。新しいデプロイでバグ発生のリスクが高ければ、企業にも顧客にもネガティブな影響があります。しかし、昨今、ソフトウェアテストに関わる役割が多様化しているのは良い傾向だと言えるでしょう。QAの専門家と手動テスト担当者が65%を占めており、自動化エンジニア、開発者、ソフトウェアエンジニアがそれに続きます。回答者の4人に1人が、組織内の全員がテストに関わっていると報告しており、多数の企業がソフトウェア開発文化に品質を組み込んでいることが分かります。

品質の専門家たちは誰でも、「テスト」と聞くとすぐに、計画から管理、メンテナンスやレポート、分析、そしてテスト実行まで、幅広いタスクを含むことを知っています。テスターがどこに時間を費やしているかを確認するために、アンケートの回答者に、最も時間がかかるタスクにランクを付けてもらいました。テストの計画とテストケース管理は最も時間のかかるタスクであると考えられており、回答者の56%が1位か2位にあげています。次に多かったのがテストメンテナンスで、回答者の39%が1位か2位に選んでいます。

テストの実行(29%)とテストカバレッジの追加(28%)が3位に並び、テスト分析(26%)と不具合報告(22%)をわずかに上回りました。回答者の35%が不具合の報告・修正は、最も時間のかからないタスクとして選びました。テストカバレッジの向上が重要な一方で、テストメンテナンスがより多くのリソースを必要とすることが分かりました。

アンケート結果から、QA業務は主に内部(社内)で対応していることが分かりました。QAの一部を外部委託していると答えたのは半分に満たず(40%)、1/3(35%)強の企業が、すべてのQA業務を社内で処理していると答えています。QAを完全に外部委託している企業はわずか7%で、QAの大部分を社外に委託している企業は14%でした。全体的に多くの開発企業がQA作業の全て〜ほぼ全てを自社内で対応していることが分かりました。

一般的にQAを社外に委託しているテストは、セキュリティテストとUIテスト／機能テストですが、社外に委託されがちなテストとして特に目立ったものはありませんでした。APIテスト、パフォーマンステスト／負荷テスト、リグレッションテスト、インテグレーションテストは社外に委託されることが多く、社外に委託をしている企業は幅広い種類のテストを社外のリソースに任せていることが分かります。

さまざまなテストがさまざまな職種で実行されていることから、デプロイ頻度が増加するに従って、品質とテスト戦略がいかに成長しているかを知ることができます。 

テストカバレッジは、アプリケーションやWebサイトがどの程度ソフトウェアテスト戦略でカバーされているかを追跡するため、多くのソフトウェア開発企業にとって、テストの成功を測る重要な指標です。多くの企業は高いテストカバレッジを求めますが、実際には100％のカバレッジはテスト時間とリソースを非効率に使うだけで、達成が不可能なだけでなく、目指すべきではありません。

しかし、デプロイ頻度が上がるにつれ、最適なレベルのテストカバレッジを維持することが課題となっています。新機能が導入されるたびに、品質チームはテスト作業を調整・拡張し、想定できるカスタマージャーニーがあらゆる点で機能していることを確認する必要があります。デプロイが頻繁になればなるほど、効率的なテストが品質維持の鍵となります。 

テストのペースとデプロイ頻度の関係を考えると、デプロイ頻度の増加を報告した多くの企業が優れたテストカバレッジも確保しているのは当然と言えます。デプロイ頻度を 50〜100%上げた企業は、テストカバレッジのレベルが優れている傾向が3倍も高くなっています。これらの企業はデプロイ頻度が高く、本番環境でバグが発見される可能性が高いにもかかわらず、実際には、品質に対する顧客の期待を超える結果を出しています。

パイプラインの自動化が進むにつれ、テストカバレッジも向上しているようです。企業のテストカバレッジが「良い／非常に良い」とした回答者は、パイプライン上のすべてのワークフローが自動化されていると答える傾向が7倍高くなっています。それに対して、自動化されたワークフローがほとんどないチームは、テストカバレッジがほぼゼロである可能性が約4倍という結果になりました。テストカバレッジの向上もパイプラインの自動化も、DevOps の採用を成功させるための重要な要素であり、報告書の後半でも説明しますが、最終的に顧客満足度の向上につながるのです。

2023年に自動テストをどのように拡張するか尋ねたところ、回答者はAPIテストを優先し、43%が自動APIテストを導入する予定であると答えました。ソフトウェア開発でAPIの開発・利用が急増し、APIテストをすべて手動で行うのは無理があることを考えると、品質の専門家が自動APIテストの導入に強い関心を持っているのは当然と言えます。

次に多かった回答は、リグレッションテスト(40%)、エンドツーエンドUIテスト(37%)、UI/機能テスト(32%)で、カスタマーエクスペリエンスを反映したルーチンテストの自動化への興味が現れています。自動化されたパフォーマンステストや負荷テスト、アクセシビリティなどの非機能テストも2023年に自動化したい要望が多く、29%が自動パフォーマンステストの導入に、21%がアクセシビリティテストの自動化に興味を示しています。

DevOpsにおけるソフトウェアテストの現状を見ると、開発パイプライン全体にわたって手動テストと自動テストの両方が実施されていることが分かります。機能テストは通常、開発のデプロイ段階で実行されますが、回答者の42%はプルリクエスト段階で自動機能テストを実施しており、35%はコード段階で自動機能テストを実施していると述べています。手動機能テスト実施の分布も自動テストに似ており、回答者の 65% がデプロイ段階で、36% がプルリクエスト段階で、36% がコード段階で実行しています。本番環境での機能テストでは、手動テストで実施する回答者自動テストで実施する回答者の差が最も大きく、デプロイの段階で38%が手動機能テストを、27%が自動機能テストを実施しています。 

アンケート回答者によると、エンドツーエンドテストは、開発パイプライン全体で手動・自動ほぼ等しく実施されており、デプロイ段階で、65%が手動エンドツーエンドテストを、61％が自動エンドツーエンドテストを実施しています。プルリクエスト段階でのエンドツーエンドテストは、32%が手動実行、33%が自動実行となっています。機能テストと同様に、本番環境でのエンドツーエンドテストは、手動テストと自動テストの導入に大きな差があります。36%の組織が本番環境で手動エンドツーエンドテストを導入しているのに対し、自動エンドツーエンドテストを実行しているチームは29％でした。 

パフォーマンステストは、アプリケーションの安定性と速度を測定する非機能テストの一種です。つまり、アプリケーションの実際のユーザー体験を示す重要な指標です。回答者のほぼ1/3がパフォーマンステストの自動化に関心を持っていると考えると、73%が現在のパフォーマンステストを単に「良い」「改善が必要である」と評価しているのも当然と言えるでしょう。パフォーマンステストに満足している評価している回答者は全体のわずか6%でした。 

同様に、アクセシビリティテストも、成功裏に導入されるにはまだ初期段階にあります。回答者の大半(73%)が、現在のアクセシビリティテストの実践状況を「良い」または「改善が必要」と答えており、世界10億人以上の人々が多様な形でのアクセスを必要としている今、このギャップは深刻です。

回答者が掲げる2023 年のテスト目標が示すように、DevOps の成功のために品質とテスト戦略を進化させる大きなチャンスがまだ残っています。テストにおける最大の課題についての回答はさまざまでした。最大の障害はテスト自動化の不足であり、開発チームとテストチームの1/5が懸念を抱いています。テストメンテナンス(13%)と他チームとのコラボレーション(11%)がそれに続きました。 

テストを妨げるのは、より技術的な問題が多いと示されています。回答者の53%は、部門間コラボレーション、インパクトの可視性、リグレッションテストの時間制限、不具合修正、テスター不足などのプロセスや人に関する問題よりも、テストの自動化、テストメンテナンス、テストケース管理の不足などの技術的な制限がテストにおける問題であると答えました。対照的に、DevOps採用に関しては、回答者の72%が技術面での制限はさほど大きな問題ではないと回答しています。

テストにおける技術的進化の必要性は、テスト自動化の導入による顧客満足度の差を見ると明らかです。テスト自動化の欠如がテストに関する最大の課題である回答した組織では、顧客満足度を「良い」または「改善が必要である」と認識している傾向があり、「素晴らしい」と考えている回答者はわずか18%でした。 

測定できないものは改善できません。では、テストの専門家はどのように品質を評価しているのでしょうか。半数近くがテストの有効性をテストの成功の指標として使用しており、その次に回答者の48％がテストカバレッジと回答しました。ピアレビューも品質チームにとって一般的な指標と分かり、47%の組織がこの方法を採用していると報告しています。他の一般的な品質向上施策としては、テストの冗長性または再利用の機会の評価(38%)、テスト実行やタイミングの最適化(38%)、合格率の評価(37%)が含まれていました。注目すべきは、これらのプラクティスのほとんどが、時間をかけられない2つのタスクである「テスト分析」か「テスト実行」のどちらかに当てはまることでした。

テストの価値の最大化という点で、障害への回答はさまざまでした。4人に1人が根本原因に関する情報の不足が最大の課題であると答え、22%が不具合修正に関するプロセスが遅いと答えています。テスターの26%にとっては信頼性の低いテストが問題であり、テストの失敗を否定的に見る文化が問題であるとする回答者が全体の1/10を占めました。テストに対する全体的な障害と同様に、テスト結果の使用に関するより一般的な課題は、技術的な制限に偏っており、全体的なDevOpsの問題とは対照的な結果となっています。

テストの可能性を制限する文化的、人的、技術的な課題に対処するには、ソフトウェア開発業界全体でテスト(および全体的な品質の取り組み)がどう見られているのかを知る必要があります。5チームに1チームはQA を組織内の戦略的な取り組みと考えており、回答者のほぼ半数が QA は組織全体にとって非常に重要である、と報告しています。QAを「ある程度重要である」とする回答者が25%、QAは重要ではないと回答したのはわずか7%でした。

アンケート回答者には、組織がQAやテストエンジニアの評価について、開発者との比較で回答しいただきました。回答はほとんどがQAの価値を反映しており、１/4が組織においてQAは戦略的な役割を担っていると答えています。また、40%の回答者が、品質チームは戦略と意思決定に対して影響力を持つ役割を担っていると考えており、26%が組織の戦略や意思決定プロセスにほぼ影響を与えないと答えています。QAやテストエンジニアの価値に対する一般的な認識と同様に、QAは影響力がないと答えた回答者は10%未満でした。

品質に関するリーダーシップは、企業や開発組織の規模と構造によって大きく異なります。アンケート回答の中では、どのリーダーシップも完全に多数を占めてはいませんが、技術責任者/CIO/CTOがアプリケーション品質への投資を主導していると答えた人が複数います。およそ1/5のチームが、品質への投資は品質責任者が主導していると答え、製品責任者やCPO、プロダクトオーナーが主導すると答えた人たちは15%でした。テストと品質を管理する品質専門のCoE(センターオブエクセレンス)を備えている組織はほんの少数（8%）で、エンジニアリングや製品部門以外の管理者が品質のリーダーとなっているケースはごくわずかでした。

品質のリーダーシップに関するアンケート結果は、当然ながら組織の規模に大きな影響を受けています。企業規模別のアプリケーション品質のリーダーシップを見ると、スタートアップや小規模企業から大企業まで、あらゆるタイプの組織でCTO、CIO、技術責任者がアプリケーション品質をリードすると答えた人が最も多く、次に多い回答は小規模企業を除いて、品質責任者がリードする、でした。

アプリケーション品質のインパクトと重要性にかかわらず、多くの組織は品質への取り組みへのさらなる投資には消極的です。当然ながら、最も一般的な阻害要因は予算であり、回答者の27%がこれを主な原因であると答えています。DevOps 採用を妨げる阻害要因と同様に、変化のプロセスが遅いことは、19% のチームにとって最大の課題であり、スキルのある人材の不足と並んでいます。その他の阻害要因は、会社による優先順位付けの欠如(14%)、リーダーシップの欠如(8%)、および社内政治(8%)が含まれます。技術的な制限が原因であるとした回答は最下位でした。

デプロイ頻度はDevOpsの成功を示す主要な兆候ですが、DevOpsの成熟度の全体像を把握するには、通常の製品リリースがどれほどスムーズであるかの理解が重要です。回答者の過半数(62%)が、リリースはほとんどストレスにならず対応可能であるとしています。6チームに1チームが、リリースがストレスになると答えており、非常にストレスが多いと回答したのは2%でした。1/5の回答者が、リリースはストレスなくスムーズであると答えています。全体として、ほとんどの組織において、リリース対応は大きなストレスの原因にはなっていないようですが、改善の余地はまだまだあるでしょう。

リリースのストレス(および潜在的なユーザー体験の障害)の管理は、ソフトウェア開発ライフサイクル全体のプロセス合理化から始まります。DevOpsと品質の障害となる要因の多くは、プロセスと文化に関連していると考えると、コラボレーションの改善はDevOpsの成熟度の向上を意味すると言っても過言ではありません。回答によると、エンジニアとQA間の製品に関わる問題の引き継ぎに改善の余地があるようです。組織の引き継ぎプロセスについて、46％の回答者が「改善する必要がある」とし、「とにかく苦痛である」と答えた人たちが9%いました。対照的に、引き継ぎプロセスが「かなり良い」とする回答者は37%しかおらず、「完全にシームレスである」と答えた人たちはわずか7％しかいませんでした。

QAと開発者のコラボレーションに関する全体像を見ると、部門横断的な作業全体についてさまざまな意見があるのは当然です。バグを特定・解決するプロセスが、最大の難関であることが分かり、「苦痛である」「改善が必要である」と答えた人たちが13%、「かなり良い」「シームレスである」と答えた人たちは9%でした。根本原因の分析を実行するための情報を見つけるというコラボレーションが必要なタスクも、似たようなフラストレーションを引き起こしましたが、「情報共有プロセスはしっかりしている」とする回答者が14%いました。

コミュニケーションと信頼性が低いテストが誤った結果をもたらすことに不満を感じている回答者は7%で、肯定的な回答（6%）を僅差で上回りました。テスト結果に対する組織の認識については、肯定的な回答者が6％で、否定的な回答者はそれよりわずかに少なく5％でした。前述しましたが、プロセスの問題が最大の悩みどころであり、情報共有とコミュニケーションが否定的な反応につながると考えられています。効果的なコミュニケーションとコラボレーションは、DevOpsを導入する開発組織の中核となるため、これらの問題点のいくつかを特定して解決することは、チームの成功に役立ちます。

半数近くが、ソフトウェア開発ライフサイクルのデプロイ段階（デプロイ直前）でバグの大部分を特定したと答えています。コードがメインブランチにマージされる前のプルリクエスト段階でほとんどのバグを発見したと答えた人たちが36％、開発の初期段階で継続的にバグを見つけられているチームは1/10にも満たず、リリース後に顧客からの報告によってバグを知ったとするチームが11％ありました。

プルリクエストやデプロイの段階でバグを発見したチームが多かったものの、テストカバレッジによるバグ発見で回答を分けると回答は少々変わりました。テストカバレッジが十分なチームは、コード段階でのバグを発見する傾向が2.5倍高く、プルリクエスト段階では2.3倍であると答えています。これは、シフトレフトおよび継続的なテストの影響であると考えられます。開発サイクルの初期段階でテストをすれば、そこでバグを発見することが可能です。チームができるだけ早くバグを見つけたい場合は、テストカバレッジを改善する必要があります。 

バグの発見と解決のプロセスは、最大の課題としてランク付けされました。ほとんどのチームが、不具合修正に数日とまではいかずとも数時間かけていると答えているのは当然と思えます。1営業日中に問題解決できるチームは1/3で、バグ修正に1〜3日かかるとするチームが多数です。解決に24〜48時間必要であると回答した人は22%、不具合修正に2日以上かかると答えた人たちも8％いました。バグ修正に1日以上かかってしまうと、デプロイが大幅に遅れ顧客満足度に悪影響を与えるリスクが高くなります。そして、61％ものチームが、日常的にこのリスクに直面していると答えています。 

テストカバレッジの向上は、ソフトウェア開発組織の多くで求められている引き継ぎプロセスの改善と関係しています。テストカバレッジが優れたチームは、引き継ぎプロセスが「良い」「シームレスである」と答える傾向が3倍程度高く、テストがコラボレーションに影響を与えることが分かります。 

テストカバレッジの向上は、バグ修正のプロセスにも良い影響を与えます。テストカバレッジが「優れている」「とても良い」「十分である」と回答しているチームは、「不十分である」と回答するチームに比べると、24時間以内にバグを修正する傾向が3倍程度高く、良いテストカバレッジを持つチームの24%が1〜8時間でバグを修正できています。対照的に、テストカバレッジが「最小限」「不在」なチームのうち、1日でバグを修正できるのはわずか15%でした。

昨年、デプロイ頻度を上げたソフトウェア開発チームの間では、テストカバレッジの向上が共通の要因となっているようです。デプロイ頻度を 50〜100% 増やした企業は、変化がなかった企業と比べ、2.5倍も多く「テスト カバレッジが良い」「優れている」と答えています。 

デプロイが頻繁になると、本番環境でのバグ発生リスクが高まりますが、テストカバレッジの高いチームは、そのリスクを最小限に抑え、顧客の期待により応えられることが分かりました。デプロイ頻度を 50〜100%増やしたチームは、変更しなかったチームと比較して、顧客満足度が「優れている」「良い」と答える傾向がほぼ2倍になっています。デプロイ頻度を上げたチームは、頻度の変更程度に差があっても、全般的に高い顧客満足度を得ていることが分かりました。 

この報告書の前半で、アンケートの結果からテストカバレッジの向上と広範囲にわたるパイプライン自動化との関係が明らかになりました。この相関関係に踏み込んでみると、パイプラインの自動化が進んでいるチームは、テストカバレッジが高く、顧客満足度も高い傾向にあるのが分かります。完全に自動化されたパイプラインを持つチームは、顧客の満足度を「良い」または「素晴らしい」と評価する傾向が3倍高く、最も自動化されたパイプラインを使用しているチームが「顧客が非常に満足している」と答える傾向は 3.2 倍も高くなります。

テストカバレッジと顧客満足度の関係を考えると、QAを重視する組織がユーザーを満足させる傾向にあることは当然と言えます。QAを重視するチームの41%が「顧客は非常に満足している」と答えた一方で、QAはある程度重要だと考えるチームは、顧客満足度が低いと回答する傾向がやや高くなっています。QAと開発者が同等の影響力と戦力的重要性を持っていると、顧客とビジネスにとっても利益となります。

戦略的資産としてのQAの評価と、高いテストカバレッジには強い相関性があります。QAを重要視しているチームは、テストカバレッジが「良い」「優れている」と答える傾向が約2倍となりました。 

高いテストカバレッジのチームは、テストカバレッジがないチームと比べて顧客満足度が1.6倍高いです。ここからテストカバレッジの高さが顧客満足度を左右することが分かります。QAがソフトウェア開発組織内の戦略的資産として見なされている企業ではテストカバレッジが高く、顧客はその効果を実感できるのです。

高いテストカバレッジは、スムーズなリリースと強い相関関係があります。効果的なテスト戦略を持つチームは、デプロイがスムーズでストレスのないものと答える傾向が約3.6倍で、テストカバレッジによっていかに組織全体のコラボレーションと作業条件が改善されるかを示しています。

大企業ほどDevOpsを採用が進んでいる

• 従業員2,000名以上の大企業は、規模の小さな企業よりもDevOpsの採用率がわずかに高く、40%がDevOpsを「ほぼ完全採用」もしくは「完全採用」していると考えています。
• 大企業は、中規模企業の2倍もDevOpsを完全採用しています。
• 小規模企業の27%はDevOpsを完全採用しているものの、51%が採用の進捗状況がわからないと答えています。

DevOpsを妨げるのは技術でなく文化である

• 回答者の72%が、技術的な制約はDevOpsの主要な阻害要因ではないと述べています。
• 2年連続で、変化プロセスの遅さがDevOpsの最大の阻害要因でした。
• リーダーシップや専門知識、優先順位付けの欠如が同率で3番目の課題となっています。

ほとんどの組織でデプロイ頻度が上がっている

• 75%の組織がこの1年間にデプロイ頻度が増加しました。
• 4 社に 1 社が週に最低1回、 18% が隔週でデプロイを実行しています。
• デプロイ頻度を50〜100%増やしたチームは、顧客満足度が高いと報告する傾向が 3 倍以上となりました。

テストに重点を置いたチームはコラボレーションができるチームである

• 回答者の1/4が、組織内の全員がテストに関わっていると答えています。
• QAを重要視するチームは、テストカバレッジが「良い」「優れている」と答える傾向が約2倍です。
• テストカバレッジが高いチームは、QAと開発者間の引き継ぎがスムースである傾向が2.7倍高くなっています。
• テストカバレッジが「良い」もしくは「優れている」チームは、デプロイはスムーズでストレスがないと答える傾向が2倍です。

テストは成長し、消費者を喜ばせている

• 回答者の1/4が、組織内の全員がテストに関わっていると答えています。
• テストカバレッジが高いチームは、高い顧客満足度を報告する傾向が2.9倍高くなっています。
• チームの48％が「テストとQAが非常に重要である」と答え、テストが重要でないと答えたチームはわずか7%です。

テストによって開発プロセスが改善されている

• テストカバレッジが「良い」または「優れている」と答えたチームは、開発の初期段階でバグを見つける傾向が2.5倍高くなっています。
• 「優れている」「とても良い」または「十分な」テストカバレッジを持つチームは、24時間以内にバグを修正する傾向が約3倍高くなっています。
• テストカバレッジが「良い」もしくは「優れている」チームは、デプロイはスムーズでストレスがないと答える傾向が2倍高くなっています。

非機能テスト、APIテストは普及の兆しあり

• 43%のチームが、2023年に自動APIテストの追加、40%が自動リグレッションテストの導入を計画しています。
  回答者の73%が、現在のパフォーマンステストを「良い」または「改善が必要である」と考えており、28%のチームが2023年に自動パフォーマンステストを開始する予定です
  73%は、現在のアクセシビリティテストの実践を「良い」または「改善が必要」と考えており、21%が自動アクセシビリティテストの開始を計画しています。 
  回答者の53%は、DevOpsの阻害要因がプロセス面や人的な課題であるのに対し、テスト戦略の阻害要因は技術的な制約であると答えています。 

成功するDevOpsチームはより多くの自動化、より多くのテスト、より多くのデプロイを実行する

• DevOpsを完全採用している チームは、1日に複数回デプロイする傾向が5倍以上高いです。
• パイプラインを完全自動化しているチームは、テストカバレッジを「良い」「非常に良い」と見ている傾向が9倍高いです。
• デプロイ頻度を 50〜100% 増やしたチームは、テストカバレッジが「良い」または「優れている」と答える傾向が3倍高いです。
• パイプラインが完全に自動化されているチームは、顧客の満足度を「良い」または「素晴らしい」と答える傾向が 2.5 倍高くなります。

あらゆる規模の組織において、DevOpsトランスフォーメーションは、変化のプロセスが遅いことが妨げとなっており、リーダーシップと優先順位付けの欠如によってより難しくなっています。しかし、DevOpsの採用に成功している企業は、テスト、パイプラインの自動化、開発文化を同時に進化させることで結果を出しています。自分の組織ではDevOpsを完全採用、またはほぼ完全採用している、と答えた回答者たちは、高度に自動化された開発パイプライン、高いコラボレーションによるテストプラクティス、さらに何よりも重要な高い顧客満足度を実現しています。これまでの「素早く行動し破壊せよ」という精神はもはや時代遅れの考え方です。迅速に行動する方法を学びながら、品質と顧客満足度を重視するチームこそが、DevOpsに成功するチームなのです。