JetBrainsのブログにKerry Beetgeの執筆で掲載された記事によると、リリース直前にアプリケーションをテストするだけでは、現代のソフトウェアの品質を保証するには不十分である。中心となる考え方は、ソフトウェア開発ライフサイクル全体に品質チェックを分散させ、変更や複雑性がさらに蓄積した後ではなく、欠陥が混入した時点に近い段階で発見できるようにすることだ。
記事は、この変化をAIが生成したコードへの依存度の高まりと結び付けている。Stack Overflowの2025年の調査を引用し、開発者の84%が開発プロセスでAIツールを使用している、または使用する予定であると指摘している。JetBrainsは、こうしたツールによって生成されるコード量の増加により、反復可能でスケーラブルなレビューが一層重要になると考えている。一方で、自動生成された成果物に誤りが入り込む可能性があるため、人による検証は依然として不可欠である。
リリース前のゲートウェイから継続的な品質保証へ
記事は、ソフトウェア品質保証（SQA）を、開発ライフサイクル全体を通じて運用要件、信頼性、セキュリティ、標準への準拠を追跡するものとし、最終製品に重点を置き、欠陥に対して事後対応することが多い従来の品質管理（QC）と区別している。継続的なアプローチによって、コードの記述時や統合時に問題を発見できるため、修正コストが低く、変更が行われた本来の文脈との関連性も高くなる。
記事によれば、現代の開発環境ではリリースサイクルが数か月から数日へと短縮されている一方、CI/CDパイプラインによって、人的介入をほとんど必要とせずに、コミットから本番環境までコードを移行できる。そのため、単一のツールに依存するだけでは不十分であり、各テスト層が異なる種類の問題を検出する。
ツールは実際に何をカバーするのか？
- 静的解析：コードを実行せずに検査し、欠陥、脆弱性、コーディング標準違反を検出する。Qodanaがその一例である。
- ユニットテスト：関数やコンポーネントが個別に動作することを検証する。例としてJUnit、Jest、PyTest、NUnitがある。
- 統合テスト：サービス、API、データフローの相互作用を検査する。ツールとしてPostmanやSoap UIがある。
- 機能テストとUIテスト：Playwright、Cypress、Seleniumなどのツールを使い、ブラウザー上でユーザーの操作経路をシミュレートする。
- パフォーマンステスト：負荷下での挙動を測定し、ボトルネック、メモリリーク、クエリの遅延の発見に役立つ。JMeter、LoadRunner、k6などのツールを使用する。
- セキュリティテスト：SAST、SCA、依存関係のスキャン、DAST、誤って組み込まれたシークレットやAPIキーの検出を組み合わせる。
ツールをどのように選定し、業務に統合するのか？
記事は、CI/CDとの統合性、使用している言語やフレームワークへの対応、反復作業を自動化する能力、コードとチームの成長に合わせて拡張できること、実行可能なレポートの提供に加え、ツール自体に関するセキュリティ対策に基づいてツールを評価することを提案している。
実装の面では、コードの記述時点にチェックを移行し、反復テストを自動化し、すべてのコミットまたはビルドで実行することを推奨している。また、コードの複雑性、重複、テストカバレッジなどの指標を使って技術的負債を監視することも勧めている。さらに、セキュリティチェックをリリース前の別個のレビューまで先送りせず、通常の品質保証フローに組み込む必要性を強調している。
certi.newsの見解
記事が提示する実質的な変化は、新しいテストを追加することではなく、開発ライフサイクル内で品質に対する責任を再配分することにある。このアプローチは、短い間隔でリリースを行うチームや、分散アーキテクチャと外部依存関係に依存するチームに有効だが、手動テストやエンジニアリング上の判断を不要にするものではない。自動化、特にAIを利用した自動化は問題の発見を速められるが、それだけでカバレッジの完全性や結果の正確性を保証するものではない。また、情報源は一般的な指針とツールの例を示しているが、ツール間の比較のための定量的な枠組みを提示しておらず、性能に関する独立した比較結果も証明していない。