Googleのソフトウェアエンジニアリング(品質に関する部分)を読んだメモ・感想/14章 大規模テスト
こんにちは。kubopです。
QA活動をしていく中で、Googleのソフトウェアエンジニアリングの11章〜14章を読みました。読書メモを書いていたのですが、忘れないよう、思い出しながら感想や、まとめを書きます。
※ まだまだ理解しきれていない部分があるため、解釈が異なる点があるかもしれません。
前回はこちら
今回は14章、大規模テストについて
大規模テスト
大規模テストとは、以下のような傾向があります。
15分か1時間のデフォルトタイムアウト時間がある。
何時間・数日実行されるテストもある
密閉されていない可能性がある
非決定性の可能性がある。
ユニットテストは、関数・オブジェクト・モジュールについての信頼を与えるが、大テストではシステム全体が意図通りに動作していることについて信頼を提供できる。
開発初期にユニットテストを構築、テストピラミッドに向けて作成し、
その後はE2Eテストや手動テストをしながらユニットテストを増やしてテストピラミッドを完成させることが、長期的・健全性のために必要。
大テストの構造
テスト対象システムを取得
必要なテストデータをシードとして与える
テスト対象システムを用いて動作を実行する
挙動を検証する
忠実性
忠実性とは、テストがテスト対象システムの本物の挙動をしているかを示す。
大規模テストで鍵になるのは、その忠実性。
例えば、大規模テストをする環境は本番に対して忠実性が高い環境が良い。
大規模テストの課題
オーナーの不在。
テスト所有者が複数にまたがってしまうこと。
互換性のないインフラストラクチャー。
標準化されない。
実行・デバッグなどの環境のインフラとプロセス面での標準化の欠如。
（恐らく、開発環境・ステージング・本番間での環境の違い）
ユニットテストではカバーできない部分
テストダブル
単一のユニットテストは、1つのクラス・或いはモジュールを対象範囲とするため、テストダブルを用いるが、モックである場合は陳腐化した場合はプロダクトコードに追随する必要があるか検知できない。
テストダブルについてはこちら
設定
ユニットテストでは、インテグレーションされた設定、コードでは表れないバイナリ情報の確かさは証明できない。
例えばバージョンの違いによる設定は、ランダムな外部の信頼不能性をもたらす。
ちなみにGoogleの障害原因第1位は設定変更らしい…。
負荷・性能
ユニットテストは高速で、小さくあるため、実際のトラフィックを想定していない。
予期しない挙動・入力・副作用
ユニットテストは、それを書いているエンジニアが持つ創造力によって制約をうけることがある。
ユーザーが発見する不具合は、大抵予期しないものだったりする…
また、ハイラムの法則も検討するべきで、
ユーザーが期待する挙動は、公開APIの中で具体的な指定のないもの全てであって、ユニットテストでそれらを全てカバーできるわけではない。
『API を実装した設計者の望む振る舞いと利用者の期待する振る舞いに乖離が生じた場合、利用者の期待する振る舞いこそがシステムの動作を決めてしまう』
真空効果
ユニットテストはある種真空状態にある、特定の条件下における試験管のようなもので、現実世界では混沌とした部分に不具合は隠蔽されることがある…。
大規模テストの類型
1 つ以上のバイナリの機能テスト
ブラウザーとデバイスのテスト
パフォーマンス、負荷、ストレスのテスト
デプロイ設定のテスト
探索的テスト
A/B 差分(リグレッション)テスト
ユーザー受け入れテスト(user acceptance testing/UAT)
プローバー(prober)† 16 とカナリア分析
障害復旧(disaster recovery)とカオス(chaos:混沌)エンジニアリング
ユーザー評価
気になったものは以下（本には全部書いてある）
探索的テスト
本番環境かステージング環境
本番環境か既知のテスト領域のデータ
手動で行う。
新規ユーザーシナリオを試行して不審な挙動を探す。
ランダムなテストではなく、試験的なプロセス。
どんなに形式的なテストを行ったとしても、ソフトウェアが「動く」ことを「証明」するためにテストを行うことはできません。
もし、特定の手順に従って、製品があなたが確信していたとおりの振る舞いをしたならば、それはデモンストレーションです。
これは心強いことかもしれませんし、その製品が何をするものなのかを説明するのに役立つかもしれません。
確かにテストプロセスの一部ではありますが、それをテストと呼ばないでください。
テストと呼ぶと、「テストとは、ただ無造作にボタンを押すことだ」と思われかねません。
私はそれを出力チェックと呼び、テストという言葉は思考する人々の世界のためにとっておくことを提案します。
結論・まとめ・思ったこと
大規模テストはユニットテストが扱えないものを扱う。
大規模テスト（E2E）を増産しまくる、というよりはまずはユニットテストの拡充だなと思いました。
外部とのやりとりや、ユニットで賄えない部分をE2Eで・・・といったような順番が良さそう。
大規模テストはオーナーが不在になりがち
チームや個人が作成したもののオーナー、責任範囲が不明瞭になりがち・・・。
QAチームで巻き取るかというとそれはそれで範囲が広くなりすぎて、もはやSETエンジニア1人が専任でつかないといけなくなりそうな。
この記事が気に入ったらサポートをしてみませんか？