Akipii Oga
akipi****@gmail*****
2008年 12月 19日 (金) 13:57:40 JST
川西さん あきぴーです。 ご丁寧な回答ありがとうございます。 Testlinkの要件管理機能は是非改善して欲しいものの一つです。 要件を検証する目的でTestlinkを使うことができるため、設計フェーズで大きな威力を発揮できると思います。 > # ただ、紐付けをインポートするための一般的な > フォーマットを考えるというのは難しいというはあると思います。 > 上手い方法が無いかどうか考えてみます。 > 何かアイディアがあればご教示ください。 要件とテストケースを紐付けてインポートするには、Testlinkで振られた要件管理IDで再インポートする方法しか ないと思います。 つまり、下記の運用イメージです。 テストケース、要件をそれぞれでTestlinkへインポート ↓ テストケース、要件にTestlink固有のIDが振られる ↓ 全てのテストケース、要件をTestlinkからエクスポート ↓ 要件IDとテストケースIDを紐付けたCSVを手作業で作り、Testlinkへ一括インポート テストケースや要件をインポートする運用をしているチームは、それぞれのマスタデータだけでなく、要件と テストケースを紐付けたデータも保持しています。 だから、それをCSVで作るのはそれほど難しくないです。 > そこで、Tracなどのプロジェクトを管理するためのツールと > 連携するための何かしらを作ってみようと思っています。 > （すみません。私はRedmineよりもTracを使っているもので......） > XPのストーリー（SCRUMのプロダクトバックログ）を > 要件として登録していければなと考えています。 上記のアイデアは僕も試行錯誤中です。 上記を運用したい状況は、仕様変更から発生するタスクやテストを変更管理で一貫して管理することです。 下記の本のP.102にあるコラム「変更要求とそれに関連する作業について」にも似たような場面が書かれています。 Amazon.co.jp： Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド: 菅野 裕, 今田 忠博, 近藤 正裕, 杉本 琢磨: 本 http://www.amazon.co.jp/Trac%E5%85%A5%E9%96%80-%E2%80%95%E2%80%95%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E7%AE%A1%E7%90%86%E6%B4%BB%E7%94%A8%E3%82%AC%E3%82%A4%E3%83%89-%E8%8F%85%E9%87%8E-%E8%A3%95/dp/4774136158/ref=sr_1_1?ie=UTF8&s=books&qid=1229661604&sr=8-1 この状況は、チケットに親子関係が発生するが、その親子関係が持つ制約条件をチケットへ機能追加できるか、 という問題に置き換えられます。 つまり下記のイメージです。 例： 親チケット・・・元々の変更要求。XPのストーリーカード、Testlinkの要件に相当する。 子チケット・・・実際の複数のタスク。Redmine、Tracで管理する作業単位。XPのタスクカードに相当する。 この場合、少なくとも下記の制約条件が発生します。 1.親チケットの工数＝子チケットの工数の合計 2.親チケットの期限＝子チケットの期間の和(Union) 3.親チケットのステータスは、全ての子チケットのステータスが終了になって、初めて終了になる。 この運用をRedmineで試していますが、正直効率が上がったとは思えません。 上記の制約を手作業で行っているからですし、かと言って、RedmineやTracのチケット機能をPGM修正しても より複雑になるだけです。 要件はタスクの観点で管理するのではなく、テストの観点で管理する方がうまくいくのではないか、と、 Testlinkの要件管理機能を見るたびにそう思います。 この機能のUIが良くなれば、TracやRedmineに無い機能として注目されると思います。 是非、改善して欲しいです。 以上、よろしくお願いします。 2008/12/18 14:24 Toshiyuki Kawanishi <tosik****@users*****>: > あきぴーさん > > > 川西です。 > 実用に即したご質問ありがとうございます！ > > >> 以前、JaSST関西にて「ビルド＝製造番号」と聞いていましたが、 >>「Testlinkのビルド＝HudsonのビルドNo」で >> 運用できるんですね。 >> その話から、Testlinkのビルドの概念が理解できて、すっきりしました。 > > 良かったです。あくまで運用の一例ですが、 > CIと組み合わせる場合は、それで問題ないと思います。 > > # 以前は、Subversionで作成したタグの名称を > TestLinkのビルド名として登録していました。 > > 他にも、インストーラを作成してくれる構成管理ツールなども > ビルド番号を振ってくれるでしょうから、 > 各プロジェクトに合わせて > そのような番号を登録すれば良いと思います。 > > >> しかしながら、以前の質問のように、 >> Testlink上で要件からテストケースを1個ずつ作成して、要件とテストケースを >> 紐付けするのは、ケース数の桁が数千〜数万の場合、非現実的です。 > > 確かに、その通りなんですよね...... > 私もそこまで要件管理機能を活用できていない状況です。 > > > そこで、Tracなどのプロジェクトを管理するためのツールと > 連携するための何かしらを作ってみようと思っています。 > （すみません。私はRedmineよりもTracを使っているもので......） > XPのストーリー（SCRUMのプロダクトバックログ）を > 要件として登録していければなと考えています。 > > ということで、個人的には、 > アジャイル的な運用を考えるプロジェクトにおいては、 > 今ある要件を一気にTestLinkに > インポートして運用するというよりも、 > 今後、洗い出したストーリー（プロダクトバックログ）や、 > イテレーションに関係あるストーリーを登録していって、 > それを既存のテストケースに紐付けるなり > それをベースにテストケースを作成する > といったことを考えています。 > > # Hudsonの事例と違って、これはまだ準備中で、 > これから実行してみようと思っている段階です。 > > >> あるいは、Testlink1.8では、 >> 要件管理の機能が大幅強化されているでしょうか？ > > TestLink 1.8 では要件管理のUIは改善されていますが、 > 文書名登録-->要件登録-->テストケースと紐付け もしくは > 文書名登録-->要件登録-->テストケース作成 > という流れは変わりません。 > > カスタムフィールドや要件とテストケースの関連の扱いに関しては > 今後のTestLinkの課題になってくるのかなと思います。 > > # ただ、紐付けをインポートするための一般的な > フォーマットを考えるというのは難しいというはあると思います。 > 上手い方法が無いかどうか考えてみます。 > 何かアイディアがあればご教示ください。 > > > 以上、よろしくお願いします。 > > > Toshiyuki Kawanishi <tosik****@users*****> > > > --- >> 川西さん >> >> あきぴーです。 >> 下記のご回答ありがとうございます。 >> >> 以前、JaSST関西にて「ビルド＝製造番号」と聞いていましたが、「Testlinkのビルド＝HudsonのビルドNo」で >> 運用できるんですね。 >> その話から、Testlinkのビルドの概念が理解できて、すっきりしました。 >> >> もう一つだけ、Testlinkの要件管理機能についてご質問させて下さい。 >> >> 今の僕はTestlinkの要件管理は使っていませんが、マスタデータは揃っているので、次回からTestlinkに >> インポートして運用したいと考えています。 >> >> しかしながら、以前の質問のように、Testlink上で要件からテストケースを1個ずつ作成して、要件とテストケースを >> 紐付けするのは、ケース数の桁が数千〜数万の場合、非現実的です。 >> >> 川西さんや他のコミッタの方は、要件管理をどのように運用しているのでしょうか？ >> あるいは、Testlink1.8では、要件管理の機能が大幅強化されているでしょうか？ >> よろしければ、運用例を教えて頂けると助かります。 >> >> Testlinkの要件管理を使いたい動機は下記の通りです。 >> >> >> >> 今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を >> >> >> 追加しています。 >> >> >> 理由は、テストの目的や観点を明確にして、お客様に説明するためです。 >> >> >> つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは >> >> >> 揃ってます。 >> >> >> 狙いは下記のトレーサビリティです。 >> >> >> >> >> >> 要件(Testlink)→テストケース(Testlink)→【チケット】(Redmine)←ソース(Subversion) >> >> >> >> >> >> 上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合は >> >> >> テスト仕様書の作成工程で潰せると思います。 >> >> 今、Redmine＋Testlinkで結合テストや受入テスト、障害修正は非常にスピードアップできてます。 >> しかし、バグ発生の原因を探ると、確かにPGMミスもありますが、仕様漏れや設計漏れ、他機能への >> 影響の考慮漏れ、など、上流工程や変更管理の品質の方に問題があると思ってます。 >> >> その対策として、Testlinkの要件管理を使いたいのです。 >> >> 質問ばかりで申し訳ありませんが、よろしくお願いします。 >> >> 2008/12/17 14:17 Toshiyuki Kawanishi <tosik****@users*****>: >> > あきぴーさん >> > >> > >> > 川西です。 >> > >> >> Redmineパッチの修正ありがとうございました。 >> >> 更に、Redmineロードマップ画面と同じく >> >>「<取消線>検証完了</取消線>-バグ修正」と表示されて、非常に >> >> 使いやすくなりました。 >> > >> > 早速、ご確認ありがとうございます！ >> > 一応私の環境では確かめたのですが、 >> > あきぴーさんの環境でも大丈夫だったようで安心しました。 >> > >> > # Tracを使った場合も同様のバグがあるようですので、 >> > 今晩にでも時間を見つけて修正します。 >> > >> > >> >> 以前の川西さん、梶野さんのご回答から推測すると、 >> >> ビルドとテスト計画は下記の認識で合っているでしょうか？ >> > （中略） >> >> 上記のように考えると、リリース後は、テスト計画は閲覧可能とするが、ビルドはCloseして >> >> テスト結果を変更できないようにするTestlinkのやり方が非常に理解できます。 >> > >> > 1〜3のとおりで間違いないと思います。 >> > >> > ただ、3については、 >> > あくまでイテレーション開発をしている場合は、 >> > TestLinkをそのように運用すると良いという一例だと思います。 >> > >> > # TestLinkの思想として >> > 「TestLinkのテスト計画＝イテレーション」 >> > 「TestLinkのビルド＝継続的インテグレーションで行う統合ビルド」 >> > と決まっているわけではありません。 >> > （念のため。） >> > >> > この場合は、イテレーション計画（スプリント計画）の時に、 >> > どのテストを実行するか考える >> > （TestLinkのテスト計画にテストケースを追加する） >> > のが良いと思います。 >> > >> > あと、個人的な例としては、 >> > 私は継続的インテグレーションサーバとしてHudsonを使っているので、 >> > Hudsonが自動で振ってくれるビルド番号を >> > TestLinkに登録するようにしています。 >> > （毎回のビルドをTestLinkに登録している訳ではありません。 >> > TestLinkで管理しているテストが必要となった時のビルドのみを >> > TestLinkに登録しています。） >> > >> > >> >> ご気分を悪くされたら申し訳ありません。 >> > >> > あ、すみません。全然、気分を悪くしたつもりはなかったです。 >> > 念のため確認というつもりで書かせていただきました。 >> > パッチがあると、 >> > 割とすんなりと本家の人がOKだしてくださるもので。 >> > >> > # 私のメールの書き方が悪かったかもしれません。 >> > 夜中に書いたもので...... >> > >> > >> > 以上、よろしくお願い致します。 >> > >> > >> > Toshiyuki Kawanishi <tosik****@users*****> >> > >> > >> > --- >> >> 川西さん >> >> >> >> あきぴーです。 >> >> Redmineパッチの修正ありがとうございました。 >> >> 更に、Redmineロードマップ画面と同じく「<取消線>検証完了</取消線>-バグ修正」と表示されて、非常に >> >> 使いやすくなりました。 >> >> >> >> 下記の件、ご丁寧なアドバイス並びにご指摘ありがとうございます。 >> >> Testlink日本語分科会の人達はとても親切なので、下記の要望をあげたら実現してくれるかな、とちょっと >> >> 甘えた部分があったかと思います。 >> >> ご気分を悪くされたら申し訳ありません。 >> >> >> >> ビルドの考え方について再質問させて下さい。 >> >> 以前の川西さん、梶野さんのご回答から推測すると、ビルドとテスト計画は下記の認識で合っているでしょうか？ >> >> >> >> 1.ビルドごとにテストケースをアサインすることはできない。 >> >> >> >> 2.ビルドは、テスト計画にアサインされたテストケースを回帰テストで管理するためにある。 >> >> (１の機能が実装されている理由に相当する) >> >> >> >> #実際の運用のイメージ >> >> 最初はビルドを1個だけ追加する。 >> >> →ビルドに紐づいたテストケースをテストする >> >> →リリース時にビルドをCloseして、テスト結果を変更できないようにする。 >> >> →2回目のテスト開始時に、新たなビルドを追加する。 >> >> テスト計画にアサインされた全テストケース(1回目のテストで成功になったケースも含む)をテスト開始。 >> >> 1回目のテスト結果は無関係。 >> >> →以下繰り返し。 >> >> >> >> 3.イテレーション単位にテストケースを変更してリリースするならば、そのたびにテスト計画を >> >> 作って、テストケースをアサインする。 >> >> >> >> #実際の運用のイメージ >> >> イテレーション1は機能A、イテレーション2は機能Bをリリースする計画を立てたと仮定する。 >> >> >> >> イテレーション1を開始 >> >> →機能Aのテストケースをテスト計画1にアサインする >> >> →テスト計画1へビルド1をアサインする >> >> →機能Aのテスト実行 >> >> →機能Aのテスト結果が全て「成功」になったら、ビルド1をCloseする >> >> →イテレーション1をリリース >> >> ↓ >> >> →イテレーション2を開始 >> >> →機能Bのテストケースをテスト計画2にアサインする >> >> →テスト計画2へビルド2をアサインする >> >> →機能Bのテスト実行 >> >> →機能Bのテスト結果が全て「成功」になったら、ビルド2をCloseする >> >> →イテレーション2をリリース >> >> >> >> つまり、XPやScrumのイテレーションはTestlinkのテスト計画に相当し、Testlinkのビルドは >> >> XPの継続的インテグレーションで行う統合ビルド(実際のシステムのビルド)と同等であると >> >> 見なしてよろしいでしょうか？ >> >> >> >> 上記のように考えると、リリース後は、テスト計画は閲覧可能とするが、ビルドはCloseして >> >> テスト結果を変更できないようにするTestlinkのやり方が非常に理解できます。 >> >> >> >> 以上、よろしくお願いします。 >> >> >> >> 2008/12/17 0:03 Toshiyuki Kawanishi <tosik****@users*****>: >> >> > あきぴーさん >> >> > >> >> > >> >> > こんばんは。川西です。 >> >> > いつもご質問ありがとうございます！ >> >> > ご質問のおかげで情報が整理できて助かります。 >> >> > >> >> > 私の分かる範囲でですが...... >> >> > >> >> >> 1.テスト結果の「各テストケースの全バグ」欄にある「解決済み」「オープン」の意味は？ >> >> >> テストケースが失敗→成功になっても、「解決済み」にならない。 >> >> >> 失敗したテストケースに紐付けたバグが解決or検証完了になっても、「解決済み」に >> >> >> ならない。 >> >> > >> >> > ご報告ありがとうございます！ >> >> > これはTestLinkもしくはredmineパッチのバグだと思いますので、 >> >> > 私の方で調べて、またご連絡します。 >> >> > >> >> > >> >> >> 2.要件とテストケースの紐付けを一括インポートする方法はありますか？ >> >> >> テストスイートXMLをインポートする時に、要件も一括インポートしたいのです。 >> >> > >> >> > これは手作業で行うしか無いと思います。 >> >> > >> >> > >> >> >> 3.ビルドの使い方をもう一度教えて下さい。 >> >> >> 現在は、テスト計画に追加されたテストケースは、テスト計画に紐づくビルドに >> >> >> 全て表示されてしまいます。 >> >> >> リリース単位でテストケースやテスト結果を管理するには、テスト計画の単位で >> >> >> 管理するしかないのでしょうか？ >> >> >> リリース時にビルドに紐付けたテストケースやテスト結果を変更できないようにしたい。 >> >> >> つまり、ビルドをリリースするバージョンのように使いたいのです。 >> >> > >> >> > ビルドをクローズすると結果を登録できなくなります。 >> >> > >> >> > 具体的には、 >> >> > ホーム-[ビルドの管理]-[<ビルド名称のリンク>]とたどって、 >> >> > 「オープン」のチェックをはずし、[更新] ボタンをクリックします。 >> >> > その後、 >> >> > テスト結果登録画面の左上のプルダウンメニューから >> >> > クローズしたビルドを選択して、[フィルターの適用] ボタンをクリックすると、 >> >> > 成功/失敗/ブロックという結果を選択するボタンが非表示になります。 >> >> > >> >> > ですので、仰っていただいたように、 >> >> > テストが終了してそのビルドをリリースした場合は、 >> >> > 該当のビルドをクローズすることをおススメします。 >> >> > >> >> > >> >> >> 過去のメーリングリストを読んだら、似たような質問をしている人もいました。 >> >> >> TestlinkのUIは、Ver1.8では使いやすくなっているでしょうか？ >> >> > >> >> > ご存じの事と思いますが、 >> >> > 最近このMLに加入していただいた方もいらっしゃいますので、 >> >> > 念のため確認させていただきますね。 >> >> > >> >> > TestLink日本語化プロジェクトのメンバーの中でも >> >> > TestLinkのコミット権を持った人が何人かいますが、 >> >> > TestLink自体の機能を追加したりする >> >> > 担当になっている人はいません。 >> >> > 基本的なミッションとしては、UIの日本語化と >> >> > デイリー＆リリース前のテストとなっています。 >> >> > >> >> > ですので、MLに寄せて頂いたご要望は、できる限りまとめて本家開発者に >> >> > お伝えしますが、私たちが直接ソースをいじっている訳ではありません。 >> >> > >> >> > TestLinkに限らず、オープンソースソフトウェアに希望の機能を追加する >> >> > 近道は本家開発者にパッチを送ることだという事を、 >> >> > 念のため再度、確認させてください。 >> >> > >> >> > # 本当は頂いたご要望を直接反映できれば良いのですが、 >> >> > その辺が悩ましいところです。 >> >> > そういえばredmineパッチは本家のトラッカーに登録したところ、 >> >> > 喜んでくれたのでコミットしました。1.8から同梱される予定です。 >> >> > >> >> > >> >> > ご要望に関しては、ごもっともだと思いますので、 >> >> > 私の方でもパッチが書けるかどうか試してみたいと思います。 >> >> > 皆さんの方でも、こんなパッチが書けたよという情報がございましたら、 >> >> > ご連絡いただけるとありがたいです。 >> >> > その方が本家に採用されやすいですので。 >> >> > >> >> > # ただ、前にもお伝えした通り、個人的には >> >> > バグ収束曲線などは連携した側のBTSで描くのが自然だと思います。 >> >> > TestLinkでグラフを描くのであれば、仰っていただいたように、 >> >> > 西山さんのExcelマクロのようなテストの進捗に関するグラフになると思います。 >> >> > >> >> > なお、今だと、1.8rc2のコードをベースにパッチを書いた方が >> >> > 本家に採用されやすいと思います。 >> >> > >> >> > # 個人的には、全文検索とテストケースのバージョン間のDiffを取るための >> >> > パッチを書いてみたいところなのですが、 >> >> > 時間があまり取れていません...... >> >> > >> >> > >> >> > 以上、よろしくお願いします。 >> >> > >> >> > >> >> > Toshiyuki Kawanishi <tosik****@users*****> >> >> > >> >> > >> >> > --- >> >> >> お久しぶりです。あきぴーです。 >> >> >> Testlinkを3ヶ月運用してみて、Redmineと共にプロジェクト管理をIT化するツールとして >> >> >> 非常に有用だと考えてます。 >> >> >> >> >> >> しかし、TestlinkのUIを使いこなせなかったり、どうしても使いにくくて改善して欲しい >> >> >> 機能があります。 >> >> >> 以下、たくさん質問してしまいますが、よろしければ、少しでもよろしいのでご回答を >> >> >> 頂けると非常に助かります。 >> >> >> >> >> >> 【実行環境】 >> >> >> Ver 1.7.4 >> >> >> >> >> >> 【Testlinkの使い方について】 >> >> >> 1.テスト結果の「各テストケースの全バグ」欄にある「解決済み」「オープン」の意味は？ >> >> >> テストケースが失敗→成功になっても、「解決済み」にならない。 >> >> >> 失敗したテストケースに紐付けたバグが解決or検証完了になっても、「解決済み」に >> >> >> ならない。 >> >> >> >> >> >> 2.要件とテストケースの紐付けを一括インポートする方法はありますか？ >> >> >> テストスイートXMLをインポートする時に、要件も一括インポートしたいのです。 >> >> >> >> >> >> 要件はCSVインポートで可能なのは知ってます。 >> >> >> （但し、UTF8でないと文字化けする。「データ」という文字は文字化けする。） >> >> >> >> >> >> 要件管理IDとテストケースを紐付けるためには、要件CSVとテストスイートXMLへ >> >> >> どのように連携させればよいか？ >> >> >> 「テストケースを要件にアサインする」画面で手作業で行うしかないのか？ >> >> >> >> >> >> しかも「テストケースを要件にアサインする」画面ではテストケース単位でしか >> >> >> 要件をアサインできない。 >> >> >> 数千〜数万オーダーのテストケースを一括インポート後に画面上で要件に >> >> >> アサインするのは非現実的です。 >> >> >> せめて、テストスイート単位で、複数のテストケースを要件に一括アサインできない >> >> >> でしょうか？ >> >> >> >> >> >> 今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を >> >> >> 追加しています。 >> >> >> 理由は、テストの目的や観点を明確にして、お客様に説明するためです。 >> >> >> つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは >> >> >> 揃ってます。 >> >> >> 狙いは下記のトレーサビリティです。 >> >> >> >> >> >> 要件(Testlink)→テストケース(Testlink)→【チケット】(Redmine)←ソース(Subversion) >> >> >> >> >> >> 上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合は >> >> >> テスト仕様書の作成工程で潰せると思います。 >> >> >> >> >> >> 3.ビルドの使い方をもう一度教えて下さい。 >> >> >> 現在は、テスト計画に追加されたテストケースは、テスト計画に紐づくビルドに >> >> >> 全て表示されてしまいます。 >> >> >> リリース単位でテストケースやテスト結果を管理するには、テスト計画の単位で >> >> >> 管理するしかないのでしょうか？ >> >> >> リリース時にビルドに紐付けたテストケースやテスト結果を変更できないようにしたい。 >> >> >> つまり、ビルドをリリースするバージョンのように使いたいのです。 >> >> >> >> >> >> 【TestlinkのUI改善要望】 >> >> >> 1.テストケースへユーザをアサインする場合、選択したテストスイートで一括アサイン >> >> >> できない。 >> >> >> 現在のUIは、最下層のテストスイート単位でしか一括アサインできません。 >> >> >> >> >> >> 修正方法は、選択したテストスイートに紐づくテストケース全てをFormタグで囲む >> >> >> ようにすればよいと思います。 >> >> >> >> >> >> 2.RedmineチケットからTestlinkのケースURLをリンクすると、Testlinkフレームが消え >> >> >> ます。 >> >> >> 同様に、テスト計画へケースを追加・削除、ユーザをケースへアサインするリンクを >> >> >> 押して別画面を開くと、フレームが表示されないです。 >> >> >> Frameの問題でしょうか？ >> >> >> >> >> >> 3.テストケースの内容、テスト結果、添付ファイルの全文検索が無い。 >> >> >> RedmineやTracのように、全文検索機能が欲しいです。 >> >> >> ITILの言う変更管理の機能を実現するために非常に重要だと思います。 >> >> >> >> >> >> 4.Testlinkテスト結果画面へバグ収束曲線、バーンダウンチャートを表示して欲しいです。 >> >> >> 西山さんのExcelマクロをTestlink上で表示して欲しいです。 >> >> >> テスト実行履歴(結果も実行時も)はDBにあるから、実装可能だと思います。 >> >> >> >> >> >> 5.テスト結果画面からemail送信機能があるが、confing.inc.phpの/** [SMTP] */を >> >> >> どのように設定するのか？ >> >> >> 一度設定したら、2回目の変更が反映されないようです。 >> >> >> >> >> >> 6.テスト結果の「各テストケースの全バグ」欄で、チケットにリンクできるのに、テスト >> >> >> ケースIDのリンクが無いので、リンクを追加して欲しいです。 >> >> >> 理由は、この欄でNGケースのチケットが解決されたか？検証完了まで持って行ったか、 >> >> >> を知りたいからです。 >> >> >> 修正方法は、テストケースIDが分かっているからリンクを張るだけです。 >> >> >> >> >> >> 僕は、タブブラウザで下記3画面を開いて、進捗をリアルタイムに確認しています。 >> >> >> >> >> >> 6-1.テスト実行→テスト結果の詳細を確認する >> >> >> 6-2.全般的なテスト計画のメトリクス→消化テストケース数から進捗を確認する >> >> >> 6-3.各テストケースの全バグ→NGケースとバグチケットのステータスを確認する >> >> >> >> >> >> 7.テスト結果、テスト実行画面でRSS機能はないのでしょうか？ >> >> >> 逐一、手作業でRefreshしなければ、最新表示されないです。 >> >> >> >> >> >> >> >> >> 過去のメーリングリストを読んだら、似たような質問をしている人もいました。 >> >> >> TestlinkのUIは、Ver1.8では使いやすくなっているでしょうか？ >> >> >> >> >> >> http://lists.sourceforge.jp/mailman/archives/testlinkjp-users/2007-November/000035.html >> >> >> >> >> >> 長文になってしまい申し訳ありませんが、一つでも回答して頂けると幸いです。 >> >> >> 以上、よろしくお願いします。 >> > >> > _______________________________________________ >> > Testlinkjp-users mailing list >> > Testl****@lists***** >> > http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users >> > >> >> _______________________________________________ >> Testlinkjp-users mailing list >> Testl****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users > > _______________________________________________ > Testlinkjp-users mailing list > Testl****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users >
