ローコードテスト自動化ツール T-DASH

CI/CDとテスト自動化をこれから始める方への入門ガイド

アプリケーションの開発が進むと、開発期間が長くなり、品質を維持していくことが困難になってきます。そのため、品質を維持して開発期間を抑えるのは重要な課題です。課題解決のためにCI/CDとテスト自動化を導入した効果や継続していくためのポイントについて、事例を交えて解説していきます。

CI/CD(継続的インテグレーション/継続的デリバリー)とテスト自動化の関係性って?

CI/CDとテスト自動化の関係性については説明する前にまず各言葉の整理をしたいと思います。

【CI(継続的インテグレーション/Continuous Integration)とは?】

アプリケーションを管理しているコードに対し複数の変更を統合する際、コンフリクトやバグの混入を未然に防ぐことができます。具体的には、管理リポジトリから新しく開発用のブランチを作成し、コードに修正を入れて、リポジトリへ統合します。この際に必要な、レビュー・ビルド・テスト・マージなど繰り返し行う作業を自動化することで、早い段階で開発者がコードにある問題点を修正できます。

【CD(継続的デリバリー/Continuous Delivery)とは?】

CIによりコードに対する修正が問題ないことが確認できた成果物を各環境(テスト環境・ステージング環境・本番環境など)へデプロイしてアプリケーションを使用できる状態にします。

テスト自動化は、アプリケーションの品質を維持するために繰り返し行うテストです。具体的には、静的テスト・ユニットテスト・結合テスト・リグレッションテスト・負荷テストなどを自動化することによって、バグの混入を未然に防げます。また意図しない動作をリリース前に発見したり、開発の早い段階での対応が可能になります。

CI/CDとテスト自動化の関係性としては、頻繁にリリースを繰り返すようなアプリケーションに対して、開発時に繰り返し行うテストを素早く同じ精度で行えます。開発者の意図していない動作を検知できるため、品質を維持したまま頻繁にリリースを行える重要なパーツのひとつです。

JenkinsでCI/CD環境を作ってみた結果

きっかけは序章にもある「品質の高い状態を維持して開発期間を抑えたい」というところから、CI/CDを導入したいと思い、以下を目的として設定して始めました。

【 CI/CD導入の目的】

・レビューの時間を減らす

・単純バグをなくす

・デグレーションをなくす

・リリース作業の時間を減らす

導入の順序としては以下の順で進めました。順にご説明していきたいと思います。

【 CI/CD導入の順序】

  • 環境構築
  • CD作成
  • CI作成
  • 静的コード解析ツールの追加
  • ユニットテストコードの追加
  • リグレッションテストの追加

環境構築

環境構築はCI/CDツールの選定から始めました。JenkinsはDockerで簡単に構築でき、私の環境でも検証できそうだったためJenkinsを選びました。

CD作成

CD作成を先にした理由は、所属していたプロジェクトに自動化されたテストがなかったからです。またリリース作業だけで1時間ほどかかる状態で、よく人的ミスが起きる状態だったため、先に着手しました。CI/CDを導入する際には効果が見えるところから着手すると、自身のモチベーションが上がり、周りの作業効率もアップできるのでいいと思います。結果として、Jenkinsのジョブ実行をするだけでリリースできるようになり、これまで発生していたリリース作業の1時間がほぼなくなり、その際の作業ミスもなくなる効果がありました。

CI作成

CIを開発ブランチのプッシュをトリガーにビルドして成果物を作成するところまで作成しました。CI/CDを導入する際に時間を取得できるなら一気にやってもいいと思います。私の場合は空いた時間に構築していったので徐々に追加していきました。結果として、成果物の作成時間がなくなりました。

静的コード解析ツールの追加

レビューを減らすために、開発ブランチのプッシュをトリガーに、静的コード解析ツールを自動実行するようにしました。この際、解析結果を即確認できるように実行時のログに解析結果のリンクを表示していると、開発者がプッシュしたタイミングで自身の解析結果を確認して、修正するように開発者に通達しておく必要があります。結果として、レビュー時間を少し減らすことができました。

ユニットテストコードの追加

単純バグをなくすために、テストコードを書くようにしました。そして、CIの静的コード解析の後に実行するように変更しました。テストコードはすべてを一気に書くのではなく、まずは自身が触ったコードや影響度が大きいコードに対して徐々に追加するとコストもある程度抑えられると思います。結果として、レビューがほぼ不要になり、UI/UXのレビューに時間を割けるようになりました。

リグレッションテストの追加

デグレーションをなくすために、リグレッションテストをSeleniumで書くようにし、CIのビルド後に追加しました。リグレッションテストもユニットテストと同じく、一気に書くと開発が進まないことやコストがかなり上がるので、徐々に追加したほうがいいと思います。結果として、テストを追加した箇所のデグレーションをなくすことができました。

そして結果として、 CI/CD導入の目的は見事に達成できたのです!

【 CI/CD導入で達成できたこと】

  • レビューの時間を減らす
  • 単純バグをなくす
  • デグレーションをなくす
  • リリース作業の時間を減らす

CI/CDのテストを継続するためにやるべきこと

CI/CDの導入目的が達成できたと書きましたが、実は問題点もあるのです。

【 CI/CD導入時に問題になったこと】

  • 開発速度が上がると勘違いして案件が増える
  • 開発者がテストコードを書きたがらない
  • テストでエラーになりリリースできない
  • テストの負債がたまる

そのため、継続するためには導入する前からこれらの考慮が必要になります。

開発速度が上がると勘違いして案件が増える

開発速度は変わらないが、テストコードを書くため開発速度は遅くなります。開発が早くなるから案件を増やそうなどと考えないようにしましょう。

開発者がテストコードを書きたがらない

よく期間が短いためテストコードは省略しました・・、みたいなことを現場では見かけます。開発工数にテストコードを書く時間も含めて見積もり、開発者にとって余裕を持った期間を与えてください。テストコードを書かないと負債がたまりメンテナンスができなくなるため、CI/CDを導入する前と大してかわりません。

テストでエラーになりリリースできない

開発者自身で理由を調べて、テストコードのメンテナンスや修正箇所の修正を行ってもらえるように開発者の理解と協力が必要になります。修正範囲が広い場合は複数人で協力することで属人化を防げます。

テストの負債がたまる

どうしても緊急で対応しなければならない場合、影響度にもよりますがスキップするのもありだとは思います。ただ、放置せずに即テストコードのメンテナンスを行うようにしてください。放置したら今後二度と使用しないテストコードになり、時間をかけて始めたテスト自動化が無駄になってしまいます。

まとめ

CI/CDは開発業務の一部でも導入するだけでメリットはあります。テスト自動化した場合はテストコードを常に最新に保ってください。開発速度は上がりませんが、品質は維持できます。

CI/CDを入れることを悩んだら、まず一部だけでも導入してみてはいかがでしょうか。効果が目に見えてあればどんどん拡充したくなるはずです!

誰でもカンタンにテスト自動化ができる時代は、すぐそこまできています。当サイトでは、テスト自動化ツールに興味のある方へ、「テスト自動化 推進ガイドブック」と「テスト自動化ツールT-DASH 基本ガイドブック」のダウンロード資料をご用意しております。ぜひダウンロードいただき、資料をご覧ください。