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

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

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

自動化で一番恐ろしいUIの変更にも対応は簡単です。

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

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

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

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

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

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

もしあなたがTAを選ぶと

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

資料ダウンロード