メニュー

すべてのテスター（主に新入生）が持つべき6つの基本スキル

6 basic skills that every tester should have

問題を排除するために楽器を試してください

ソフトウェアテストまたはQAは、低賃金または低賃金の仕事であるという誤解にもかかわらず、新規参入者がIT業界に参入するための最良のプラットフォームです。

テスターが必要とする最も重要なスキルは バグを見つける能力 。そして、あなたがバグを見つけるのが好きな人なら、あなたはこの分野を愛し、成長するでしょう。

そうは言っても、バグを見つけてQAプロセスをより適切に処理するのに役立つスキルは他にいくつかあります。

これは、ほとんどの企業で採用されているQAプロセスを示し、新しいテスターに​​テストについての説明を提供する記事です。

詳細には、文書化プロセスと標準、テスターの事前作業、制約ベースのテスト、部分的な開発中のテスト、そして最後にサインオフプロセスについて学びます。

基本的なテストスキル

さぁ、始めよう。

学習内容：

＃1。ドキュメンテーション

テストにはドキュメントが不可欠です。ほとんどの企業は、このタスクを新規参入者に割り当てています。成功するには、 良い語彙 なぜなら、文書化標準などの残りのものはあなたの管理下になく、チームと会社のプロセスに依存しているからです。

また、文書化プロセスの価値を確認してください。利点はたくさんあります。要件の変更の追跡、テストステップの追跡、作業のログ記録などに役立ちます。

おすすめの読み物=> ソフトウェアテストでドキュメントが重要である理由

＃2。試験対策

入手可能なすべての文書の中で、以下は無視できません。これらは成果物ドキュメントとも呼ばれ、クライアント、開発者、テスターの理解を橋渡しします。

a）テスト計画：最初から最後までのテストの流れをグラフ化します 。

テスト計画は、テストフェーズの範囲とアクティビティを示しています。チームはQAリードによって作成され、テスト計画に書かれているすべてのことについて貢献し、最新の状態に保つ必要があります。

一部のチームには、マスタープランとフェーズワイズプランの複数レベルのテスト計画があります。

ビジネスアナリストに尋ねる質問

テスト計画には次のものが必要です。

  • プロジェクト名とバージョン
  • テスト計画識別子–作成者、ドラフト番号、作成日など。
  • はじめに–プロジェクトの概要、目的、および制約
  • 参照–入力として使用される参照のリスト（正確で最新のバージョンを使用していることを確認してください）
  • テスト項目–モジュール、バージョン、スコープ、スコープ外など。
  • 全体的なテストアプローチ/テスト戦略–使用するツール、欠陥追跡プロセス、実行するテストのレベルなど。
  • 合格/不合格の項目基準–テスト実行ガイドライン
  • 一時停止と再開の基準
  • テスト成果物–テストケース、テストレポート、バグレポート、テストメトリックなど。
  • テスト環境の詳細
  • 連絡先情報を含むチーム名簿。モジュールまたはテストタイプごと
  • テスト見積もり–時間と労力。予算の詳細は機密情報であり、ここでは見つかりません
  • リスクと軽減計画
  • 承認
  • その他のガイドライン

また読む=>

b）テストシナリオ：

各要件に基づいて「何をテストするか」を1行で示し、通常はスプレッドシートを通じて文書化および追跡します。

それらのほとんどは含まれています：

  • モジュール/コンポーネント/機能名（ログイン、管理、登録など）
  • シナリオIDは参照用です（例：TS_Login_001）
  • シナリオの説明–「何をテストするか」例：ログインにより、有効な資格情報を持つユーザーが正常にログインできるかどうかを検証します
  • シナリオの重要性–時間が不十分な場合に優先順位を付ける–高/中/低
  • 要件ID–トレーサビリティのため

参考文献=>

c）テストケース：

正確なテストケースは、正確なテスト結果を提供します。一部の企業がテスト管理ツールを採用している場合でも、スプレッドシートは、特に初心者にとって、テストケースを作成するための一般的な媒体です。テストケース作成の基礎は、SRS / FRD / Reqドキュメントです。ただし、それだけでは不十分な場合が多いため、BA / Devチームと多くの仮定と話し合いを行う必要があります。

効果的なテストケースの作成 テスターが持っていなければならない最も重要な資格です。通常、すべてのテストケースはポジティブ/ネガティブに分類されます。 陽性のテストケース 有効な入力を提供し、肯定的な結果を得ています。 ネガティブテストケース 無効な入力を行い、正確なエラーメッセージを取得しています。

テスターのためのヘルスケアドメイン知識pdf

これらの詳細については、以下を確認してください。

すべてのテストケースに共通する属性のいくつかは次のとおりです。

  • シナリオID–テストシナリオドキュメントから取得
  • テストケースID–一意の識別と追跡用。例：TC_login_001
  • テストの説明–テストされたテスト条件の簡単な説明
  • 実行手順–テスト方法の詳細な手順
  • テストデータ–テストステップに提供されるデータ
  • 期待される結果–期待どおりの結果
  • 実際の結果–テスト実行時のAUTの応答
  • ステータス–合格/不合格/実行なし/不完全/ブロック–テストの結果を説明します
  • コメント–詳細について
  • 実行者–テスターの名前
  • 実行日–テストが実行された日付
  • 障害ID–テストが失敗した場合に、テストケースに対してログに記録された障害
  • 構成の詳細– OS、ブラウザー、プラットフォーム、デバイス情報（オプション）

おすすめの読み物=>

＃3。テストプロセス–実行するテストは何ですか？

膨大な数のテストタイプがありますが、そのすべてをそのAUTで実行できるわけではありません。時間、予算、ビジネスの性質、アプリケーションの性質、およびクライアントの関心は、アプリケーションで実行するテストを選択する際の主要なプレーヤーです。

例えば：オンラインコマースポータルの場合、ストレステストと負荷テストは必須です。ただし、見逃してはならないテストタイプのいくつかは次のとおりです。

＃4。部分開発段階でのテスト

一般的に、中堅企業や新興企業では、時間とリソースが限られています。ここでのテスターは、モジュール統合の前にテストプロセスを開始する可能性があります。つまり、ユニットおよび中間統合テストを実行する可能性があります。

これらの段階の結果は正確とは見なされないことに注意することが重要です。そのため、すべての準備が整ったら、全体的なブラックボックステストを計画する必要がある場合があります。その部分を見落とすと、コストがかかり、テストが効果的でなくなる可能性があります。

＃5。バグレポートドキュメント

実践的に、これはこれまでに作成する最も重要なQAドキュメントです。

優れたバグレポートに必要なフィールドは次のとおりです。

  • 欠陥ID–通常はシリアル番号
  • 欠陥の説明–問題の1行の説明
  • 場所–問題が見つかったAUTのモジュール/エリア
  • ビルド番号–バージョンとコードのビルド番号
  • 再現する手順–問題につながる手順のリスト
  • 重大度–問題の重大度を説明するレベルを設定します–低、中、高、ブロッカーなど。
  • 優先度–開発者が設定して、欠陥が修正される順序を決定します（P1、P2、P3など。P1-最高）
  • 割り当て先–その時点での欠陥の所有者
  • 報告者–テスターの名前
  • ステータス–バグのライフサイクルステージを表すさまざまなステータス
    • 新規–バグが見つかり、報告されました
    • オープン–QAリードによる検証
    • 割り当て済み–それぞれの開発者に割り当てるために開発リードに送信されます
    • 進行中/作業中–開発者はそれに取り組み始めました
    • 修正済み/解決済み–開発者はそれに取り組んでいます
    • 確認済み/クローズ済み– QAチームが再テストし、バグが修正されていることを確認しました
    • 再テスト– QAチームは開発者による解決に同意せず、再作業のためにバグをさらに進めます
    • 重複–同様のバグがすでに存在します
    • 延期–有効なバグですが、今後のリリースで修正される予定です
    • 無効–バグではないか、再現できないか、十分な情報がありません

参考文献=>

＃6。サインオフプロセス

サインオフ 最終的なドキュメントの送信は、QAリード/マネージャーのタスクです。ただし、チームは、最終的なレビューと監査のために、上記のドキュメント（テストシナリオ、テストケース、および欠陥ログドキュメント）を提出する必要があります。

必ず、それらすべてを校正し、最終バージョンを送信してください。

また読む=>

結論

これは、私がテスターだったときに直接目撃して経験したプロセスであり、これがあなたにいくつかの有用な指針を与えてくれることを願っています。

最後に、テストでのキャリアは私にとって絶対的な喜びであり、あなたにとってもそうだといいのですが。

あなたのキャリアに最適です！

推奨読書

^