Shift-Left & Shift-Rightアプローチ
Shift-LeftとShift-Right
Shift-Leftはソフトウェアのデリバリーチェイン（端的に言えばCI/CDパイプライン）の早い段階（より左）で特定のプロセスを実行すること。多くの文脈でテストやセキュリティの事を指しているが、どんなプロセスでも適用できる。
Put simply, shift left refers to the concept of performing a given process earlier in the software delivery chain.
When you hear people talking about the shift-left concept today, they’re usually discussing either software testing or IT security.
However, the shift-left idea can be applied to any type of process that occurs within the delivery chain. Data management, software monitoring and even software marketing could be moved to the left, too.
Shift-Rightはソフトウェアのデリバリーチェインの遅い段階（より右）で特定プロセスを実行すること。アプリケーションのリリース前にリリース後の問題を把握するために行う。
As you might imagine, shifting processes to the right means performing them later in the delivery pipeline. In many cases, this specifically means taking processes that typically happen before application release and moving them into production, to help you catch post-release issues before end users notice them.
テストやセキュリティなどのコアソフトウェア配信プロセスを継続実施することが重要。
Shift-left and shift-right are both valuable concepts, but DevOps teams should not embrace them in isolation. Instead, think of shift-left and shift-right as steps that you can take to make core software delivery processes like testing and security continuous across your pipeline. Continuity is the real goal.
Shift-Left Testing
テストにおけるShift-Leftという単語は適切でないという指摘。
I think the first time I heard the term was in a talk by Paul Gerrard – perhaps a webinar for EuroStar in 2014. In the notes I made at the time, I have this sentence “
Shift Left ??? – redistributing test activities … same thing we have been saying … why is he calling it shift left? I don’t understand this at all.”
Shift-Leftという単語は開発プロセスが直線的なプロセスの様に感じらるので、コンセプトが誤解されるのではないか？コンセプトに合うのは継続的/全体的テスト（Continuously/Holistic testing）*
What I fear may happen using the term ‘shift-left’, is that some people will misunderstand the concept and go back to big upfront requirements that need to be tested before coding is even started. Shift-left also doesn’t include the idea of DevOps, so people have started saying shift-right, or shift-outwards.
I personally think better terms are testing continuously or holistic testing, taking into account whatever your context may be.
Continuous Testing
DevOpsのあらゆる場所でテストはあるという指摘。
Shift-Right Testing
リリース前だけでなくリリース後の本番環境でのテストも含めてShift-Rightであり、以下の項目が例として挙げられている。
release validation（リリースの検証）
destructive/chaos testing（破壊的テスト、カオステスト）
A/B and canary testing（A/Bテスト、カナリアテスト）
CX-based testing（カスタマーエｋスペリエンステスト）
crowd testing（クラウドソーシングテスト）
production monitoring（本番モニタリング）
extraction of test insights from production data（本番データからのテスト項目の抽出）
Shift-Right Testing: The Emergence of TestOps
Shift-right entails doing more testing in the immediate pre-release and post-release phases (i.e. testing in production) of the application lifecycle. These include practices such as: release validation, destructive/chaos testing, A/B and canary testing, CX-based testing (e.g. correlating user behavior with test requirements), crowd testing, production monitoring, extraction of test insights from production data, etc.
Shift-right not only introduces such new testing techniques, but also requires testers to acquire new skills, make aggressive use of production data to drive testing strategies and collaborate with new stakeholders, such as site reliability engineers (SRE) and operations engineers.
CXは、カスタマーエフォートスコア（CES）、ネットプロモータースコア（NPS）、カスタマー満足度スコア（CSAT）などのさまざまなメトリックを使用して測定する。これらはある程度Shift-Leftも可能だが、ほとんどは本番稼働中のシステムからの測定になる。
Unlike classic testing, this takes into account real-world users and their experiences. An application with perfect traditional quality scores (such as FURPS) may still suffer from poor CX if it fails to delight the customer. CX is measured using various metrics such as Customer Effort Score (CES), Net Promoter Score (NPS), Customer Satisfaction Score (CSAT), etc. While it is possible to shift-left some of these measurements to some degree, most CX measurements are deduced from systems in production (or close to production).
TestOps
The Emergence of TestOps
TestOpsは単純にShift-Rightの事をではなく、可能なものはShift-Leftした継続的なテストを指す。
Though the term TestOps (like all the X-Ops sub-disciplines within DevOps) implies the collaboration between testing and operations, it isn’t simply about shift-right. Why? Because with DevOps, operational disciplines themselves have shifted left (such as shift-left of monitoring, configuration management, SRE, etc.). Hence TestOps—true to the principle of continuous testing—refers to better collaboration with operations disciplines across the DevOps lifecycle.
TestOps Shift-Left
アーキテクチャや構成リソースなど本番環境を使ったテストに近い内容もShift-Leftされる。
- Architecture quality（アーキテクチャの品質）
- Scalability analysis（スケーラビリティの静的分析）
- Performance/stress testing（パフォーマンステスト）
- Reliability testing & analysis（信頼性テストと分析）
- Maintainability（メンテナンス性）
- Configuration quality（構成リソースの品質）
- Configs “as-code”（コード化された構成リソース）
- Unit test configurations（構成リソースのユニットテスト）
- Equivalence testing（同等性テスト）
- Rollback testing（ロールバックのテスト）
- Early Monitoring（早期の監視）
- Unit test monitoring configs（監視リソースのテスト）
- Monitoring in test（テストの監視）
TestOps Shift-Right
よりユーザ利用に近い領域がShift-Rightの対象になっている。
- Chaos Engineering（カオスエンジニアリング）
- Contolled failure simulation（制御された障害シナリオの挿入によるシステムの信頼性のテスト）
- Reliability analysis（信頼性分析）
- A/B and Canary Tests & Synthetic Transactions（A/Bテスト、カナリアテスト、Synthetic Transactions）
- Testing in prod（本番環境でのテスト）
- Rollback testing（ロールバックテスト）
- User simulations（トランザクションのエミュレーション）
- Tests as monitoring probes（監視プローブによるテスト）
- Predictive Ops Insight（ユーザの行動予測）
- Extract test intelligence from prod data（本番データからのテスト知見の抽出）
- CX analystics（カスタマーエクスペリエンスの分析）
コメント・シェア
