TOC
単語
| 伴う | ともなう | 伴随，随着 | |
| 規約 | きやく | 规范，变准 | |
| 共通 | きょうつう | 共同的 | |
| 徐々に | じょじょに | 慢慢地，逐渐地 | |
| 見出し | みだし | （文件）目录 | |
| 注釈 | ちゅうしゃく | 注解，说明 | |
| ハイパーリンク | hyperlink | 超链接 | |
| 現象 | げんしょう | 现象，表现 | |
| 改修優先度 | かいしゅうゆうせんど | 修改的优先顺序 | |
| しばしば | 经常，通常 | ||
| 間違える | まちがえる | 错误，搞错，弄错 | |
| 新たな | あらたな | 重新的，新的 | |
| 出してくる | だしてくる | 提出来 | |
| 補足情報 | ほそくじょうほう | 补充信息 | |
| もたらす | （由…）带来 | ||
| 一気に | いっきに | 一口气，一下子 | |
| 既存システム | きそんしすてむ | 已有的系统 | |
| 新規機能 | しんききのう | 新定的功能 | |
| 制限 | せいげん | 限制，局限 | |
| ペンディングリスト | pending list |
ポイント
-
これらがもたらす問題点。 → 由此带来的问题。
-
本来はツールを使うつもりですが。 → 本来计划使用工具的。
-
勉強することがいっぱいなので。 → 因为要学的东西太多了。
-
とりあえず手で管理する。 → 总之先手工管理。
会話
会話の背景
- コーディングに入りますと、それに伴ってテストも始まる。
- テストをすると、テストリポートや、バグリポート、および変更連絡票などが発生する。これらのドキュメントの規約も関係者のあいだで意識をさせて、共通な行動を行うよう、努力が必要である。
登場人物
- 石田：プロジェクトマネージャー
鈴木：開発チームリーダー
山田、田中、前田：開発チームメンバー
会話内容
-
石田：
- こんにちは。
- 現在コーディングに入りまして、テストも徐々に始まります。それにより、テストリポートや、バグリポート、および変更連絡票などが発生しますので、今日はテスター、SE、プログラマーにも集まってもらって、これらのドキュメントの規約などに関して議論してもらおうと思います。
-
鈴木：
- そうですね。まずテストリポートから始めましょう。
- ここでいうテストは機能テストと統合テストです。我々はテスト計画通り、自分が担当しているところの機能をちゃんとテストしなければなりません。その結果をテストリポートとして書いてもらいます。
- テストリポートでは、まず、見出しの部分には、テスターの名前を書いてください。それと、テスト対象となるモジュールの名称、バージョン、テスト環境、データベース環境および使っているデータベースの名称、それと関係している外部のシステムなどを記述してください。
- そのテストの内容としては、各テスト項目は一行になると思います。あるモジュールに対してのテストはまとめて一緒に置いておく。各行には、番号、テスト機能、テスト対象、テスト内容、予想結果（画面変化、データベース変化など）、結論、注釈、バグの重要度などがあります。
-
山田：
- 今回のテストでは、自動的な管理ツールを使いますか？
-
鈴木：
- 今回は、自動的な管理ツールは使いませんので、Excelフォーマットを記述してください。その上で、もしハイパーリンクで、テスト結果の間に、また関係の項目間を連結できればベターだと思います。
-
山田：
- 分かりました。バグリポートはどうでしょうか？
-
田中：
- バグリポートはテストリポートから取ってきますが、エラーが出た項目をそのままコピーしてくることはいけません。バグリポートは開発者あるいはプログラマーにフィードバックするので、各バグに関して、以下のような項目が必要です：バグ番号、バグ現象、発見者・テスター、対応したテスト番号、改修優先度、など。
- このバグリポートをチームリーダーに渡して、チームリーダーより、作業の指示として関係するプログラマーに配布します。
-
石田：
- おそらく、コーディングに入っても、お客さんの都合により仕様の変更、また不具合により仕様の変更をすることがしばしば発生します。それらの仕様変更などに関してもドキュメントを書いて、ちゃんと管理しなければなりません。
-
鈴木：
- そうですね。一部はバグとも言えますが、実際は仕様が曖昧とか誤っていたこともあります。またユーザーが新たな要求を出してくることもあります。この場合は、大抵SEが関係者と相談し、変更連絡票を書くことが必要です。
- 変更連絡票には、以下の項目が必要です：変更連絡表番号、現状、新たな要求、関係した機能、変更優先度、など。
- ほとんどの場合は実際的には新しい仕様ですので、ここまでの要求定義と同じように、必要な画面設計や、機能フロー図、またビジネスリールなどの補足情報を添付することが必要です。
-
前田：
- そうすれば、コーディングのほうは、これらの仕様変更にしたがって、新たな作業をしなければならないでしょうか？
-
鈴木：
- 基本的にはそうですが、全部ではありません。
- ということは、バグリポートでも、変更連絡票でも、仕様変更でも、チームリーダーがチェックすることが必要です。これらがもたらす問題点は全部が一気に解決できるわけではないので、やはり優先度により、重要性、まだ既存システムの変更の大きさにより、計画しなければなりません。
- おそらく、一部はプログラマーに戻して、改修や新規機能として作業してもらいますが、一部は時間や資源、また予算の制限で、すぐやれないかもしれません。それと、ユーザーの要求は、ここでもまだはっきりしていないこともよくありますから。
-
田中：
- そのときは、ペンディングリストを作ることになると思います。このリストは、今すぐやれないですが、やってほしいことを記述しておきます。
- ベンディングリストは変更連絡票と似ていますが、およそ以下の項目が必要です：ペンディング番号、提出者、提出日、概要、ペンディング詳細、ベンディング理由、関係した機能、作業優先度、など。もちろん、変更連絡票と同じように必要な補足情報を添付することもよくあります。
-
石田：
- ところで、今回の開発では、バグ管理、変更管理には何かツールを使うでしょうか？
-
鈴木：
- 本来はツールを使うつもりですが、ただし、今回はEclipseをはじめ、StrutsやHibernateなどフレームワークもあるし、皆さんには勉強することがいっぱいなので、テストやバグのほうがはとりあえず手で管理するになっています。
- 次回のプロジェクトでは、BugzillaかGNATSなどオープン系のバグ管理ツールを使う予定です。
-
石田：
- 了解しました。
- それでしたら、今日のミーティングはここまでで終わらせましょう。
- 皆さん、どうもありがとうございました。
-
皆：
- どうもありがとうございました。
「真诚赞赏，手留余香」
WZhong
真诚赞赏，手留余香
使用微信扫描二维码完成支付
