Tbpgr Blog

元エンジニア 人事 tbpgr(てぃーびー) のブログ

プログラミング全般 | 受け入れテスト

概要

受け入れテスト

詳細

よりよい受け入れテスト

・UIを通して実行する
・ソフトウェア全体のテスト
・できるだけ本番環境に構成を近づける
・全自動
・CIの一部

目的

・リリースの信頼性・安定性を上げる。
・手動テストに費やす時間を減らす。

どのようなケースを作成するか

受け入れテストは全てを網羅する必要はないが、すべてのレイヤーを通すようなエッジケースが必要。
もっともコアなケースから。
システム本来の目的を達成する旅路をケースにするのが良い。
代表的なペルソナを作る。

並列実行について。

・方法1
Selenium Grid,ケース分割して複数マシンで実行。
・方法2
テストの分割。素早く終わる通常のケースと、遅い優先度の低いケースに分ける。
前者は常に実行。後者は夜間のデイリービルドなど。

表示待ち

スリープするか、ポーリングして入力を待つか。
ただし、後者は早いがソケットを使い切るなど問題があり実装方法に工夫が必要。

割れ窓

バグがないのに壊れやすいテストは信頼を失い皆が無視するようになり価値を失う。

UIの工夫

製造時にテストのしやすいUIを意識する。
部品の位置で判断させるとちょっとした変更がテストに影響してしまう。
ユニークな識別子を埋め込んでおくことでテストを変更しないで済むようにする。

テストデータ

自分で用意する。
テストを壊さず再実行可能に。
テストデータの設定はテストとプロダクトコードが同じコードベースであれば
プロダクトコードの機能を利用することで必要なコードが減る。

外部システム連携

受け入れテストの前に連結部のテストを行うことで無駄なテスト時間を減らす。
※受け入れテストはシステム全体のテストになるため、障害が出た場合にエラーの判別が難しい。
はじめに外部依存の部分のみでエラーが発生すれば、あれこれ悩みながら解決する時間が不要になる。

ページモデル

同じページに様々なシナリオからアクセスすることになるためページはクラス化して独立管理する。
これによりコードの重複が減り、修正時もページのみ修正すればよくなる。

テストコードの品質

プロダクトコードと同様に記載する。可読性、品質が低いとリファクタリングの足枷となる。

テストツールでテストを縛らない

実装よりもインターフェース重視のテストにする
うまくやればアダプターと多少の修正で移行できる

共同の場

関係者を同じ場所に集める
XPのプラクティスと同じ話。

テストの保守

全員の仕事

ペアテストプログラミング

製造者と協調でき、テストしやすい開発をできる
基本的には通常のペアプロと同じ効果