what is software testing
テストの定義、タイプ、方法、およびプロセスの詳細を含む100以上の手動テストチュートリアルを含む完全なソフトウェアテストガイド：
ソフトウェアテストとは何ですか？
ソフトウェアテストは、アプリケーションの機能を検証および検証して、指定された要件を満たしているかどうかを確認するプロセスです。これは、アプリケーションの欠陥を見つけて、エンドユーザーの要件に従ってアプリケーションがどこで機能するかを確認するプロセスです。
手動テストとは何ですか？
手動テストは、開発されたコード（ソフトウェア、モジュール、API、機能など）の動作を予想される動作（要件）と比較するプロセスです。
学習内容：
手動ソフトウェアテストチュートリアルのリスト
これは、ソフトウェアテストに関する最も詳細な一連のチュートリアルです。このシリーズで言及されているトピックを注意深く読み、基本的なテスト手法と高度なテスト手法を学びます。
この一連のチュートリアルは、知識を豊かにし、テストスキルを向上させます。
ライブプロジェクトでのエンドツーエンドの手動テストの無料トレーニングの練習：
チュートリアル＃1： 手動ソフトウェアテストの基本
チュートリアル＃2： ライブプロジェクト紹介
チュートリアル＃3： テストシナリオの作成
チュートリアル＃4： ゼロからテスト計画文書を書く
チュートリアル＃5： SRSドキュメントからのテストケースの作成
チュートリアル＃6： テストの実行
チュートリアル＃7： バグ追跡とテストサインオフ
チュートリアル＃8： ソフトウェアテストコース
ソフトウェアテストのライフサイクル：
チュートリアル＃1： STLC
Webテスト：
チュートリアル＃1： Webアプリケーションのテスト
チュートリアル＃2： クロスブラウザテスト
テストケース管理：
Windows10用の最高の無料クリーンアップソフトウェア
チュートリアル＃1： テストケース
チュートリアル＃2： サンプルテストケーステンプレート
チュートリアル＃3： 要件トレーサビリティマトリックス（RTM）
チュートリアル＃4： テストカバレッジ
チュートリアル＃5： テストデータ管理
テスト管理：
チュートリアル＃1： テスト戦略
チュートリアル＃2： テスト計画テンプレート
チュートリアル＃3： テスト推定
チュートリアル＃4： テスト管理ツール
チュートリアル＃5： HPALMチュートリアル
チュートリアル＃6： Jira
チュートリアル＃7： TestLinkチュートリアル
技術テスト：
チュートリアル＃1： ユースケーステスト
チュートリアル＃2： 状態遷移テスト
チュートリアル＃3： 境界値分析
チュートリアル＃4： 等価分割
チュートリアル＃5： ソフトウェアテストの方法論
チュートリアル＃6： アジャイル手法
欠陥管理：
チュートリアル＃1： バグのライフサイクル
チュートリアル＃2： バグレポート
チュートリアル＃3： 欠陥の優先順位
チュートリアル＃4： Bugzillaチュートリアル
機能テスト
チュートリアル＃1： ユニットテスト
チュートリアル＃2： 正気と煙のテスト
チュートリアル＃3： 回帰試験
チュートリアル＃4： システムテスト
チュートリアル＃5： 受け入れ試験
チュートリアル＃6： 統合テスト
チュートリアル＃7： UATユーザー受け入れテスト
非機能テスト：
チュートリアル＃1： 非機能テスト
チュートリアル＃2： 性能試験
チュートリアル＃3： セキュリティテスト
チュートリアル＃4： Webアプリケーションのセキュリティテスト
チュートリアル＃5： ユーザビリティテスト
チュートリアル＃6： 互換性テスト
チュートリアル＃7： インストールテスト
チュートリアル＃8： ドキュメントテスト
ソフトウェアテストの種類：
チュートリアル＃1： テストの種類
チュートリアル＃2 ： ブラックボックステスト
チュートリアル＃3： データベーステスト
チュートリアル＃4： エンドツーエンドのテスト
チュートリアル＃5： 探索的テスト
チュートリアル＃6： インクリメンタルテスト
チュートリアル＃7： アクセシビリティテスト
チュートリアル＃8： ネガティブテスト
チュートリアル＃9： バックエンドテスト
チュートリアル＃10： アルファテスト
チュートリアル＃11： ベータテスト
チュートリアル＃12： アルファテストとベータテスト
チュートリアル＃13： ガンマテスト
チュートリアル＃14： ERPテスト
チュートリアル＃15： 静的および動的テスト
チュートリアル＃16： アドホックテスト
チュートリアル＃17： ローカリゼーションと国際化テスト
チュートリアル＃18： 自動化テスト
チュートリアル＃19： ホワイトボックステスト
ソフトウェアテストのキャリア：
チュートリアル＃1： ソフトウェアテストのキャリアの選択
チュートリアル＃2： QAテストジョブを取得する方法–完全ガイド
チュートリアル＃3： テスターのキャリアオプション
チュートリアル＃4： 非ITからソフトウェアへのテストスイッチ
チュートリアル＃5： 手動テストのキャリアを開始する
チュートリアル＃6： 10年間のテストから学んだ教訓
チュートリアル＃7： テスト分野での生き残りと進歩
面接の準備：
チュートリアル＃1： QA履歴書の準備
チュートリアル＃2： 手動テストの面接の質問
チュートリアル＃3： 自動化テストの面接の質問
チュートリアル＃4： QAインタビューの質問
チュートリアル＃5： 就職の面接を処理する
チュートリアル＃6： 新しいものとしてテストの仕事を得る
異なるドメインアプリケーションのテスト：
チュートリアル＃1 ： 銀行アプリケーションのテスト
チュートリアル＃2： ヘルスケアアプリケーションテスト
チュートリアル＃3： ペイメントゲートウェイのテスト
チュートリアル＃4： テスト販売時点管理（POS）システム
チュートリアル＃5： eコマースウェブサイトのテスト
QA認定のテスト：
チュートリアル＃1： ソフトウェアテスト認定ガイド
チュートリアル＃2： CSTE認定ガイド
チュートリアル＃3： CSQA認定ガイド
チュートリアル＃4： ISTQBガイド
チュートリアル＃5： ISTQB Advanced
高度な手動テストのトピック：
チュートリアル＃1： 循環的複雑度
チュートリアル＃2： 移行テスト
チュートリアル＃3： クラウドテスト
チュートリアル＃4： ETLテスト
チュートリアル＃5： ソフトウェアテストメトリクス
チュートリアル＃6： ウェブサービス
この手動テストシリーズの最初のチュートリアルを見る準備をしてください!!!
手動ソフトウェアテストの概要
手動テストは、開発されたコード（ソフトウェア、モジュール、API、機能など）の動作を予想される動作（要件）と比較するプロセスです。
そして、どのようにして期待される動作を知ることができますか？
要件を注意深く読んだり聞いたりして、完全に理解することで、それを知ることができます。要件を完全に理解することは非常に重要であることを忘れないでください。
コンピュータのオペレーティングシステムの名前
テストする対象のエンドユーザーとして自分自身を考えてください。その後、ソフトウェア要件ドキュメントまたはその中の単語に拘束されることはなくなります。次に、コア要件を理解し、システムの動作を、書かれていることや伝えられていることに対してだけでなく、自分自身の理解や書かれていないことや伝えられていないことに対してもチェックできます。
場合によっては、要件の欠落（不完全な要件）または暗黙の要件（個別に言及する必要はないが満たす必要があるもの）である可能性があり、これについてもテストする必要があります。
さらに、要件は必ずしも文書化されたものである必要はありません。ソフトウェアの機能について十分な知識を持っているか、一度に1ステップずつ推測してテストすることもできます。一般に、アドホックテストまたは探索的テストと呼びます。
詳細を見てみましょう：
まず、事実を理解しましょう– ソフトウェアアプリケーションと他の何か（たとえば車両）のテストを比較する場合でも、概念は同じです。アプローチ、ツール、および優先順位は異なる場合がありますが、主要な目的は同じままであり、単純です。つまり、実際の動作を期待される動作と比較します。
第二に– テストは、内面から来るべき態度や考え方のようなものです。スキルを学ぶことはできますが、デフォルトでいくつかの資質を持っている場合にのみ、テスターとして成功します。テストスキルを学ぶことができると言うとき、私はソフトウェアテストプロセスに関する集中的かつ正式な教育を意味します。
しかし、成功したテスターの資質は何ですか？以下のリンクでそれらについて読むことができます：
ここでそれを読んでください=> 非常に効果的なテスターの品質
このチュートリアルを続行する前に、上記の記事を読むことを強くお勧めします。これは、ソフトウェアテスターの役割で期待される特性と自分の特性を比較するのに役立ちます。
記事を読む時間がない人のために、概要は次のとおりです。
「あなたの好奇心、気配り、規律、論理的思考、仕事への情熱、そして物事を分析する能力は、破壊的で成功するテスターであるために非常に重要です。それは私のために働きました、そして私はそれがあなたのためにも働くと強く信じています。あなたがすでにこれらの資質を持っているなら、それは確かにあなたのためにも働くようになりました。」
のコア前提条件について説明しました ソフトウェアテスターになる。 ここで、手動テストが自動化テストの成長の有無にかかわらず、独立した存在であり、常に存在する理由を理解しましょう。
手動テストが必要な理由
テスターであることの最も良い点、それも手動テスターであることを知っていますか？
ここではスキルセットだけに頼ることはできないのは事実です。あなたはあなたの思考プロセスを持っている/開発しそして強化しなければなりません。これは、実際には数ドルで購入できないものです。あなた自身がそれに取り組む必要があります。
あなたはしなければならない 質問をする習慣を身につける そして、あなたがテストしているとき、あなたは彼らに毎分尋ねなければならないでしょう。ほとんどの場合、他の人よりも自分自身にこれらの質問をする必要があります。
前のセクションで私が推奨した記事（つまり、非常に効果的なテスターの品質）を読んだことを願っています。はいの場合、テストは思考プロセスと見なされ、テスターとしてどの程度成功するかは、人としての資質に完全に依存することがわかります。
この単純なフローを見てみましょう。
- あなたは何かをします（ アクションを実行する ）ある程度の意図を持ってそれを観察している間（予想と比較して）。今あなたの 観察 スキルと 規律 物事を実行することはここで絵になります。
- 出来上がり！何だって？あなたは何かに気づきました。あなたは完璧を与えていたのでそれに気づきました 詳細への注意 あなたの前に。あなたはそれを手放すことはありません 奇妙な 。これは、予期しない/奇妙なことが起こるというあなたの計画にはありませんでした。あなたはそれに気づき、さらに調査します。しかし今、あなたはそれをやっています。あなたはそれを手放すことができます。しかし、あなたはそれを手放すべきではありません。
- あなたは幸せです、あなたは原因、ステップ、そしてシナリオを見つけました。これを適切かつ建設的に開発チームやチーム内の他の利害関係者に伝えます。あなたはいくつかの欠陥追跡ツールを介してまたは口頭でそれを行うかもしれませんが、あなたはあなたが 建設的に伝える 。
- おっと！そのようにするとどうなりますか？入力として適切な整数を入力したが、先頭に空白が含まれている場合はどうなりますか？仮に？ … 仮に？ … 仮に？簡単に終わらない、簡単に終わらないはずです。あなたはするであろう 想像する 多くの状況とシナリオ、そして実際にあなたもそれらを実行したくなるでしょう。
以下の図は、テスターの寿命を表しています。
上記の4つの箇条書きをもう一度お読みください。私がそれを非常に短くしたが、それでも手動テスト担当者であることの最も豊かな部分を強調したことに気づきましたか？そして、いくつかの単語で大胆な強調表示に気づきましたか？これらは、手動テスト担当者が必要とする最も重要な品質です。
さて、あなたはこれらの行為を他のものに完全に置き換えることができると本当に思いますか？そして今日のホットトレンド–自動化に取って代わられることはありますか？
SDLCでは どのような開発方法でも、常に一定であるものはほとんどありません。テスターとして、要件を消費し、テストシナリオ/テストケースに変換します。次に、それらのテストケースを実行するか、直接自動化します（いくつかの会社がそれを行っていることを私は知っています）。
あなたがそれを自動化するとき、あなたの焦点は安定しています、それは書かれたステップを自動化することです。
正式な部分、つまり手動で記述されたテストケースの実行に戻りましょう。
ここでは、書かれたテストケースの実行に焦点を当てるだけでなく、その間に多くの探索的テストも実行します。覚えていますか？そして、あなたは想像するでしょう。そして、あなたは抵抗することができなくなります、あなたは確かにあなたが想像したことをするでしょう。
以下の画像は、テストケースの記述がどのように簡略化されているかを示しています。
フォームに記入し、最初のフィールドに記入しました。マウスが次のフィールドにフォーカスを移すのが面倒です。 「タブ」キーを押しました。次の最後のフィールドも入力しました。(送信)ボタンをクリックする必要があります。フォーカスはまだ最後のフィールドにあります。
おっと、誤って「Enter」キーを押してしまいました。何が起こったのか確認させてください。または、送信ボタンがあります。ダブルクリックします。満足していません。何度もクリックするのが速すぎます。
気づきましたか？意図されたものと意図されていないものの両方で、非常に多くの可能なユーザーアクションがあります。
テスト対象のアプリケーションを100％カバーするすべてのテストケースを作成することに成功するわけではありません。これは探索的な方法で行われる必要があります。
アプリケーションをテストしながら、新しいテストケースを追加します。これらは、以前はテストケースが作成されていなかった、発生したバグのテストケースになります。または、テスト中に何かが思考プロセスをトリガーし、テストケーススイートに追加して実行したいテストケースがさらにいくつか取得されました。
この後でも、ないという保証はありません 隠されたバグ 。バグのないソフトウェアは神話です。ゼロに近づけるようにターゲットを設定することしかできませんが、上記で見たプロセスの例と同様ですが、これに限定されない、人間の精神が同じものを継続的にターゲットにしなければ、それは起こり得ません。
少なくとも今日の時点では、人間の心のように考え、人間の目のように観察し、人間のように質問と回答を行い、意図した行動と意図しない行動を実行するソフトウェアはありません。そのようなことが起こったとしても、誰の心、思考、目がそれを模倣するのでしょうか？あなたのものですか、それとも私のものですか？私たち人間も同じ権利ではありません。私たちは皆違います。では？
自動化が行われている場合の手動テストの必要性：
自動化テストには、最近独自の栄光があり、今後数年間でさらに多くの栄光がありますが、手動のQAテスト（人間/探索的テストを読む）に取って代わることはできません。
あなたは前に聞いたことがあるに違いありません-‘ テストを自動化するのではなく、チェックを自動化します ’。この文は、手動のQAテストが自動化テストのどこにあるかについて多くを語っています。世界中の多くの有名人がこのトピックについて書いたり話したりしているので、これについてはあまり強調しません。
自動化は、次の理由でヒューマンテストに取って代わることはできません。
- それはあなたの目の前で（あなたがテストしている間）そしていくつかのケースでは舞台裏でも起こるすべてについての実行時の判断を要求します。
- それは明確で絶え間ない観察を要求します。
- それは要求します 質問。
- 調査が必要です。
- それは推論を要求します。
- テスト中に必要に応じて、計画外のアクションを要求します。
テストは、詳細を吸収し、処理し、アクションを実行し、人間の心や人間のように実行できるツール/マシンに置き換えることができます。これらはすべて、実行時およびすべての可能なコンテキストで実行できます。このツールもまた、すべての可能な人間のようでなければなりません。
つまり、人間によるテストに取って代わることはできません。数年後にはハリウッドのSF映画がそれに近いように見えるかもしれませんが、実際には、想像できるように、数百年はそれが来るのを見ることができません。無限の可能性を信じているので、永遠にそれを書き留めることはありません。
ちなみに、実際に数百年経っても、恐ろしい世界の絵が想像できます。トランスフォーマーの時代。 :)
= >>推奨読書– 最高の手動テストサービス会社
自動化は手動テストをどのように補完しますか？
前にも言いましたが、自動化はもう無視できないともう一度言います。継続的インテグレーション、継続的デリバリー、継続的デプロイが必須になりつつある世界では、継続的テストを怠ることはできません。私たちはそれを行う方法を見つけなければなりません。
ほとんどの場合、ますます多くの従業員を配置しても、このタスクの長期的な効果はありません。したがって、テスター（テストリード/アーキテクト/マネージャー）は、何を自動化し、何を手動で実行するかを慎重に決定する必要があります。
非常に正確なテスト/チェックを作成して、当初の期待を逸脱することなく自動化し、「継続的テスト」の一環として製品を回帰しながら使用できるようにすることが非常に重要になっています。
注意： 「継続的テスト」という用語の連続という単語は、同じ接頭辞を付けて上記で使用した他の用語と同様の条件付きおよび論理的な呼び出しの対象となります。この文脈での継続とは、昨日よりも頻繁に、より速くなることを意味します。意味はありますが、毎秒またはナノ秒を意味する場合があります。
ヒューマンテスターと自動チェック（正確な手順、期待される結果、およびテストの終了基準が文書化されたテスト）の完全な一致がなければ、継続的テストを達成することは非常に困難であり、これにより、継続的インテグレーション、継続的デリバリー、および継続的デプロイが実現しますより困難。
上記のテストの終了基準という用語を意図的に使用しました。私たちの自動化スーツは、もはや従来のものと同じにすることはできません。それらが失敗した場合、それらが速く失敗することを確認する必要があります。そして、それらを迅速に失敗させるために、終了基準も自動化する必要があります。
例：
たとえば、Facebookにログインできないブロッカーの欠陥があるとします。
その場合、ログイン機能は最初の自動チェックである必要があり、自動化スイートは、ステータスの投稿など、ログインが前提条件である次のチェックを実行しないでください。あなたはそれが必ず失敗することをよく知っています。したがって、失敗をより早くし、結果をより早く公開して、欠陥をより早く解決できるようにします。
次のことは、あなたが以前に聞いたことがあるはずのことです– すべてを自動化しようとすることはできませんし、そうすべきではありません。
自動化された場合にかなりのメリットが得られるテストケースを選択します ヒューマンテスターに提供され、投資収益率が高くなります。さらに言えば、すべての優先度1のテストケースを自動化して、可能であれば優先度2を自動化する必要があるという一般的なルールがあります。
自動化は実装が簡単ではなく、時間がかかるため、少なくとも優先度の高いケースが終了するまでは、優先度の低いケースの自動化を避けることをお勧めします。自動化するものを選択し、それに焦点を合わせると、継続的に使用および保守される場合のアプリケーションの品質が向上します。
結論
高品質の製品を提供するために手動/人間によるテストが必要な理由と方法、および自動化がそれを補完する方法を理解している必要があります。
QA手動テストの重要性を受け入れ、それが特別である理由を知ることは、優れた手動テスト担当者になるための最初のステップです。
今後の手動テストのチュートリアルでは、手動テストを実行するための一般的なアプローチ、自動化との共存方法、およびその他の多くの重要な側面について説明します。
このシリーズのチュートリアルのリスト全体を読むと、ソフトウェアテストに関する膨大な知識が得られると確信しています。
ホワイトボックステストとブラックボックステストの違い
ご連絡をお待ちしております。以下のコメントセクションであなたの考え/提案を自由に表現してください。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- アルファテストとベータテスト（完全ガイド）
- 機能テストと非機能テスト
- SoftwareTestingHelpの最高のQAソフトウェアテストサービス
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- ソフトウェアテストの種類：詳細を含むさまざまなテストの種類
- キャリアとしてのソフトウェアテストの選択