【JaSST’17 Tokyo フォローアップ】受け入れテストの自動化


みなさん、こんにちは。Cygamesエンジニアの折田です。

先日、JaSST’17 Tokyoの「CEDECコラボセッション」で講演させていただきました。セッションの実現に向けてご尽力いただいたCEDEC事務局、JaSST事務局、ならびにJaSST実行委員のみなさんに、この場を借りてお礼を申し上げます。

JaSSTはソフトウェアテストに従事されている方、もしくはソフトウェアテストに関心を持っている方をターゲットにしたシンポジウムです。私自身もソフトウェアテストに長年携わってきたので、同じ課題に取り組む同志にナレッジを共有する絶好の機会だと考えました。

JaSST’17 Tokyoでは、自動テストにフォーカスを絞り、前半と後半でぞれぞれテーマを分けて解説しました。

【前半】自動テストの実装事例

OpenCV、Python、Appiumを使った受け入れテストの自動化について、CEDEC 2016では語られなかった技術的な詳細や最新の開発成果を含めた「完全版のセッション」をお届けしました。前回はスライドで簡単に紹介するのみだった下記のサブシステムについても、デモ動画を再生しながら、その有用性をアピールしました。

  • スクリーンキャプチャー
  • OCRサービス
  • ドライブレコーダー
  • エビデンスビューワー

【後半】自動テストの設計アプローチ

自動テストでは、どうしても「スクリプト」にフォーカスを置いた議論が展開されがちです。しかし、自動テストの開発資産を安定的に運用するには「データ」の設計が何よりも重要なのです。また、自動テストの開発資産の劣化速度を遅らせるために「スクリプト」から「リソース」への分離も欠かせません。この三位一体(トリニティ)の設計アプローチについて、開発者と保守担当者の視点からそれぞれ解説しました。

  • スクリプト
  • リソース
  • データ

JaSST’17 Tokyoでの講演内容

JaSST’17 Tokyoで講演した「受け入れテストの自動化」のプレゼン資料をそのままPDF化したものです。主題のみが書かれており、その行間を口頭で補足する前提になっていますが・・・全体の流れは十分把握できるかと思います。

さらなるカイゼン

実際にシステムの運用をはじめると、さまざまな問題点が浮き彫りになります。その原因が自分たちにあれば、粛々と修正するだけですが・・・時には、利用しているミドルウェアの性能限界の壁に阻まれることがあります。これまでは「枯れた技術を組み合わせる」ことをモットーとして開発を進めて来ました。しかし、技術的なブレークスルーを見い出すため、その代替手段を独自開発するに至りました。その開発成果については、この技術ブログで公開したいと思います。

もし、Cygamesに興味を持っていただけた方は、こちらの採用ページをご確認ください。