どんなときどのようにテストケースをバージョン管理するべきか

この記事は Emanuele Ciurleo によるゲスト投稿です。

テスターであるあなたは、ある時点で理解しているかぎりのアプリケーション要件を検証するために、そしてたいていは、開発ライフサイクルの特定のポイントで特定のバージョンのソフトウェアを対象として、テストを設計します。テストは機能要求および非機能要求を考慮するだけでなく、テスト対象システムの潜在的なリスクを軽減することもねらいとします。システムの特定部分の開発がとりわけ複雑であることがわかっていれば、要件として文書化されていないシナリオに基づいて、追加のテストをいくつか作成することもあるでしょう。そうすると、テストチームがどれだけ潜在的なリスクを理解しているかに応じて、テストスイートはより強固に対象を検証するものになります。これは、テスト駆動型開発の一部として作成されるテストにも、Seleniumスイートを構成する自動化テストにもあてはまります。あなたがテストを作成したとき、それはテストするべきものをテストしていました。すばらしい！

ところが、アジャイルの世界では特に、ソフトウェアは常に発展し続けます。あなたの理解度が変わり、要件が変わり、必然的にコードが変わります。

したがって、あなた(やチームのメンバー)が念入りに作り上げたテストスイートがアプリケーションの新しいバージョンにはもう適合しないということもまれではありません。ドロップダウンがラジオボタンに変更された場合、対応する新しいテストのセットが必要になり、古いテストは不要になります。そこでテストを見直して、新しい要求に合うよう更新します。きわめて簡単なことです。

ところで、バージョン1.4.2から1.4.3へのアップデートで、「姓」フィールドの最少文字数のテストに使用される値が3文字から2文字に変更されたとします。古いバージョンに対してテストを実行しても成功しますが、なぜテストは変更されたのでしょうか? この変更には予期しない影響があるでしょうか？このテストをバージョン1.4.2に対して実行するのは適切でしょうか？バージョン1.4.2用にテストスイートを作成し、バージョン1.4.3に合わせてテストを変更したのであれば、デプロイメントが失敗したとき、どうやってロールバックシナリオをテストすればよいのでしょうか？バージョン1.4.3だけでなく1.4.2のテストも保存しておく必要があります。

いつどのようにテストケースが変更されたかを理解できれば、コンテキストや、テストケースが検証する範囲を理解するのが容易になります。テストを作成したテスターには、機能がどうしてそのようにテストされたかは明白だとしても、今日、新しいメンバーが入ったとして、理解できるでしょうか？バージョン履歴があれば、当初に想定されたテストの検証範囲や、時間が経つにつれて、どんな理由でどのようにテストが発展してきたかを新しいメンバーも理解できます。また、時間をおいて行なわれたいくつもの小さな変更によって、作成当初の検証範囲をテストがもうカバーしていないという事態を防ぐのにも役立ちます。

規制の厳しい環境で作業している場合は、法制コンプライアンス基準を満たすために、ミッションクリティカルなアセットの以前のバージョンを保持することが非常に重要である場合があります。たとえば、情報セキュリティの管理について定めたISO/IEC 27001:2006では、ドキュメントには管理上の決定の記録を含めることとし、セキュリティ管理策からリスク評価プロセスやポリシーへのトレーサビリティが重要であるとされています。テストケースのバージョン管理は、実施されたテストアクティビティに関する完全な履歴レコードを保持し、開発からテストおよびリリースまでの完全なトレーサビリティの証明を可能にします。

よくあることですが、おのおのの状況によって、うまくいく方法は異なるかもしれません。しかし、基本となるいくつかのツールを使用するのは、テストのバージョン管理を導入する手始めとして役立ちます。

バージョン管理システム
テストケース管理: テストケースをバージョン管理する方法
テストケースをバージョン管理することの利点
まとめ
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■
- テストの生産性向上をTestRailでお試しください

バージョン管理システム

コードのバージョン管理は、ソフトウェア開発において広く受け入れられている作業方法であり、これを実現するのによく使われるツールがGitです。Gitの2大サプライヤーはGithubとGitlabですが、そのほかにも選択肢があります。Gitでは、コードとして作成されたテストに対するすべての変更がコミットされます。Gitの強力な機能を利用して、特定のブランチやコミットにバージョン番号を含むタグを付けることができます。

コードのバージョン管理と同様に、テストケースをバージョン管理すれば、テストケースの複数のバージョンを並べて比較したり、以前のバージョンのテストケースを復元したり、プロジェクト内に複数のブランチを作成し、テストケースのコピーを持ったりすることが可能になります。

開発チームとの連携によって、テストのバージョン番号とソフトウェアのバージョンを合わせることができます。つまり、バージョン1.4.2のテストスイートは、バージョン1.4.2のソフトウェアリリースをテスト対象とします。

テストケース管理: テストケースをバージョン管理する方法

タブやスプレッドシートを分ければ、ExcelファイルやGoogle Sheetに記述されたテストをバージョン管理することもできますが、過去のテストケースデータを探すのがめんどうです。また、テストケースのバージョン管理をサポートしていない他のツールでは、大量の過去のバージョンを搔き分けて目的のデータを探し出すことになる可能性が高いでしょう。これは理想的な状況とは言えません。

TestRailのようなテストケース管理ツールを使用すると、統一されたプラットフォームでテストケースを管理できます。もちろん、テストケース管理ツールはテストケースの作成に利用できるものですが、TestRailなどの一部のツールは、複数のバージョンにわたるテストケースへの変更を自動的に記録します。

*TestRail Enterprise版のテストケースバージョン管理機能は、任意の2つのバージョンのテストケースを並べて表示し、差異をハイライトできます。*

TestRail を利用すると、複数のバージョンにわたって発生した変更をすばやく解析し、すみやかに意思決定を下すことができます。複数のバージョン間の差分をハイライト表示し、簡単に比較できるため、問題を修正する方法や、バグが発生している理由、何かが想定されたとおりに動作していない理由をよりよく理解できます。

ソフトウェアプロジェクトが拡大するにつれ、どんなテストチームも要件やテストケースの変更を複数のリリースに渡ってどうやって管理していくかについて考えざるをえなくなります。

テストケースをバージョン管理することの利点

アプリケーションが進化するにつれて、シナリオに対するテスターの理解も進化し、テストの検証範囲も変わるでしょう。履歴情報が保持されていれば、テストスイートやスモークテストに入れるテストケースを選択する際に参考にできる情報が増えます。

たとえば、テストの一環として、何らかの暗黙的な動作を検証するためにテストを作成したとします。すると、そのテストが変更されたとき、意図的にしろ、そうでないにしろ、検証対象としていた暗黙的な非機能要求(NFR)は失われます。情報が失われると、その後の意思決定では考慮されないため、意図しない結果が発生することや、テストが期待通りに動作しないといった事態につながる可能性があります。

もう1つ考慮すべきシナリオは、業界によっては、リリース時に実施されたテストに関する書面でのテストレポートが求められることです(特に官庁、医療、金融などの分野ではそうです)。バージョン管理されていれば、ツールを使って「過去に戻り」、特定のリリースに対してどのテストが実行されたかを正確に把握し、レポートを生成できます。2020年のリリース1.1ではどんなテストが実行されたか？スキップされたテストまたは失敗したテストはあったか？シナリオXまたはYはテストされたか？テストケースのバージョン管理は、このような疑問に答えるのに役立ちます。

まとめ

結局のところ、なぜテストケースのバージョン管理は重要なのでしょうか？それは、テストケースのバージョン管理によって、テスターや他のメンバーが、プロジェクトのライフサイクルを通じてテストがどのように発展し、変化してきたかを理解できるからです。履歴情報が利用できれば、テスターはじゅうぶんな情報を得たうえで、作業品質を確保するためにどこに(多くの場合は限られた)時間を費やすかを決定できます。また同様に重要な理由として、チームに新しくテスターが入ったとき、あるテストが過去にどのような理由で変化してきたかという意思決定プロセスを確認したり、そもそも、テストがもう不要ではないかどうかを判断したりするのが容易になります。これは、新しいテスターがより効率的にスピードに追いつくのに役立ち、チームメンバーの頭の中にだけ蓄えられたローカルな知識の問題を軽減します。最後に、おそらく最も重要な理由は、テスターであるあなたが「何をテストしましたか」と聞かれたときに、自信をもって答えることができるからです。

著者は15年以上にわたってソフトウェア開発ライフサイクルにおけるさまざまな役割を果たし、DevOps基盤、カスタマーサポート、ソフトウェア開発、チームおよびプロジェクト管理などに携わってきた経験から、ソフトウェア開発とは、またエンドユーザーへのソフトウェアのデリバリーを効果的に管理するとはどんなことであるかについて、360度の視野を持っています。アジャイル手法を熱烈に支持し、アジャイルの基本原則の普及活動や、アジャイル初心者へのコーチングを通して、締め切りと予算どおりにデリバリーできるパフォーマンスの高いチームの構築を支援しています。

※ 本記事で紹介している「テストケースのバージョン管理機能」は今後日本リリース予定のバージョンでご利用可能になる予定です。

（この記事は、開発元Gurock社の Blog 「When and How to Version Control Your Test Cases」2022年3月14日の翻訳記事です。）