TestLink

2017/06/01

TestLinkにExcelのテスト項目書をインポートする方法

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インポート

| | コメント (0)

2016/03/12

TestLink Tutorialのリンク

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はこんなことができるよ、という説明。

| | コメント (0)

2016/01/31

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までマイナーバージョンアップされているようだ。
この辺りの情報も調べてみたい。

| | コメント (0)

2015/03/14

エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること

長沢智治さんの記事がとても素晴らしいのでメモ。
以下は主張のないラフなメモ書き。

【参考】
オピニオン:長沢智治: エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider

(引用開始)
エバンジェリストは、マーケティング活動の一環のため、「市場を作り、成熟させる」ことが求められてしかるべきである。
(中略)
従ってエバンジェリストの活動とは、「自分が携わっている製品や技術の詳細を伝える」ことではなく、「世界観を伝える、つまり市場の変遷であったり、トレンドであったり、その中での製品や技術の立ち位置であったり、コンセプトであったりを伝える」ことが第一だと考える。「世界観」についてのコンセンサスを現場で持てたなら、きっとその現場は、自分たちに合った解を議論と体験の中から導き出せるはずだ。
(引用終了)

akipiiさんはTwitterを使っています: "すごく良い記事。エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること。オピニオン:長沢智治: エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider http://t.co/mn9H0d4ud3"

【1】僕は、RedmineやTestLink、iDempiere、vTigerCRMなどのオープンソースのツールが好きだ。
自分たちで使いこなすうちに、どんな場面で利用すると効果が出るのか、が分かってくる。
使いこなすうちに、自分たちの世界がグレードアップする感覚が好きだ。

そして、じきに新たな課題を感じ取る。
では、その課題とは何なのか?

それは単に、そのツールだけでは解決できない課題という意味だけではない。
そのツールを使いこなすことで、アウフヘーベンされ、本来の問題の本質が見えてくる、という意味の方が強い。

ツールで得られた現場の経験知をモデル化していくうちに、そのモデルがどんな問題にフォーカスしているのか、そのモデルが対象とする問題解決のスコープとその限界が見えてくるのだ。

【2】そんなことを考えながらツールを使っていくと、そのツールの熱烈なファンになる。
こんな機能が欲しい、もっと使いやすくしたい、他のツールに似た機能があるといいな、とか、色んな欲求が出てくる。
あるいは、このツールはこんなにすごいんだよ、と他の人に薦めたくなる。

エバンジェリストの役割は、そのツールを宣伝することだ。
エバンジェリストの影響力が大きいほど、ツールを使うユーザ数も増える。

しかし、その方向性が行き過ぎると、そのツールのライバル製品をけなしてしまう言動をしてしまう時がある。
熱烈なファンがそのツールしか眼中に無く、他のツールの良さまで見えなくなってしまう危険があるのだ。

パッケージ製品のベンダー、オープンソースのツールやパッケージ製品を販売するエバンジェリストは、そのような落とし穴に嵌る時があるのではないか。
僕自身、そんな時があったなと反省するときもあった。

【3】上記の長沢さんの記事では、エバンジェリストは、単にツールを宣伝する人ではなく、ツールが提供されるマーケットを開拓する役割を持つことを主張されている。
その意見は、思わず、そうだよ、と納得した。

ライバル製品との機能比較、製品の持つ新しい技術や仕様などの細部の話が全てではない。
むしろ、エバンジェリストが持つ世界観を世の中に提示すべき。
では、その世界観とは何なのか?

それは、市場の変遷や技術の変遷の中で、そのツールがもたらす新しい価値とは何なのか、を提示すること。
つまり、製品や技術のような枝葉末節の話ではなく、ツールがもたらす価値が現場のどんな問題を解決し、どんなステージを提供するのか、という価値観を提示することだ。

そんな世界観や価値観をエバンジェリストが世の中に提示することで、現場で従来は解決できなかった課題がクリアされる。
あるいは、ツールを導入する前はそもそも、そんな課題すら認識しておらず、問題意識も持っていなかった人もいるに違いない。

そんな人達に、ツールがもたらす価値やメリットを提示して、潜在的なニーズを掘り起こし、問題意識すら持っていなかった新たなユーザ層を獲得し、市場をどんどん広げていく役割がエバンジェリストに求められるわけだ。

市場を開拓し広げていくことで、ユーザから製品へのフィードバックも増えて、製品もどんどん改良されていく好循環も生まれる。

オープンソースの製品もパッケージ製品と同様に、利用ユーザが集まるコミュニティが活発に活動するほど、コミッタと利用ユーザの間で有意義な議論が行われ、製品のあるべき姿が見えてくる。
製品がどんな場面で有効に使えるのか、という利用シーンが明確になるだろう。

更には、製品がもたらす価値のスコープが見えてくることで、製品の新たな課題も見えてくるだろう。
その新たな課題は、製品がどんな方向に進化すべきか、というロードマップに大きく影響するだろう。

個人的な妄想としては、オープンソースの製品群を連携させた一連の「プロジェクト管理サーバー」のような概念を提示し、それがソフトウェア開発プロセスを進化させていることを明示したいなあ、と思っている。

| | コメント (0)

2015/02/22

「実験的アプローチによる改善活動」の記事のメモ

「実験的アプローチによる改善活動」の記事がとても参考になるのでメモ。

【参考】
第162回 実験的アプローチによる改善活動(全4回の第1回)|SQiP:Software Quality Profession

第163回 実験的アプローチによる改善活動(全4回の第2回)|SQiP:Software Quality Profession

パイロット開発にAgile開発のアイデアを適用した事例~実験的アプローチ #JaSST_Kansai: プログラマの思索

実験的アプローチによる現場改善~JaSSTソフトウェアテストシンポジウム-JaSST'13 Kansai

akipiiさんはTwitterを使っています: "同感。手段が問題を具現化する。特にITはそう。「ある手段を知らない状態では、課題と感じないような部分が、実は大きく改善できるポイントがあるケースが多いから」第163回 実験的アプローチによる改善活動(全4回の第2回)http://t.co/oya8EMekoB"

【1】(引用開始)
よく、「手段を目的化してはだめだよ」と言われます。私は、それは正しいと考えていますが、「最初にまず目的を考えて、それに合った手段を考えなければならない」か、と言うと、必ずしもそうではないと考えています。
なぜかというと、ある手段を知らない状態では、課題と感じないような部分が、実は大きく改善できるポイントである場合があるからです。

実験的アプローチによる改善活動では、日常的になるべく多くの「筋が良い手段」を効率良く収集することと、反復活動の中で小さな課題を抽出することで、日々の活動の中で、「あ、前に収集した手段で改善できる課題がありそうだ」「あ、今課題になっていることに、あの手段が使えそうだ」というように、なるべく小さな粒度で課題と手段を相互に結び付けます。
(引用終了)

新しいツール、道具、手法を知ることで、新たな問題や課題を感じ取り、その課題を解決できるように手段を適用していくやり方は、僕は好きだ。
IT業界の技術革新の流れを振り返れば、このパターンによる解決がかなり多いのではないか、と思う。

【2】僕の経験としては、RedmineやTestLinkを使いこなすことで、アジャイル開発やテスト管理で感じていた諸問題に適用できる!と気づいて、色々試すことができた。

オープンソースのツールは、簡単に試せるし、中身のソースも読めるから自分なりに改造もできる。
また、ツールのコミッタと議論すれば、自分が抱えている問題を解決するような機能改善を実現してくれる場合もある。
さらに、オープンソースのツールを使う人達と議論すれば、新たな利用シーンで別の問題を解決してくれる事例に気づかせてくれる。

実際、RedmineやTestLinkのコミュニティで議論して、色んな機能が改善された場合もあったし、Redmineをこんなシーンで使うのか!という気付きを得た時もあった。

僕は、オープンソースのツールを使って、業務プロセスやソフトウェア開発プロセスを改善ないし変革する手法が好きだ。
ソフトウェアは単なるツールではない。
ソフトウェアを導入すれば、運用が変わり、不要な人員や役割が削除されて組織も変わり、人の行動すらも変わっていく。

プログラミングだけでなく、作ったシステムが人に影響を与えて、人の行動や価値観すらも変えてしまう所にすごく興味がある。

【3】そんな経験を踏まえて、僕が今考えているアイデアはいくつかある。
一つは、Redmineというツールを色んな角度で分析することで、どのような方向へ発展すべきか、という問題意識を持っている。

Redmineが今後発展する方向のアイデア: プログラマの思索

もう一つは、ERPやCRMのオープンソースのツールを使いこなすことで、中小企業向けの業務に適用して、業務の効率化や業務改革を行えないか、という問題意識がある。

オープンソースの業務アプリケーションを組合せてERPを構築するアイデア: プログラマの思索

ERPはなぜ難しいのか?~オープンソースERPで業務改革を試したい: プログラマの思索

オープンソースCRM「vtigerCRM」の資料: プログラマの思索

この辺りも試してみたいと思っている。

【追記】
残り2回の記事も公開されている。
第3回の記事では、原因結果グラフとテスト駆動開発の組合わせに関する実験結果も書かれていて、非常に興味深い。

第164回 実験的アプローチによる改善活動(全4回の第3回)|SQiP:Software Quality Profession

第165回 実験的アプローチによる改善活動(全4回の第4回)|SQiP:Software Quality Profession

| | コメント (0)

2014/11/16

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク

TestLinkのインポート用ExcelマクロImportExcelMacroのリンクをメモ。

【参考】
MrBricodage/TestLink--ImportExcelMacro

TestLink Open Source Test Management

TestLink - Open Source Test Management - Gitorious

TestLinkの資料リンク: プログラマの思索

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

以前は、日本のTestLink有志がTestLinkCnvMacroを公開していて、そのExcelマクロを使えば、テストケースの一括登録&一括修正、テスト実績や要件の一括登録&一括修正ができた。
このツールがなければ、TestLinkの画面上で数百~数千のテストケースを逐一手作業で登録しなければならないから、非現実的だった。

しかし、そのマクロも公開されなくなり、TestLinkのバージョンも上がってしまい、テストケースを一括登録する方法がよく分からなくなった。
TestLinkの1.8以降では、ExcelからXML出力したファイルを読みこませれば良かったらしいが、時々うまくいかない時があったから。

だから、TestLinkのインポート用ExcelマクロImportExcelMacroには期待している。
使い方のPDFを読むと、Excelでテストスイートで階層化したテストケースも読み込めるようだし、要件とテストケースを紐付ける機能もあるみたい。

テスト管理は、Excelとテスト管理ツールの連携が一番重要だと思う。
やはり、テストケースの元ネタはExcelで作り、実際のテスト実行履歴はTestLinkで管理し、顧客向けの資料はTestLinkからExcel出力すればいいようにしたい。
つまり、Excelは、ある時点のテスト実績のスナップショット。
したがって、Jenkinsのようなビルドツールで、TestLinkからテスト結果をレポート出力するように、定期的にキックする仕組みがあれば、なお良いだろう。

また試してみる。

| | コメント (0)

2014/10/10

TestLinkの資料リンク

オープンソースのテスト管理ツールTestLinkの資料をまとめておく。

【1】TestLinkの使い方

TestLinkの機能や画面の使い方はコチラ。
慣れるまでに、コツがいる。
画面操作は、iPhoneやRedmineなどに比べると、あまりイケテない。
但し、オープンソースなので、皆で修正すればいいと思う。

【2】TestLinkをアジャイル開発へ適用した事例紹介

ETWest2009で発表した事例。
個人的には、TestLinkを使って初めて、漸進的開発(小規模リリース)と反復型開発の違いを体感できた。

【3】TestLinkのプラクティス

SEA関西で発表した資料。
TestLinkは単なるテストケース管理ツールではなく、テスト管理手法のベストプラクティスが含まれていると思う。

【4】TestLinkにExcelのテストケースをインポートする方法

テスト管理では、必要悪だが、どうしてもExcelのテストケースと同期する必要がある。
Excelでテストケースを作りこんでおき、そのExcelをTestLinkへ一括インポートできれば、運用がすごく楽になる。
なぜなら、ちょっとしたシステムでもテストケース数は数千~数万くらいは作る必要があるからだ。

Ver1.7までは、有志が作ったExcelマクロを使うしか無かったが、Ver1.8以降は、TestLinkのインポート機能が使えるようだ。

| | コメント (0)

2014/09/15

testlinkをwindowsにインストールする時の注意点

testlinkをwindowsにインストールする時に、エラーが出た時の対処をメモ。

【参考】
testlinkをwindowsにインストールする - shouhの日記

TestLink1.9.10へのバージョンアップ時の調査 - Qiita

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

WindowsでXAMPPにTestLinkをセットアップすると、ログイン画面で、
「Fatal error: Uncaught exception 'SmartyCompilerException'」
というエラーが出る時がある。

対処方法は下記の通り。

(引用開始)
この問題に関しては、下記のフォルダを最新のSmarty3に置き換えれば回避できる。

testlink\third_party\smarty3

http://www.smarty.net/download

Smarty 3.1.18(安定板)をダウンロードする。
(引用終了)

| | コメント (0)

2013/09/01

日経Systems2013年9月号にRedmineの記事が掲載されました

日経Systems2013年9月号にRedmineの記事が掲載されました。

【元ネタ】
日経BP書店|雑誌バックナンバー - 日経SYSTEMS2013年9月号

日経SYSTEMS - 9月号の「検証」で、プロマネツールのRedmineの導入の勘所を書きました。一読いただければ分かるように、「いかにしてメンバーに使ってもらうか」が今回のメインテーマです。その意味では、10年近く前に別の雑誌で書いたグループウエア導入についての記事に共通点を感じました。システムの利用を促すには工夫が必要です。 (矢口)

Twitter / akipii: ツールを入れるとプロセスも組織も変わる。 RT @NikkeiSystems: 9月号の「検証」で、プロマネツールのRedmineの導入の勘所を書きました。その意味では、10年近く前に別の雑誌で書いたグループウエア... http://fb.me/2j53Jdiui

日経Systemsにredmineの記事を書きました: プログラマの思索

日経SYSTEMS 2012.10 - 情報技術建築家日記

記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

日経Systemsは2011年7月号にもRedmineの記事を@sakaba37さんと執筆させて頂きました。
それから2012年、2013年と継続的にRedmineの記事を掲載されています。

品川Redmine勉強会で日経Systemsの記者の方が参加されていて、お話を伺った所、読者アンケートを取った結果では、Redmineの読者評価がいつも高いそうです。
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索にも書きましたが、おそらく日本のSIの現場でRedmineを使っている事例が多いのでしょう。

その理由を推測すると、いくつかあげられると思う。
ITSの高機能化やSVN・Gitなどの構成管理ツールの普及、そしてJenkinsのようなビルド管理ツールの普及という
ソフトウェア開発を支援する基盤が揃ってきたこと。
そして、ソフトウェア開発の案件の短納期・低コストへの流れ。
それらの問題に対して、ITSを使ったチケット駆動開発に興味を持ち、実際に現場に導入されているのだろう。

だが、ITSと言えば、Redmineだけでなく、Tracもあるし、有償ならばJiraやMSのTeamFoundationServer、IBMのRationalTeamConcertもある。
色んなツールの中でRedmineの普及が目立つ理由は、おそらく、日本のSIの開発現場では開発支援ツールそのものに投資する環境でないため、無償のツールの選択肢としてRedmineが選ばれているのではないか、と思う。

もし、お金に物を言わせる環境があれば、サポートもあり、テスト管理やメトリクス集計など豊富な機能を持つJiraやTFSがお勧めだろう。
コミュニティで聞くと、開発ツールに投資してくれる会社では、JiraやTFSなどを導入しているという話をよく聞く。

普通の開発現場では、新しいツールを導入するための投資費用を出してくれる所は少ない。
LAMPの経験があれば、インストール作業はそれほど難しくない。

そして、Redmineならば、ネット上にたくさんのノウハウが転がっている。
チケット駆動開発はTracから生まれたが、Redmineで育まれ、そして他のITSでも同様に運用できる手法。

チケット駆動開発の面白さは、アジャイル開発への適用が一番と思うが、それ以外にも、GitやJenkins、TestLinkなどの他ツールと連携して開発の効率化を試すこともできる。
他にも、ITSの豊富な機能を生かして運用保守・ヘルプデスク管理・資産管理・工数管理などの社内業務にも適用することが出来る部分だと思う。

チケット駆動開発のエッセンスは「チケットをXPのタスクカードのように扱う」という一点だけなのに、そこからたくさんの運用方法が生み出されている所が面白い。

特に、Redmineはオープンソースのプロジェクト管理ツールなのに、RESTやメールによるチケット自動登録などの機能もあるおかげで、いろんな運用の可能性を秘めている。
この辺りのノウハウも考えていきたい。

【追記】

9/12(木)午後に、@sakaba37さんとチケット駆動開発に関する講演を行います。
今日ものある方はぜひご参加下さい。

【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します: プログラマの思索

| | コメント (0)

2013/07/10

TestLinkとEnterprise Architectを連携する

TestLinkとEnterprise ArchitectやRaQuestを連携するスクリプトが公開されていたのでメモ。

【元ネタ】
日々精進 - スパークスシステムズ ジャパン代表のBlog:TestLinkとEA/RaQuestとの連携 - livedoor Blog(ブログ)

スパークスシステムズジャパン フォーラム - ニュース

TestLinkの要件管理機能: プログラマの思索

jenkins-testlink-plugin: プログラマの思索

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

Enterprise Architectでモデルを書いて、そのモデルから要求を紐づけている時、その内容をTestLinkの要件管理機能にインポートできるスクリプトを公開している。
目的としては、モデルに書かれた仕様と本来の要求が関連している関係をTestLinkのテストケースと関連付けて、要求から仕様を経てテストケースに至るまでのトレーサビリティを実現したいことだ。

特にテストケース作成時に、要求や仕様を全て網羅しているか、という観点で、テストケースに対する要件カバレッジを取ると、結構網羅できていない時が多い。
つまり、テストケースの作成段階で、テストされない要求が結構出てくる。
だから、テストケース作成の作業は細心の注意を払う時が多い。

そして、TestLinkのテストカバレッジ機能を使えば、実際にテストできたテストケースから、逆に要求をどこまでテストで検証できたのか、という要件カバレッジを見ることもできる。
実際のテストでは、1サイクルのテストで全ての要求を網羅するのは不可能だ。
実際は、複数のサイクルで要求を網羅できるのが普通だから、アジャイル開発のように、テストケースやテスト対象の要求を分割して、サイクルないしイテレーション単位にテストして、要件カバレッジを100%にする戦略が必要となってくる。

TestLinkを使ってみると、実際のテスト管理や要求管理の奥深さを知ることができて面白かった。

個人的には、TestLinkのテストケースや要件管理とastahの要求図や概念モデルを連携できれば面白いだろうと思う。
特に、要求図はゴール指向分析という要求工学から発生した技術なので、よく考えられているのではないかと想像している。

astah* professional 6.1の要求図: プログラマの思索

Astahプラグインの資料のリンク: プログラマの思索

色々試してみる。

| | コメント (0)

より以前の記事一覧