Test Automatioin UniversityのTest Automation in DevOpsのまとめです。

1. Intorduction to DevOps

DevOpsは品質に対する責任をチーム全体に広げた
- 小規模で低リスクなリリースを実現するためのに運用と開発、QAの壁は薄くなり、テストやリリースを支えるインフ作成、保守にだれもがアクセスできるようになった (する必要がある）
テストはDevOpsの核
Trunk based development
deployment pipeline
- パイプラインのボトルネックを特定し、バリューストリームを維持し、必要なFBを迅速に行う必要がある
- パイプラインの進行中にも新たな修正を行ってコミットしている
Continuous delivery のサンプル

引用元： https://testautomationu.applitools.com/course32/chapter1-img7.png
Continuous deployment のサンプル

引用元： https://testautomationu.applitools.com/course32/chapter1-img7.1.png

自動でユーザまで届くので被害を抑えるためにBlue/green や Canaryリリースをするのがいい

2. What’s in your pipeline?

はじめに緊急リリースについて考える
- そのリリースで必要なことはなにか
早いステージでは高速なフィードバックが得られる
- Unittests, Static analysis, Component tests
遅いステージでは遅いフィードバックだが、品質に自信が持てるようになる
- UI Tests, Perfomnce tests, exploratory testing
各ステージがチームの誰かの価値ある情報が得られるように設計する必要がある
ステージごとの依存性を確認し、ルールを決めること
- 並列でUI TestsとPerformance testsがある場合にどちらかFailsしたらその後のステージに進めるのかどうかみたいな
チーム内でPipelineを可視化してみるのがおすすめ
- Pipelineがどのように機能しているかを知るために下記のようなことを書き出す
  - その段階の結果を誰が知る必要がありますか？
  - その段階が失敗した場合、誰に警告されますか？彼らはどのように警告されますか？
  - 各段階からのフィードバックループはどのくらいですか？それで、コードベースへの変更をコミットしてから、何かが成功または失敗したというフィードバックを受け取るまで、それはどのくらいの期間ですか？
  - これらのフィードバックループを短縮する方法はありますか？並列化できるステップは他にもありますか？
  - ステージ間の依存関係は何ですか？外部システムへの依存関係はありますか？
  - テストダブルを使用して、これらの外部システムをスタブ、偽造、またはモックアウトして、これらの依存関係を減らすことができますか？
  - パイプラインにはどのようなゲートがありますか？たとえば、テスト環境にデプロイする準備ができていることを知るには、何が真実である必要がありますか？その時点までに成功しなければならない特定のテストはありますか？それともステージングやプロダクションに？
パイプラインの目標は、問題が発生した場合に迅速で一貫性のあるフィードバックと実用的なアラートを提供して、継続的デリバリーまたはデプロイの自信を与えることです。

3. Test automation strategy for DevOps

自動化されたテストを編成し、パイプラインに含められるようにチームを導く
テストピラミッドの概念は適用される
Continuous Delivery で成功するためのポイントが有る
State of DevOpsの調査結果によるとテスターの助けを得て開発者が行った信頼性の高いテスト自動化がパフォーマンスの高いチームと相関があることを示していた
CDを成功させるためには継続的なテストが必要であり、自動化もその一部である
- DevOpsの文化はチーム全体が自動化に従事することを意味してる
テストピラミッドのような視覚的なモデルはチームメンバーがコラボレーションするのに役立つ
- テストの特性や戦略を理解しやすい？
チームの様々な役割の人と必要なテスト、パイプラインに含めるべきテストについて話し合いましょう
- 回帰テストだけでなく、パフォーマンス、セキュリティ、信頼性、耐障害性、あらゆるテストが必要になる可能性がある
- Test suite canvas framework ahunsberger/TestSuiteDesign
- 今あるテストスイート評価したり、追加したテストスイートを計画するのに役立つ
- 話すことで以下の状態になり、本番に小さな変更を頻繁に加える自信を与えることができる
  - 障害にタイムリーに対処する信頼性の高いテスト
  - 優れたテストデータ
  - 適切な自動テストステージを確保
自動回帰テストがない場合にどこから始めるか
- 着手しやすいところから
  - 低レベルのテスト
  - テスタブルなコードの箇所
- リスクの高いところから
  - 発生頻度とインパクトから
- 顧客にとっての価値の高さから
最初のテストをパイプラインに組み込むことが大事
- 新機能に対する1ケースからでもいい
- あとから追加していけばいい
レガシーなシステムへのアプローチ
- Strangler Fig pattern
  - 徐々に新しいシステムに置き換える
  - そこをテスタブルにして、自動テストを追加していく
頻繁にメンバーをあつめテストスイートを見直すこと

4. Infrastructure Considerations

クラウドインフラとコンテンを使う
- TAS, SUTどちらでも同じ利益が得られる
- 並列化しやすい　実行スピードアップ
- テストステージごとに環境を準備できる効率アップ
- 費用も抑えられる
IaC
ローカルでもテストの実行しやすくなる

5. Learing in Production

監視
- 主に診断、アラートに使う
ロギング
- エラーの報告と関係するデータを管理できる
- 高価になりがち
  - 量が多いから？
トレース
- どの機能で、どのくらいの期間、どんなパラメータが渡されたか、ユーザはどの程度深く関わっていたかがわかる
- 高価になりがち
  - 量が多いから？
メトリック
- 時間間隔で測定された数値
- ログよりも安価で保存と処理が可能
- Prometheusが代表例
- ELK
可観測性(o11y)
カオスエンジニアリング
- 可観測性とともにUnkown Unknownをみつけるのに役立つ
- ランダムな事象をお越して対応する
- 安全に実行できれば自動化できる
本番でのテスト
- deployするけどリリースしない（多くの人に届けない）
- Feature toggleやカナリアリリース、ダークローンチなどの手段で可能になる
テスターの思考（探索的テストてきな）部分は本番環境でのテストを考えるの役立つ

6. Getting your Whole Team Engaged

テスト、自動化、DevOpsを成功させるにはチーム全員が協力する必要がある
どうやって実現するか
- 小さな差分を頻繁に本番にデプロイする
  - リスクの管理
  - 市場に早く届けられる
- 品質を組み込む
- Continous testing と Delivery
  - 自動化がいる
- Continous learning と improvement
テストの自動化と継続的なテストは両方とも重要な成功要因
Continuous testingのCDへのインパクト
- 自動化されてテストスイートの継続的なレビュー、改善
- 開発者とテスターの継続的な協働
- テスターは探索的、受け入れテスト、そしてその他の手動テストを実行します
- 自動テストから迅速なFBがもらえます
落とし穴
- 自動化が技術的負債に繋がる可能性がある
- ミディアムパフォーマーからはいパフォーマーになる際に現れる
- 自動化を進めつつ技術的負債を管理し解消する準備も進めること
本番環境でのテストでの学び
- どこをテスト自動化するかの優先度決めに役立つ
- ユーザが必要とする機能がなにかを知ることができる
- 使用していない機能がわかる（テストする必要のない機能もわかる）
フィードバックループを短くし続けるために
- パイプラインを可視化して短縮可能な場所や方法を見つける
- 自動テストの信頼性とスピードを改善する
- 共通認識を作り、サイクルタイムを短縮する
チーム成功の秘訣は優秀な人材の採用と最高の仕事させること
- 文化を変えるのは難しい
- 高い心理的安全性は高性能なチームの特徴
  - 失敗しても大丈夫と思える状態
- 品質にフォーカスする。スピードではなく
  - テスト戦略、開発手法、ツール、本番環境から学ぶ仕組み、パイプラインを通じた迅速なフィードバックなどの基盤を構築する
  - 長期的に見たら速く進む
ゴール設定と進捗の計測
- 小さく、計測可能な検証を行うこと
- チームにとって最も大きな課題を中心に短期的な目標を設定する
- 小さな事件を設計し、進捗を測定し、次の問題に進むこれを繰り返すこと