【ソフトウェアテスト】ドメイン分析テスト

同値分割法/境界値分析については他の記事で記載しましたが、ドメイン分析テストも境界値を用いてテストします。このテスト方法は、関係性のある複数の変数について、入力データの有効範囲にフォーカスしてテストをする手法です。同値分割法/境界値分析では、一つの機能に関して境界がいくつか設定されていて、各境界の前後でそれぞれ動作が変わるような仕様に対してパーティションを分けてテストしていましたが、そのような数値による境界をもつ機能がいくつか関連して複数結果に分かれるような仕様のケースでは、ドメイン分析テスト技法が使用できます。ゲームのダメージ計算式で、与えた最終ダメージ数値に応じてクリティカル倍率をかけた数値を上乗せするといった場合に、元となるダメージ数値がいくつか、相手の防御数値がいくつか、数値いくつ以上でクリティカル倍率は何倍が適用されるか、各数値には有効・無効となる境界があり、かつ最終の数値ごとに複数のクリティカル倍率が用意されているといった仕様があったときに、ドメイン分析テストによって必要なテストケースを洗い出すことができます。

テスト(運用・保守・サポート)

Python基本文法

Python基本構文についてです。

【ソフトウェアテスト】クラシフィケーションツリー技法

クラシフィケーションツリー技法は主に、複数のテスト対象と各対象の値が複数関連する状況で、各対象を木構造で図示することで、テスト対象の機能や状態を階層的に分類し、その組み合わせや変数いくつ分を対象とするか等の組み合わせの強度について、整理検討するときに用いる技法です。ドメイン分析テスト技法の際には、複数の境界値による動作変化の関連性と、その組み合わせで想定される複数パターンの網羅を表形式で表現する方法を取りましたが、クラシフィケーションツリー技法では、1つの機能に関わる複数の要素、各要素に想定される複数パターン、各パターンで想定される変数のパターンと、想定される内容を木構造の図で上から下へ記載して整理する方法を取ります。ブラウザベースでWebサイトを作成して、ウィンドウの表示サイズをPCサイズのレイアウトとスマホサイズのレイアウトで2パターン適用するとして、PCサイズレイアウトが正常に適用されているかを確認するときのテストスコープについて、ブラウザは[GoogleChrome][MicrosoftEdge][Firefox][Safari]をテスト対象と仮定し、各ブラウザのサイズや文字サイズ設定を変更しても問題ないか、さらに設定するウィンドウサイズは想定の最小値・最大値・全画面のパターンで、文字サイズは通常から何％拡大を対象とするかなどを考慮し、どの組み合わせでのテストを必要とするかを検討するといったような場合には、当該技法を用いることで視覚的に情報を整理しやすくなります。

テスト(運用・保守・サポート)

Python基本文法2

Python基本文法についてです。

テスト技法の種類をまとめる

業務でテスト設計を行うことになったのでテスト技法について学んでいきたいと思います。

【ソフトウェアテスト】直交表/ペアワイズ法　②

直交表そのものについては直交表/ペアワイズ法　①で記載しています。この記事では主にペアワイズ法についてまとめます。ペアワイズ法は組み合わせテスト技法の一つであり、直交表で考慮した各因子に想定されている水準が均等に分布するという条件を緩和し、各水準の組み合わせが少なくとも1回以上出現するようなペアを選択することで、直交法そのものよりもテストの粒度を粗くしてテストケース数を抑える手法です。

テスト(運用・保守・サポート)

【ソフトウェアテスト】欠陥分析手法について

「【ソフトウェアテスト】不具合報告のインシデントレポートについて」記事で記載したとおり、インシデントはチケット作成して報告されたのち、内容を分析して対応をし、作成から完了に至るまで管理します。そうして蓄積されたインシデントレポートは、報告対応されたそのレポート自体が、以降で類似の現象を検出した際の資料として用いられる面もありますが、内容を分析することで、今後の開発品質向上を目指すための判断材料として活用することができます。いずれのインシデントレポートも、何かしら問題があったから作成されているものであり、問題点は解決した時点で完了とはせずに、内容を振り返って同じ轍を踏まないように以降の活動を随時改善していくことが肝要です。近年のアジャイル化が進んでいるプロジェクトなどの場合は、直近の開発内容に対するインシデントレポート単体を都度分析するような時間も設けられずに次々進んでいくことがありますが、プロジェクト全体としてインシデントレポートを統合管理し、アジャイル開発の各プロジェクト進行とは別途で機会を設けて、振り返りと共に不具合分析を行うことは、高品質な開発を目指す上で必要な活動です。ソフトウェア開発現場の現状として、プロジェクト形式もインシデントレポート形式もさまざまある状況なので、欠陥分析の手法もこれが絶対という唯一のものではなく、状況や期間などに合わせて必要な手法でアプローチをすべきです。統計的内容に基づく分析、インシデントごとの要因に基づく分析、その両面からの分析など、どのような面からアプローチするかによって用いる手法もさまざまあります。

テスト(運用・保守・サポート)

【ソフトウェアテスト】レビューについて

ソフトウェアテスト領域には、動作させることを前提とした対象をテストする動的テストと、動作させることを前提としていない対象をテストする静的テストがあります。単体テストや結合テストなど、作成したものを動作させてテストをするのが動的テストですが、静的テストは動作させる対象がなくてもテストが実施できます。静的テスト活動の種類としてレビューがありますが、開発活動の中で作成された製品やシステム自体以外のものは、レビュー対象としてテストすることが可能です。

テスト(運用・保守・サポート)

【ソフトウェアテスト】エラー推測テスト

エラー推測テストは経験ベーステストの一種です。最も単純な表現をするならば、「どうすればエラーが発生するか」を想像して試行し、エラーを再現させることを目的としたテストの手法です。

テスト(運用・保守・サポート)

【QA】テストケースの書き方

システム開発における評価・検証では評価する為の状態や手順、そして確認するべき期待結果等の情報をまとめたテストケースを事前に作成することになります。しかしテストケースの書き方が不十分であると他の実施者がそれを見た時はもちろん、テストケースを作成した本人でもいざ評価をする際にテストケースに書かれた情報を正しく読み取ることが出来ない可能性があります。良質なテストケースは"誰が実施しても同じ期待値を得られる"ということです。本稿ではそのために意識するべきことをまとめていきます。

テスト自動化

テスト自動化とは、人の手によって行われるソフトウェアテストの全体あるいは一部を自動化することを意味します。そもそもソフトウェアテストは、不具合を見つけることが目的です。そのため、テストを繰り返し行うことも増えています。テスト自動化によって、テストにかかる人的負担を減らし、将来的なコストの削減が期待できます。テストといっても、その中にはさまざまなプロセスが含まれます。ソフトウェアテスト技術者資格認定組織である「ISTQB（国際ソフトウェアテスト資格認定委員会）／JSTQB（日本ソフトウェアテスト技術者資格認定組織）」の定義によると、テストプロセスは以下の5つの要素で構成されています。テストプロセス　・テスト計画作業とコントロール　・テストの分析と設計　・テストの実装と実行　・終了基準の評価とレポート　・終了作業

テスト(運用・保守・サポート)

【ソフトウェアテスト】QC7つ道具と新QC7つ道具　②

QC7つ道具は、主に生産現場における各種数値を元に品質やリスクなどを分析して、品質管理を進める手法でしたが、品質管理に関わる問題は定量的分析のみでは対応しきれないようなものもあります。「【ソフトウェアテスト】欠陥分析手法について」記事でも触れているとおり、統計的分析は定量的解析手法で対応可能ですが、問題の要因に対してアプローチしようと考えた場合に、あらゆる要因が数値化できるのであれば定量的分析手法を用いれば解決できますが、数値化が困難であったり、集計して数値化して分析すると考えた場合に非常に手間がかかるような要－因に対しては、定性的な分析手法が必要になります。また、生産活動そのもののみではなく、プロジェクト全体の管理もQC活動、品質管理活動で対応すべき事象です。プロジェクト進行における問題点の可視化や共有に際して、数値データではない文字データや言語データでの集計管理をして、そうした定性的データを共通化された手法を用いて分析することにより、どのような生産現場でどのようなスキルの人が品質管理対応をする想定になったとしても、ある程度容易に対応できるように作成された手法のなかでも代表的な7つの手法が、新QC7つ道具(N7)として分類されています。英語ではNew Quality Control – 7 Tools等と呼ばれます。

テスト(運用・保守・サポート)