実践アジャイルテスト
この投稿は インタープリズムはAdvent Calendarを愛しています。世界中のだれよりも。 Advent Calendar 2017の7日目 の記事です。
背景など
インタープリズムはAdvent Calendarを愛しています。世界中のだれよりも。 Advent Calendar 2017の6日目で投稿した interprism.hatenablog.com
の後半になります。
今回はこの本の14章を主にまとめたいと思います。
テストで「何を自動化すべきか」、「何を自動化すべきでないか」について記述します。
アジャイルテストの自動化戦略
何を自動化できるのか？
- 継続的インテグレーション、ビルド、展開
ソフトウェア開発に含まれるあらゆる退屈な、あるいは繰り返しの作業は自動化の候補である
単体レベルのテストの自動化と継続的インテグレーションは第一の優先事項である
すべての入力変数の順列組み合わせを含むスプレッドシートの読み取りや、出力とスプレッドシートの保存されている期待結果の比較など
- GUIのテスト
ビジネスロジックが少量あるいは全くないGUIであってもテストは必要である
自動化が単純なものから自動化を試みる
- GUIの裏側のテスト
GUIそのもののテストを自動化するより容易である
- 負荷テスト
通常手動の負荷テストは現実的でないか、または正確ではない
- 比較
出力結果と期待値を手作業で比較して意図しない変更が行われていないことを確認するよりも相当早く、より正確である
- データ生成や準備
他のテストに影響を与えないように、あるいはテストの再実行の妨げにならないようにデータの破棄も自動化に含めるべき
何を自動化すべきでないか？
- ユーザビリティテスト
ソフトウェアのユーザビリティの側面を理解している人間の作業は自動化できない 自動化は人の目に飛び込んでくるような視覚的な問題を逃してしまう
- 探索的テスト
探索テストの主要なゴールの一つは製品について多くのことを学習し、その情報を将来の開発を改善するために利用することであるが、自動化スプリプトはそれを行ってくれない
- 絶対に失敗しないテスト
例: 住所の入力フィールドのテストで2番目の番地情報が必須でないか手動で確認した後の自動化されたリグレッションテスト
→手動で検証した後にそれを必須フィールドに変更することはあり得ないので絶対に失敗しない
一度の手動テストが成功し、その後デグレしないために自動化するコストが見合わないと感じるのであれば自動化することはやめるべきである →もし判断が間違っていると分かってもその後で自動化する機会がある
- １回限りのテスト
ほとんどの場合、１回限りのテストは手動実行で十分である
結論
2回に分けて「実践アジャイルテスト」の本を紹介しましたが、
もっと記載したい内容も多くありましたが、仕方なく割愛したので記事を見て気になった方は本を購入してみてはいかがでしょうか。
