Re: [ja-discuss] リリース候補版・開 発版に対する取り組み
Yutaka kachi wrote: 前から話題になっていることでもありますが、 現在のsmoke testにもテスト項目を盛り込んでいきたいですよね。 http://openoffice.s16.xrea.com:8080/pukiwiki/pukiwiki.php?%5B%5B2.0.3rc_QA%5D%5D#content_1_5 ただ、テスト項目を増やすと時間がかかるばかりなので 既存のテストに盛り込んでいくのが良いんじゃないかと思います。 リリース候補用と開発版用で、別に計上すればいいのかな。 リリース候補用は、全体の項目のなかから少なくともこれだけは確認 しておきましょうという部分集合でよいはずですよね。ということは、 全体でがんがん内容を増やしたり、別途新規の項目を増やしたとしても、 リリース用のテスト作業に掛かる時間が増えるというわけでもないでしょう。 ところで、 欧米用のテスト項目と、東アジア用のテスト項目と、中東アジア用のテスト 項目は、共通部分と、それぞれ固有の部分とに分けられると思いませんか。 中東アジア用のテスト項目を日本語圏では特に考えもしないように、 東アジア用のテスト項目を欧米圏で網羅・考慮してくれているなんて 考えない方がよいのではないでしょうか。 ですので、東アジア用の固有のテスト項目があってもいいと思いませんか。 例えば、縦書き、文字数指定・文字数行数指定、ふりがな、日付、元号、 漢数字、並べ替え、索引、日本語あいまい検索、フォント名、太字/斜体、 オンラインヘルプの訳語とメニュー名/ダイアログ上の項目名が一致しているか、 Microsoft Officeでの訳語とOpenOffice.org上で対応する機能や項目の訳語が 同一(類似)であるか、アプリケーション間での日本語文字を含んだ文字列の コピーと貼り付け、、、 確かに上記のいくつかについては、以下に↓ご提案のように、日本語文字列を 既存のテスト項目に含めればいいようですが、、、既存の欧米用のテスト項目 では考慮されていない機能もあるのではないでしょうか。 たとえば、「Short text message」を入力・保存できるか確認するというテスト 項目があるんですけど、この文字列に日本語を追加する。 -- 例 -- Short text message こんにちは、世界。12345 そして、インストール先やファイル保存先のフォルダ名やファイル名に日本語文字を使う。 特にシフトJIS固有の2バイト目に半角の\マークが来る全角文字を使うなど。 「―ソЫⅨ噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭祥薌」 例えば、 アカウント名に「表野」さん(表) フォルダ名に「ソフトウェア」(ソ) そして、テストスクリプトにも、それを盛り込む。 さらに、テストを自動進行しないで、画面確認を人間ができるようにする。 そうですね。目視しないと正誤がわかない場合がありますね。 tora wrote: ●開発版に対して ・日頃の作業はなるべく最新の「開発版」で行う ...(省略)... ●リリース候補版に対して ・リリース候補がリリースされたら、rc1 に対して、徹底的に試験する ...(省略)... ・最終のリリース候補に対しては、新たに提案されている sanity チェック (テスト項目を少なく絞って、さっさとリリースする)チェックを行って、 さっさとリリースする 提案の方向性については、賛成です。 これを実現するには、いろんな協力体制が必要になってくるようにも思います。 特に開発版については、日本語関連の機能がどこで反映されたのか 追跡する必要がありますよね。 今は、Issueが通ったところで、よかったよかった となっていて、 それが正しく反映されてるかまで追跡できていません。 #なので、日本語フォント順のようなミスが出たんですよね(^^ はい。ごめんなさい。としか言えない私。。。上記の件に関しては、 issue を発行しておいて、修正内容を確認していませんでした。 これを効率よく追跡するには、どのようにするのが良いでしょう。 まず、ソースコードなどに対する修正が、CVS 上のブランチ上で行われています。 メインの幹では 1.52 とかいう revision 番号ですが、枝では、1.52.1.3 などの ような番号になっています。 そして、そのソースコードなどを使ってエンジニアなどが独自に内部でビルドし、 修正内容の確認を行い、さらに、内部で QA のテスターがテストして、OK が出た ところで、メインの幹(トランク)へ統合され 1.53 などになります。 従って、上記の作業期間における変更は、外部からダウンロードできるビルドには 反映されていないのです。OK が出て、そして始めて、メインの幹に統合され、 ビルドされ、そして始めて、外部からダウンロードできるようになるわけです。 そこで、少なくとも2つ考えられます。 (1)修正が行われた時点で、ja コミュニティにおいても、CVS から修正内容を 入手し、独自にビルドし、修正結果を確認する (2)外部からダウンロードできるようになるまで待って、そのビルドに対して 修正結果を確認する まあ、緊急な不具合でないのであれば、(2)をしっかりとやっておけばいいのかな。 という気もいたしますが、どないもんでしょうか。 Tora - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ja-discuss] リリース候補版・開 発版に対する取り組み
catchです 中東アジア用のテスト項目を日本語圏では特に考えもしないように、 東アジア用のテスト項目を欧米圏で網羅・考慮してくれているなんて 考えない方がよいのではないでしょうか。 ですので、東アジア用の固有のテスト項目があってもいいと思いませんか。 ... (2)外部からダウンロードできるようになるまで待って、そのビルドに対して 修正結果を確認する これって、実はTCMテストでカバーできるのではないでしょうかネ それに向けて、ビルドも公開されましたし。 ・TCMテストする！ ・今回のTCMテスト項目を検証してみる。 ・2.0.4-ja向けで改善される項目(Linux日本語tips、文字並び順・・・)を 確認する なんてことをやってみましょうか。 可能ならコレに合わせて、QAテストの項目を調整できれば良いんじゃないかな。 tora wrote: Yutaka kachi wrote: 前から話題になっていることでもありますが、 現在のsmoke testにもテスト項目を盛り込んでいきたいですよね。 http://openoffice.s16.xrea.com:8080/pukiwiki/pukiwiki.php?%5B%5B2.0.3rc_QA%5D%5D#content_1_5 ただ、テスト項目を増やすと時間がかかるばかりなので 既存のテストに盛り込んでいくのが良いんじゃないかと思います。 リリース候補用と開発版用で、別に計上すればいいのかな。 リリース候補用は、全体の項目のなかから少なくともこれだけは確認 しておきましょうという部分集合でよいはずですよね。ということは、 全体でがんがん内容を増やしたり、別途新規の項目を増やしたとしても、 リリース用のテスト作業に掛かる時間が増えるというわけでもないでしょう。 ところで、 欧米用のテスト項目と、東アジア用のテスト項目と、中東アジア用のテスト 項目は、共通部分と、それぞれ固有の部分とに分けられると思いませんか。 中東アジア用のテスト項目を日本語圏では特に考えもしないように、 東アジア用のテスト項目を欧米圏で網羅・考慮してくれているなんて 考えない方がよいのではないでしょうか。 ですので、東アジア用の固有のテスト項目があってもいいと思いませんか。 例えば、縦書き、文字数指定・文字数行数指定、ふりがな、日付、元号、 漢数字、並べ替え、索引、日本語あいまい検索、フォント名、太字/斜体、 オンラインヘルプの訳語とメニュー名/ダイアログ上の項目名が一致しているか、 Microsoft Officeでの訳語とOpenOffice.org上で対応する機能や項目の訳語が 同一(類似)であるか、アプリケーション間での日本語文字を含んだ文字列の コピーと貼り付け、、、 確かに上記のいくつかについては、以下に↓ご提案のように、日本語文字列を 既存のテスト項目に含めればいいようですが、、、既存の欧米用のテスト項目 では考慮されていない機能もあるのではないでしょうか。 たとえば、「Short text message」を入力・保存できるか確認するというテスト 項目があるんですけど、この文字列に日本語を追加する。 -- 例 -- Short text message こんにちは、世界。12345 そして、インストール先やファイル保存先のフォルダ名やファイル名に日本語文字を使う。 特にシフトJIS固有の2バイト目に半角の\マークが来る全角文字を使うなど。 「―ソЫⅨ噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭祥薌」 例えば、 アカウント名に「表野」さん(表) フォルダ名に「ソフトウェア」(ソ) そして、テストスクリプトにも、それを盛り込む。 さらに、テストを自動進行しないで、画面確認を人間ができるようにする。 そうですね。目視しないと正誤がわかない場合がありますね。 tora wrote: ●開発版に対して ・日頃の作業はなるべく最新の「開発版」で行う ...(省略)... ●リリース候補版に対して ・リリース候補がリリースされたら、rc1 に対して、徹底的に試験する ...(省略)... ・最終のリリース候補に対しては、新たに提案されている sanity チェック (テスト項目を少なく絞って、さっさとリリースする)チェックを行って、 さっさとリリースする 提案の方向性については、賛成です。 これを実現するには、いろんな協力体制が必要になってくるようにも思います。 特に開発版については、日本語関連の機能がどこで反映されたのか 追跡する必要がありますよね。 今は、Issueが通ったところで、よかったよかった となっていて、 それが正しく反映されてるかまで追跡できていません。 #なので、日本語フォント順のようなミスが出たんですよね(^^ はい。ごめんなさい。としか言えない私。。。上記の件に関しては、 issue を発行しておいて、修正内容を確認していませんでした。 これを効率よく追跡するには、どのようにするのが良いでしょう。 まず、ソースコードなどに対する修正が、CVS 上のブランチ上で行われています。 メインの幹では 1.52 とかいう revision 番号ですが、枝では、1.52.1.3 などの ような番号になっています。 そして、そのソースコードなどを使ってエンジニアなどが独自に内部でビルドし、 修正内容の確認を行い、さらに、内部で QA のテスターがテストして、OK が出た ところで、メインの幹(トランク)へ統合され 1.53 などになります。 従って、上記の作業期間における変更は、外部からダウンロードできるビルドには 反映されていないのです。OK が出て、そして始めて、メインの幹に統合され、 ビルドされ、そして始めて、外部からダウンロードできるようになるわけです。 そこで、少なくとも2つ考えられます。 (1)修正が行われた時点で、ja コミュニティにおいても、CVS から修正内容を 入手し、独自にビルドし、修正結果を確認する (2)外部からダウンロードできるようになるまで待って、そのビルドに対して 修正結果を確認する まあ、緊急な不具合でないのであれば、(2)をしっかりとやっておけばいいのかな。 という気もいたしますが、どないもんでしょうか。 Tora - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 可知 豊 Yutaka Kachi http://www.catch.jp/ [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ja-discuss] リリース候補版・開発版に対する 取り組み
# そもそも、リリース候補版・開発版に対する日本のコミュニティにおける # QA(品質保証)テストの姿勢・取り組み方に見直しの余地が多く残っていると思います。 Sei_HONDA wrote: ここのところ、ぜひぜひ別スレでご提案ください。 ●開発版に対して ・日頃の作業はなるべく最新の「開発版」で行う ・testtool などの全世界の言語の人たちが行う試験結果を追証するのに時間を 費やしてしまって、後は付けたしで、というような姿勢ではなく、 日本語ネイティブでしかわからない、日本語圏文化のユーザーしか使わない、 機能をより重点的に、日頃から使ってみて、試してみて、仕様そのものを考え 直してみたり、テストしてみたりする ●リリース候補版に対して ・リリース候補が近づいてきた時点で、その時点の最新の「開発版」に対して、 より濃い試験をやってみる ・リリース候補がリリースされたら、rc1 に対して、徹底的に試験する ・rc2, 3, ... に対しては、rc1 の時期にやり残した項目を試験する ・最終のリリース候補に対しては、新たに提案されている sanity チェック (テスト項目を少なく絞って、さっさとリリースする)チェックを行って、 さっさとリリースする というような「叩き台」では、いかがでしょうか。 Tora - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
