テクノロジー戦略本部 テクノロジー開発部 平山です。
普段はマネジメントを担当していますが、状況に応じて上流工程にも関わったりしています。
今回は高速エンハンス開発を見据えて取り入れたテスト手法についてお話させて頂きます。
テストの目的
現在開発中の基幹システムは事業の変化に柔軟に対応したいという目的からマイクロサービスアーキテクチャを適用しています。
この基幹システムは問い合わせから買取業務までを担うため、デグレーションを発生させてしまうと日々の業務に影響を与えるだけでなく、最悪の結果としてお客様からの信頼も失いかねません。
これを防ぐためには追加・変更した機能だけでなく、全ての機能をテストすればいいのですがこれだけで軽く数人月はかかってしまいます。
これでは事業の変化に柔軟に対応したいと言う当初の目的が損なわれてしまうため
『出来る限り楽に品質を守る仕組み』が必要になりました。
世の中には色々な仕組みがありましたが、その中で弊社が目をつけたのがKatalon(https://www.katalon.com/)です。
細かな説明を書き出すと長くなってしまうので省略しますが、誤解を恐れずに言ってしまうとWebブラウザやスマートフォンアプリのテストを自動化するためのソフトウェアです。
GUIツール上でテストが作れるため学習コストもそれほど高くなさそうだなというのも選択した理由の一つでした。
テスト方法
弊社ではシステムの品質を下記の様に確認する仕組みを取っています
- 作成したプログラムに対応するテストコードを書く
- 実際に画面・アプリを操作して実施する
- 機能テストが完了したらKatalonで自動化テストを作成する
- Katalonのテスト実行タスクをCIに組み込み日次で実行する
いくら自動化できるとは言え、同じ様なテストを全てのフェーズで行うと非効率なので積み上げによる品質保証としています。
作成したプログラムに対応するテストコードを書く
弊社ではフレームワークとしてRuby on Railsを用いて開発を行っており、コードテストはRspecで行っています。
テストコードもレビュー対象としており、作成したプログラムが仕様どおりに動く事を確認している状態になっています。(モチロン完璧ではないですが・・・)
実際に画面・アプリを操作して実施する
自動化テストは機械が行うものなので、画面崩れやレスポンスまでの時間など人の感覚に頼った確認は出来ません。
また、新規開発ではテスト開始時にまともに動く事はほとんどないためKatalonを作って確認するよりも実際に画面を操作しながら確認した方が効率が良いです。
ちょっと話がずれますがテスト実施やバグ対応を通して若手エンジニアが成長しているのを見ていると、実際に触る機会を設けたのは良かったなと思っています。
機能テストが完了したらKatalonで自動化テストを作成する
Katalonの操作方法やテストケースの作成方法については詳しいサイトが沢山あるのでここでは実際に行っている方法だけ紹介させて頂きます。
Katalonでテストケースを作成する際にコードで書き出してもいいのですが、画面操作をレコーディングして自動で作成されたテストコードを修正する方が楽でした。
ログイン等頻繁に出てくる操作はモジュール化して各テストケースから呼び出すようにすることで余計な修正作業を省くことができます。
テスト観点に応じてID、PASSなど値を変えられるのも大きなポイントでした。
Katalonにはフォームやボタンをテストで扱うためのTest Objectというものがあります。
これを画面毎に作成して共通化することでフロントの変更にも対応しやすくなりました。
テスト実行後に値が表示されているか?などのよくある確認も共通化しています。
特定の項目は色々な画面に表示するケースが多いため作成にかかる時間短縮にもなりました。
Katalonのテスト実行タスクをCIに組み込み日次で実行する
Katalonでテストが動くことが確認できたらテストコードをGit上にpushします。
弊社ではCIにKatalonを組み込んであり、テストコードがマージされたら実行されるようになっています。
将来的にはこれを日次で動くように設定し、問題を発見したらSlackにレポートを送る+JIRAにチケットを切るなど面倒な作業を自動化したいと考えています。
課題
まだまだ開発中なのでこれからも出てくると思いますがパッと思い出せる課題を書いておきます。
現在開発中の基幹システムではフロントをVue.jsを用いてSPA(シングルページアプリケーション)で構築しています。
弊社では画面の操作をレコーディングしてから生成されたテストコードを修正する流れになっているのですが、オブジェクト(フォームやボタンを表すもの)を特定するための一意となるキーがないためXPATHで参照する形になっていました。
このままではヘッダー部のデザインを変えただけでテストが動かなくなってしまうため、フロントエンドエンジニアに相談してIDを付与してもらう様にしました。
テストを行うためにテストデータが必要になる場合があります。
確認したい観点によって必要なデータが異なるので事前に用意するにも限界があったため、テストデータを作成するSQLファイルを用意してテストケース実施時に実行する形を取りました。
しかし、期限日など日付を扱う場合に動的に変更したいケースがあるためどの様に実現するのが良いのか模索中です。
スマフォアプリでもWebブラウザの様に自動でテストができるらしいのですが、アプリは絶賛開発中のためまだ検証できていません。
検証ができたら(いつか)ブログに書こうと思います
まとめ
システムを開発するうえできちんとテストを行って品質を確認すると言う作業はとても大切です。
しかし、品質ばかりに目を向けていると社会や事業の変化に合わせるのが遅れてしまうためバランスを取りながらシステムを作って行きたいと思っています。
来年のリリースを予定しており、実際に効果がわかるのはまだまだ先ですが今時点ではこのテスト手法が合っているのかなと思います。
