シフトレフト
ソフトウェア開発の計画（左）からリリース・運用（右）までの流れのなかで、早い段階（左）の方でテストを開始すること。
テスターによる手動テストより、自動テストしましょうという話。
最もリスクの高い要素を早期のうちにテストできるだけでなく、その後もそれらを継続的テストに再利用できる。
早いうちからコードの品質に関するフィードバックを直接、繰り返し開発チームに提供する。
ソフトウェアテストの歴史と近年の動向 24,26ページ
https://image.slidesharecdn.com/historyoftestingandcurrenttrends20190313-190405130314/95/-24-638.jpg?cb=1554550940
https://image.slidesharecdn.com/historyoftestingandcurrenttrends20190313-190405130314/95/-26-638.jpg?cb=1554550940
継続的テスト: IBM の見解
アジャイルおよび DevOps 手法の導入が増えつつあるなか、開発ライフサイクルを繰り返すたびに手作業でテストを再実行するというパターンは続けられなくなっています。十分な時間がないだけでなく、手作業でリグレッション・テストを実行するために担当者を増員すると、収益が減ることになるためです。さらに重要な点として、開発者へのフィードバックに時間がかかると、生産性が極度に低下する点があります。よりペースが速くなった開発ライフサイクルに遅れを取らないためには、テストの有効性が非常に重要な特性となります。テストの有効性を最適化するには、最大数の問題を検出するテストを最小限の数に絞って実行します。より従来型の開発ライフサイクル (この場合、すべてのテストが 1 つのフェーズ内で実行されます) に取り組むチームでさえも、欠陥の修正、既存の機能に対する変更、さらに新機能のすべてがバンドルされた新しいビルドを入手するたびに、スケジュールに遅れることなくリグレッション・テストを完了することはできないという結論に至っています。以下の図を見るとわかるように、開発ライフサイクルが数回繰り返されるだけで、新機能の数が増え、したがってテストの数も大幅に増えていきます。
https://www.ibm.com/developerworks/jp/devops/library/d-continuous-testing-shift-left-trs/image001.jpg
必要なリグレッション・テストをスケジュールに遅れずに完了する唯一の方法は、適切なテスト・セットを自動化することです。スピードと品質のバランスを取るために、成熟した DevOps チームではテスト自動化と、手作業による予備的テストの両方を、継続的パターン内で実行しています。
継続的テスト
継続的テストによってソリューションの品質に関するフィードバックを即時に提供できるようになれば、チーム全体に信頼が生まれます。ビジネス利害関係者にとっては、継続的テストにより、デリバリーが信頼できるものであり、ビジネスに影響するリスクが最小限であるという確信が強くなります。プロジェクト・デリバリー・チームにとっては、継続的テストの手法およびツールによってテストが与える影響が最小限になります。その結果、プロジェクトのコストが削減されるだけでなく、ソリューションを提供するまでの時間が短縮されます。そして最も重要なことに、高品質で信頼性の高いソリューションを提供できるようになります。
shimizukawa.icon UnitTestを書いてテスト自動化すれば品質を維持しつつスピードを得られるとも読めるけど、shimizukawa.iconはUnitTestで担保できるのは実装者が想定した動作だけだと思う。このため、ユーザー操作のテスト自動化を目的としたシステムテスト自動化を行う必要があると思う。
シフトレフト アプローチでパフォーマンス テストを最適化する方法 – Parasoft
shimizukawa.iconそうか、このリンク先で紹介してる方法とSentryのパフォーマンス監視を組み合わせれば、継続的パフォーマンステストに使ってパフォーマンス劣化が自動的に検出できるようになるのか。
継続的テスト: IBM の見解
例えば、ライブ・アプリケーションの品質が低く、評判が悪い場合を想像してみてください。以下のシナリオで、プロジェクト・チームがテスト能力を高めて、可能なときに限らず、必要とあればテスト自動化を行えるようにするにはどうするのかを説明します。
まず、(ビジネス、開発、テスト、運用などに関する) すべての利害関係者が協力して、アプリケーションを本番環境にデプロイした後に見つかった欠陥の根本原因を把握します。チームは欠陥データと分析を基に、最も影響の大きい欠陥の原因が以下の 2 つの領域にあることを発見しました。
他のシステムとの統合
応答時間の遅れ
チームは、本番環境にデプロイする段階まで待つのではなく、開発プロセスの早期にリスクの高い統合に関してテストを行う必要があると判断しました。そうすれば、利害関係者が協力して、全員が合意したインターフェースとデータ定義をシステム・アーキテクチャーの一部として取り込むことができるためです。
また、致命的なパフォーマンス問題を早期のうちに識別して修正できるよう、ビルドが利用可能になると同時に低負荷パフォーマンス・テストを行うことも決めました。パフォーマンス・テストの結果をビルドごとに追跡すれば、パフォーマンスに低下があるかどうかがすぐにわかります。
全員が合意したインターフェースに基づき、開発者とテスターが協力して、リスクの高いインターフェースごとに仮想サービス (スタブ) を作成します。インターフェース・スタブによって他のシステムを模倣すれば、開発プロセスの初期段階 (コードが作成されてビルドされた時点) のうちに、開発者とテスターがリスクの高い領域をテストできるようになります。
チームはさらに、多数の機能統合テスト、そして主要な応答時間テストを自動化します。本番での大きな欠陥の多くは、これらが原因となっていたからです。