ソフトウェアテスト293の原則(第5章)

ソフトウェアテスト293の鉄則

■■第5章 テストの自動化

全体的に、テスト専門チームが自動化を行うことが前提として書かれている。あたしとしては、テストの自動化は開発チームが行うので「あー、そうそう」という感じだったが、昔ひっかかったこと、上司に言いたいことなどを中心にPickUpしてメモ

■102：目的はコストダウンではない,開発プロセスの迅速化だ
主な目的は

1. 回帰テストによるバグ（デグレ）の早期発見
2. 問題点の早期報告
3. 不完全なプログラム修正の早期発見

■110：回帰テストを自動化しただけではバグは出ない
自動化のテストが正しくなければ、バグは発見されない（＝もちろん）

■113：テスト記録の再生は思うようには機能してくれない
これも非常にその通り。仕様変更の対応でテストの記録を直す方が大変だったりする。テストのバグか実装のバグかの判断がつかないなど。採用の見極めが必要。

■115：ユーザーインタフェースは変わるためにある
自動化に際しては、インタフェース部分を抽出し、テストコンポーネントとしてまとめ、それぞれに自動テストを作りこむことが大切。下記はGUIからインタフェースを抽象化する方法。3.と4.がピンと来ないんだよなー。どういう感じなんだろう？

1. ウィンドウマップ：ウィンドウ内の各要素に名前をつけて、その名前で管理する方法
2. データ駆動型自動テスト：Excelなどを使ってテストデータの作成を行い、入力値と期待値を1行に1テストケースの割合で記入
3. タスクライブラリ：ユースケースをタスクという形にして構成要素毎に分解
4. キーワード駆動型自動テスト：鉄則128参照
5. APIベースの自動化：鉄則132参照

■120：テストの自動化に必要なのは,プログラミング,テスト,プロジェクト管理のスキル
テストの自動化とは、ソフトウェア開発そのもの。よってテスト設計と自動化設計のスキルは異なる。それぞれの専門家を適切に割り振ることが成功への近道

■123：自動化テスト環境の開発にはレビューを活用せよ
確かによく言われる。自動テストが正しいことのテストは必要ないのか？と。堂々巡りで意味がないのでは？と。よってレビューは大事。ペアプロすればいいんだよね？

■126：反復コードを避けるためだけにテストライブラリを構築するな
テストのプロシジャは多くの処理の反復を伴うもの。また同じ機能を多くの組み合わせと異なった順番で実施される。互いに関連しあうタスクのシーケンスに影響を受けるため、レビューやバグの検証、デバッグも困難になるので注意すること。

■128：プログラマ以外ならキーワード駆動型自動テストが最適
基本的にはデータ駆動型と同じだが、データだけではなく、項目の組み合わせも登録できる。ただし、フレームワークの準備、タスクライブラリの作成、Excelなどから1行ずつアクセスする機能の定義など、テスト自動化に十分な時間がかけられないと、オーバーヘッドが大きすぎる。

■130：テストツールはデータと処理を分離せよ
データ駆動型自動テストなどが該当。回帰テストの実行と、エラーを発見時の切り分けが容易となる。

■132：自動化のためにはプログラミングインタフェースを活用しろ
GUIテストの自動化の反対派⇒GUIの自動化は難しい。仕様も変わるし/推奨派⇒一番顧客の目に触れるから真っ先に決まるもの。あたしは前者だな。GUIの自動化でうまく行った試しがない。

■138：テストの自動化計画はプロジェクトの早い段階に立てる
アジャイルプラクティスでも、初日に環境作れって言ってた

■140：即効性のある自動化から始めよ
対象にするテストケースを選ぶより、効率の改善という面から選択すべき