TestlinkのUI改善要望 (Testlinkjp-users) - TestLink日本語化

あきぴーさん


川西です。

> 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
> >>
> >> 長文になってしまい申し訳ありませんが、一つでも回答して頂けると幸いです。
> >> 以上、よろしくお願いします。

TestLink日本語化

[Testlinkjp-users] TestlinkのUI改善要望