テストの相互依存性（ギア本 7.2.6節）に関係する体験談
前のテストケースのアウトプットを次のテストケースのインプットにすることで、多くの包括的なテストが実行できます。しかし、効率化だけを目的としたテストケースの連結は、実行方法が手動であれ自動であれ、注意しなければなりません。前のテストケースのアウトプットに誤りがあったら、後続のテストは意味をなさなくなるからです。
そんな中、意図してテストを相互依存させるケースがありました。データの相互依存性を確認するテストです。
手動テスト担当者は、ライフサイクルのテストに頭を悩ませていた。そのテストは、システムにユーザー情報を登録してから想定される、60件もの複雑な注文を入れるものだった。複数のユーザーが絡み合い、複数の実行環境をまたいで注文していく。1日がかりで実行しても、オペレーションをミスしてしまうと頭からやり直しになってしまう。
期待結果と違う事象が見つかった場合、それが本当に欠陥なのか、オペレーションをミスしたのか、あるいは期待結果が間違っているのか、切り分けなければならなかった。オペレーションミスがなくなれば、切り分けも楽になり、無駄な労力をなくすことができるだろう。自動化することで解決できないだろうか。
オペレーションミスをなくすために、自動化は有効です。テストツールは、退屈したり注意力散漫になったりしません。指定したとおり、正確に動きます。人が実施するには複雑で嫌気がさすようなテストは、機械に任せてしまうのが得策です。
手動テスト担当者は、このテストを自動化することにしました。自動化することで、手動テスト担当者は面倒なテストから解放され、正確なオペレーションとテスト結果を手に入れることができるようになりましたが、それが最善の解決策だったのでしょうか。
ギア本の第1章「テスト自動化のコンテキスト」には、カオスを自動化してもカオスが速くなるだけだという注釈が書かれています。そもそもこのテストの目的は何なのか、手段は適当であるかを再検討する必要があるでしょう。
ライフサイクルテストの場合、テストを相互作用させることは誤りではありませんでしたが、効率的ではありませんでした。必要だったのは自動化ではなく、ギア本で紹介されている解決策だったのかもしれません。
テストの複雑性（ギア本 7.2.8項）に関係する体験談
技術に関わる人はテクノロジーに我を忘れる傾向があります。「有能なツールを手に入れた技術者は、あらゆるテストを自動化したくてたまらない」そんな技術者の心情が、ギア本では語られています。しかし、複雑なテストの自動化に成功しても、複雑な自動テストをメンテナンスし続けなければならなくなってしまいます。
ある日、自動テスト担当者に「カードへの書き込みやスキャナによる読み取りが必要なテストを自動化してほしい」と依頼があった。このテストを自動化するには、疑似的にカードへ書き込みを行うツールや、スキャナによる読み取りをコントロールするツールの作成も必要である。
依頼のあった100ケースの内容を見ると、カードへの書き込みは、ほぼすべてのテストケースで行われていたが、スキャナによる読み取りが必要なケースは2つだけであった。そこで自動テスト担当者は、スキャナによる読み取りが必要なテストは手動で実行してもらうようお願いし、残りのテストケースの自動化と、カードへ疑似的に書き込むツールを作成することにした。
スキャナによる読み取りをコントロールするツールも開発できないわけではありません。しかし、開発とメンテナンスにかかる工数と、テストを自動化することで削減が見込まれる工数を比較すると、コスト削減どころかコストが増加してしまうこともあります。ありがちなのは、「今、時間があるから」という理由で安易に自動化してしまうことです。自動テスト担当者は、自動化する価値があるか判断するための基準を持ち、自動化するかどうか見極めましょう。
テストケースのデバッグ容易性（ギア本 7.2.5項）に関係する体験談
デバッグをするときに、自動テストが「失敗した」という結果だけもらっても、修正に取り掛かることができません。「どのような操作をしてテストが失敗したのか」「そのときどんなエラーメッセージが出力されたのか」といった情報があって初めて、どこを修正すればいいのかの見当をつけることができます。
では、デバッグに必要な情報が自動で出力されれば、情報の内容はどんなものでもかまわないのでしょうか。
そのプロジェクトは、システムテスト担当者が50人、開発者が500人といった大規模なものであった。自動テスト担当者は有償の自動テストツールを使い、リグレッションテストを実行していた。
ある日、デグレードを発見した自動テスト担当者は、自動テストツールが出力した結果ファイルをインシデントレポートに添付し、開発者に向けて発行した。結果ファイルには、自動テストが操作や判定をしたときの画面キャプチャや時間が細かく記録されており、何が起きたのかをさかのぼって調べるには、十分な情報が記録されていた。
しかし、開発者は添付した結果ファイルを確認してくれなかった。そのファイルを確認するためには、専用リーダーが必要だったのだ。
この結果ファイルは非常に優れたものでしたが、開発者のすべての端末に専用リーダーをインストールしてもらうことはできませんでした。結局、自動テスト担当者は、ツールが実行した操作手順を文章に起こし、報告するしかなくなってしまいました。
自動テストやツールを導入する時には、それらが扱うファイルの関係者や用途を洗い出し、あらかじめ手を打っておく必要があります。また、ギア本「7.2.3 テストデータの形式」でも話題に上がっているように、ファイルの形式が特殊である場合、最新化などの作業が増えてしまいます。どんな場面であっても、柔軟で扱いやすい形式を選択するのが望ましいでしょう。
