ソフトウェアの複雑化・高機能化にともない、QA現場に求められるテストの業務負荷は増大しています。しかしながら、QA人材の不足に陥るQA現場も多く、人海戦術でカバーすることも難しくなっているのが現実です。昨今の日本社会で散見されるソフトウェアの品質問題は、こうした品質保証の課題が一因となっているケースが少なくありません。

品質・生産性の高いテストを実現するうえでは、「品質保証DX」が有力な解決策です。QA現場のプロセスにDX（デジタルトランスフォーメーション）の概念を適用し、あらゆる開発サイクルにおける「持続可能な生産性向上」の実現を図るものです。

品質保証DXの実現にあたっては「品質計画」「開発・テスト環境」「テスト実行」の3点が重要となります。第2回では、品質計画の課題やポイントについてお伝えしました。詳細については、第2回の記事をご一読ください。

【第2回】：品質計画の手順と着目ポイント

第3回となる本記事では、2つ目に重要となる「開発・テスト環境」の計画や運用、適切なソリューションの適用に向けた課題と取り組みについて解説します。

開発・テスト環境の計画や運用における課題

開発・テスト環境の計画や運用は、品質保証そのものの業務品質を左右する重要な要素となります。しかし現実には、開発・テスト環境の計画や運用において課題に直面するQA現場が少なくありません。ここでは、3点の課題について解説します。

1. 本番環境・ステージング環境・テスト環境における挙動の相違

同じ操作であっても、各フェーズで用いられる環境によって動作結果が異なるケースが散見されます。構成要素のわずかな設定やバージョンの差異から挙動の相違が生じることもあり、原因調査には多くの工数を費やすことが通例です。総合テストなどのプロジェクト終盤に近いフェーズで問題が検出された場合、リリース遅延につながりかねません。

たとえば、「テスト環境で問題のない機能が本番環境で正しく動作しない」といった事象は特によく見られます。本番環境での問題を調査するにあたってテスト環境で実施しても再現せず、調査に難航することが往々にしてあります。構成要素を特定バージョンに戻して再実行するなど、多くの工数をともなう作業が生じることが少なくありません。

この課題を解決するためには、開発・テスト環境の構成要素における設定・バージョンの正確な管理や、柔軟な調整が行える仕組みが必要です。

2.開発・テスト環境の競合による業務の遅延

開発・テスト環境を複数のメンバーやプロジェクトで共用している場合、競合による業務の遅延は看過できない課題です。利用したい環境がタイムリーに確保できないことで、品質保証の生産性も低下してしまいます。

たとえば、必要な試験端末が別のプロジェクトで利用されており、完了を待たなければ実機テストが行えない、といったケースが挙げられます。特に品質保証は、多端末テストや多くのリソースを要するE2Eテストの必要性から、環境の競合に直面しやすいと言えます。

環境の拡充によってカバーは可能ですが、プロジェクト予算の制約もあり、この課題に直面するQA現場は少なくありません。

3.非機能要件に対応可能な環境の構築

パフォーマンスやセキュリティ、ユーザビリティといった非機能要件への対応も、開発・テスト環境における大きな課題です。一般に、品質保証において非機能要件のテストは後回しにされやすく、プロジェクト終盤に問題が発覚して大きな手戻りとなるケースが多々あります。

また、リリース後に顕在化する品質問題も、非機能要件のテスト不足に起因するケースが少なくありません。たとえば、「実運用の負荷を想定したテストが不十分なままリリースした結果、高負荷に耐えられずシステムがダウンした」といったケースが挙げられます。十分な負荷テストが行われていればリリース前に検出できるものの、非機能要件のテスト難易度の高さから、こうした品質問題を見逃す事例は後を絶ちません。

最適な開発・テスト環境の実現に向けたポイント

QA現場への「品質保証DX」の適用にあたっては、開発・テスト環境の計画や運用の最適化を図ることも重要なテーマといえます。ここでは、最適な開発・テスト環境の実現に向けた3つのポイントについて解説します。

1.複数要素における設定情報の一元化

開発・テスト環境を正確かつ効率的に管理・構築するうえでは、複数のソフトウェア構成要素における設定情報の一元化が不可欠です。構成要素ごとに散在する設定情報を集約し、それを基に環境構築を行います。これにより個別の設定作業を回避し、環境構築を簡素化することが可能です。

設定情報を一元化するための具体的な手法としては、IaC（Infrastructure as Code）が挙げられます。IaCとは、環境構築における設定情報などをコードとして管理し、それを基に環境構築を行う手法です。コードのメンテナンスだけで環境の変更に対応できるため、設定作業の簡素化・省力化につながります。

また、設定情報をコード化することでシステム化が容易となる利点も大きいため、IaCは品質保証DXにおいても中核技術の1つとなります。

2.自動化システムとの連携

環境の競合を防ぐうえでは、開発・テストにおけるプロセスの自動化により、利用時間の短縮や稼働率の向上を図ることが不可欠です。したがって開発・テスト環境には、自動化システムとスムーズに連携できることが求められます。

自動化システムを構築する具体的な手法としては、CI/CD（Continuous Integration / Continuous Delivery）が挙げられます。CI/CDとは、実装やビルド、テスト、デプロイといった一連のプロセスを1つのパイプラインとして自動化するアプローチです。

そのうえで、開発・テスト環境の使用状況を可視化し、環境稼働率を最適化する仕組みや、仮想化技術やクラウドの活用により、開発者やテスターごとに必要な環境を必要なタイミングで提供する仕組みの構築は必要不可欠と言えます。これらを手動で対応する割合が増えるほど、品質保証が困難になるといっても過言ではありません。

CI/CDは、品質保証DXの実現においても事実上欠かせないアプローチと言えます。開発・テスト環境の管理・構築に用いるソリューションを選定する際には、「CI/CDパイプラインに組み込めるか」が重要な観点となります。

3.品質計画に沿った早期の環境構築

開発・テスト環境は、前回のテーマである品質計画に沿って早期に管理・構築することが求められます。品質計画で定めた環境要件や環境モニタリング方式などを満たせない場合、品質目標の達成が困難となることは避けられません。

特に、非機能要件のテストに対応できる環境の構築は、プロジェクトの早期段階で実施することが望ましいと言えます。既存環境上の問題から非機能要件に対応したソリューションを適用できない、といった問題がテスト段階で判明した場合、品質を十分に担保できない状態でのリリースを余儀なくされる恐れもあります。

最適な開発・テスト環境を実現するソリューションとは？

今回は開発・テスト環境の計画や運用、適切なソリューションの適用に向けた課題やポイントについて整理しました。

開発・テスト環境においては、前述のようにIaCが有力な手法となります。ただしIaCの運用には課題もあり、慎重なソリューションの選定が必要です。

IaCの課題を解消し、最適な開発・テスト環境を実現するうえでは「TORQUE（トルク）」が有力な選択肢となります。第4回となる次回は、有力な環境ソリューションであるTORQUEに関してご紹介します。

• 「品質保証DX」の実現に向けて