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

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

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

【QA】テスト観点の出し方

システム開発における評価・検証は、避けることのできないバグや不具合を市場に流通する前に可能な限り取り除くことのできる重要な工程です。またテスト観点が明確なテストケースは実施者ごとの評価精度のブレを防ぎ、不具合の発見率を高めることができます。しかしこの工程を最大限活かすには"なぜそのテストをするのか”、”そのテストで何を確認したいのか”という観点を正確かつ明確に定めていなければなりません。テスト観点の洗い出しが不十分なまま重大な不具合を見逃してしまうことで機会損失や信用を失うなど、多くのリスクを生んでしまう恐れがあります。

【ソフトウェアテスト】ユースケーステスト

ユースケース(use case)テストとは、システム開発要件や機能仕様などのテスト対象に対して利用者サイドから想定しうるテスト対象の使用状況や相互の作用をユースケースとしてシナリオを想定することで、対象の利用に際して問題がないかを主軸にしてテストを行う手法です。シナリオを想定してテストを行うため、シナリオテストと混同されやすいですが、シナリオテストと比較してテスト対象や目的やテストの粒度など違う部分があるので、ユースケーステストとシナリオテストはそれぞれ別の手法として、実施するテストケースに応じて使い分けが必要です。シナリオテストは主に特定の機能や操作の流れを一連のシナリオとしてテストするもので、対象となる仕様や要件のみならず、ストーリーとして関連が想定される動作や異常系処理などもテストスコープに含むため、ユーザーサイドの視点で対象に対して詳細なテストを実施しますが、ユースケーステストは、あくまで対象となる仕様や要件から想定されうるユーザーストーリーをテスト対象とする前提で、シナリオテストよりもテストスコープは狭くなると想定されます。また、記事内にて後述しますが、ユースケース図を用いていることもユースケーステストの特徴であり、シナリオを順序立てる記述形式はシナリオテストもユースケーステストも同様ですが、テストケースの整理や共有の方法によってテストケース自体をレビューできるため、静的テストのアプローチがしやすいテスト技法です。

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

【ソフトウェアテスト】不具合報告のインシデントレポートについて

開発プロジェクトで発生した問題はインシデントとして、管理・分析・対応が必要です。プロジェクト全体を通しての問題となるとかなり範囲は広く、人的トラブルやステークホルダー間での問題など、開発しているプロダクト以外の問題も含んでしまうので、本記事では主にプロダクトのテストに関して検出された動作の不具合(バグ)に焦点を絞って記載します。プロダクトのテストに際して検出した不具合は、報告・対応したあとは蓄積データとして、引き続きプロジェクトで参照・活用されます。実際の開発現場によっては、早期レビューでのやりとりに関するものや、開発とテスターが口頭で連携できるような状況で報告即時対応できる程度の不具合対応など、状況により必ずしも定められたドキュメントの形式で報告されるものとは限りませんが、可能な限り検出対応した不具合は履歴を残しておくことで、プロダクトの品質向上を目指すことができます。ほとんどの場合は不具合管理に別途外部のbug tracking system（BTS）を使用しています。BTSはインシデントレポート1件をチケットという1単位で扱います。チケットの形式や内容が必ずしも同一の形式に沿っているというものではありませんが、不具合の報告管理をするチケットの内容は、管理運用の観点から記載が必要となる項目はある程度決まっています。余談ですが、BTSは不具合報告のみならず、チケット駆動開発 (TiDD) を実施するプロジェクトでは開発作業自体の管理進行目的で使用される場合もあります。

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

Nuxt.jsについて調べてみた

今回は多くのフロントエンド開発で利用されているNuxt.jsについて調べてみました。

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

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

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

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

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

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

採用サイトのリニューアル

当社の採用サイトがリニューアルされました。今後も定期的に更にコンテンツを追加する予定です。

News・お知らせ

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

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

【ソフトウェアテスト】シナリオテスト

シナリオテストはユーザー視点で利用場面を想定し、操作フロー、入力値、発生する正常系挙動異常系挙動など、ユーザーが利用する一連の流れを想定したうえで発生しうるストーリーを元にテストを実施する手法です。ブラックボックステスト技法はさまざまあり、あくまで無数に存在しうるテストケースから粒度や対象を整理抽出してより広く浅いテストケースを目指すようなものがほとんどです。しかし、複数機能をもつシステムを実際に利用する際には、複数回の遷移を繰り返したりシステムが何重にも関連したりするので、1つの機能を対象としたテストや、2つ3つの機能間の関連をテストしただけでは、再現し得ないような組み合わせでの不具合が発生する懸念は常にあります。フリーチェックやモンキーチェックなどと呼ばれるものも、結局は「ユーザーなら再現しうる」可能性を想定して実行するものですが、それを数値や手順を明確にしてより詳細にテストし、かつ明示することでその内容をテストの履歴としたり、テストの要件自体もレビューなどで評価対象とできることがこのシナリオテスト手法の利点と考えられます。また、ユーザーのストーリーを元にテストするという点から、よりユーザーサイドでの視点から評価できるため、単純に欠陥を検出するのみならず、UI/UXの評価検討なども実施することができます。

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