PR

テスト自動化はユニットテストを分厚く

 2つめの自動テストの導入は、テスト実行を効率化する方法としては王道だ。テストを自動化するツールを導入して、実行手順や期待結果を記述した「テストスクリプト」を作成する。テストツールはテストスクリプト通りにソフトウエアを動作させて、テストを自動実行する。

 自動テストを構築できていると、次のスプリントのリグレッションテスト(プログラムの一部の変更でほかの箇所に不具合が出ていないかを確認するテスト)の手間を大幅に効率化できる。リグレッションテストは前回のテスト手順をほぼそのまま実施するからだ。

 ただし、アジャイルでの自動テストの導入には注意が必要だ。「自動テストではUIテストよりユニットテストを優先する」という原則を守らないと、自動テストが逆にテスト効率化の足を引っ張ることになる。自動テストにはいくつかの種類があり、得意領域が異なる。テストは種類ごとに3つの層に分けられる。これは「テストのピラミッド」として説明されることが多い。

テストのピラミッド
テストのピラミッド
書籍「初めての自動テスト」(オライリー・ジャパン)を参考に筆者作成
[画像のクリックで拡大表示]

 1番下の自動テストの層である「ユニットテスト」では、ファンクションやメソッドといった小さなプログラムや1つのプログラムをテストする。プログラムの規模が小さく、自動テストのジョブは早く終わる。つまり、テスト実行のスピードが高速だ。

 2番めの自動テストの層である「インテグレーションテスト」では、複数のプログラムに対してパラメーターを渡した結果の返り値を確認して、機能が正しく結合できているかどうかをテストする。多くのプログラムを実行してユニットテストよりも複雑さが増すため、実行スピードは遅くなる。

 最も上の自動テストの層である「UIテスト」では、画面に対して実際の利用をイメージした操作を行い、期待する結果になるかどうかをテストする。複数の画面を行き来するため、応答待ちや入力で時間がかかる。ユニットテストやインテグレーションテストに比べるとテスト実行のスピードが大幅に遅く、桁違いの時間がかかる。

 テスト実行のスピードはユニットテストが最も速く、UIテストが最も遅い。インテグレーションテストはその中間だ。下の層で実施できるテストを上の層で行うと、余計な時間がかかってしまう。自動テストの実行時間が長すぎて、リリース速度に影響するという本末転倒な事態も起こり得る。自動テストを構築する際には「このテストはより下の層でやれるのではないか」と常に自問する癖をつけるようにしよう。

 テスト実行のスピードだけでなく、テストスクリプトの改修時間の観点でも、できるだけ下の自動テストの層に寄せたほうがいい。下の層ほど改修が入りにくいからだ。UIテストで確認する画面のUIには頻繁に変更が発生するが、ユニットテストで確認するプログラムのファンクションやメソッドにはそうそう変更は生じない。

 自動テストでは「テストスクリプトの改修に時間を取られ、ほかのことができなくなる」といったトラブルがよく起こる。だいたいの場合、原因はUIテストの自動化に頼る比率が高すぎるからだ。できるだけ下の自動テストの層、ユニットテストでやれることはユニットテストでやるようにするとこうした事態を避けられる。

佐藤 博之(さとう ひろゆき)
SHIFT
ビジネストランスフォーメーション事業部 エンタープライズビジネスユニット 技術支援グループ アジャイル・自動化ファンクション ファンクションサブマネージャー
佐藤 博之(さとう ひろゆき) IT企業において、SIプロジェクトを中心に要件定義から運用保守に従事。2016年1月にSHIFT入社後、アジャイル案件を中心にテストマネジャー、テストエンジニアとして複数案件を担当。現在は技術支援部門のアジャイル・自動化ファンクションに所属。アジャイル案件を中心にQA部門立ち上げ支援、自動化構築支援など、プロジェクトを推進している。
池田 健太郎(いけだ けんたろう)
SHIFT
ビジネストランスフォーメーション事業部 エンタープライズビジネスユニット 技術支援グループ アジャイル・自動化ファンクション ファンクションサブマネージャー
池田 健太郎(いけだ けんたろう) IT企業において、組み込み関連プロジェクトを中心に要件定義から総合テスト工程に従事。2015年9月にSHIFT入社後、プロジェクトマネジャー、テストエンジニアとして複数案件を担当。現在は技術支援部門のアジャイル・自動化ファンクションに所属。アジャイル案件を中心にQA部門立ち上げ支援、自動化構築支援など、数多くのプロジェクトを推進している。