基本設計・詳細設計とは

システム開発にはさまざまな工程があります。要件定義・基本設計・詳細設計などなどの工程が存在します。設計書を作成するのは、開発工程の前段階である「設計」工程。設計工程はシステム開発の方向性を左右するため、特に重要とされています。さらに設計工程は「基本設計」と「詳細設計」に分かれます。設計業務に携わっていなくても、名前は聞いたことがあるという方は多いのではないでしょうか。ただ、具体的にどのような違いがあるのか明確に理解できていない方もいるかもしれません。

基本設計(外部設計)(PG/フロントエンド)

要件定義とは何か

システムの開発やWeb制作の現場にいると「要件定義」や「要求定義」という言葉を耳にする機会もあるでしょう。しかし、要件定義、要求定義について実は理解していない、という方も少なくありません。システム開発プロジェクトにおいて「要件定義」は、プロジェクト成功の鍵を握る、重要な役割を担っています。

要件定義(PG/フロントエンド)

【ソフトウェアテスト】状態遷移テスト

何かの操作を行うと何かのアクションを実行して実行後の状態になり、実行後の状態からさらに次の操作を行うとまたアクションを返すといったように、ソフトウェアに限らず何かしらの機能を持つものは、機能を使う前と機能を使った後でそれぞれ状態が変わります。状態が仕様想定どおりに遷移しているかどうかを確認する技法として、状態遷移テストがあります。

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

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

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

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

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

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

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

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

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

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

【QA】不具合を発見した時

ソフトウェアやその機能についてテストを行った場合、何かしらの不具合を発見することがあります。実施者は発見した不具合が市場への流出するのを防ぐ最初の防衛ラインとなります。では実際に不具合を発見した場合、実施者はどう不具合報告をすればよいか。※開発チーム所属するQA担当であることを想定した内容となります。プロジェクトによって不具合を報告する際のルールは様々なため、この限りではないことを留意してください。