top 20 practical software testing tips you should read before testing any application
すべてのテスターに、この記事で更新されたソフトウェアテストのプラクティスを読んでもらいたいと思います。 。 各ポイントを注意深く読み、日常のテスト活動に実装してみてください。これは私がこの記事を通して読者に期待することです。テストの実践を理解していない場合は、 以下のコメントセクションでさらに説明を求めてください。
ただし、これらすべてのテスト方法を経験から学ぶことができます。しかし、間違いを犯す前に、これらすべてのことを学んでみませんか？
さあ、見てみましょう それら！
これが私が経験によって学んだベストテストプラクティスのいくつかです：
経験豊富なPDFのangularjsインタビューの質問と回答
＃1） テスト結果を徹底的に分析する方法を学びます。 テスト結果を無視しないでください。最終的なテスト結果は「合格」または「不合格」の場合がありますが、「不合格」の根本原因をトラブルシューティングすると、問題の解決策が得られます。テスターは、ログに記録するだけでなく、尊重されます。 バグ だけでなく、ソリューションを提供します。
＃二） 最大化することを学ぶ テストカバレッジ アプリケーションをテストするたびに。 100％のテストカバレッジは不可能かもしれませんが、それでも、いつでもその近くに到達しようとすることができます。
＃3） 最大のテストカバレッジを確保するために、 テスト対象アプリケーション（AUT）をより小さな機能モジュールに分割します。 このような個々のユニットモジュールにテストケースを記述します。また、可能であれば、これらのモジュールを小さな部分に分割します。
例えば、 Webサイトアプリケーションをモジュールに分割し、「ユーザー情報の受け入れ」がモジュールの1つであると仮定します。この「ユーザー情報」画面を、テストケースを作成するための小さな部分に分割できます。UIテストなどの部分。 セキュリティテスト 、 機能テスト 「ユーザー情報」フォームなどの
すべてのフォームフィールドのタイプとサイズのテスト、否定テストと検証テストを入力フィールドに適用し、そのようなすべてのテストケースを記述して最大のカバレッジを実現します。
＃4） テストケースの作成 、最初に目的の機能のテストケースを作成します。つまり、要件に応じた有効な条件を作成します。次に、無効な条件のテストケースを作成します。これは、テスト対象のアプリケーションの予期される動作と予期しない動作をカバーします。
＃5）前向きに考える。 バグ/エラーを見つける目的でアプリケーションのテストを開始します。アプリケーションにバグがないことを事前に考えないでください。バグを見つけることを目的としてアプリケーションをテストすると、間違いなくバグを見つけることができます。 微妙なバグ また。
＃6） 要件分析および設計フェーズ自体でテストケースを作成します。このようにして、すべての要件がテスト可能であることを確認できます。
＃ 7） あなたを作る コーディング前に開発者が利用できるテストケース。 より多くのバグをログに記録できると考えて、テスト用の最終的なアプリケーションリリースを待つ間、テストケースを保持しないでください。開発者にテストケースを徹底的に分析させて、高品質のアプリケーションを開発してください。これにより、再作業時間も節約できます。
＃8） 可能であれば、特定して テストケースをグループ化する 回帰試験 。 これにより、迅速かつ効果的な手動の回帰テストが保証されます。
＃9） 重要な応答時間を必要とするアプリケーションは、パフォーマンスを徹底的にテストする必要があります。 性能試験 多くのアプリケーションの重要な部分です。 に ハンドブック テスト。これは、パフォーマンステストで必要な大量のデータが不足しているため、テスターが最も無視している部分です。
アプリケーションのパフォーマンスをテストする方法を見つけてください。テストデータを手動で作成できない場合は、パフォーマンステスト用のテストデータを作成するための基本的なスクリプトをいくつか作成するか、開発者に作成を依頼してください。
＃10）プログラマーは自分のコードをテストすべきではありません。 私たちで議論されているように 前の投稿 、開発されたアプリケーションの基本的な単体テストは、開発者がテスター向けにアプリケーションをリリースするのに十分なはずです。しかし、あなた（テスター）は開発者にテストのために製品をリリースするように強制するべきではありません。
彼らに自分の時間をとらせてください。リードからマネージャーまで、誰もがモジュール/アップデートがテスト用にリリースされる時期を知っており、それに応じてテスト時間を見積もることができます。これは、 アジャイル プロジェクト環境。
＃11）要件テストを超えてください。 アプリケーションが実行するはずのないことをテストします。
＃12） 回帰テストを行っている間 前のバググラフを使用する （バググラフ–さまざまなモジュールの時間に対して検出されたバグの数）。このモジュールごとのバググラフは、アプリケーションの最も可能性の高いバグ部分を予測するのに役立ちます。
＃13） テスト中に学んだ新しい用語、概念を書き留めます。アプリケーションのテスト中は、テキストファイルを開いたままにしてください。 テストの進捗状況と観察結果を書き留めます 初期化。最終テストリリースレポートを準備する際に、これらのメモ帳の観察結果を使用してください。この良い習慣は、完全な明確なテストレポートとリリースの詳細を提供するのに役立ちます。
＃14） 多くの場合、テスターまたは開発者は、テスト対象のアプリケーションのコードベースに変更を加えます。これは、銀行プロジェクトのようにライブトランザクション処理の実行を回避するために、開発またはテスト環境で必要な手順です。
テスト目的で行われたそのようなコード変更をすべて書き留めます また、最終リリース時に、これらの変更をすべて最終的なクライアント側のデプロイメントファイルリソースから削除したことを確認してください。
＃15）開発者をテスト環境から遠ざけます。 これは、リリースまたはデプロイメントドキュメントに欠落している構成変更を検出するための手順である必要があります。開発者がシステムまたはアプリケーションの構成を変更することもありますが、展開手順でそれらについて言及するのを忘れます。
開発者がテスト環境にアクセスできない場合、テスト環境で誤ってそのような変更を行うことはなく、これらの不足しているものを適切な場所でキャプチャできます。
＃16） するのは良い習慣です ソフトウェア要件および設計フェーズ自体から直接テスターを関与させます。 このようにして、テスターはアプリケーションの信頼性に関する知識を得ることができ、詳細なテストカバレッジが得られます。この開発サイクルに参加するように求められていない場合は、リードまたはマネージャーに、すべての意思決定プロセスまたは会議にテストチームを参加させるように要求できます。
＃17） テストチームは ベストテストプラクティスを共有する 、組織内の他のチームとの経験。
＃18）開発者との会話を増やす 製品についてもっと知るために。可能な限り、紛争を迅速に解決し、誤解を避けるために、対面でのコミュニケーションを行ってください。
ただし、要件を理解したり、紛争を解決したりする場合も、メールのように上書きされた同じ通信方法で通信するようにしてください。口頭で何もしないでください。
＃19）走らないで 時間がなくなって 優先度の高いテストタスクを実行します。 テスト作業に高い優先順位から低い優先順位を付け、それに応じて作業を計画します。関連するすべてのリスクを分析して、作業に優先順位を付けます。
＃20）明確で、説明的で、明確な文章を書く バグレポート 。 バグの症状を提供するだけでなく、バグの影響と考えられるすべての解決策も提供してください。
テストは創造的でやりがいのある作業であることを忘れないでください。最後に、それはすべて、この課題にどのように対処するかについてのスキルと経験に依存します。
ネットワーキングインタビューの質問と回答のPDF
あなたに：
以下のコメントであなた自身のテスト経験、ヒント、またはテストの秘密を共有することは、間違いなくこの記事をより面白くて役立つものにするでしょう！
ご意見をお聞かせください/ 提案 この記事について。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストは感情的なタスクですか？
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- ソフトウェアテストにおけるモンキーテストとは何ですか？
- アプリケーションテスト–ソフトウェアテストの基本に！