コードを書かずに自動化しませんか?

TestArchitect(以下TAと記述)を使用すると、CやJavaやPython言語のようなメンドウな文法や、複雑な記述を覚えたりする必要はありません。ログインのテストをしたいのなら、表に以下のように書くだけです。あと実行ボタン押してください!日本人が大好きなExcelライクなユーザインターフェースはあなたのマニュアルテストケースをそのまま自動化できるかもしれません。

アクション名パラメータ1パラメータ2
login高橋password1
open_dialogjuichi1111111111111111

自動化で一番恐ろしい

UIの変更

にも対応は簡単です。「ユーザインタフェース振る舞い」と「TestArchitectのアクション」は、1対1で定義されています。なのでUIが変わったからといって、次の日にスクリプトが全部動かなくなり、全てのスクリプトがそのUI変更に影響を受け1週間自動化スクリプトが動かなくなるということはありません。

もしあなたがTestArchitectを選ばないと

右のような専門的なコードを書かねばならないかもしれません。残念ながらアメリカやヨーロッパでは、多くのエンジニアが情報系の大学を出た人が効率よくコードを書き自動のテストを実装しています。もちろんその人が自動化のコードを書く場合はTestArchitecの書き方でも、右のような専門的なコードでも効率は変わらないかもしれませんが(筆者は情報系の大学院を出ていますが、絶対TestArchitectで書くほうが早いです)、日本のテスト担当者のスキルレベルだと難しいかもしれません。多くのマニュアルテスターがたくさんいる環境でもTestArchitectは有用です。マニュアルテスト担当者は非常に少ない教育で自動化テスト担当者になることも可能です。

それでもTestArchitectを選ばないお客様

なぜなら初心者でもマウスとキーボードで記録し、それを再生できるから

あなたはツール会社の展示会に行ってこんな言葉を聞きませんか?「マウスやキーボードで1回記録させれば、次回から同じ操作は自動化ツールがやってくれます。劇的にテストのコストが減ります」。何度そんな言葉を言われ続け、筆者は騙され続けたことか。何千というテストケースをゴミに捨ててきました。もしあなたのソフトウェアが一切ユーザーインターフェースが変わらず、一切OSをアップデートされないのであれば、問題ありません。でもそんなのはソフトウェアではありません、簡単に変えることがソフトウェアです。1回めの操作記録が簡単だとしても、なにかユーザインターフェースが変われば、右のような複雑怪奇なコードを変えなければなりません。もしくは毎回マウス・キーボードを記録しなければなりません。そしてどちらの選択肢も正しくないのはいつか気づくはずです。

 

もしあなたがTAを選ぶと

  • テストの自動化羅率を70%以上を達成する
  • テスト自動化の対投資効果を数週間で実感できます
  • 回帰テスト時間の70%以上を削減できます
  • 自動化テストを早期に導入し、また開発終了と同時に自動化テストを終了することができます
  • 1つのテストスクリプトはもちろんプラットフォームやハードウェア構成に依存せず走らせることができます(更にRemote TestKitと組み合わせると、ひょっとしたらあなたはビーチで過ごす時間がとっても増えるかもしれません!?きっと、たぶん)

更に詳しい情報