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

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

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

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

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

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

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

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

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

テスト工程について

初心に帰ってテスト工程について復習していきたいと思います。

テスト技法と種類

テスト技法とは、ソフトウェアテストのテストケースを作成するための技法です。同値分割法、境界値分析、デシジョンテーブルテストなど、さまざまなテスト技法が存在します。テスト技法を利用することで、テストケースの抜け漏れを防いだり、効率よくテストケースを作成することができます。

【初心者向け】デシジョンテーブルについて

本記事ではテスト技法の一つの「デシジョンテーブル」について解説していきます。

CCNA学習＃５未経験の方向け

復習・トランスポート層（レイヤ4）とは、通信における信頼性に関するプロトコル群です。・通信の方式、通信状態の確認方法、以上発生時の対処など通信が期待通り行われるためのプロトコルを定義しています。前回までは、ホスト同士の通信IPアドレスについて、まとめていました。IPアドレスが郵便番号、ポート番号が住所でかみ砕いて理解しましょう。

その他(インフラ)

【CSS】基本のまとめ | セレクター編

今回は、Webページの見た目を設定するCSSのセレクターについてまとめました。CSSは、Web開発をするにあたって欠かせない知識となっています。ぜひ最後までお読みください！

製造・コーディング(PG/フロントエンド)

【初心者用】AWS基礎②

前回は、AWSで知っておくべき用語やよく使われるサービスがどんなのがあるのか学んできました。今回は、AWSの初学者として、どんな内容を理解しておけばいいのか、AWSの入門編としてクラウドプラクティショナーという資格があるように、その内容についても触れながら学んでいきましょう。AWS資格は、AWSに関する専門知識やスキルを証明する資格で、試験対策を通してAWSを効率よく学ぶことができます。

その他(インフラ)

【データベース】基本のまとめ | 初心者向け

今回は、システム開発をおこなううえで重要な「データベース」についてまとめました。初心者向けの簡単な内容となっていますので、ぜひ最後までお読みください！

製造・コーディング(PG/バックエンド)

【初心者用】AWS基礎⑥

前回はクラウドプラクティショナーの出題範囲のうちのAWSの主要サービスの識別分野のところを学習してきました。EC2、EBS、AMI、ELB、Lambda、Auto Scaling、S3、EFS・Storage Gateway・Snowball、VPC、Route53そのうちのS3まで、学んできました。今回はAWSの主要サービスの識別のEFSから学習していきたいと思います。●これから学習していく分野テクノロジー　・AWSの主要サービスの識別　・テクノロジーサポートのリソースを特定請求と料金　・AWSの様々な料金モデルの比較対照　・AWS請求と料金に関連した多様なアカウント構造の認識　・請求サポートに利用できるリソースの特定

その他(インフラ)

1年目のインフラエンジニアに必要なスキル | データモデリングとは？

データモデリングは、ビジネス要件に必要な情報を整理してビジュアル化し、データ検索を容易にする、システムがデータの精度を保つために必要な概念です。特にインフラエンジニアやデータベースエンジニアの方など、データに深く関わる職種では重要なスキルであり、これからエンジニアとしてキャリアを築いていくためには避けて通れません。本記事では、エンジニアに必要なスキルの一つであるデータモデリングについて分かりやすく解説します。