how prepare yourself
テストケースの作成に備えて生産性を向上させる方法：
テスターが高品質のテストケースを作成することを決定し、テストケース作成の効率と生産性を向上させたい場合、テスターがこれらの目標を達成するのに役立つ重要なポイントはほとんどありません。
まず、IT業界で成功するすべてのソフトウェアテスターに必要ないくつかの重要なポイントを専門的かつ心理的に準備する必要があります。これは「 入力 テストケースの作成を開始する前のテスターの場合は「」。
次に、プロジェクトに関連する品質指標を理解する必要があります。これは、テストライフサイクルのさまざまなフェーズでテスターのパフォーマンスを評価するためのツールとして使用されます。これは「 出力 完了後のテスターの場合 テストケースの作成 。
最後に、テスターは、バグがどのように報告され、問題がエスカレーションされ、テストレポートが標準手順に沿ってどのように作成され、プロジェクトの利害関係者が理解できるかを知る必要があります。
学習内容：
テスト用の無料のSOAPWebサービス
テストケース作成の準備
1） テストケースの作成は芸術であり、単なる仕事や仕事ではありません。ソフトウェアの一部またはセグメントを設計および開発することはできますが、効率的なテストアプローチですべてのシナリオで完全にテストされない限り、それは役に立たず、誰もがリリースして使用する資格がありません。そう、 自分をプロジェクトの重要な人物として扱い、テスト活動をプロジェクトの重要なタスクとして扱います 。
2） ザ・ 前向きな姿勢での情熱 、これは最高の個人です 品質テスターは持っている必要があります プロジェクトのライフサイクル全体。情熱はチームビルディング能力を動機付け、態度は質の高いテストケースを書く際に優れた生産性をもたらします。つまり、テストライティングアクティビティは、プロジェクトの最終出力として優れた結果を達成するという共通の目標のための専門的および個人的な資質のブレンドです。
3） ポジティブで ネガティブテストケース テストケースの作成の一部ですが、テスターはセミポジティブである必要があります バグを見つけることでテスト中のアプリケーションを壊すという考え方 。これは否定的な考え方ではなく、リリース後に誰かがバグを特定する状況を回避したり、システムの一部のユーザーがシステムを破壊する状況を回避したりします。
4）テスターの効率 テスト中のシステムで特定されたバグの数に基づいて推定するのではなく、成功したテストケースを作成する機能に基づいて推定する必要があります。その結果、欠陥が発見されます。したがって、テストケースは、カバレッジと トレーサビリティ システムの境界とスコープに基づいて最大にする必要があります。
5） アプリケーションドメインを完全に理解する 。例えば、ウェブサイトのテストは、何千人もの人々が同時に利用している証券取引所向けに開発された金融ソフトウェアをテストするよりも簡単です。単純なウェブサイトの機能はどのテスターでも理解できますが、金銭的条件と機能は、関連する学歴やトレーニングを持っているか、持っているまで、すべてのテスターが理解できるわけではありません。 ドメインエクスペリエンス 。
したがって、テスターが新しいプロジェクトに割り当てられるとき、テスターは、資格があり、期待どおりに仕事を遂行できるかどうかにかかわらず、自己評価を行う必要があります。機能要件を理解するのが難しい場合は、テスターの効率とパフォーマンスに関する将来の誤解を避けるために、事前にプロジェクトチームにエスカレーションする必要があります。これは、適切な計画とトレーニングを通じて、プロジェクトマネージャーまたはテストマネージャーによって処理されます。
6） プロジェクトの要件と実行するテストの種類は、プロジェクトごとに異なります。テスターは、あらゆる種類のテストを実行できるように準備する必要があります。 能力を制限しないでください あなたのスキルと専門分野に。あらゆるタイプのテストのテストケースを作成して実行する責任と課題に取り組む準備をしてください。
多くのテスターは、手動または自動化のテスターとして自分自身を適応させたり、投影したりしようとします。パフォーマンステスト、負荷テスト、またはストレステストに関しては、必要な知識をトレーニングまたは収集することで役割を果たし、準備をしているテスターはほとんどいません。そう、 迅速な学習者になる 責任を持ってキャリアを積む準備をしてください。
7）テストの種類を特定する 実行する必要があり、AUTのテストに必要なスキル。 例えば、 一部のプロジェクトではブラックボックステストのみが必要であり、一部のプロジェクトではホワイトボックステストのスキルが必要です。 「の知識 スクリプティング 」または「 SQL 」または「 マークアップ言語 HTML / XMLなどのような」、またはソフトウェアのインストール/インストールのトラブルシューティング方法に関するシステム知識などは、自分で学習するか、同じトレーニングを受ける必要があるプロジェクト固有の要件です。
8） テストケースがカバーしていることを確認します パフォーマンステスト、セキュリティテスト、および回帰テストの種類。 例えば、以下のログイン画面を使用してアプリケーションにログインするには：
例を使用したホワイトボックスとブラックボックスのテスト
- 数千人のユーザーが同時にシステムにログインしているときにアプリケーションが安定しているかどうかを確認するためにパフォーマンステストが必要になる場合があります。このシナリオをカバーするようにテストケースを作成する必要があります。
- アプリケーションが適切な権限と権限を持つユーザーにのみシステムの使用を許可しているかどうかを確認するためにセキュリティテストが必要になる場合があります。テストケースは、これらのシナリオをカバーするように作成する必要があります。
- コア機能と重要な機能がすべてのリリースで正しく機能しているかどうかを確認するために、回帰テストが必要になる場合があります。
9）テストケースレビュー ：ソフトウェア開発とテストライフサイクルの中で最も重要で見過ごされているフェーズの1つは、「 レビュー 」。プロジェクト計画に十分な時間配分が含まれている場合 レビュープロセス プロジェクト開発のすべての段階で、私たちが期待できる最高品質の成果物と成果物。
たとえば、テストケースの作成を開始する前に、テスターは「要件仕様」ドキュメントがレビューされ、すべてのレビューポイントがドキュメント内で考慮および更新されているかどうかを確認する必要があります。組織が適切で成熟したプロセスに従っている場合、すべてのドキュメントテンプレートには、ドキュメント自体の最初のページにこの変更情報が含まれている必要があります。
テストケースドキュメントは、次の方法で少なくとも3回確認する必要があります。
i）セルフレビュー
ii）ピアレビュー
iii）完全性、テストカバレッジ、トレーサビリティ、およびテストケースがテスト可能かどうかについて他の人がレビューします。
10） 最後に、 見積もり方法を理解し、 テストタスクを計画する 。 1日の予定された推定時間のみ作業するように計画します。これは、タスクを時間どおりに開始して完了し、翌日のタスクの計画を立ててその日に出発することで実現できます。
深夜に滞在したり、週末をオフィスで過ごしたりすることは避けてください。現在、効率的なプロジェクト管理アプローチが利用可能であり、プロジェクトはアジャイル環境で実行されています。マイルストーンがプロジェクトチームによって達成されない場合、それはプロジェクトチームからの非効率ではなく、非効率的なプロジェクト管理として扱われます。
注意 ：覚えておいてください 自動テスト 、テストケースは、少なくとも1回は明確に記述およびレビューし、テスト対象のアプリケーションの機能フローを完全にカバーする必要があります。自動化テストツールは、手動テストケースが明確に定義および記述されている場合にのみ、テストケースを正常に記録および実行できます。
品質メトリクス
これは、ソフトウェアテストフェーズでの重要なアクティビティです。テストチームは、プロジェクトの目標を達成するために使用されるさまざまなテストメトリックを完全に認識している必要があります。テスターのパフォーマンスは、テスト実行フェーズだけでなく、要件分析、テストケースの作成、実行、欠陥レポート、そして最後にテストレポートフェーズから収集されたすべてのテストメトリックに基づいて評価されます。
以下のいくつかの重要なテストメトリクスを見つけてください テスターの生産性とテストフェーズの効率を高めるために、ほとんどの組織がこれに続きます。
また、参照してくださいテストフェーズで使用されるその他の有用なテストメトリック：
=>重要なソフトウェアテストの測定基準と測定値および ライブプロジェクトのバグ追跡、テストメトリック、およびテストサインオフプロセス。
1）平均テスト効率
- 1人あたりのバグ-テスト作業の月。
- 平均として計算されます（テスト作業中のバグの合計（人月単位））。
- すべての内部リリース後、およびテスト完了後に計算されます。
- 許容限度：50未満である必要があります
2）平均的な顧客の欠陥密度
- 配信後にクライアントから報告されたバグと、テスト作業の合計（数か月）。
- 平均として計算されます（配信/テスト作業後のバグの合計（人月））。
- 外部リリースおよびプロジェクト完了後に計算されます。
- 許容限度：1未満である必要があります
3） 機能テストの失敗
- 失敗した機能テストケースの数/実行された機能テストケースの総数。
- 毎月または隔週で計算されます。
4）重大度レベル1のバグ
- 重大度レベル1（ブロッカー）で識別されたバグの総数。
- ブロッカーの問題により、ソフトウェアのテストを続行できません。
- 週単位で計算されます。
5）重大度レベル2のバグ
- 重大度レベル2で識別されたバグの総数（メジャーバグ）。
- 主要なバグのため、機能のテストを続行することはできませんが、システムの他の部分で続行することはできます。
- 週単位で計算されます。
6）重大度レベル3のバグ
- 重大度レベル3で識別されたバグの総数（マイナーバグ）。
- 識別されたバグは軽微であり、テストを停止しないため、テストを続行できます。
- 週単位で計算されます。
7）重大度レベル4のバグ
- 重大度レベル4（外観上の問題）で識別されたバグの総数。
- 識別されたバグは外観に関連しており、次のリリースで修正されるため、テストは問題なく完了することができます。
- 週単位で計算されます。
バグレポート
バグ報告メカニズムは、アプリケーションの品質を維持するために、成熟したテストプロセスで制御する必要があります。バグのステータス、重大度、および優先度を知るために、適切な権限のある人に適切なエスカレーションプロセスが必要です。がある 利用可能な多くの無料および商用のバグ報告ツール Bugzilla、Mantisなどのように、問題追跡メカニズムで非常に効果的であり、プロジェクトで使用される任意のテスト管理ツールと簡単に統合できます。
すべてのテストプロジェクトで、オンラインステータスレポートメカニズムの標準的な手順に従う必要があります。これらのバグ追跡システムに記録および報告されたすべてのバグ/問題は、直ちに各当局に電子メールを送信する必要があります。これにより、当局はそれに応じて計画を立て、行動を起こすことができます。
バグ報告プロセスを詳細に学ぶ次の記事を読む：
=> 良いバグレポートを書く方法は？ヒントとコツ
=> サンプルバグレポート
=> なぜバグレポートはすべてのテスターが学ぶべき芸術なのですか？
=> バグのライフサイクル
=> Webおよび製品アプリケーションのサンプルバグレポート
テストレポート
バグレポートシステムで発生、ログ記録、エスカレーションされたバグレポートとは別に、テストレポートは、テストのステータスや、テストレポート期間中に特定および計算されたその他の重要な指標を知るための最も重要なドキュメントの1つです。
以下は、そのような単純なテストレポートの1つです。
また、次の便利なチュートリアルをお読みください効果的なテストレポート：
=> 効果的なテスト要約レポートを作成するためのガイド
=> テストの実行をスマートに報告する方法(ステータスレポートテンプレートのダウンロード)
コンピュータのオペレーティングシステムの名前
結論
テストケースを作成するための準備プロセスは、プロジェクト内のリソースの割り当てだけでなく、適格なテスターとしての準備や、テストライフサイクル全体およびリリース後も監視されている品質メトリックの理解など、いくつかの重要な要件があります。
したがって、プロセス、標準、手順に従い、情熱を持って品質メトリクスを厳密に順守することで、優れたテスト効率、生産性、品質テスターを自動的にもたらすことができます。これは、あなたの職業生活の習慣になります。
これらの品質要因は、いくつかの質問をすることで自己分析またはグループ分析できます これは、テストケースの作成と実行において効率的なアプローチを達成するという目標において、私たちが自己とプロセスの改善の正しい軌道に乗っているかどうかを示します。
- 機能要件/ユーザー要件/ビジネスユースケースドキュメントを確認しましたか？
- 機能要件ドキュメントはレビューされ、レビューコメントで適切に更新されていますか？
- テストするすべての機能の画面プロトタイプを受け取りましたか？
- テストのライフサイクル全体を通じてテスト可能で追跡可能なテストケースを作成することに慣れていますか？
- テスト対象のアプリケーションをテストするために必要なスキルセットとドメイン知識がありますか？
- テストケースを実行するために必要なトレーニングや技術的な知識が必要ですか？
- 質の高いドキュメントを準備するための時間をカバーする、テストケースの作成、レビュー、および実行のスケジュールはありますか？
- テストケースをレビューする同僚と、テストする機能の完全性と適用範囲をチェックするための認定された対象分野の専門家がいますか？
- すべての機能要件に対応できる十分なテストケースがありますか？
- パフォーマンス、負荷テスト、およびセキュリティテストに十分なテストケースがありますか？
- インストールと回帰テストに十分なテストケースがありますか？
- 問題をエスカレーションしたり、バグを報告したりするための連絡先はありますか？
- バグ追跡ツールは、すべての人に必要な許可を得て適切に構成されていますか？
- テスト計画で定義されているすべてのプロセスに従うことに満足していますか？
- すべてのレビュー会議に参加していて、開発チームまたは管理チームと話す機会を得ていますか？
- 生産性と効率が向上していますか、それとも同じ対策を講じる必要がありますか？
推奨読書= >> 最高のオンラインクリエイティブライティングコース
プロジェクトの種類や協力している組織によっては、テスターが自己改善分析を求める可能性のある同様の質問がたくさんあります。最も重要なことは、これらすべての活動は、プロセスに従うためだけに行われるべきではなく、それを通して行うことができるあなたの毎日の習慣として行われるべきであるということです。 テストへの情熱 のみ。
推奨読書
- アプリケーションのバグを見つける方法は？ヒントとコツ
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- 多言語ウェブサイトをテストするための7つの基本的なヒント
- サンプルバグレポート
- ソフトウェアテスト面接の準備方法
- PrimereBookダウンロードのテスト
- アプリケーションをテストする前に読む必要のある実用的なソフトウェアテストのヒントトップ20
- ソフトウェアテストにおけるモンキーテストとは何ですか？