ノンプログラミングでゆく テスト⾃動化への道＠ユーザ系SIer 下⽥ 武史 

発表者の紹介 名古屋で⾃動⾞部品会社のIT部⾨勤務 担当業務はWebアプリ開発・運⽤基盤の構築 2018年から社内の開発プロセス強化を担当 中でもテスト⼯程の効率化に着⽬ 2017年にPGM単体テスト効率化を実施 2018年から 機能単体〜シナリオテストの効率化に着⼿ ⾼速開発⼿法の導⼊ 

テスト⼯程の効率化へ期待する声 『WindowsUpdateの度にテストするのは⼤変』 『毎⽉アプリの改訂があるけれど、最低限の リグレッションテストしかやり切れず、不安･･･』 テスト負荷の軽減が望まれている 負荷の軽減といえば⾃動化だが･･･ 『⾃動化はx年前にやったけど、すぐメンテされなく なった』 『⾃動化PGMが難しい(思ったように動かない)』 皆、苦い思い出があり、警戒している 

なぜ⾃動化が失敗するのか 考察 ⾃動化は、それが継続して使われて効果が出る ⾃動化すると初期開発負荷が⾼くなる 維持・改訂する中ですぐ回収できる(はず) なぜ継続して使われないか︖ 累積 テスト ⼈⼯ システム 維持改訂回数 ⾃動化 ⼿動 

開発する⼈≠維持する⼈ 開発者と維持担当者で望まれるスキルが異なる ITスキル深堀り 業務理解深掘り ★Seleniumなど⾃動化スキル 開発スキル幅広く 調整スキル(ユーザ/インフラなど)幅広く (ある会社の場合) 維持担当者は⾃動化スキルまで勉強する余裕なし ⾃動テストの メインユーザ 開発者領域 維持担当領域 スキルの選択肢 

開発する⼈≠維持する⼈ (ある会社の場合) 最初は動くが、運⽤の中で改訂が発⽣すると・・・ ・ 画⾯にボタンをひとつ追加する ・ ページを追加する ・ ブラウザやOSが更新される すぐ動かなくなる。 しかし、維持担当者は中⾝が分からないし、 開発者はもういない。(そもそも引き継げたのか･･･) →使われない 

維持担当者はテスト仕様を書く専⾨家 テスト仕様書 Excel/Word ⾃動実⾏ プログラム テスト テスト仕様書 Testablish ⾃動実⾏ プログラム テスト ⾃動⽣成 seleniumベース 記述 開発 記述 使う⼈が使いこなせないものは使われない PGM PGM PGM 理想はテスト仕様書を書けば⾃動テストが実現 (以前) (現在) むずかしい とくい これならかける さらに効率化するため、テスト⾃動化サービスを構築 Testablish を導⼊ 

Web配信 テスト⾃動化サービス 仕様書出⼒可能 

テスト⾃動化サービス 今後の拡張予定 クラウド 

効果の数値は出せないが、 半年で投資した時間以上の効率化が出きている。 定量効果以外にも、以下のような定性効果あり。 - テスト⼿順とデータが明確化（テスト品質向上） - 仕様改訂の敷居が下がる（価値向上） - モチベーションアップ︕（なにか動くぞ） 今後はサービス機能強化と共に、画⾯仕様から テストケースを⾃動⽣成出来ないか、検討。 また、ツールの⽅、ご興味持たれましたら、 Testablishで検索してみて下さい︕ 

御静聴ありがとうございました。