以下の内容はhttps://uga-box.hatenablog.com/entry/2024/10/10/000000より取得しました。


【技術本まとめ】Leading Quality - セッション2のまとめ

LEADING QUALITYという本を読んでいて、そのうちのセッション2(戦略的に品質の意思決定を下す)のメモ

第4章 手動テスト自動テスト

  • うまくいっていない会社の例
    • 「100%自動化してQAチームの負荷を下げよう」
    • どこを自動化?誰がメンテナンスするのか?が不明
    • 時間のない中では自動化関連のタスクが消化できなかった
    • みんな自動化のことを言わなくなった
    • テストインフラは壊れたまま
    • アプリケーションの変更が早すぎて、自動テスト可能にするのが追いつかない
    • バグが自動テストをかいくぐっていた
  • うまくいっている会社の例
    • チーム文化:チームが結束して問題解決とプロセス改善に取り組んでいた
    • 期待値:自動化を通じて実現できることとその限界を正確に把握していた
    • タイミング:プロダクトの成熟度、および、プロダクトライフサイクルに応じて、どのツールを利用することが適切か知っていた
    • インフラ:自動化の取り組みを最大限に活用できるように妥当なインフラを整備していた

なぜこんな誤解が生まれるのか

  • 大規模な人に影響を与えるために、自分たちが望むようにメッセージのやり取りをする 「選択的アーキテクト(Choice Architects)」という人がいる - エドワード・バーネイズ -「選択的アーキテクト」はこの本で解説されている
  • 誰が、選択的アーキテクトか?それは品質のプロフェッショナルたち
  • 開発スピードという難題の解決策を求めた

なんでも自動化できるのか

  • テストは自分たちが気づいていないことを新たに明らかにし、また知っていることがやはり真実であると確認する継続的な試み
  • その情報がわかれば次に何をすべきかが判断できる
  • テストには大別すると2つのタイプがある
    • 調査(または「探索」):創造性を発揮してプロダクトに関わる新たな情報を得るテスト
    • 検証(または「確認」):何が起こるべきかを期待した状態で行われるテスト
  • 検証で問題が発見されたら調査しなければならない、これは常に何らかの形で手動テストが必要とされる理由

なんでも自動テストすべきか

  • 検証は手動でも自動でもできるので、いつ・どちらを適用するかを知ること
  • 手動より自動化した方が有効となる3要素(IBMが実施した調査を元に書かれた論文「Reducin th Cost of IT Operations」より)
    1. 自動化されたテストケースが変更の手を入れることなく長期にわたって利用できること
    2. テストケースが細かい操作を必要としないこと
    3. 手動で実施よりも維持するコストの方が安いこと

第5章 プロダクトの成熟度と品質

  • 企業の成長に伴って、テストに対するチームの考え方も変化している
  • それぞれのプロダクトは大きく、次の3つの段階を得ていた
    • 実証段階:プロダクトマーケットフィットの模索
      • ユーザーのほとんどがイノベータやアーリーアダプター
      • バージョンアップの度に改良されていくことに寛容
      • MVPの提供にフォーカスされている
      • QA戦略はアドホック
    • 予測可能段階:スケーリングに耐えるインフラの構築
      • ユーザーが拡大してアーリーマジョリティが含まれる
      • プロダクト開発の体制やQAの優先度が新しくなる
      • 安定した稼働が大きな価値を持つようになる
      • QA戦略は、チームが適切なインフラを使って素早く動けること
    • スケーリング段階:負の影響を最小限に抑えたプロダクトのグロース
      • ユーザーにレイトマジョリティやラガードといったユーザーが増えてくる
      • QA戦略は、企業がスケーラブルな成長を遂げられるようなものにする必要がある

うまくいかなくなってきた場合は、ニーズに合わせたQA戦略の適応が必要かも知れない

レガシーコードに対して、ユニットテストも統合テストもない場合は、『レガシーコード改善ガイド』の中の5つのステップが良い

  1. 変更点を洗い出す
  2. テストを書く場所を見つける
  3. 依存関係を排除する
  4. テストを書く
  5. 変更とリファクタリングを行う

第6章 継続的テストとフィードバックループ

  • 継続的テストとは、最初のコンセプトから稼働後まで、プロダクト開発ライフサイクルのすべての段階でテストを行うべきである
  • 継続的テストは問題の特定と対処が早ければ早いほど長い目で見ると、時間と労力を節約できる。
  • しかし、フィードバックループは素早いほど良いと言うわけではなく、テストのタイプが異なれば提供される情報も異なる
  • どんなフィードバックが必要なのかを明らかにすることから始めると、どんなタイプのテストが最適かを判断する有力な心を得られる
  • 例えば、ユニットテストなどに比べて探索的テストはフィードバックの提供まで時間はかかるが、その価値を否定するものではない
  • フィードバックループをより良いものにする4つの分類
    1. スピードよりも価値を優先する
    2. 同時並行のテスト実行でスケールを拡大する
    3. 継続的改善を通じて学ぶ
    4. チームを生かすインフラを構築する

第7章 テストインフラへの投資

  • QA環境などのメンテナンスに時間が割かれているなら、ソースコードを変更したらすぐに本番環境にデプロイして、本番環境でテストする手もある
  • ただし、デプロイの高速高速化に加えて、デプロイ後に何が起こっているかをモニタリングし、必要に応じてすぐに元に戻したり修正したりできるインフラは絶対必要
  • ユーザが本当に気にしているのは次の4点なので、これが保たれているようにする
  • カナリアリリースという社内チームや一部のユーザだけに対し限定的に機能を解放する手法もある



以上の内容はhttps://uga-box.hatenablog.com/entry/2024/10/10/000000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14