how improve test release process
ソフトウェアの「開発フェーズ」から「テストフェーズ」までの配信に関連する一般的なプロセスを見てみましょう。 本番/クライアントへのバグのないソフトウェアリリースの成功 。
これらのプロセスは、ソフトウェア会社によって見落とされたりスキップされたりするため、テスト管理が不十分になり、「 バギー 」ソフトウェアがクライアントにリリースされ、「 不満のあるお客様 」。
たとえ すべてのリリースについて、テストチームによって多くの時間と多大な努力が払われています 、リリースされたソフトウェアが定義またはベンチマークされた品質を備えていないか、期待される基準を満たしていない場合、顧客に対する企業の評判に影響を与えるだけでなく、プロジェクトチームの意欲を削ぎ、意気消沈させます。最も重要なのは、テストチーム全体です。 。
このシナリオのテストチームの一員である場合は、「テスト機能を改善する方法と、この状況を克服するためのより良い方法はありますか」と考え続けるかもしれません。
複数のドメインとプラットフォーム、および複数のテストフレームワークを使用したソフトウェアアプリケーションとエンタープライズ製品のリリースに関与するさまざまなテストチームでの経験に基づいて、いくつかのヒントと提案を提供したいと思います。 テストリリースプロセスを改善する方法 、これにより、世界クラスのソフトウェアを提供するためのテストエンジニアまたはテストマネージャーとしての職業生活が簡素化されます。
学習内容：
テストリリースプロセス
次の表は、入力、プロセス、出力などの3つのユニバーサルフェーズを含むテストリリースプロセスの概要を示しています。
Windows10でbinファイルを開くにはどうすればよいですか
| 入力 | 処理する | 出力 |
|---|---|---|
| 7 | コードレビューチェックリストが更新され、VSSで利用可能になりましたか？ | |
| 前のプロセス 開発 | プロセスはで始まります •リリースされたソフトウェアのテストサーバーへのインストール | 次のプロセスのニーズ •煙/健全性テストに合格したソフトウェア |
| 情報/ドキュメントリファレンス •ユーザー要件ドキュメント •ソフトウェア要件仕様 •ユニットテスト計画 •コーディング標準 •コードレビューチェックリスト •開発計画 •品質保証計画 •タスクの割り当て • ワークパッケージ •プロジェクトスケジュール • プロジェクト計画 •構成管理計画 •リスク管理計画。 | サブプロセス •すべてのユニットのテストケースを準備する •開発と単体テスト •不適合手順の処理 •構成管理計画の実装。 •リスク管理計画の実施 •プロジェクトの進捗状況の監視 •エラー訂正とレビュー | 内部顧客のニーズ •バージョン番号付きのソフトウェアビルド •リリースレポート •テストケース/テストスイートドキュメント •テスト実行計画 •トレーサビリティマトリックス • テストデータ |
| 着信入力の検証 •プロジェクトドキュメントはレビューおよび承認されていますか？ •コーディング標準、コードレビューチェックリストは参照用に利用できますか？ •タスクが割り当てられ、作業パッケージが更新されましたか？ •機能仕様、開発計画、品質計画がレビューされ、承認されていますか？ •リスク管理計画には、リスクを処理するための軽減策と不測の事態がありますか？ •製品を時間どおりに納品するためのプロジェクトスケジュールの有効性？ | プロセス仕様 •ユニットテストケースは、すべての開始基準と終了基準で構成されている必要があります •コーディング標準へのコードの順守 •NCPはガイドラインに従って処理する必要があります •構成管理の手順は、構成管理計画に準拠する必要があります •リスク処理は、リスク管理計画に準拠する必要があります •スモークテストは、すべての主要な機能に合格しています | 外部の顧客のニーズ •バグフリーソフトウェア |
| サポートプロセス •ヒューマン/ハードウェア/ソフトウェア/リソースの割り当て •ハードウェアの故障メンテナンス •チームメンバーへのトレーニング | プロセスはで終了します •リリースされたビルドでの煙/健全性テストの実行 | 効率パラメータ •各ユニットは、テストの最初のラウンドに合格する必要があります •プロジェクトスケジュールに従って完了するタスク •リリース前にスモークテストに合格する必要があります •ソフトウェアをテストするためのチームの情熱のテスト |
すべてのテストチームは、 ユニーク チェックリスト ソフトウェアリリースの場合、 ソフトウェアのドメインとプラットフォーム、およびプロジェクト管理方法論（アジャイルスクラムなど）に従って、および手動/自動テストフレームワークに従って、テストの実行を開始する前に、リリースされたビルドを受け入れて、時間と労力を節約します。
これは、テストリリースフェーズで最も重要な効率パラメータの1つです。
テストリリースプロセスの改善：
1）リリースレポートを確認する 新しい機能、既存の機能のカスタマイズ/変更、以前のビルドからのバグ修正については、スモークテストまたは健全性テスト、あるいはその両方の組み合わせの実行を開始することを決定します。
2） アップデートを確認する テストドキュメント まだ更新されていない場合は、新機能とバグ修正に従って。通常、ソフトウェア開発ライフサイクル中に、これらのドキュメントは、毎週の定期的なプロジェクトレビューミーティングに基づいてテストチームによって更新されます。
3） 構成リポジトリのソフトウェアビルドを確認する プロジェクト計画で定義された標準に従って、ビルド番号、バージョン番号、ラベル付け、またはリリース名のコメントが更新されます。また、ビルドが正常にコンパイルされ、テストサーバーにインストールされていることを確認します。
4）リリース後にクイックプロジェクトレビューミーティングをスケジュールする リリースされたビルドの長所と短所、既知のバグと重要な機能などについて話し合い、誤解を避け、重要なクライアント要件を確認します。ソフトウェアリリースの品質に大きな影響を与えるため、開発チームとテストチーム間の口頭でのコミュニケーションは絶対に避けてください。
5） バグ追跡ツールが適切に構成されていることを確認します 、プロジェクトに割り当てられたテストチームと開発チームの場合、ソフトウェアのビルド番号とリリース番号、およびソフトウェアのモジュール/機能。これにより、バグを効率的にログに記録できます。そうでない場合は、優先度の高い方法でプロジェクトマネージャーまたはテストマネージャーにエスカレーションする必要があります。
6） ビルドを開発チームに返す 煙または健全性テストでビルドが失敗した場合でも、妥協することなく。厳密には、システムがスモークテストで失敗した場合はテストを続行しないでください。これにより、多くの時間と労力が節約され、後続のリリースでリリースされるソフトウェアの品質が向上します。
7） 1にプロジェクトリリースをスケジュールするst曜日 これは、テストマネージャーがビルドの安定性に基づいて次のテストサイクルを計画するのに役立ち、また、ソフトウェアの品質をかなり前もってエスカレートするクイックテストレポートをプロジェクトマネージャーに送信するのに役立ちます。開発チームが金曜日にプロジェクトのリリースをスケジュールしている場合、週末は、手動または自動のビルドフレームワークでのビルドの問題だけでなく、ずれにも利用できます。
8） テスターがドメインで適切にトレーニングされていることを確認します これは、テストチームがテストスケジュールを順守し、次のテストラウンドの時間を収集するのに役立ちます。また、プロジェクトでホワイトボクシングが必要な場合は、テストチームをトレーニングし、スクリプトやSQLなどの必要なテクノロジに触れる必要があります。
9） 複数のプロジェクトでのテスターの割り当てを回避する リアルタイムでのテスト実行の品質に大きく影響するためです。実際には、経験豊富なテスターでさえ、機能や機能を見落としているだけでなく、作業が多すぎたり、期限のある複数のプロジェクトに割り当てられたりすると、一部のテストケースが失敗しないと想定してテストケースをスキップします。
10） テストチームに情熱を持って感謝します テスターは「その日」のために働いたり、「それを1日と呼んでください」とコメントしたりしてはいけません。ソフトウェアに複数のモジュールがあり、機能主義者が完全にまたは部分的に統合または相互に関連している場合、テスターは、最終的なソフトウェア/製品の品質を対象として、優れたカバレッジとトレーサビリティマトリックスを備えたテストケースの作成/実行に情熱を注ぐ必要があります。外観上の問題でさえ「バグ」であり、「1つのバグ」としてカウントされるためです。
十一） ソフトウェアのインストールが簡単で簡単であることを確認します これは、開発マネージャーまたはインストールマネージャーが同じジョブを実行するのを待たずに、テストチームが必要に応じてソフトウェアを再インストールするのに役立ち、利用可能なテスト時間を不必要に殺してしまうためです。たとえば、Windowsベースのインストールは簡単ですが、多層テスト環境で複数のWebサーバーとワイドエリアネットワークが関係する場合、テスターはソフトウェアのインストールに数時間かかる場合があります。の場合 ソフトウェアテストのカバーとインストール、アンインストール 、ソフトウェアのパッチまたはアップデートの場合、テストチームとテストケースを実行するプロセスについて詳細に話し合う可能性が高くなります。
12） 自動化ツールがライセンスで利用可能であることを確認します のために 自動化テストフレームワーク 。自動化されたフレームワークでのテストケースの実行は、自動化されたツールが適切に構成され、複数のユーザーに対してライセンスが付与されている場合、手動のテストシナリオと比較して簡単です。特に、テスト計画に通常のテストケースの実行と回帰テストとは別にパフォーマンスと負荷のテストが含まれる場合、テスターは複数のサーバー、複数のブラウザー、複数のユーザーなどの複数の環境でのテストケースの実行をカバーする必要があります。
13） ゴーストマシンがテスト用にセットアップされていることを確認します テストの実行を開始する前。ゴーストマシンは、テスト環境が異なるマシンです。たとえば、Webアプリケーションソフトウェアは、Windows 7＆Access DB、Windows 2008＆SQL Server、Windows 8＆Oracle、Mainframe＆DB2などの複数の環境で、Chrome、Firefox、InternetExplorerなどのすべてのブラウザでテストするように計画できます。 、Safariなど、 いくつかの「システムテスト」 ハードディスクを完全にフォーマットして新しいソフトウェアをインストールしたり、パッチやアップデートなどで既存のソフトウェアをアップデートしたりする必要もあります。
14） 新機能/変更要求の実装を避ける テストの実行を停止し、ソフトウェアを再リリースして、テストフェーズを再度開始します。これは、外部の顧客を満足させるため、または少なくとも管理運営委員会や場合によっては販売/マーケティングチームの要求を満たすためのビジネス要件に従って、多くのソフトウェア組織では非常に悪い習慣です。 「アジャイル」プロジェクト環境では、顧客からの変更要求が常に推奨されますが、ソフトウェアをテストチームにリリースする前に、適切に計画して実装する必要があります。
テストリリースコンテンツの管理と制御
テストリリースコンテンツの管理と制御は、ITソフトウェアにとって、または次の図に示すIT以外のソフトウェア環境にとっても最も重要です。
- プロジェクトマネージャーおよび/またはプロジェクト運営委員会は、組織マトリックスの権限に依存し、リリースごとにコンテンツを選択する責任があります。
- バグや新機能、および顧客からの変更要求が特定されて承認されると、開発チームによって実装されます。開発チームは、開発/実装を開始する前に、プロジェクトの利害関係者に通知する必要があります。
- 実装された最終リリースに基づいて、テストチームは関連ドキュメントを更新し、それに応じてテストの準備をします。
- テストチームは、リリースレポートで定義された要件に従って、煙/健全性テストを開始します。
- Sanityに合格すると、テストチームはスケジュールに従ってテストの実行を開始し、タスク、つまり機能テスト、非機能テスト、セキュリティテスト、システムテスト、パフォーマンステスト、負荷テスト、ユーザー受け入れテストなどを割り当てます。
- テストサイクルの最初のラウンドが完了すると、テストレポートがすべての利害関係者と開発チームマネージャーに送信され、テスト実行の次の反復を計画します。
- テストレポートのステータスとバグの重大度および複雑さに応じて、2回目のテスト実行または回帰テストの完全なサイクルがユーザー受け入れテストと一緒に計画されます。
- 計画されたテスト実行サイクルが完了すると、機能、機能、およびバグ修正の合格/不合格/不合格について、プロジェクトのすべての利害関係者にテストレポートが送信されます。
サンプルリリースレポートテンプレート：
注意 ：リリースレポート用のサンプルMS Wordテンプレートは、以下からダウンロードすることもできます。
以下をご覧ください サンプルリリースレポート 」は、プロジェクトチーム全体の職業生活をこれまで以上に幸せにする、リリースプロセスの主な側面をカバーしています。
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
＃1）範囲
XYZ CompanyLimitedのGPSナビゲーションが内部テスト用にリリースされています。リリースされたバージョンは1.0.7、リリース番号は14.0、ビルド番号は105.25.03です。このソフトウェアリリースには、以前のリリースからの新機能と主要なバグ修正が含まれています。スモークテストは開発フェーズから合格していますが、回帰テストに進む前にスモーク＆サニティが必要です。
＃2）参考文献
GPSNavigation_URD_1.0.12、GPSNavigation_FFD_2.17、GPSNavigation_BusinessUseCases_1.23.10、GPSNavigation_TestPlan_1.44、GPSNavigation_TestSuites_2.10、GPSNavigation_UnitTesting_23.3
＃3）リリースの説明
このリリースはGPSナビゲーションの制御リリースであり、次の機能が含まれています。
*でマークされた機能は、このリリースの新機能です。
次の機能は、このリリースでは実装されていません。
1.モジュール1
1.1機能1
1.1.1機能1
＃4）構成管理
構成管理ツールとしてVisualSourceSafeを使用しています。ビルドは次のパスで利用できます。
内部リンク：http：//234.23.45.111/internalbuild/gpsnavigation/release1.0.13
外部リンク：https：// 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
＃5）インストール手順と手順
ビルドのインストールに関する詳細情報をQA /テストチームに提供します。
＃6）問題/修正されたバグ
バグのステータスは、欠陥追跡システムで更新されます。
＃7）修正すべき問題/バグ
＃8） 成果物
＃9）既知のバグ/問題
＃10）リリースチェックリスト
| はい・いいえ / | 説明 | Y / N |
|---|---|---|
| 1 | Visual Source Safeですべてのファイルがチェックされていますか？ | |
| 二 | 内部標準に従って、ラベルはVSSの適切なフォルダーに配置されていますか？ | |
| 3 | リリースは、VSSで「外部」/「内部」リリースとして識別できますか？ | |
| 4 | コメントで、バージョンはVSSで言及されていますか？ | |
| 5 | コメントでは、VSSで簡単な説明が記載されていますか？ | |
| 6 | コードがレビューされ、コードレビューの問題がClear Questに記録されていますか？ | |
| 8 | ユニットテストドキュメントが作成され、レビューされましたか？ | |
| 9 | ユニットテストケースが実行され、ステータスの結果が更新されましたか？ | |
| 10 | 更新されたユニットテストケースドキュメントはVSSで利用できますか？ | |
| 十一 | このリリースのすべてのクリアクエストの問題は解決/クローズされましたか？ | |
| 12 | すべてのワークパッケージタスクがVSSで完了および更新されましたか？ | |
| 13 | スモークテストは完了し、合格していますか？ |
=> ダウンロード： サンプルリリースレポートテンプレートをダウンロードするには、ここをクリックしてください MSWord形式で。
結論：
テストリリースプロセスを継続的に改善する方法
ヒント＃1） ソフトウェアのリリースとビルドを維持するための重要な要素を処理し、一元化されたソフトウェア構成管理システムを担当するリリースエンジニアリングチームをセットアップします。
ヒント＃2） ソフトウェア開発ライフサイクル、製品開発ライフサイクル、およびソフトウェアテストライフサイクルに関連するプロセスに従うためのプロジェクトチームの動機付けと評価。プロセスを定義することはできますが、関係者が従わない限り、プロセスを定義する意味はありません。
ヒント＃3） 経験と過去の履歴に基づいて、テストの労力を見積もります。テストケースの作成は、同じものの実行とはまったく異なります。テスターは、何をテストするか、どのようにテストするか、いつテストするかを理解する必要があります。そうしないと、テストサイクルが複数回行われたとしても、テストサイクルに費やされた労力が無駄になります。
ヒント＃4） 最後に、可能かつ実行可能な場合は、広く受け入れられているテストツールを使用してテストフェーズを自動化します。自動ビルドツールと自動テストツールを使用すると、ソフトウェアの品質が50％以上向上し、自動フレームワークが適切に設計されている場合は100％の品質が保証されます。
ヒント＃5） 最後になりましたが、テストリリースは単なる仕事ではなく、プロジェクト内のすべての利害関係者の生活をより簡単で快適にするための技術です。
著者について： Balu A.は、20年以上のITソフトウェアの経験と、Microsoft、Oracle、Java、およびモバイルテクノロジを使用してドメイン全体にエンタープライズアプリケーションとモビリティソリューションを提供する10年のプロジェクトおよびテスト管理の経験を持つ経験豊富な技術機能ITプロフェッショナルです。彼は基本的に、人々が正しい態度でリーダーになることを促進することに情熱を持っているリーダーであり、プロセス指向の環境で働くことを愛し、プロセスが従業員の効率、品質、生産性を向上させると信じています。
に次のチュートリアル、私たちは学びます–方法 テストケースの効率を改善します。
以下のコメントであなたの考え/質問を教えてください。
プロセスに従ってソフトウェアリリースを入手してください！
優れた生産性と労力でスケジュールどおりにテストを完了します!!
バグのない、品質が保証されたソフトウェア配信を実現してみてください!!!
この記事が気に入ったら、友達と共有することを検討してください。
推奨読書
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストにおけるモンキーテストとは何ですか？
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- サンプルバグレポート
- 実用的なソフトウェアテストQAプロセスフロー（リリースの要件）