要求管理とテスト管理、その間のトレーサビリティの維持、および要求(仕様)カバレッジの把握 －－－ TestLinkとExcelツールで運用する

TestLinkは上流からもっと活用できる

TestLinkはオープンソースのWebベーステスト管理システムです。公式サイトのtestlink.org から、Get a Bitnami Virtual Applianceをクリックしてbitnamiのサイトへ行けば、インストーラが入手でき、簡単に始めることができます。
（例えばWindowsのクライアントPCでも、手軽にインストール／アンインストールを繰り返すことができるので、気楽に試行錯誤しながら運用方法を検討できる環境が得られます。）

MantisやJIRA、Bugzilla,Trac,Redmine、FogBugzなどのバグトラッキングシステムとも連携可能であるとWikipediaのTestLinkの項で説明されています。
他にも紹介されている主な機能の中に「要求仕様を登録しテストケースと関連づけ」があり、また利点として、「要求仕様とテストケース、バグ票を関連付けて管理できる」と記載されています。

私はといえば、以下の点に特に注目してその利用を始めました。

• テストだけではなく、要求(仕様)リスト(階層構造)を管理できる
• 要求(仕様)からテスト設計(テストケース)、テスト結果、(バグ票)までのトレーサビリティを管理することができる
• 要求カバレッジや仕様カバレッジの把握が容易になる

しかし、本当に実務の中でこの利点を十分に引き出そうとするとに、運用レベルでの工夫が必要となります。
本稿ではそのプラクティスの一つを示します。
ここでご紹介するのは、テストレベルで言うと主に上層を対象とするものです。そう了解してください。

特徴としては、要求とテストケースを直結するのではなく、間にテスト要求分析を挟むことを前提とした構成にしたことです。こうすることで無理なくトレーサビリティを維持できるようになっています。

また、要求仕様をUSDMでExcelシートに記載している場合に、その情報をTestLinkでインポート可能なXMLファイルに出力するExcelツール(USDM2TestLink) を作成しましたので、そのツールの紹介もします。

このツールの特徴は、次の通りです。

• 要求仕様(要求リスト)がUSDMで作成されていることを前提としている
• 要求仕様とそれに対応するテスト要求のレコードを追加するためのXMLを出力する
• テスト要求に対応する(リンク済み)テストケースのレコードを漏れなく追加するXMLを出力する

この特徴の意味するところですが、トレーサビリティを確保したレコードを一気に作ってしまえるところにあります。

テストケースのレコードを新規作成する度に、対応する要求の方のレコードにリンクを張っていく作業はとても面倒です。なので、最初に要求側と1対1でリンクを張った状態のテストケースまでを全部一気に作成してしまうことにしました。
もちろん、いつも1対1になっている必要はないですし、それを推奨しているわけでもありません。ただ、1対1にリンクされた状態を出発点として、設計の中でテストケースのレコードを複製したり、統合したり、構造を変形していけば作業し易いと考えたわけです。
新しく作成したレコードにリンクを張る作業に比べると、既に張ってあるレコードを複製したり統廃合したりする方が手間がかからないですし、網羅性も維持し易いと思います。

プラクティス紹介

要求仕様はUSDM(Universal Specification Describing Manner)のような階層構造を持つリスト形式で与えられていることを想定しています。
（USDMではない場合でも、要求(仕様)がリスト形式になっていることは多いと思います。）
さて、テストとの関係で要求(仕様)カバレッジをしっかりと把握したいと考えた場合、これらの要求側のレコードとテストケースのレコードとの間にリンクを張って管理すれば良いと考えるのは自然なことです。
実際、ここで取り上げるTestLinkにはその機能がありますし、そのような使い方を紹介する記事も幾つも見付けることができます。
しかし、ここで紹介する方法は先述した通り、少し別の工夫が入っています。

まず、Test.SSF でも示されている通り、テストライフサイクルも進化してきており、テストもいきなり詳細設計や実装に入るようなことは今や推奨されてはいません。
テストについても要求分析やアーキテクチャ設計といった手順を踏むべきです。

ここではその部分にテスト設計技法の一つとして知られるHAYST(Highly Accelerated and Yield Software Testing)法のFV表(Function Verification Table) を使うことにします。
（HAYST法は最終的に直交表を使った組み合わせテストを含むので、そこにばかり注目が集まってしまう傾向があります。誤解の無いように断っておきますが、ここでは直交表や組み合わせテストは関係ありません。ここで関係するのは、もっと上流の汎用的な部分のみになります。）
なぜFV表なのかといえば、それは他の技法に比してシンプルでありながら必要十分で、それ故に汎用性も高いと思えるからです。
ここで必要十分といった意味は、次のようなことです。
まず、FV表は分析結果の全てをそこに詰め込もうとするようなものではありません。基本的にはそれはテスト対象を(HAYST法オリジナルでは目的機能毎に)分割したものでしかないのですが、要求やテストと一緒にレコードとして登録しておく情報単位としてはちょうど良いのではないかと思うからです。
でももしも分析結果を全て登録しておきたいとか、他の技法が好みであれば、添付ファイルやカスタム属性等を定義してここに盛り込んでいけば、何とかなるのではないかと思います。

さて、ここでの狙いをV字モデル上に表現すると以下の図のようになります。

また、USDMとFV表がどのような形式のものであるかを、以下の図に示しておきます。

図を見るまでもなく、USDMとFV表がだいたい対応付けられそうだ、と気づいている方は多いと思います。双方ともにFeature Set のヌケモレを防ぐということを主たる目的に掲げていると思いますので、当然の結果だと言えると思います。
この関係を利用していきます。
（厳密に言うと、FV表は元々は機能検証表(Function Verification Table)のことで、ここに挙げる機能とは目的機能のことになります。しかし、ここの段階ではそのことには拘らないことにします。なので、ここではもはやFV表とはFeature V&V Tableのことである、と定義し直されていると考えて頂いた方が良さそうです。）

次に、このUSDMとFV表がTestLinkのデータ構造の中でどのように管理されるかを以下の図に示します。

この構造で、要求とテストの間のトレーサビリティが確保できます(辿ることができます)。
（私は最初、FV表の各行をTestLinkのTestSuiteに対応付けしようと考えました。しかし、それではトレースが維持できず、上手くいきませんでした。TestSuiteはテストを分割したり纏めたりするためのものです。それに対し、FV表はテスト対象のFeature Set を分割するものです。このことを踏まえて改めて見直してみると、今回示しているプラクティスは実はもともと必定な結果のように思います。）

縦線で区切られた左側で既存の文書形式(USDMとFV表)とその中の項目までを示し、右側は紫色のノードでTestLinkのレコード種別を示してあります。そして、それらをどのように対応させるかをオレンジ色の矢印で示しています。

左側の緑で表現されている項目はUSDMのものであり、薄い水色で示される項目はFV表のものです。

色の濃い青い項目は、従来知られている項目に対し、ここで少し拡張して新しく導入したものになります。

ここではFV表は目的機能に拘らないことにしているので、USDMの要求に対しても、仕様に対してもまずは1行ずつ機械的に対応付けています。また、「V&V区分」は、USDMの要求に対してはValidation、仕様に対してはVerificationを機械的に割り付けています。

「テスト設計区分」が何かということについては、定義が必要であるようなものを考えているわけではありません。例えばということで、次のような項目にしてあります。(ツールでTestCaseを生成すると、TestSuiteとして以下のレコードも生成します。)

• "無則組合せ(HAYST法)テスト"
• "単機能テスト"
• "有則組合せテスト"
• "禁則組合せテスト"
• "状態遷移テスト"
• "シナリオテスト"
• "負荷テスト"
• "セキュリティテスト"
• "非機能テスト"
• "エラー処理テスト"

ツールはFV表の1行毎にリンクで対応付けられた一つのテストケース(もちろんレコードを作るだけで内容は空っぽですが)を作成します。そして「V&V区分」がVerification（すなわちデフォルトのままであればUSDMの仕様に対応）のものが "単機能テスト" に属し、Validation（すなわちデフォルトのままであればUSDMの要求に対応）のものが "無則組合せ(HAYST法)テスト" に属するようにしてあります。

最後まで1対1の関係を維持しなければならないわけではありません。「テスト設計区分」についてもこれをいつも推奨しているわけでもありません。作業が容易になる出発点としてこの構造を提案しています。最初に1対1の関係を仮定したところから構造を組み替えていく方式を採ることで、トレーサビリティ情報の維持管理を容易にし、カバレッジが容易に確認できる状態を維持します。

ここで、ソフトウェアテストの国際標準規格ISO/IEC/IEEE 29119との対応関係を見てみましょう。ISO/IEC/IEEE 29119のPart2の「8.2 テスト設計及び実装プロセス」にはテスト設計および実装手順は以下のように示されています。(逐次とは限らず反復されても良い、とされている。)

• テストベース分析からの特質集合(feature set)の抽出
• テスト条件の抽出
• テストカバレッジを抽出
• テストケースの作成
• テスト集合の組み立て
• テスト手順の作成

「ここに示されている手順と対応付いた運用がしっかりとできそうだ」と思って頂ければ、ここまでの説明はまずます成功したということになるでしょう。（そう願って記載しています。）

ところで、上の図で緑の中に一つだけ青で示されていて目立っていると思われる「目的」についてまだ説明していませんでした。
先述した通り、「USDMとFV表がだいたい対応付けられそうだ」ということをここまで利用してきています。しかし一方、簡単に対応付けてはいけない違いもあります。
USDMは「理由」を重視しており、FV表は「目的機能」を重視しています。
この違いをよく理解して運用することが重要です。
残念ながらこの説明は簡単ではないので、また別の記事にしたいと思います。
「目的」と「理由」がどう違うのかについては、Facebookノートに「USDMとHAYST法を上手につなげるには」 というタイトルで一度記載しているので、参考にしてください。

Excelツール紹介

【基本的な使い方】

ツールはUSDM2TestLink.xlsmという名前のExcelファイルで提供 しています。このExcelファイルのBookを開き、〔XML出力指示＆設定〕シートから処理を指示します。下図参照。

処理したいUSDMの要求仕様書を格納するフォルダと、TestLink用のXMLファイル出力用の二つのフォルダを準備します。
〔XML出力指示＆設定〕シートの「入力パス設定」「出力パス設定」ボタンを押すと、フォルダ選択ダイアログが現れますので、それぞれ用意したフォルダを選んで設定してください。
処理したいUSDMのExcelファイルを「入力文書フォルダ」に設定したフォルダに格納します。
このとき、それらのファイルのバックアップを取っておいてください。
本ツールは入力ファイルの全てのUSDMのシートについて、その右側の列にFV表を挿入する処理を行います。つまり入力ファイル側も書き換えるので、万が一に備えてバックアップの作成をお願いします。これで準備は出来ましたので、処理の実行です。
（USDMの形式は微妙に差のあるものが存在していると思います。本ツールはスパークスシステムズジャパン株式会社の製品Enterprise ArchitectのUSDMアドインが出力する形式に合わせています。私が別途公開しているFreeMind形式から変換するツール が生成する形でもあります。形式が確認できるように雛型として使えるExcelファイルを今回紹介したツールの方のリポジトリにも置いておきます。）

〔XML出力指示＆設定〕シートには以下の二つのボタンがあります。

• 「全処理(FV表追加＋XML出力)開始」
• 「FV表追加処理のみ」

「全処理(FV表追加＋XML出力)開始」ボタンを押すと、入力文書フォルダにあるExcelファイルを、そしてその中の各シートを順番に開き、USDMであるか否かを判定し、USDMであればその右側の列にFV表を挿入します。そしてTestLink用のXMLファイルまで一気に出力します。
処理結果は〔処理結果記録〕シートの方にリストとして記録されますので、そちらを確認してください。

出力文書フォルダには以下の3つのフォルダが新しく作成されます。

• 「要求」
• 「テスト」
• 「ログ」

「要求」フォルダにはUSDMの要求と仕様、FV表の情報を登録するためのXMLファイルが生成されています。
「テスト」フォルダにはFV表の各行に対応付くテストケースの情報を登録するためのXMLファイルが生成されています。
「ログ」にはExcelシートのセルをどう認識したかを記録したHTMLのテーブル形式で出力したファイルが生成されています。不十分なHTMLモドキですが、ブラウザで表として表示できると思います。

「要求」側と「テスト」側の2種類のXMLファイルをそれぞれTestLinkに登録すれば、上記してきたプラクティスをスタートさせるデータ構造がTestLink上に出来上がると思います。

もう一つの「FV表追加処理のみ」の方のボタンですが、これを実行した場合はFV表の挿入だけを行い、XMLは生成しません。
TestLink上ではなく、先にExcel上でFV表の内容を記載したい場合に使用します。
記載後に「全処理(FV表追加＋XML出力)開始」ボタンを押せばXMLを出力できます。
どちらのボタンの処理も、既にFV表が存在するならば、2重に挿入したり、内容をクリアするようなことはありません。（FV表のタイトル部で既存か否かを判断していますので、タイトル部を編集しないでください。）

【その他注意】

• TestLinkのカスタムフィールドを使います。最初にcustomFields.xmlをTestLinkに登録しておくなど、整合性を確保するようにしてください。
• チェックボックスの数、〔XML出力指示＆設定〕シート上での「意味」の文字列とTestLinkのチェックボックスの文字列が一致しているか確認してください。
• その他の設定項目については、基本的にデフォルトのまま使用することを推奨します。
  • せっかく項目が分かれているのでカスタムフィールドに分けたくなりますが、カスタムフィールドのテキストエリアは長さに制限があり、元の情報が途中で切られてしまう可能性があります。
  • また、細かく分けてもそれほど使い道は無いように思います。
• USDMにおける認定仕様については、これを認めないことを推奨します。
  • 認定仕様を認めると、要求でもあり仕様でもある行ができてしまうことや、1層目の場合左の列が空いていないのでその表記法が定まらない等の不都合があり、その判定についても処理の仕方についても、ツールのプログラムを複雑化させる原因になっています。一応対処できるようなコードは入れてありますが、あまり良い仕様になっているとは思っていません。
  • 仕様としてどうあるべきかと考えてみると、プログラム上の都合の事等ではなく、認定仕様についてはやはり本来認めるべきではないと思えてきます。
  • 作るときには良いとして、テストを考える時点までにはこれはちゃんと要求と仕様に分けておくべきです。Verificationが検討されない部分を残しておくのはどう考えてもよろしくないと思うからです。

おわりに

TestLinkについては少し古い記事ではありますが、「きちんと学びたいテストエンジニアのためのTestLink入門」など、参考になる情報がWeb上で見つかると思います。
また、書籍でも『Redmineによるタスクマネジメント実践技法』 の中に「第3部 RedmineとTestLinkの連携(TestLinkの運用方法)」として運用方法の記載があります。
ただし、そこに記載されているのはテスト領域の運用方法ということになっていますので、今回ここに紹介した上流のプラクティスと合わせて頂ければ、もっと活用の領域を広げることができ、一貫した管理が実現できると思います。

テスト管理ツールも新しいものがいろいろと出てきており、そういった新しいものに比べるとTestLinkはUIが少し古びて見えてしまうこともあり、また目につきやすいところでもあるので悪口も散見されます。
しかし、古くからあるということは実績を積み上げてきたということでもあり、上流からしっかり活用できるものとしてまだまだ活躍の場があるものと思っています。