Quality@Speedを実現するための5ステップ | ソフトウェア品質向上・セキュリティツールのParasoft

（この記事は、開発元Parasoft社 Blog 「The Five Steps Required to Enable Quality@Speed」2018年2月9日の翻訳記事です。）

誰もが高品質のソフトウェアをもっと速くと望んでいます。今日のソフトウェア開発チームに対する要求は膨大です――競争の激化と市場圧力の高まりへの対応、機能と複雑さの増大、製品の品質・セキュリティ・信頼性への高い期待などなど。そこで、変化によりすばやく対応でき、顧客の要求をより確実に満たせるという期待から、アジャイル開発手法が人気を集めています。

しかし、アジャイルや（最近では）DevOpsは、より少ないリソースでより速くソフトウェアを完了させる方法として売り込まれることが多いものの、実はそれが主目的ではありません。現実を見れば、ITプロジェクトの70％が失敗している、あるいは目標を下回っているなか、優秀な開発チームは、現在のプロジェクトを成功させるだけでなく、その後の反復開発や将来の製品に備えて、開発プラクティス改善の道を探っています。この記事では、アジャイルや反復開発手法に不可欠のアジリティを実現し、単なる完成品ではなく、品質とセキュリティの目標を満たし、さらに上回る製品を生み出す方法について説明します。

Quality@Speedの答えは継続的テスト

結局のところ、テストはより良い品質をより速く達成するうえで、課題でもあり、解決策でもあります。アジャイルプロセスでは、多くの開発ステップを小さくし、設計と実装を行いやすい単位に機能を分割できます。しかし、新しい機能の統合は危険であり、テストの範囲は不明確です。以前の記事で触れたように、テストは、アジャイル手法の導入時にソフトウェアチームが苦労する大きな理由の1つです。チームはテストの過剰や不足によって泥沼にはまり、必死で追求しているはずのアジリティを失います。

継続的テストは、DevOpsやアジャイル開発を採用しているソフトウェアチームが直面する問題の解決策と見なされています。ウィキペディア（Wikipedia）の定義では、継続テストとは「ソフトウェアリリース候補に関連するビジネスリスクのフィードバックを即時に得るために、ソフトウェアデリバリーパイプラインの一部として自動テストを実行するプロセス」です。定義は簡単ですが、継続的テストを実施し、時間をかけて最適化するとなると、まったく別の問題です。

アイスクリームのコーンをピラミッドに変える

理想的なテストピラミッドは、プロジェクトのどこに時間と労力を投入するのが最適かを表します。理想的なピラミッドでは、貴重な時間と労力は、ピラミッドの基礎となるユニットテストの包括的なスイートを作成するのに投資し、それをAPIとサービステストによってバックアップします。ピラミッドの上部には、比較的少数のシステムテストやGUIベースのテストがあります。

しかし、このピラミッドは、しばしば逆さまのアイスクリームコーン型になります。この場合、壊れやすく複雑なシステムレベルのGUIテストに時間と労力をかけすぎています。システムレベルのGUIテストを実行するには、機能を完全に実装して統合する必要があるため、ソフトウェア開発ライフサイクル（SDLC）の初期段階では継続的に実行できないテストばかりになります。継続的テストを成功させるための鍵は、アイスクリームコーンを溶かして、開発者が新しい機能を実装している間も継続的に実行できる自動ユニットテストおよびAPIテストの作成に集中することです。

継続的テストでQuality@Speedを実現するための5ステップ

ユニットテストの基盤を構築する――テストの作成、実行、および保守のプロセスを自動化することによってこれを実現します。ユニットテストの作業を作成および保守しやすくするだけで、開発チームはすべてのコンポーネントに対してプロジェクトレベルのユニットテストを採用するでしょう。
サイクル終盤の壊れやすいUI中心のテストに頼らない――UI中心のテストに頼ると、問題の診断と修正に時間と費用がかかるだけです。すべての手動テストシナリオを自動化しようとはせず、ユニットテストとAPIテストの基礎を強固にすることに投資し、まず、UIと通信するアーキテクチャが堅固であることを確認します。
ピラミッド全体のコードカバレッジを把握する――また、要件/ユーザーストーリーへのトレーサビリティを明らかにします。それなしでは、開発チームは、テストされたものとテストされていないものを判別できません。さらに、テストカバレッジを把握していないということは、ピラミッドの各レベルで何をテストすればよいか分からないということであり、ささいな変更でも多くのテストが必要になり、プロセス全体がスローダウンするということです。詳しくは、変更ベースのテストに関する以前の記事を参照してください。
アプリケーションの依存関係のサービス仮想化によってシフトレフトする――これにより、開発ライフサイクルの早い段階でAPIテストを実行できるようになります。自動化の推進とバグの早期発見――バグにはセキュリティ、アーキテクチャ、パフォーマンス上の欠陥などがあります――これが成功の鍵です。
変更影響分析によってアジャイル開発を加速する――ビルドごとに、それぞれの新しいイテレーションで導入されたリスクの詳細を理解します。変更影響分析が提供する分析結果は、テストする必要があるものだけに焦点を当てたテストを行う上で重要です。変更影響分析がなければ、場当たり的なアプローチを採るしかありません。データに基づく賢明な意思決定を通じてのみ、現実的な継続的テストが可能です。

改善をはじめるには

あたりまえのことながら、テストピラミッドをレビューし、プロジェクトの現在の立ち位置を評価するのが最善の方法です。ビルドのたびに実行できる強固な自動ユニットテストの基礎はありますか？できるだけ多くの製品APIを自動でテストしていますか？仮想化はされていますか？システムの完成間際まで実行できない複雑な手動UIテストに依存していませんか？改善の道は、適切なテストピラミッド、自動化、およびデータ収集と分析の構築を基礎とします。

成功への道は、たとえば次のようになります:

テストの自動化をテストの作成・実行・管理のすべてに採用し、現行のユニットテストスイートを拡張して、妥当な範囲の製品コードを含めます。
静的解析を使用して、レガシーおよびサードパーティのコードを含むコードベース全体を解析し、テストで見つからない可能性のあるバグやセキュリティ脆弱性を検出します。静的解析は、プロジェクトのコーディング規約への準拠にも重要です。
システムレベルのテストおよびUIテストへの依存を減らします。 システムレベルのテストも重要であり必須ですが、最優先にするべきではありません。またシステムテストの段階は、重大なアーキテクチャ・パフォーマンス・セキュリティの問題を発見するべき時期でもありません。ユニットテストやAPIテストの堅固な基盤を構築すると、UIテストやシステムテストへの依存を減らすことができます。この記事で紹介した他の推奨事項に従っていれば、システムレベルのテストが始まる前に、システムの大部分がすでに十分に検証されているはずです。
サービスの仮想化を活用して、開発のより早い段階で自動化されたAPIテストの実行を可能にします。より早くAPIテストを行うことで、パフォーマンスやアーキテクチャの健全性など、システムの危機的な局面を発見するのに役立ちます。これはセキュリティのテストにとっても重要な段階です。
データ分析を使用してテスト対象範囲を決定します。開発チームを最小限のテストに集中させ、各イテレーションで適切なカバレッジを確保することは、アジャイル開発手法にアジリティを取り戻すための鍵です。

まとめ

今日のソフトウェア開発チームに対する膨大なプレッシャーは、期日を守り、仕様どおりの製品を構築することを困難にしています。アジャイル開発などの新しい開発手法は、チームが顧客の期待に応えることに集中する助けにはなってきましたが、依然としてプロジェクトは遅延し、エラーも多く、テストは現代の開発手法にもつきまとう危険の多い側面であり続けています。大幅な改善を達成するには、自動化されたユニットテストの堅固な基盤を築き、サービス仮想化を利用して、早期に、また頻繁にAPIテストを実行します。また、データ分析を使用してテスト管理を推進することで、テスト結果が大幅に向上することを忘れないでください。