自動テストを始めよう! ~中級編~

このエントリーをはてなブックマークに追加
こんにちは。
inomata@QAです。

本日は停止リリースです。相変わらずinomataは出番が少ないので、例によって深夜テンションでブログを書きます。
ちなみに金曜ロードショーはもののけ姫です。きっと巷では「だまれ小僧!」とかつぶやかれてることでしょう。

今回は自動テストを始めよう!~中級編~と題して書いてみます。ちなみに初級編はありません。
ここでは主にseleniumを使った(またはそれに似た方法)自動テストを想定していますが、初級編は導入や使い方という部分なので、
そのあたりはGoogle先生に聞いてみるとたくさん出てくると思います。
ここではもっとソフトウェアテストより観点で、いかに自動テストをうまく運用するかを考えて見ます。

あとライブ感を出すため時間を書いていきます。
それではスタート。

3:04
  • テストは早く!早く!!
テストは早く終わる様に作ることが重要です。とにかく早く終わらせることです。
早く終わらせることによって開発へのフィードバックを早くし、テスト→修正のサイクルを早くすることができます。
長時間かかるテストは今すぐ分割しましょう。そしてできるだけ並列で実行出来る仕組みやテストの構成を用意しておくことが重要です。
とにかく早くです。

  • テスト結果は0か1か。
テストを確実に実行できるというのは重要な要件です。
テストが失敗するのはコードに問題がある時だけ!という状態にしておくということです。
例えば、実行環境のせいでテストが失敗するという状況を作ってしまうと、テスト結果が信用されなくなり、開発へのフィードバックが遅くなります。
テスト実行の動作は常に安定させるようにしましょう。不安定にしかならないのであれば、思い切ってやめてしまうのも選択です。

  • それは何をしているか?

実行されるテストケースはしっかり管理され、何をテストしているのかを明確にしておきます。
こうしないとテスト内容が重複してしまい、ムダな部分が生まれてしまいます。また細かく分割されて管理されていると、局所的なテストを行う時に便利です。
一見ちゃんとテストしてるように見えるが、実は意味の無い自動テストというのが一番厄介です。

3:30
  • 依存のない設計
データの依存性をなくして、いつでも繰り返し実行できるようにしておく必要があります。
テストの実行に順番を持たせると、結果として時間のかかるテストになってしまいます。
テストを早く終わらせるためにも依存性をなくしましょう。依存性が無ければ、テストを繰り返し実行することが簡単になり、使いやすくなります。

  • 失敗した時の原因が分かりやすいように
テストは成功(バグがないこと)を前提に作成してはいけません。バグありきで、テストが失敗したときにいかに有益な情報をくれるかを考えることがポイントです。
例えば何かの差分をとるテストで、失敗したときにどこがどう変わっているのかを見つけられなければ、テストとしてのレベルは低いでしょう。
また、ログを見ればいいじゃん、とも思われますが、デバッグの負担を減らす意味でも、手順やデータなどの性格で詳細な情報は提供するべきです。
これは不具合レポートの書き方の重要性と同じです。

  • 正しいコードを自動化する
今すぐカバー率を上げようとして、現物合わせで自動テストを作ると、間違った結果で自動テストが作成される可能性があります。
これが行われると、ある時動作が変わっていて今まで動いていたのかが謎。という現象が起こります。
自動テストは常に正しい結果が確認されてから作成する必要があります。事前に期待結果が定義されていてそれに沿ったテストを作成するのが基本ですが、
キャプチャ&リプレイツールでは事前に期待結果を作成しておくのは難しいので注意が必要です。
余談ですが、自動テストをいつ作成するかというのは議論の余地があると思います。


4:05
  • 何から自動化する?
自動テストの準備ができた。けど何から自動テストを作ればいいの?という場合は、正常系の簡単な機能テストから自動テストを作成することをお勧めします。
正常系の簡単な機能テストなんてほとんどバグが出ない!意味無い!!と思われるかも知れませんが、まあ、そうかも知れません。
しかし、ここが壊れてると100%の確率でとんでもないことが起きます。
例えば「ログインをする」という部分はそうそう壊れません(たぶん)。しかし、ひとたび壊れるとその被害が甚大なことは想像に難くないでしょう。
正常系の簡単な機能テストというのは、壊れた場合の被害がとてつもない場合が多いのです。これが壊れないようにガイドラインとして自動テストを作成しておくのは、思いのほか効果的です。
まとめると、以下を優先して自動化していくと良いです。
 1.正常系の簡単な部分
 2.壊れたら大変なことになる機能、あるいは要素(クロスブラウザなど)

もちろん、しっかりと戦略を立てているならば、それに基づくのが一番です。


5:28
  • おわりに
自動テストを導入するに当たって考慮すべき点をいくつか上げてみましたがいかがでしょうか?
これを全部実践するようにするにはかなり大変ですが、後々大変(もしくは破綻)にならないためにも最初からしっかりした計画を立てて実践しましょう。

それでは。


次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...