You are on page 1of 14

品質管理基準

-テスト工程管理マニュアル-

Ver 1.3.

初版:2006/01/25
最終改訂日:2006/10/19
F.Makino<makino@webcrew.cn>
0.テスト工程実施フロー
動作確認完了 1.開発、動作確認完了

テスト前確認 2.テストを行えるか確認

テスト準備 3.テストの事前準備

既知のバグゼロ テスト実施 4.チェックシートを用いてテスト
まで繰り返し

コード修正 5.バグ表を見ながら修正

6.プロジェクトマネージャに
PMに確認 報告の上、確認してもらいます

納品 7.PMの責任の元、納品

<number>
1.1.テスト前確認事項
1.仕様書に明記してある機能について実装が行なわ
れていること
2.基本的な動作確認がとれていること
– テストは動作を完成させる作業ではない

以上二点を必ず確認してから
テストを開始して下さい。 <number>
2.1.テストの事前準備1
● テスト環境
– テストDB、テストサーバ
● システムはKernel、Revisionに至るまで可能な限り実環境に
合わせること
– VirtualServerなどを活用すると良い
– 開発環境とテスト環境は必ず分けるようにして下さい
● チェックシートの用意
– 項番、項目とチェックボックスから構成される簡単なも
ので十分です
– チェックをするという行為は人間工学的にエラー率を減少させる共
に、エラー箇所を視認できる形で確認できます
– テスト完了はチェックシートの提出を必須とします
<number>
2.2.テストの事前準備2
● テスト方法の周知
– 何をテストするのか、どのようにテストするのか

必ず全員のメタファを共有させること
● ケースバイケースで質問を促すこと
– テストを実演する

最低でも1回は行なうことが重要です
● バグ報告手法の周知
– ハードコピーに対して日付、フェーズ、氏名、メモで可
– 「その場で記述」させることがポイントです
– BTSなどを利用しても良いが、直感的であることが重要
● エクセルやブラウザでは集中力がとぎれてしまいます <number>
3.1.テストの実施1
● 開発(修正)完了
– 必ずCVSにてTAGを打つ
例:「RELEASE-1_0_0-RC1」等
– RC1はReleaseCandidate1(リリース候補1)の意味
– テストの前提条件を満たしているか確認する
満たしていない場合はテストを開始してはいけません
– テストの事前準備が完了しているか確認する
準備が完了していない場合はテストを開始してはいけません
● テスト環境へリリース
– 可能な限りリリースごとにディレクトリを分ける
● /SampleApp.rc1,/SampleApp.rc2など
<number>
3.2.テストの実施2
● テスト
– 常に1項目につき2人以上のチェックを行う
● 時間的に無理な場合にも、可能な範囲でチェックするよう心
掛けて下さい
– 自分の作ったモジュール以外をチェックするなど
– チェックシートに沿って行う
● 画面をざっと見て、まとめてチェックなどの行為はテスト漏れ
が発生するリスクが高まる為、厳禁です
– バグ票はその場で記述する

時間が経過するとバグの詳細を忘れてしまいます
● 第三者にもエラーポイントを簡単に視認出来るようにする事
で、開発(修正)効率を上げる事が可能です
<number>
3.3.テストの実施3
● テストの終了
– チェックシートの項目が全てチェックされたら、テスト完
了とする

テストの完了について「見通しがある」ことが重要です
– バグ票について日時、フェーズ、氏名、メモがあるかを
確認する
– バグ票について番号を振る
● 修正作業
– バグ票の不具合を修正
● PMの許可無く、それ以外のバグを修正してはいけません

<number>
4.再テスト
● 再テスト前の確認
– バグ票のバグは修正され、動作確認されていること

テストと動作確認を混同しないように注意してください
● 再テスト開始
– 「テストの実施1」~「テストの実施3」を行なう

チェックシートは新しいものを利用します
● 再テストの回数
– 既知のバグが無くなるまで繰り返すこと

<number>
5.テストサイクル
● テスト回数
– 初回を含めて最低でも3回以上行なうこと
● 再テストの実施において
– 再テストの1~2回目は全ての項目についてチェックを
行なうこと
● システム全体に影響がある部分についても修正されている可
能性が非常に高い為、改めて全体の通しテストを行います
– リリース後の軽微なバグ修正など
● 目的を絞ったチェックでも構いませんが、チェックシートは必
ず用いてください

<number>
補足A:FAQ
● テストが続行不能な問題が発生したら?
– 単機能の問題である場合

その機能に属するテストを中止、別な部分のテストは続行
– もちろんバグ票は必ず記述してください
– システムの根幹に関わる問題である場合

すぐにテスト全体を中止し問題の検討、対処を考える
– ある意味で、テストの開始条件が整っていないということです
● 修正作業中に未知のバグを発見したら?
– バグ票を起こすだけにし、修正は実施しません
● 次の再テストフェーズで修正しましょう
– 修正する(したい)場合、必ずPMに判断を仰ぎます
<number>
補足B:注意点
● 目的が不明確、ステータスが不明確になるようなテ
ストは行なわない
チェックシートを用いないテストは行なわないようにします
● 動作確認とテストを区別する
テストは動作しているプログラムに対して行なう行為です
● テスト環境でのテストをもって公式な完了とする
テスト環境以外(例:個人の開発環境)でのテストは動作確認で
あり、顧客へ提供する為のテストとしては不十分です
● テスト中にコードを絶対修正しない
テスト中にコードを修正する作業は、テストの前提条件を破壊
するため、テストの信頼性を大きく低下させます
<number>
補足C-1:心得
● テスト地獄に陥らないようにする
– 通常、テスト→修正→テスト→修正という作業を、明確
な区切りの無いまま続けると下記のような現象が発生
します

メンバーの士気の低下
● テスト品質の低下
● 納品物の品質が安定しない
– チェックシートを用いる理由として、現在の状況、到達
点が見通せるためPMやメンバーの不安が低下します

<number>
補足C-2:心得
● 修正作業の意味を自覚する
– 修正作業はそれまで行なったテスト結果が無効になる
行為です

根本的な修正であればあるほどテスト規模は大きくなります
– このとき修正の難易度は無関係です
● 自明の理である部分に注意をする
– 通常、誰でも単純な修正作業の場合において、影響範
囲を見逃す傾向があります
● 自動化テストは納品の為のテストにはなり得ない
– 自動化テストは非常に有用であり可能な限り記述すべ
きですが、納品の為のテストにはなりません
<number>