コードカバレッジとは?
testing

コードカバレッジとは?

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

テストケースの作成方法:テストケースの書き方とは?
testing

テストケースの作成方法:テストケースの書き方とは?

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

テストマトリクスとは
testing

テストマトリクスとは

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

スクラムでプロジェクトを管理する

スクラムでプロジェクトを管理する

アジャイルの最も一般的な方法であるスクラムは、複雑な作業/製品に最も速く効果的な方法でアプローチおよび開発するのに役立つ基本的なフレームワークです。 従来のウォーターフォールの開発の場合、事前に決めたスケジュールを完了するため、夜・土日の残業も沢山みられており、開発の前に、きちんと計画を立てたが、仕様の変更などで中々そのスケジュールに間に合うことが難しいのです。しかし、アジャイルではそのような課題がほとんど解決できます。もちろん、プロジェクトの要件によってメリット・デメリットがありますが、アジャイルは小規模のプロジェクトに比較的に向いています。 アジャイル手法に基づいて構築されたスクラムフレームワークについて上記の課題をどう解決するかは下記に解説します。 スクラムチームの役割について 基本的にスクラムチームは3つの役割に対してそれぞれの責任と権限を持っています。その3つの役割は開発チーム・プロダクトオーナー・スクラムマスターです。 プロダクトオーナー プロジェクトの一番責任が高い人物です。お客様、エンドユーザーの要求・課題をチーム(普通はスクラムマスターだけ)に説明する人です。システムを開発する上でのプロジェクトバックログを管理します。開発チームメンバーが機能や要件の説明・目的などを把握するために、プロダクトバックログの項目を優先順位で常に更新されることを確保する必要があります。 プロダクトオーナーは最終的にバックログ項目の優先順位付けと更新を担当しますが、スクラムマスターまたは開発チームは、見積もり(時間、コストなど)のコスト、リソース)、依存関係、技術的な作業項目に関する情報を共有することによって、このプロセスをサポートすることができます。 スクラムマスター スクラムは説明が簡単ですが、いつも正しく動くことが簡単でないから、スクラムマスターという役割があって、チームをいつもスクラムの軸をずれないようにサポート、

BrSEの有効なツールー業務分析(Business Analize)

BrSEの有効なツールー業務分析(Business Analize)

オフショア開発に不可欠な役割としてはブリッジSEです。技術力不足による品質の不安定さや言語・文化の違いによるコミュニケーションロスを防ぐために、ブリッジSEが活躍します。 BrSEの主な役割は下記のようにと広く知られていると思います。 依頼主となる日本企業の担当者とのコミュニケーション 作業進捗報告 納品物の検品・修正 具体的な仕事: 現地スタッフへの説明 設計書作成 開発の進捗管理 納品物の受け入れ確認 依頼先への報告作成・翻訳 しかし、上記の各仕事をうまくできるBrSEは多くないと思います。大きな理由としては依頼主から要求された要件を「よく」把握しないからだと考えられます。もちろん、コミュニケーション、IT知識、マネージャー、文化理解などのスキルも不可欠なものですが、 ただ、技術、言語、マネジメントばかりに目を向ける癖があって、自分が開発するシステムの本来となる目的を軽く見てしまい、オフショア開発チームと説明するときも、不足で結局、開発チームが目的を完全に知らない間にシステムを作ってしまうのです。 つまり、システムの背景・関連事物・将来の実用をしっかりと把握しないといけません。要はシステムの業務分析が必要となります。プロジェクトはどこからいつから始まるか、またはどんなプロダクト・どう完成するかをつかめるのがBrSEの一番大きなチャレンジだと思います。 あらゆる種類の質問に対応するために、ビジネスプロセス分析をするための重要な手法のいくつかを紹介いたします。 ステップ1:プロジェクトに関するすべての情報を収集する プロジェクトに関連するすべての詳細を収集するのは、BrSEの責任でプロジェクトに関係する人々(プロジェクトマネージャー、プロジェクトスポンサー、

テスト密度とバグ密度の指標について
testing

テスト密度とバグ密度の指標について

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

テストケースサンプル事例:良いテストケースを書くためのベストプラクティス
testing

テストケースサンプル事例:良いテストケースを書くためのベストプラクティス

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

テストケースとは? なぜテストケースが重要なのか
testing

テストケースとは? なぜテストケースが重要なのか

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

ユーザ 受入テスト(UAT)とは
testing

ユーザ 受入テスト(UAT)とは

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

システムテスト定義・種類・テスターのシステムテスト種類の選択基準
testing

システムテスト定義・種類・テスターのシステムテスト種類の選択基準

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