Testing Strategies

• プロ開発者は自身のコードをテストする
• 単体テストや受け入れテストを書くだけでは足りない
• よいテスト戦略が必要

QA Should Find Nothing

QA Is Part of the Team

• 開発とQAが対立するのはよくない
• 協調してシステムの品質保証につとめるべき

• QAがつとめるべき役目

  • Specifier
  • Characterizer

QA as Specifiers

• 仕様や要件を抽出し、自動受け入れテストに翻訳する役目
• ビジネスはハッピーテストを書く
• QAはエッジケース、境界条件、アンハッピーパスのテストを書く

QA as Characterizers

• exploratory testing

  • 動いているシステムの正しいふるまいを特徴づける
• 要件をテストに翻訳するのではなく、動いているシステムの真の振る舞いを特定する

The Test Automation Pyramid

• TDDでユニットテストを書く

• システムの仕様を受け入れテストとして記述し、CIを回す

  • デグレ防止
• これらは序の口

Unit Tests

• プログラマによるプログラマのためのテスト
• 最低水準の部品の仕様書

Component Tests

• ビジネスルールをカプセル化するコンポーネントに対してテストする
• 入力に対して出力をテストする

• FW

  • Cucumber等
  • GUIならSelenium等
• QAチーム、および開発陣の補助付きでビジネス陣が書く

• ハッピーテスト寄り

  • 重箱の隅をつつくのはUnit Testsの役目

Integration Tests

• コンポーネントが多数ある大きなシステムで有意なテスト
• コンポーネント自体のビジネスルールというよりは、コンポーネント同士の協調をテストする
• アーキテクト、設計リーダーが書く
• パフォーマンスやスループットのテストもここで行うかも

• CIでは行わないのが普通

  • 長時間かかるから
  • nightly, weeklyなど

System Tests

• Integration Testsの究極系
• パフォーマンスやスループットのテストもここで
• システムアーキテクト、テックリードが書く

• システムが正しく構築できていることを検査するのが目的。網羅率は高くない

  • 10%そこら

Manual Exploratory Tests

• 「想定外」を人海戦術で見つけるやつ

• 「正しく動作すること」や網羅率が目的ではない

  • それは下位のテストでカバーしているはず
• 人間が操作する上で「なんかおかしい」を見つけるのが目的
• ので、これを自動化するのは本末転倒

Conclusion

• TDDで単体テストを作成したり受け入れテストを自動化したりするのは序の口
• QAが何も見つけずに済むのが理想

• 開発とQAが手を取り合ってテスト戦略を策定して

  • Unit Tests … 最低水準の部品の仕様書、高網羅性
  • Component Tests … ビジネスルールへの準拠 = 受け入れ
  • Integration Tests … 部品同士の協調
  • System Tests … システム全体の協調
  • Manual Exploratory Tests … なにかおかしくないか

• 可能な限り高頻度で回す

  • フィードバックの最大化
  • システムを常にクリーンに

英語

• deem

  • と考える、みなす

• peculiarity

  • 奇妙な点