プログラマの思索

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か？概要や定義、現場での使われ方について解説

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか？
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか？

この辺りは色々考えてみたいと思っている。

TestLinkの要件管理にUSDMを適用する方法が紹介された記事をメモ。

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

USDMは清水吉男さんが提唱されている派生開発XDDPの要件管理技法の一つ。
僕の理解では、CMMIなど今までのソフトウェア工学の知見をベースにきちんとしたプロセス設計で開発しましょう、というものと思っている。
USDMでは、要件をFV表に対応付けることで漏れなく管理できるようにした仕組みと理解している。
「要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?」でも紹介されている。

USDMの考え方はとても良く考えられていると思うが、実際の運用ではExcelベースなので使いづらい部分が個人的にはあった。
しかし、上記の記事を読むと、ExcelでUSDMで要件を作り、TestLinkの要件管理機能にインポートして一括管理するようだ。
これは個人的に面白いと思う。

以前、TestLinkでテスト管理した時に要件IDを振って運用してみた時があった。
すると、要件カバレッジが取れるので、テスト結果の時系列推移ごとに、要件をどれだけテストでカバーできたのか、を見ることができる。
また、テスト後に、どの要件でバグが発生したのか、その割合を算出することで、障害の原因分析にも使える。

OSSのテスト管理ツールTestLinkはまだ可能性があると思うので気になった時に調べてみたい。

TestLinkのテストケースはクラスとインスタンスの考え方で区別するツイートを見つけたのでメモ。

[QCの基本]テストインスタンスについて｜Tsuyoshi Yumoto｜note

TestLinkでは、テストケースそのものの管理とテスト結果を記録する機能が分離されている。
この考え方は、テストケースがクラス、テスト結果がインスタンスで区別すると理解しやすい。
メリットは、回帰テストを実行できること、テストケースを再利用しやすく保守しやすいこと。

「Redmineによるタスクマネジメント実践技法」でもTestLinkのこの考え方は記載していた。

しかし、現場のExcelテスト仕様書では、テストケースとテスト結果は分離されていない場合がほとんどだろう。
だから、回帰テストの管理が面倒だし、障害管理との連携もスムーズでない。
その理由は、テスト管理ツールが導入されておらず、Excelで頑張っているからだろう。

下記ツイートにあるように、テストケースをクラスとインスタンスで分離する考えは、本来はSIで最も有効なのにね。

テスト管理ツール入れるなからこの概念が実装されてることが必須条件です。#テスト管理ツールはテストインスタンスがキモ
[QCの基本]テストインスタンスについて｜Tsuyoshi Yumoto @yumotsuyo #note https://t.co/FG1B7RPOSi

— Tsuyoshi Yumoto (@yumotsuyo) June 22, 2021

TestRailもPractiTestも、古いので有ればTestLinkもちゃんとこの思想で実装されてたよ。当然IBM、oracle、hpから出てた有償のバカ高いテスト管理ツールもこの思想で作られてた。

— Tsuyoshi Yumoto (@yumotsuyo) June 22, 2021

<s>ぶっちゃけ、本来強力な効果を発生するであろうSIer的な環境ほど採用はきびしいです。いいたかないですが、テスト仕様の版管理とか、テスト仕様と実行結果は分離すべきいう概念自体が理解できる人間が管理者レベルにおいても少ない傾向があり、教育コストが高くなりすぎます。</s>

ア

— D-Hori (Web技術アカ) (@d_hori_web) February 10, 2021

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルが公開されていたので自分用にメモ。

【参考】
CATとは？ :: CATマニュアル

TestRail ドキュメント

QualityForward マニュアル

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

2022年現在、日本で有償のテスト管理ツール導入を考えた場合、上記の3つに絞られるのではないだろうか。
理由は、3社ともに日本の開発元、販売元であるので、サポートを受けやすいためだ。

僕としては本来はOSSのTestLinkを使いたいが、やはり使いにくい場面も多い。
上記3つの有償のテスト管理ツールはUIもよく考えられていて、マニュアル無しでもソフトウェア開発チームならばすぐに導入できるだろうと思う。

個人的印象では、CATとQualityForwardはExcelテスト仕様書のUIイメージに近い。
だから、Exccelのテスト仕様書をWebに置き換えただけ、という感覚で使える。

一方、TestRailは、テストケースを全てWeb上で一括管理するためのツールだ、という特徴を強く押し出している。
Web上でテストケースを追加したり更新したり、Redmine障害チケットと連動したりするUIがすごく使いやすい。
Redmineがチケット管理をWebに置き換えたように、TestRailはテストケース管理をExcelからWebへ完全に置き換えたイメージに近い。

よって、僕の感覚ではTestRailが好きなのだが、やはりテストケースは数千～数万も登録する必要があるので、そのままでは現場で使えないと思う。
そこで、事前にCSVやXMLで大量のテストケースを作り込んで一括インポートし、実行フェーズではTestRailで運用する、というやり方が一般的ではないか、と推測している。
つまり、TestLinkを運用する時と同じように、事前にExcelテストケースは準備し、一括インポートした後、テスト実施管理はTestLinkでやる、みたいな感じだ。

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルをより詳しく読んで理解したいと思う。

テスト管理ツールに触った経験が少しだけあった。
TestRail、CAT、QualityForwardの感想をラフなメモ。

【参考】
テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

CAT | テスト管理ツール | 株式会社SHIFT

テスト管理ツールQualityForward｜ソフトウェアテスト・第三者検証のベリサーブ

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

脱Excel！ TestLinkでアジャイルにテストをする：エンジニアがお薦めする 現場で使えるツール10選 - ＠IT

SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」

ETWest2009講演資料「TestLinkでアジャイルにテストする」

【1】欧米製のテスト管理ツールと日本製のテスト管理ツールでは、やっぱり発想が全く異なる。

TestRailはドイツ製。
テストケースは全てWeb上で管理する。
Excelのテスト仕様書は完全に廃棄される。

だから、TestRailではWeb上のUIが非常に使いやすい。
テストケースをツリー構造で表したり、Redmineの障害チケットと連携したり、テストケースをフィルタリングするのがやりやすい。
UIはTestLinkよりもはるかに使いやすい。

一方、CATやQualityForwardは日本製。
Excelのテスト仕様書をそのままインポートして、UIもExcel上のテストケースと全く同じ。
たぶん、従来の日本のソフトウェア開発チームならば、普段はExcelでテストケースを管理しているので、運用しやすいだろう。

【2】TestRailとCATやQualityForwardの大きな差は、テスト集計機能の有無にあると思う。

CATでは、SubversionやGitと連携する機能があるのでソースコード行数を保持できる。
だから、テスト密度、バグ密度を表示する機能もある。
また、信頼度成長曲線、PB曲線も表示してくれる。
つまり、日本のSIが品質管理で使いたいと思う機能は、一通り実装されている。

QualityForwardでも、PB曲線は表示される。
またカバレッジパネルという機能もある。
これは、テストケースの項目別集計に対し、テスト結果の割合を表示して、どれくらいテストを消化したのか、バグが多く出ているのか、などを表示する。

一方、TestRailでは、テスト集計機能はほとんどない。
テスト結果の状況を表示するサマリ画面はあるので、テスト状況をさらに細かくドリルダウンすることはできる。
また、バーンダウンチャートもあって、テスト時間を計測すれば、予実で表示されるみたい。
しかし、基本は、REST APIでBIツールに取り込んでもらうか、CSV出力して自分で集計してもらうことが必要。

【3】こういう内容を書くと、日本製のテスト管理ツールの方が良さげに見えるが、僕はTestRailの方が使いやすそうに思えた。

実際に画面に触れてみれば分かるが、TestRailの方がRedmineのようなUIに近い。

TestRailのマイルストーンは、Redmineのバージョンと同じ。
TestRailのテストケースは、Redmineのチケットと同じ。
そうみなせば、Excelのテスト仕様書はいらない。
そもそも、Redmineを使い始めたら、ExcelでWBS管理や課題管理はやらなくなる。
それと同じ。

日本製のテスト管理ツールにはテスト集計機能があるので、色々使えそうと思ったが、罠も多い。

まず、テストケースや障害チケットの粒度を揃えたり、テストケースや障害チケットの分析項目を標準化したり、集計する以前の前処理にすごく手間はかかる。
本来は、テスト作業やテスト成果物は標準化できていればよいが、やはりシステムごと、案件ごとに微妙にカスタマイズされているので、その辺りに規制をかける必要がある。

また、信頼度成長曲線をツール上で表示する時、障害チケットをインポートするタイミング以降でしかグラフを表示してくれない。
つまり、テストを始める前に、テスト管理ツールとRedmineを連携しておく必要がある。
テスト途中でRedmineと連携する設定を行うと、インポートする日以前のバグ発生数のグラフが表示されない事象が発生する。
なぜそんな仕組みなのか分からないが、Redmineチケットのカスタムフィールドをテスト管理ツールに取り込めないケースもあるし、信頼度成長曲線のグラフで表示したい日付情報をチケットのカスタムフィールドで対応できないケースもあるからだろう。

テスト密度やバグ密度も表示されるのは便利だが、結局、そのデータの妥当性を精査する必要があるし、テスト密度やバグ密度が基準範囲から外れていれば、細かく原因分析する必要がある。
よって、ツールで集計されたデータをそのまま鵜呑みにはできない。

そんなことを考えると、テスト管理ツールもRedmineと同じく、テスト管理の予定と実績を蓄積するのに専念し、テスト集計機能はBIツールを使ったり、自分でExcelやRで集計するように、作業を分離した方が良いと考える。
集計して分析する作業はどうしても標準化できないから。

【4】まとめると、TestRailはExcelのテスト仕様書を完全になくしてWeb上で完結する。
Redmineライクな感じ。

一方、CAT、QualityForwardはExcelのテスト仕様書をそのままインポートできるので、ExcelをWeb上で触っている感じ。

たぶん、日本のIT企業のテスト管理や品質管理は機能の網羅性テストを重視していて、欧米のIT企業のテスト管理は機能の充足よりもいちはやくリリースできる品質を担保する観点を重視する、という違いが出ているように思えた。
この辺りに、日本人の品質管理の思想と欧米のアジャイルな品質管理の思想の違いを感じる。

とはいえ、テスト管理ツールは発展途上のツールと思うので今後も見ていく。

人類よ！これがテスト管理ツールだ！テスト管理ツール天下一武道会がついに開催！ - connpassを視聴してみて、最近のテスト管理ツールについて興味を持った。
ラフなメモ。

【参考】
人類よ！これがテスト管理ツールだ！テスト管理ツール天下一武道会がついに開催！ - connpass

テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

そうだ TestRail を使ってみよう。 - Qiita

TestRail 入門 [TestRail Documentation]

10年前にTestLinkを一通りいじくり倒した経験があるので、テスト管理ツールの良し悪しは知っているつもり。
今回のイベントで、有償のテスト管理ツールのTestRailに興味を持った。

TestRailの良い点は、UIがとても使いやすいこと。
マニュアルがなくても、テストケースを作ったり、テスト結果のOKやNGを登録したり、サマリを見る、とか、直感的に操作できる。
テスト管理ツールはどれも、複雑な操作が割と多くて使いにくい。
だから、使いやすいUIはとても重要。

もう一つは、TestRailは外部接続APIが豊富なこと。
デモでは、TestRailsでAutomation機能を有効にした後、mablで自動テストを実行させて、その結果をTestRailに登録し、結果がNGならBacklogに起票して、その通知をSlackに流す一連の操作が、全て自動化されていた。
TestRailのREST APIを使って、Pythonスクリプトで操作したらしいが、こういう一連の自動テストの実行と結果の記録、バグチケットの起票、チャットへの通知はよくある利用シーンなので、とても面白い。

最近は、テスト自動化がかなり当たり前になってきた状況もあるので、ビジネスロジックのxUnitをJenkinsで定期実行して、その結果をTestRailに記録させる、とか、UIテストの自動化ツールmablを使う、とか、色んな利用シーンがある。
テストでは、バグチケットの起票、テスト結果の通知はできるだけリアルタイムに共有したいので、こういう一連の操作が自動化できる方が断然良い。

開発プロセスの改善という観点では、チケット管理システムの分野は既に当たり前になってきているが、テスト管理の部分はまだ未開拓の分野が多いように思う。
だからこそ、数多くの有償ツールが出回って、いろいろアピールしているのだろうと思う。
この辺りは、調べて見る価値はありそう。

テスト管理ツールに必要とされる機能要件は欧米と日本で異なるのではないかという記事を見つけたのでメモ。

【参考】
欧米のテスト管理ツールとCATにおける、要求の違いについて - CAT Tech Blog

TestLink利用に際して参考になるブログ - misc.log

テスト工程の管理をするツール、TestLinkについて - Qiita

脱Excel！ TestLinkでアジャイルにテストをする (1/6)：エンジニアがお薦めする 現場で使えるツール10選（5） - ＠IT

テストを育てるためにテスト管理ツール「TestRail」を使ってみた | 「世界」旅と子育てを愛するアジャイルコーチのブログ

ちょっと今、テスト管理ツールをもう一度調べている。
10年前はTestLinkを使っていて、それなりにテスト管理の技法は研究していた。
しかし、TestLinkそのものに不満が色々あって、結局使わなくなってしまった。

とはいえ、テスト管理をExcelでやるのは時代遅れ。
テスト管理のように、数千～数万のテストケースの予実管理を行う管理作業こそ、ツールで自動化すべきだ。
なのに、なぜ、特に日本では、テスト管理の重要性は知っているにも関わらず、テスト管理ツールが普及しないのか？

上記の記事では、欧米と日本では、品質に関するリスク管理の観点が異なるからではないか、と指摘している。
欧米では、シェア確保と先行者優位を優先するので、品質よりも市場投入のタイミングを重視する。
よって、品質よりリリースタイミングを優先し、バグがあれば機能制限を設けたりする。

一方、日本では、リリースタイミングよりも、予定されていた機能の品質が担保できていることを重視している。
なぜなら、いくら機能が良くても品質が悪ければ、クレームの嵐になり、ブランド価値が毀損されるからだ。
つまり、日本では、製品の機能と品質は表裏一体とみなす。

この違いから生じる、テスト管理ツールへの要件は何か？
欧米では、重要な利用シーン（ストーリー）をベースに品質を評価する。
よって、ストーリー（シナリオ）を分割し、テストケースのタイトルにStep1、Step2の順に確認項目を記載し、テストを実行していくGUIになる。

一方、日本では、機能テストをベースに品質を評価し、全項目で一定の品質を確保する必要がある。
よって、全ての機能を網羅したテスト仕様書がまず準備されて、各テスト項目はかなり詳細に手順や確認項目を書き込み、1つずつ潰していく。

上記記事にあるTestLinkのテストケース編集画面と、CATのテストケース編集画面の違いが面白い。
TestLinkでは、テストケースのタイトルがツリー構造で表示され、その一つを選ぶとポップアップされ、テストケースを編集する。
一方、CATでは、テストケース編集画面はExcelの表形式と全く同じ。

確かに、TestLink、あるいはTestRailsでも、テストケースのタイトルが一覧表示されていて、その詳細はポップアップで編集するイメージだ。
なぜなら、ストーリーベースなので、テストケースの詳細を見なくても、業務のストーリーを元に、その手順を踏めばいい。
テストケースをグルーピングする機能の方が重要だ。
つまり、欧米のテスト管理ツールでは、テストケースの粒度は荒い。

一方、日本のテスト管理では、機能ベースで全てのテストケースを網羅すべきというプレッシャーがあるので、テストケースの粒度はかなり細かい。
テストケースをテスト観点のカテゴリで分ける方が大事だ。
ゆえに、テスト管理ツールでテストを実行する場合、テストケースの詳細をじっくり読み込まないと、テスターはテストできないだろう。

おそらく、日本のテスト管理では、テストケースをグルーピングする機能よりも、テストケースにハッシュタグを付ける、とか、ツリー構造で階層化する機能の方が重要なように思える。
なぜなら、機能ベースのテストケースでは、グルーピング機能を強化しても、ツリー構造が深くなるので、肝心のテストケースを表示させるためのUIの導線が複雑になりやすいからだ。

TestLinkは個人的には好きだったが、テストケースの元ネタとなるテスト仕様書はExcelで作りこんでTestLinkにインポートしたり、テストケースを一括編集する時はTestLinkからExcel出力した後でExcel上で一括編集して再度TestLinkに取り込む、などの作業をしていたのを思い出した。
つまり、TestLinkというテスト管理ツール上でそういう作業はやりにくかったのだ。
すなわち、日本では品質を担保するためのテスト管理の概念が違う点が、根本原因にあったのだろう。

テスト管理ツールの利用、という古くて新しい問題については今後も色々考える。

TestLinkにExcelのテスト項目書をインポートする方法の記事があったのでメモ。

【参考】
【TestLinkでナレッジ蓄積】Excelからテスト項目書をインポートする方法 | Ques

MrBricodage/TestLink--ExcelMacros: Excel files containing Macros that handle XML files compatibles with TestLink

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク: プログラマの思索

TestLink

(引用開始)
TestLinkはExcelから直接インポートできない

TestLinkのインストール作業手順は、インストール方法の記事や書き込みが多いため、
ここでは省略させて頂きます。

TestLinkを使う上で苦労した点はテスト項目書からのインポート作業になります。

TestLinkへインポートするにはXML形式に変換する必要があります。
弊社のテスト項目書（ナレッジ）の多くはExcelで作成されており、
Excelの内容は直接TestLinkへインポートすることができません。
TestLinkへインポートするには、一度、Excel形式からXML形式に変換する必要があります。
TestLink上にて、テストケースを手入力で入力することは可能ですが、
数あるテスト項目書を手入力で行うと時間がかかるため、
短時間で行うには補助ツールが必要になります。

テスト項目書のインポート/エクスポートを補助する便利ツール

ExcelからXMLに変換し、XMLからTestLinkへインポートするには、
Excel→XML変換ツールが必要になります。
また、TestLink上のテスト項目書を編集する場合、
TestLink上よりもExcel上で編集できた方が楽です。
TestLinkにはエクスポート機能があり、実行するとXML形式で保存できます。
エクスポートデータをExcelで編集するにはXML→Excel変換ツールが必要になります。

そこで、下記の両方を行うことができる補助ツールを探してみました。

Excel→XML変換
XML→Excel変換

昔は「TestLinkCnvMacro」という補助ツールがありましたが、今はありません。
今回は「TestLinkCnvMacro」の代わりに、
海外のツールですが、「02-ImportTestCasesIntoTestLink.xls」を使います。
(引用終了)

02-ImportTestCasesIntoTestLink.xlsの使い方は、上記の記事にある。

TestLink上からXML出力
→encoding=”UTF-8″を”Shift-jis”に変更して保存
→文字コードを「Shift-jis」にして保存
→02-ImportTestCasesIntoTestLink.xlsへインポート

02-ImportTestCasesIntoTestLink.xlsからXML出力
→encoding=”ISO-8859-1″を”UTF-8″に変更して保存
→文字コードを「UTF-8」にして保存
→TestLink上でXMLインポート

TestLink Tutorialのリンクがあったのでメモ。

【参考】
TestLink Tutorial: A Complete Guide

前文英語だが、画面キャプチャがあるので、操作方法は分かる。
チュートリアルの目次は下記の通り。

(引用開始)
In this tutorial we will learn
・Advantages of TestLink
・Login to TestLink
・Creating a Test Project
・Creating a Test Plan
・Build Creation
・Creating Testsuite
・Creating a Testcase
・Assigning test case to test plan
・Creating Users and Assigning Roles in TestLink
・Writing Requirements:
・Executing a test case
・Generating Test Reports
・Export Test case/ Test Suite
・Importing Test case/ Test suite
(引用終了)

但し、コメントを読むと、SMTPのメール設定、RedmineやMantisとの設定、Jenkinsからのテスト結果の自動登録などの方法は記載されていないので、注意。
あくまでも初心者向けに、TestLinkはこんなことができるよ、という説明。

TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法が公開されていたのでメモ。

【参考】
TestLinkで手動テストと自動テストを統合する : Jenkins編 - Qiita

TestLinkで手動テストと自動テストを統合する : JUnit編 - Qiita

TestLink

TestLink Cloud Hosting, TestLink Hosting - Installers and VM

TestLinkOpenSourceTRMS/testlink-code: TestLink Open Source Test & Requirement Management System

TestLinkのdocker imageをdockerhubにアップロードしてみた - Qiita

Unitils ?

TestLink Plugin - Jenkins - Jenkins Wiki

ootaken/TestLinkJenkinsIntegration: sample of integration of TestLink and Jenkins

(引用開始)
そのような徐々に自動テスト化していく中では手動テストと自動テストを同時にリグレッションテストやスモークテストとして行ったりするので、両方をまとめて管理したい、まとめて状況を見たいというお話をマネージャーさんからリクエストされることが度々あります。
私にそんな話が来るぐらいと言うことは世の中でもそういうニーズがあるに違いない、そもそもHPのQuality CenterやIBMのRational Quality Managerのような商用のテスト管理ツールにはそういう機能ありますね。
でも、そのためだけに商用を買うのも・・・っていうことで、俺たちのOSSテスト管理ツールのTestLinkにもそういう機能がありました。
というのでTestLinkの自動テスト統合機能を調査してみましたのでまとめてみます。
(引用終了)

上記の手法は、JUnitでテスト自動化した結果をTestLinkに取り込んだり、Jenkinsのビルド結果をTestLinkに取り込んで、そのテスト結果や分析結果をTestLink上で表示させる手法だ。
方向性としては、TestLinkにはAutomationという設定があり、自動テスト結果を取り込むAPIやUIが用意されているので、それを使うというアイデアだ。

なぜそんな手法が必要になるのか？
プログラマとしては、テスト結果は終わった結果なので、そこまで興味があるわけではない。
しかし、マネージャや品質保証部の担当者としては、最新のテスト結果が欲しかったり、日々のテスト結果の履歴から品質分析したいという要望がある。
つまり、マネージャなどの利害関係者向けに、テスト結果のレポートツールが必要なわけだ。

そこで、テスト結果のレポートツールとしてオープンソースのTestLinkがあり、TestLinkの自動テスト結果取り込み機能を使えばうまくいくわけだ。

上記の記事を読むと、設定方法には色々な試行錯誤がいるようだが、利害関係者に見せるには十分な機能だろうと推測する。

TestLinkに一度データが入れば、TestLinkに溜まったテストデータを解析すれば、色んな知見が得られる可能性もある。

最近の僕はTestLinkの情報を追いかけていなかったが、2016/1時点で、Ver1.9.14までマイナーバージョンアップされているようだ。
この辺りの情報も調べてみたい。