テストの自動化の理想と現実

先週、「プロジェクト成功のためのソフトウェアテストの勘所」というセミナーが開催された。興味もあっていってみたかったが、都合がつかず。ということで、ネットで参加者のレポートを検索。。

「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート を書きました(アークウェブ ビジネスブログ)

「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート(wiki)

主にソニー高橋寿一さんの基調講演のポイントがメモされている。テーマはテストの自動化と理想と現実についてであり、安易なテスト自動化への傾倒には罠がある、といった感じだ。僕も今テストケース作成をツール化しているのだが、あまりにも網羅率への意識が強いとテストケースの肥大化と無駄化が進んでしまい「バグをみつける」という目的から逸脱しそうになる。サービス/機能を全て網羅することは重要ではあるが、それはテストのもうひとつの目的、「品質保証」の切り口でなければ意味がなくなってしまう。

「テスト網羅率100%です」などといった頭の悪いこと言わないようにしよう

まずテストケースを設計するときは網羅率100%を目指して作り、そのあとから有効なものや優先順位の高い項目をリストアップしていく、といった作業がいいんじゃないかと今の僕は考えている。著者のいうとおり、ただ安直に「網羅率100%」というだけではコストに見合った品質は得られない。

# 網羅率100%(に近い)テストケースを作るのってすごく大変なので、そこをツール化しようとチャレンジ中
# 万能ではないにしろ、GUIをメインにしたサービス限定とかで実現してみたいな

(自動化に)向かないテスト

• 回帰テスト（賛否両論あり）

僕はどちらかという賛否の「賛成」のほう。扱っているプロダクトの特質からかもしれないが、ここをどう自動化・効率化するかが大きいと思ってます。インターネットのサービスでは総じて同じことが言えそうな気がします。あくまで私見ですが。

状態遷移テスト

• 状態遷移は状態遷移図を書いた後、自動化する価値がある

ポイントだけなので詳細は推測になってしまうが、状態遷移図をインプットとしてテストケースやテスト実行を自動化する、という意味であれば、なるほど、それは価値は意外と大きい。各画面とその遷移グラフから何をチェックすべきか、といったノウハウがあればテストケース作成はある意味シンプルかも？

回帰テスト（リグレッションテスト）

• 上手く自動化する手法はない。自動化には最深の注意が必要

講演者である高橋さんが回帰テストの自動化に否定的だからなのか。もう少し詳細情報がないかググってみるか。

==

その他、かなり有益な情報が載っているので、上記以外はあとで読む。