Table of contents 1. What is Software Testing Methodology? 2. Functional Testing 3. Non-Functional Testing 4. Difference Between Functional Testing and Non-Functional Testing 5. Conclusion 1. What is Software Testing Methodology?Software Testing Methodology is different strategies, types of testing, and approaches used to certify that the product meets the

はじめにあなたはバグ（ソフトウェアの不具合）、特に基本的なバグを見逃したことはありますか？　もしそうであれば、その時、「どうしてこのようなバグを見逃したのだろうか」と自分に聞いてみたことはあるでしょうか？ ソフトウェアテストの実行者であれば、誰でも下記のようなケースを体験したことがあるはずです。 I.　テストをしたはずのテストケースにおいてバグが発生する II.    基本的な（すごく簡単な）テストケースを見逃す III.  要件を把握できない ソフトウェア開発ライフサイクルでは、テストは最後の工程となるため、見逃されてしまったすべてのバグはテスト実行者の責任であるという考えが一般的です。このため、バグを見逃すことはテスト実行者として最悪のことだといっても過言ではありません。バグの見逃しというのは実行者の自身の不注意などによるミスで起きるほか、客観的な原因でも発生します。 そこで、この記事ではバグを見逃すことを避けるために注意したいことをご紹介したいと思います。 主観的な原因ソフトウェアテストはロジックや根拠に基づいていることが望ましいとされています。ただ。残念ながら人間は必ずしも100％ロジックで動くわけではありません。ソフトウェアテストの世界でも、しばしば以下に掲げるようなことが原因となり、ミスが発生します。 １．パラレルトレンド（Parallel trend）パラレルトレンドとは、同じような条件の場合には同じ結果が出ると信じることです。これは一番よく起こりがちなミスです。例えば、あるテストケースをきちんと実行した後（結果：OK）、別のシナリオを実行する際、先ほどと同じテストケースを見ただけですぐに結果も同じであると判定してしまう傾向が該当します。こうした思いこみは潜在的なバグを見逃してしまう原因となります。 パラレルトレンドを避ける方法としては以下の取り組みが効果的です。 I.　同値分割法と境界値分析を用い、テストケースを作成すること

はじめにソフトウェアテストにおけるテスター（実行者）としてバグを起票したり、問い合わせを行ったりする際、エビデンスを取得することは最も大事な作業の一つです。一番手っ取り早いのはWindowsに標準搭載されているSnipping Tool（スニッピングツール、ホットキー：Windowsキー+Shift+S）を活用し、画面に表示されている部分、もしくは全体画面をスクリーンショットとして切り取った上で、Microsoft Paint（マイクロソフトペイント）かMicrosoft Paint 3D（マイクロソフトペイント3D）で編集するという方法があります。編集時に該当箇所にマークや文字を入れることでわかりやすいエビデンスができます。 しかし、一部のウェブサイト、特にECサイトの画面は縦に長い仕様のものが少なくないため、Snipping Toolでは画面全体のスクリーンショットを一発で撮りづらいという問題があります。そんな時におすすめするのがAwesome Screenshot（オーサムスクリーンショット）です。 Awesome ScreenshotとはAwesome ScreenshotはGoogle Chrome（グーグルクローム』にサポートされている拡張機能です。10年間以上にわたり安定したサービスを提供している実績とグローバルで300万人以上のユーザー数を抱えており、キャプチャーソフトとして一番信頼できるツールのひとつと言っても過言ではありません。 インストール方法まずGoogleでAwesome screenshotと入力し、キーワード検索をかけるとChrome ウェブストア経由Chromeの拡張機能として簡単に追加できます。もし見つからない場合は以下のURLから直接追加してみてください。 URL：https://chrome.google.

はじめに今回のテーマである「なぜプロジェクトにテスト計画が必要なのか」という質問に答える前に、まずテスト計画とは何であるかについて考えてみましょう。 テスト計画とはテスト計画とは、プロジェクトにおけるシステム要求仕様を対象としたテスト概要ドキュメントです。テスト範囲、テスト戦略、テストプロセス、リソースなどの必要な情報が含まれています。会社の構成やプロジェクトによって、テスト計画も異なっていますが、テスト計画の最終目的は一緒で、システムまたは製品が仕様および他の要件を満たしているかどうかを確認することです。 それでは、次にテスト計画がプロジェクトでどのように役立つのかについてみていきましょう。 テスト計画はシステムが正しく実行され、使用できる状態になることを確認するために作成されます。さらに、テスト計画を作成することにより、規定された要件および仕様に対するシステムの適合性に対する客観的な評価も行うことができます。 テスト計画に必要な項目とはでは上記の要件を満たすためにテスト計画にはどのような内容やコンテンツを含めるのがよいのでしょうか。 プロジェクトの品質、さらにテストの進捗を確保するために、テスト計画には、次のようなコンテンツを含めることが重要です。 ・テスト範囲：テスト計画に適用される単体テスト、結合テスト、システムテストなどの各テスト段階を記述します。各テスト段階に応じてどのテスト種類（機能テスト、パフォーマンスなど）が適用されているかどうかを明確します。 ・コンストレイント：テストに関するコンストレイントは、判断可能な範囲で全てリストアップします。例えば：テスト環境の誤差、リソース、スケジュール、ツールなどの不足があれば、記述します。 ・リスクリスト：プロジェクトの品質に影響を与える可能性があるリスクをリスト化します。リスクには予防できるリスクと災害やパンデミックなどの不測の事態によって引き起こされるリスクがありますが、前者に対してはしっかりと対応策を洗い出しておくことが有効です。後者についても万一に備えて事前に何ができるかを検討しておくとよいでしょう。 一版的なリスクとしては、テスト環境、

Before the software/application is released to the users, it needs to be tested. In testing there are many techniques, methods, aspects to ensure that the software/application works as it was originally created. One of the indispensable steps when performing testing is validation. Validation is the process of evaluating

はじめにソフトウェアテストは、開発されたソフトウェアアプリケーションが要件を満たしているかどうかを確認するために実行される重要なフェーズの1つです。 そのフェーズがうまく行われるように、さまざまな確認メトリック/テストパラメータが生まれました。 そして、それらのメトリックの1つがコードカバレッジです。そこで今回はコードカバレッジついて解説します。 「コードカバレッジとは何か？」、「なぜ考慮する必要があるか？」 などの疑問が、すぐに解決しますよ。 1. コードカバレッジとはコードカバレッジ（「網羅率」とも表現される）とは、テスト手順でソースのコードがどれだけ網羅的に正常に検証されているかを判断するソフトウェアテストメトリックであり、ソフトウェアがどの程度包括的に検証されているかを分析する助けとなります。 コードカバレッジは、ホワイトボックステストにおける形式の1つと見なされます。 コードカバレッジの価値とは、そのレポートの中にあります。 まず、レポートから全体的なパーセンテージが取得されます。 例えば、ソースコードが100行あるとしましょう。この場合、ツールで69％のコードカバレッジが出力されたら、コードの31行がテスト対象外になっているということです。これのおかげで、改善できる箇所がまだあるということが理解できます。 また、コードカバレッジは全体的なパーセンテージの算出だけに役立つものではありません。現在のコードカバレッジツールでは、モジュール、ファイル、クラスやメソッドごとの詳細ビューも表示されます。 これにより最初に低いコードカバレッジがある領域を特定できます 2. なぜコードカバレッジが必要なのか？ a) コードカバレッジの背後にある意味テストを作成するたびに次のような質問を思いつきますよね。 テストスイート上にテストケースがもう十分に足りているか？ その答えはコードカバレッジです。 コードカバレッジ値が高いと、バグが潜在している可能性が低くなります。システムによって適当な最小パーセンテージを設定することも重要です。しかし、

This article is hopefully useful for those who are looking for a method to perform all-pair matching testing, in order to reduce the number of test cases, save time and effort. Many people believe that testing software as much as possible, believe that it is important to include all possible

この記事では、完全なテストケースを作成する方法について具体的な手順を説明します。 テストケースの詳細については以下の過去記事で紹介していますので、下記のリンクをご覧ください。 テストケースとは？ なぜテストケースが重要なのか テストケースの作成準備テストケースを作成する前に、顧客から提供された仕様書を注意深く読んで分析する必要があります。 何か分からないことがある場合は、チームメンバーまたは顧客と話し合って、最も正確なテストケースを作成できるようにする必要があります。 テスト ケース 作成まず、テストケースを作成するために必要なツールを選択する必要があります。 テストケースを手動で作成するツールとして弊社SHIFT ASIAではExcelをよく使用しており、個人的にも強くお勧めします。 また、Excel以外にもインターネット上にさまざまな無料ツールが公開されているので、必要に応じてダウンロードし、使用することもできます。 次にテストケースを完了するための基本的な手順を以下にご紹介します。 Step1：テストの目的を決定する顧客の要件仕様を明確に理解する必要があります。 ソフトウェアシステムの機能のテストケースを書き始めるとき、最初にすべきことは、システムの要件を理解して定義することです。 例：新規会員登録機能には、登録の成功と失敗の確認が必要です。 Step2：テストパフォーマンスを決定する （ソフトウェアシステムの理解に基づく）優れたテストケースを作成するには、機能要件を十分に理解している必要があります。また、 操作を含めソフトウェアがどのように使用されているかを理解した上で、さまざまな機能を整理していきます。 例：正常な登録メールを作成するには、次の基準を満たす必要があります。 →新規登録メールの作成が完了できること →新しく作成したメールで正常にログインできること →データベース（DB）に登録されたメールが保存されていること Step3：非機能（non-function）

Functional testing is one of the 4 main types of Integration Test in software testing. So what is functional testing and what types are functional testing? Let’s find out together! 1. What is functional testing? Functional testing is testing for the functionality of a software or an application. It

What are test cases? How can I write good and effective test cases? Let’s find out the answer about what a test case is and how to write an effective test case. 1. What are test cases? Test cases (Test scenarios) are also abbreviated to TCs, are testing possible

はじめにソフトウェアテスト工程ではテスト結果を抜け漏れなくチェックすることが欠かせません。今回はテストケース手法として、テストマトリクスを活用する方法について解説します。 1.  テストマトリクスとはマトリクスとは、テストの全体像を表示し、テスト結果をキャプチャするためのフローグラフのノード数のサイズの正方形のテーブルです。 マトリクス上の各行と列はノードの名に対応しており、各セルは行ノードと連携している列ノードに対応したケースの名前です。 2. テストマトリクスが必要な理由テストマトリクスは、主に下記の目的に使用できます。 ・一連のテストを記録するには2つの基準の交点に基づいており、記入すると希望回数の場合が実施されたことを証明するものとして使用されます。 ・入力データに対して実行されたテストの数をすばやく示します。 ・欠陥が発生する特定の状況を特定するのに役立ちます。 ・マトリックスが入力データで満たされると、テストケースが除外されていないことを確認するためのチェックリストとして機能します。 3. ソフトウェアテストにおけるテストマトリクスの利点と欠陥 利点：・シンプル、簡潔。 ・抜け漏れを避け、チェックが必要なすべてのケースをカバーできます。 ・入力データに変更があった場合、テストケースを簡単に変更できます。 ・環境で多くのエラーが発生する領域にテストを簡単に集中させることができます。 ・複数の入力条件の組み合わせがある場合、複数のケースを簡単にテストできます。 欠陥：・ケースが多すぎると混乱します。 ・出力の表現の難しさが存在します。 ・プロジェクトをよく知らないと混乱を招きます。 ・観点が多いと混乱を招きます。 4. マトリックスの作成方法 テストマトリクスを作成するには、次のことを行う必要があります。 ・テストするオブジェクトを行に配置します。 ・列にテストケースを表示します。 ・行と列を組み合わせて、テストするケースに優先順位（重み）を付けます。 なお、テスト時に使用されるマトリックスファイル構造には、関数リストと視点の組み合わせがあります 機能リストの入力データは縦に並べられ、視点は横に並べられます。

はじめにテスト密度とバグ密度は、下流工程で定量的な品質指標として使用され、案件品質の分析評価に欠かせないものです。これらの指標の下限値～上限値と実績テスト密度と実績バグ密度を組み合わせることで、どの機能に品質面の懸念があるかを確認することが可能です。 これにより該当する機能のテスト項目の網羅性をレビューしたり、バグ内容を深く検証したり、現象発生区分/原因区分/原因工程/バグ重要度などの品質についてより詳しく分析したりすることができます。そこで今回はテスト密度とバグ密度についてご紹介します。 目次 １．テスト密度とは ２．バグ密度とは ３．どのようにバグ密度を分析するか １．テスト密度とはテスト密度とは、案件の規模単位（SLOC・FP）でテスト項目の件数を示す指標です。テスト密度はテスト件数を規模単位で割るという方法で算出します。 （SLOC：ソースコードの行数、FP：ファンクションポイント） テスト密度の指標設定は、下流工程のスケジュールなどの作成の時に社内の品質指標と案件の特性などを組み合わせ、対応範囲の各テスト工程の指標の下限値/標準値/上限値を設定します。 テスト密度の分析・評価は、以下のように行います。 各テスト工程におけるテスト設計の段階で、設定されたテスト密度の指標を使用し、実際テスト設計の件数がその指標を達成するかどうかを確認します。ただ、実績テスト設計の件数が多ければ多いほど、テストの網羅性が高いという意味ではないため、テスト設計の成果物の品質を保証するためには、テスト密度の指標評価だけではなく、各機能のテスト項目の網羅性が高いかを徹底的にレビューすることが重要です。 各テスト工程のテスト実行段階においては、普段、テスト工程の途中での判定やテスト工程修了時の判定で、指標と実際バグ密度、[NN1] テスト項目の消化件数の差異を分析評価します。

はじめにテストケースのサンプルは、組織によって異なる場合があります。 しかし、テストケースを作成するために標準のサンプルを使用することは、プロジェクトのテストプロセスを設定する上で最初の一歩と言えます。 また、ビジネスチームがテストケースを確認するプロセスがある場合は、両方の当事者が合意したサンプルでテストケースをフォーマットする必要があります。 このチュートリアルでは、例を使用して手動テストでテストケースを作成する方法を学習します。 マニュアルテストでテストケースを作成する方法まずシナリオのテストケースを作成しましょう。ここでは「ログイン機能を確認する」ことを例に説明します。 手順①: シナリオを説明する簡単なテストケースは次のようになります。 手順②: 実行するためのテストデータが必要になります。 手順③: 環境で特定の一連のアクションを実行する必要があります。 この場合、以下のように手順を文書化します。 ●　テスト手順は上記のように単純ではないため、ドキュメントが必要です。 ●　手順を文書化することにより他の利害関係者がレビューしやすくなります。 手順④: ソフトウェアテストのテストケースの目標は、期待される結果をチェックすることです。 この場合、以下のように文書化する必要があります。 良いテストケースを書くためのベストプラクティス最後になりますが、良いテストケースを書くために必要なポイントを以下にまとめてみましたので、ご興味のある方は是非参考にしてください。 1. テストケースはシンプルで透過的である必要がある できるだけ単純なテストケースを作成します。テストケースの作成者がそれらを実行しない可能性があるため、それらは明確かつ簡潔でなければなりません。 2. エンドユーザーを念頭に置いてテストケースを作成する ソフトウェアプロジェクトの最終的な目標は、顧客の要件を満たし、使いやすく操作しやすいテストケースを作成することです。このため、テスターはエンドユーザーの視点を念頭に置いてテストケースを作成する必要があります。 3. テストケースの繰り返しを避ける テストケースの繰り返しは避けましょう。他のテストケースを実行するためにテストケースが必要な場合は、前提条件列のテストケースIDでテストケースを呼び出します。

はじめにテストケースの作成はソフトウェア開発において不可欠な活動であり、ソフトウェアテストの最も重要な部分の1つと見なされています。この記事ではテストケースについて、そもそもどういったものであるのか、なぜ必要なのか、どのような内容が記載されているかを解説したいと思います。 テストケースとは何であるかを知りたい場合は参考にしてください。 テストケースとはテストケースとは、ソフトウェアやシステムが期待通りに動作するかを確かめるため、提供された手順や利用するデータ、条件、実行パターン、期待される結果などを念頭に置いて文書化したものです。テストケースは、テストチーム、開発チーム、および管理者によって使用され、アプリケーションのドキュメントがない場合は、テストケースをベースラインドキュメントとして使用することが可能です。 誰がテストケースを作成することになっているかテストケースは通常、品質保証（QA）チームまたはテストチームのメンバーによって作成され、各システムテストの段階的な手順として使用することができます。 開発チームがシステム機能または一連の機能を終了すると、テストが開始されます。 これは、テストケースのシーケンスまたはコレクションは、テストスイートと呼ばれます。 テストケースにはどのような側面が含まれているかテストケースは、以下にあげる項目で構成されます。 1) 対象： ここでは、テスターはその特定のテストケースで実施する対象（特定の機能・UIなど）を言及します。 2）手順： ここでは、テスターは目的を達成するために従う必要のあるステップに言及します。 3）期待値： ここでは、テスターは提供された要件に従って期待される出力について言及します。 4）入力データ： これはテストを実行する際に利用するデータを指します。 5）

はじめにソフトウェア製品の価値は顧客要件と利用者のニーズを満たしているかどうかによって決まります。そのため、現在のソフトウェア検証モデルにおいては単体テスト（ＵＴ）、統合テスト（IT）、システムテスト（ST）の各種テストを実施した後、ユーザ受入テスト（UAT）を行うことが必要です。今回は、ユーザ受入テストについて一緒に見ていきましょう。 ソフトウェア検証の工程ユーザ受入テストの概要１．ユーザ 受入 テストとはユーザ受入テストとは、ソフトウェア製品が顧客要件と期待に沿って動作するか、ユーザのニーズを満たしているかを確認するために顧客/エンドユーザーによって実施されるテストの一種です。そのテストはソフトウェア製品が正式に運用または市場にリリースされる前の最終的な階段で実施されています。 ソフトウェア製品の作成工程２．実施対象前述のとおりユーザ受入テストを実施する主体は以下になります。 ●エンドユーザー ●顧客 ３．なぜユーザ受入テストが必要なのか次にユーザ受入テストのメリットを見ていきましょう。ユーザ受入テストの代表的なメリットは以下の通りです。 ●　全ての機能が正常に動作するかどうかを確認することで、システムに残存している不具合を発見することが可能 ●　プロジェクト実行中に加えられた変更・追加の部分が全て開発者に伝達されているかを確認することが可能 ●　ユーザ受入テストの手法にはアルファテストとベータテスト（Alpha & Beta Testing）の2種類が含まれているため本番環境でテストを実施しやすくなり、エンドユーザーにもたらす影響を確認することが可能 ４．ユーザ受入テスト実施の手順以下がユーザ受入テストの基本的なステップです。 ユーザー受入テストの基本ステップ●　ソフトウェア製品を作成するためのビジネス要件を分析します ●　ユーザ受入テストのテスト実施計画を立てます ●　テストシナリオを作成します ●　受入テストを実施するためのテストケースを作成します ●　実際のデータに最も近いテストデータを用意しておきます ●　ユーザ受入テストを実施します ●　テスト実施後の結果を記録します ●　製品の状態・機能を全て確認します

Software is an significant invention that help our life easier and more comfortable. We use software in every field, at any time and for many purposes: smart phone, smart home, automated manufacturing machines, medical devices, etc... There are several stages to the software development lifecycle to ensure the software suitable

はじめに今回は「システムテスト（ST：System Testing） とは何でしょうか」、「システムテストにはどんな分野がありますか」、「システムテストにはどんな手法がありますか」、「テスターになるにはどんな準備が必要ですか」といった質問にそれぞれ回答していきたいと思います。では、一緒に見ていきましょう。 システムテストとは 定義システムテスト（ST: System Testing) は、「総合テスト」又は「システム試験」とも呼ばれています。システムテストとは、顧客要求と期待に沿って統合後のソフトウェア製品の機能をすべて動作するかどうかを確認する技法です。 現在のソフトウェア検証工程によると、システムテストは単体テストと結合テストを実施した後に行うことになっています。 システムテストの主な分野システムテストの対象となる分野は一般的には以下のとおりです。 ●パフォーマンス：エラーが発生せずにシステムがユーザー要求に従って動作することを確認します。 ●セキュリティー：コンピュータのデータ、アプリケーション、ネットワーク、デバイスへの不正アクセスなどのセキュリティー違反の対策を行います。 ●回復性：もしシステムがクラッシュした場合、期待どおり速やかにシステムが回復できるかどうかを確認します。 ●インタフェース：システムテストの工程にもソフトウェア製品のインタフェースが検証されます。インタフェースであろうと機能であろうと顧客要求通りソフトウェア製品の動作を確認します。 ●可用性：システムが継続して稼働し、安定して利用できることを確認します。 ●構成可能性：開発環境から本番環境に移動する際、故障が発生していないようにソフトウェア製品をインストールできるかを確認します。 ●持続可能性（サステナビリティ）：大容量と高負荷を処理する際にシステムが問題なく動作することを確認します。 ●ドキュメント：

To ensure that the software product is error-free before it is released, it is necessary for the product to go through a testing process. The necessary tests for such software are all encapsulated in the name of Integration test. However, do you understand what Integration testing is? 1. What is

はじめにソフトウェアの開発では、完璧なプログラム・アプリケーションを完成させるために欠かせない工程が数多く存在します。そのうちの不可欠な工程のひとつとして、システムテストがあります。システムテストというのは、プログラマーまたは開発者にとってよく知られている用語ですが、IT業界とは関係ない多くの人にとってはあまり馴染みがないものです。そこで今回は、システムテストについて一緒にみていきましょう。 システムテストとは 定義システムテスト（ST: System Testing) は、「総合テスト」または「システム試験」とも呼ばれており、全ての機能が統合した状態で、ソフトウェアまたはシステム全体の全てのコンポーネントと機能が要求と仕様書に沿って動作するかどうかを確認する工程です。そして、さまざまなハードウェアとソフトウェアに統合した場合にも仕様書どおりに安定した動作を確保することが求められます。 アプローチ方法現在のソフトウェア開発モデルでは、高品質のソフトウェアを作成するために通常、単体テストと結合テストが完了した後にシステムテストを実施します。また、テストのアプローチ方法はブラックボックステストの技法に基づいて行われることが一般的です。すなわち、コーディング、プログラミングなどのシステムの内部動作に関する知識を必要とせずに、ソフトウェアの外部性能のみを確認する手法で実施されます。 システムテストのメリットテクノロジー製品の開発プロセスにおいてはソフトウェア検証の工程が非常に重要です。「なぜシステムテストが必要なのか」という質問に答えるために、以下にシステムテストのメリットを簡単にまとめましたので、ご覧ください。 ●国際標準（ISO/IEC）を満たした製品・アプリケーションの品質確保が可能 ●顧客要求または仕様書の記載に沿ってソフトウェア製品の性能・機能の動作を確保することが可能 ●ソフトウェア製品のシステム全体の検証を実施することで本番環境で発生し得るエラーと不具合を最小限に抑えることが可能 ●顧客から製品・アプリケーションに対する信頼と満足を獲得することが可能 ●製品に発生しているエラーと不具合を何度も繰り返して検証する必要がなくなり、作業効率の向上が可能

ソフトウェアやシステムは人間が開発する以上、不具合などが発生することはどうしても避けられません。こうした不具合を防ぐためにはソフトウェア製品の品質と適切な機能を保証することが欠かせませんが、その上で主要な役割を果たすのがソフトウェアテストです。ソフトウェアテストにはいくつかの手法がありますが、今回は「ホワイトボックステスト」というテスト技法について、詳しくご説明します。 1. ホワイトボックステストとはホワイトボックステストとは、どのコードの行がエラーを引き起こしているかをテストすることでプログラムのソースコードと内部構造を評価するテスト技法です。つまり、システムの内部構造がクリア（ホワイト）な状態を前提としたテストということです。 この技法はオープンボックステスト、クリアボックステスト、コードベーステスト、単純なボックステスト、ガラスボックステストとも呼ばれ、テスト対象は機能、機能モジュールなどのソフトウェアコンポーネントです。ホワイトボックステストは、ソフトウェア開発の初期でエラーを検出する上では最も効果的な手法です。 2. ホワイトボックステストのメリットとデメリット仮にGUI（Graphical User Interface、グラフィカル・ユーザ・インターフェース）が使用できなくてもテスト自体は早めに開始することが可能です。 開発者は、単体テストの作成中にホワイトボックステストを使用しますが、Junit (Java フレームワーク)、 PHPUnit (PHPフレームワーク)、NUnit (.Net フレームワーク) などの単体テスト補助ツールを利用することで品質保証における客観性を保証することができます。ただし、ホワイトボックステストを実行するテスターはコードを詳しく理解できる知識を持っている必要があります。また、コード構造によりテストケースの再利用はほとんど不可能です。 3.

ソフトウェアの品質を高める上で欠かせないテスト工程では、いくつかの主要なテスト技法が存在します。今回はその中のひとつであるブラックボックステストについてご紹介します。 ブラックボックステストとはブラックボックステストとは、システムの内部構造を考慮せずプログラムが仕様通り設計されるかを検証するテスト方法です。システムの内部構造を直接確認することはできないシステムをブラックボックス（中身が見えない箱）に見立ててテストを実行するため、このように呼ばれています。ブラックボックステストはシステムの内部構造を理解していない場合でも、仕様書があればテストを実施できるというメリットがあり、主に機能テストとシステムテストで行われるほか、機能以外のユーザビリティなどのテスト（非機能テスト）でも実施されます。 ブラックボックステストのテスト技法としては主に以下の5種類があります。 1. 同値分割法 同値分割法とは入力条件を類似と見なすことができるグループ（同値クラス）に分割し、テストを実行する技法です。同値クラス分は、出力、内部変数、時間に依存する値（例えば、イベ ントの前後）のほか、インターフェースパラメータにも存在し、テスト実行においては各クラスから代表的な値を使って分析します。同値分割法は単体テスト、統合テスト、システムテストなどのすべてのレベルのテストに適用できます。 2. 境界値分析（限界値分析） 境界値分析とは、仕様条件の境界となる値（境界値）とその隣の値に対してテストする技法のことです。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端に当たる値です。具体的には「未満」や「以下」などが該当し、こういった境界部分は間違いを引き起こしやすく、

Okay, this is my first blog ever. Thank you for entering this link. Now come to the title, what's Postman? Postman is an API client, an app, that's mainly used to create, share, test and document APIs. With Postman, you can create/save HTTP/s requests and read their responses.

In this article I'll write about the difference between manual testing and automation testing. Manual TestingManual Testing is a type of software testing in which test cases are executed manually by a tester without using any automated tools. The purpose of Manual Testing is to identify the bugs, issues, and

I've been using Rspec to configure my test automation source code and today I want to introduce Rspec testing framework to all of you. RSpec is the most popular Ruby on Rails testing framework according to Ruby on Rails community. It is also perfectly capable to test any Ruby-written code.

Load testing is a type of performance testing that simulates a real-world load on any software, application, or website.[1] So basically, if your application needs to handle a huge amount of user/request, load testing is recommended. During the load testing phase, we could detect throttle defect in the