まだまだこのへんは「うんうんそうだね」という話題が多い章です。

次あたりから、初めてだとん?ってなるgTAAの話とかが出てくる。(のだった気がします)

2.1 テスト自動化に影響するSUTの要素

SUT(テスト対象のソフトウェア)やその環境を評価する上で気をつけなければいけないポイント。

  • SUTのインターフェース
  • SUTが使用している(組み込まれている)サードパーティ製のソフトウェア
  • 操作するインタフェースのレベル?(Levels of intrusion)
  • SUTのアーキテクチャの違い
  • SUTの複雑度

Levels of intrusion

がちょっとわからなかった。

SUTが存在する前からテスト自動化の計画を立て始めることはできる。

2.2 ツールの評価と選定

機能テストツールの選定でありがちな失敗

  • 既存ツールとの連携がうまくいかない
  • SUTの依存関係によってテストツールがサポートしなくなる
    • Javaのバージョンをあげたとき、とか
  • GUIのオブジェクトが認識できない
  • テストツールが複雑すぎる
  • 他のシステムと競合する
  • SUTの影響
    • テスおt自
    • テスト自動化ツールを使ったときだけSUTの応答がおそすぎるとか
  • コードに影響する
    • テスト自動化ツールがプロダクトコードの一部を変更してしまう
    • そんなことってあるのか・・・?
  • リソースが限られている
  • アップデート
  • セキュリティ
  • 環境やプラットフォーム間で互換性がない
    • 別環境に持っていくと自動テストが動きません、とかよくありそう

自動化ツール選定時のポイントや何をもって選ぶべきかなどは大事ですね。ISTQBのこのポイントだとまだぽやっとしているので、もっと具体化してリストアップできるのでは。

2.3 自動化とテスト容易性

画面の要素を認識しやすくしておくなど、SUTのテストしやすさを考えて作るのが大事。

  • 観測のしやすさ
    • SUTはシステムの内部情報を把握しやすくするインタフェースが必要(?)。ニュアンスはわかる。期待値と結果が合っているかどうかの確認時などに使う。
  • 制御しやすさ
    • UIの要素や関数の呼び出しなど、テストツール側とSUTとのやりとりがしやすいような仕組みが要る
  • わかりやすいアーキテクチャ
    • ちょっと抽象的・・・。

確かに自動テストを主にやっているエンジニアからすると、「もうちょっとマシな作りにしておいてくれよ」と思うことは多々あります。

画面上の別要素に同じidが振られている、とか。全然identifyできてないパターン。

とはいえ、その手の初歩的なところはさておき、ふつうの(GUIを扱うテスト自動化をしたことがない)開発者が作りながらテスト容易性を気にするというのはなかなか難しいんじゃないかなと思います。

なので、よく言われるように「開発の上流工程からQAを参加させて云々」というのが大事になってくるのでしょうね。