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