続・テストの種類に関して振り返ってみた、GoogleのS/M/Lもね

以下、テストタイプとGooglenS/M/Lのテストレベルに関して簡単に整理。

E2Eのテストにおける、テストタイプいくつかをざっと整理

  • システムレベルの機能テスト
    • 基本、機能仕様にシステムの振る舞いが合致しているかを確認するテスト
      • Story TestやScenario Testはこちら。
    • Mobileアプリだと、Mobileアプリから何らかの操作を行い、サーバと通信して、結果を描画する所までを1つの流れと見る。
    • 日時、株価、乱数や通信環境に依存した結果を検証することも求められるが、それは難しいので可能な限りUnit testのテストレベルでテストを実施できるようにすることが望ましい
      • 時間を止めたテストを行うなどは、システムレベルでは難しい・・・

  • 回帰テスト
    • 今まで蓄積したテストを回帰的に回すテスト。多くは自動化されていることが望ましい。
    • OS/機種/言語などの組み替えにより試験を実施することも望ましい
      • バリエーションに対する描画崩れを見る(screenshotなど)
      • 機種依存のような不具合を見つける
    • 例えば、Appium使って、iOS/Androidのシミュレータでのバリエーション試験なんかはちょうど良いかも
  • 表示崩れに対するテスト
    • UIの判別は自動化が困難な領域。一番現実的なのは、Screenshotを撮影し、人間が目視で確認する
      • ImageMagicなどの画像ライブラリを使い、ある程度のしきい値で人が確認しなくて良いものを篩い落とすくらいは自動化できるかも
      • Web系は結構そろってきている・・・
    • ユーザビリティテストに区分されるかもしれない
  • 結合テスト
    • 複数の、異なる責任範囲を持つ機能間を統合したときに期待通りに動作するかを確認するためのテスト
    • 画面遷移、イベント、フレームワークとの結合、WebAPIとの結合なんかが主
    • 一部、Stubサーバを使う形もあり
  • スモークテスト
    • 第三者的なQAによる試験を実施できるか、というような、動作を最低限確認するためのテスト
    • アプリが正常にビルドできて起動可能か、とか、そういうレベルでの定義でも良い

自動化を推進することで得られるメリット

  • 開発速度の向上
    • リリース間隔が決まっているとしても、そこに取り込むことができる機能の量を増やすことが可能
  • 新しいOSや関連ライブラリの修正に対して、正しくエラーを出すことで早く気づける/修正できる

その他

  • ドメイン知識やプラットフォームなどの周辺知識をある程度持っていることが検証者としては必要な傾向にある
    • iOS/Androidに対する操作/ガイドラインへの知識など
  • ユニットテストであれば、MVCのMが中心となるほうが良い。(MVCではそれがおそらく多いことは健全。)
  • 自動化が困難だといわれる画面表示に関しても、入力に対して出力を得られるものはユニットテスト可能な場合が多い。そのため、できるだけ画面とロジックを切り離して、ロジック箇所に対するテストを増やすことが可能な設計を考える。それにより、テストで確認できる領域を増やしていく。
  • BDD/ATDD/specification by exampleとして扱うなら、テストシナリオをそのままドキュメントに近づけるアプローチもあり

テストの実施などの区分

テストの計画 = Plan
テストの実行 = Drive
テストの判定 = Judge
テストの結果 = Report/Feedback

Google のS/M/L

過去、テストレベル in Googleに記載済み。

今考えている、

  • 開発者/開発チームの責任範囲(実装範囲)とその関わりをもとにテストレベルを区分する

は良いアプローチかもしれない。SOAでサービス開発を行っていると、結構、個々のチームに差分があり、足並みを揃えることが難しい。むしろ、有機的に強調して、責任範囲を超えてシステム全体を安定(最適化)させていく方向に流れ、そのときに使い回せる粒度で抽象度をとどめておくほうが大事かも。

以下、再掲

Small test

Small tests are mostly (but not always) automated and exercise the code within a single function or module. The focus is on typical functional issues, data corruption, error conditions, and off-by-one mistakes. Small tests are of short duration, usually running in seconds or less. They are most likely written by a SWE, less often by an SET, and hardly ever by TEs. Small tests generally require mocks and faked environments to run. (Mocks and fakes are stubs—substitutes for actual functions—that act as placeholders for dependencies that might not exist, are too buggy to be reliable, or too difficult to emulate error conditions. They are explained in greater detail in later chapters.) TEs rarely write small tests but might run them when they are trying to diagnose a particular failure. The question a small test attempts to answer is, “Does this code do what it is supposed to do?”

  • 単機能/モジュールが責任範囲
  • よくある機能に対する不具合、エラーケースに対するテストなどがここ
  • mockやstubを使い、早く回すことを重視する
  • 開発の中に組み込んでいく

Medium Test

Medium tests are usually automated and involve two or more interacting features. The focus is on testing the interaction between features that call each other or interact directly; we call these nearest neighbor functions. SETs drive the development of these tests early in the product cycle as individual features are completed and SWEs are heavily involved in writing, debugging, and maintaining the actual tests. If a medium test fails or breaks, the developer takes care of it autonomously. Later in the development cycle, TEs can execute medium tests either manually (in the event the test is difficult or prohibitively expensive to automate) or with automation. The question a medium test attempts to answer is, “Does a set of near neighbor functions interoperate with each other the way they are supposed to?”

  • 2個以上の相互に影響のある機能をテストする時の区分
  • それぞれの機能のつながりに対してテストすることに焦点を当てる
  • 開発の中に組み込んでいく

Large Test

Large tests cover three or more (usually more) features and represent real user scenarios, use real user data sources, and can take hours or even longer to run. There is some concern with overall integration of the features, but large tests tend to be more results-driven, checking that the software satisfies user needs. All three roles are involved in writing large tests and everything from automation to exploratory testing can be the vehicle to accomplish them. The question a large test attempts to answer is, “Does the product operate the way a user would expect and produce the desired results?” End-to-end scenarios that operate on the complete product or service are large tests.

  • E2Eとよく呼ばれるように、システム全体で目的を達成するかなどを確認するための区分
  • すべてが自動化できるわけではなく、xxx性試験のような、アジャイル4象限では第2, 3, 4に区分されるような領域の試験が主
  • テスト対象の規模も大きくなり、テストの実施に関しても時間がかかるようになる。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中