今回は「性能テスト」について「なんでやるの？」「どんなことやるの？」についてまとめます。 世間一般だと「負荷試験」とも呼ばれたりしていますが…まぁ、非機能の確認と思えば一緒のような気もします。 目次 性能テストの必要性 性能テストの目的 性能テストの種類 ロードテスト ストレステスト ロングランテスト （おまけ）目標値 性能テストの必要性 なぜ性能テストを実施するのか 性能問題は往々にしてC/O後に問題が見つかります。 通常行われる機能テストだけで検出できない問題のため、専用のテストを行っていないと性能問題がC/ ...

今回は「テスト実施結果報告 は どのように作るべきか」についてまとめます。 目次 報告を受け取る人は何を知りたいのか テスト実施状況の分析 最終断面 実施済みテストケース累積 不具合解消状況の分析 最終断面 信頼度成長曲線 テスト品質の分析 ケース見直しに対する原因と対策 障害起票されたが障害確定しなかったチケットの分析 障害起票漏れしていたケースの分析 アプリケーション品質の分析 ...

今回は「不具合が埋め込まれて見つかるまで」どのような仕組みになっているかを解き明かしていきます。 プロジェクトにおける「不具合管理」やテストフェーズでの「不具合対応フロー」などを考えるためのベースとなる情報になるハズです。 目次 プロセス全体像 根本原因 誤り 直接原因（欠陥） 障害 問題 プロセス全体像 現実、現場で働いている状況踏まえての感覚や前述の内容を踏まえてまとめると以下のような構造が作れる気がします。 作りとしては不具合発生のプロセスと不具合管理フローを組み合わせたようなものになっています。 根本原因 環境や組織、ソフト、ハードといった面でシステム開発にとって適切でない状態となっていると、そこが原因となって次の誤りを誘発 ...

今回は「不具合、欠陥、バグ、障害、エラー … などの用語の示す意味の違い」についてまとめます。 目次 はじめに どんな用語があるのか どんな分類方法があるのか 不具合発生のメカニズムによる分類（機電系） 不具合発生のメカニズムによる分類（ITシステム系） テスト実施時の不具合管理フローによる分類 はじめに 用語の定義はプロジェクトによってまちまちなので、プロジェクトに参画するたびメンバーと認識をあわせる必要があります。 実際、不具合まわりの解説をしているブログやサイトも名称はやや異なる定義をしていたりしました。 ここでは「用語にはどんなものがあるか」と「分類する考え方にどんなもの ...

今回は「テスト観点」についてまとめます。 私の経歴が Webシステム開発 ばかりなので、内容がWebシステム開発を前提に記載している点はご了承ください。。 目次 テスト観点とは テスト観点一覧（サンプル） 全体 詳細（機能テスト） 変更履歴 テスト観点とは 「テスト観点とはテストの切り口」 テスト実施する際、どのような人が設計・実施したとしても漏れ・ダブりが発生しないよう、あらかじめテストの方向性を定義したものです。 テスト観点を一覧化した「テスト観点一覧」を利用することで効率的にテスト設計・実施を行えるようにします。 また、この「テスト観点一覧」は再利用可能な形にしておき、システム改修や他 ...

テスト計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト計画」へ書き起こすと良さそうな内容をまとめました。 ここで取り上げている「テスト計画」は「個別のテスト計画」に相当するので、「単体テスト計画」「結合テスト計画」「システムテスト計画」といった工程ごとにドキュメントが作成されるものになります。 工程によって必要なもの必要でないものがあると思いますので、必要なものが最低限記載されるよう修正して使っていただければと思います。 テスト計画 表紙 文書識別番号 変更履歴 テスト内容 テスト対象機能 テスト観点 テストトレ ...

テスト全体計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト全体計画」へ書き起こすと良さそうな内容をまとめました。 このレベルのドキュメントをどれくらい書く機会があるのか…という疑問もありますが、必要となったとき考えるのでは遅いので、今回のまとめを作成しました。 ここで取り上げている「テスト全体計画」は「プロジェクト全体を通してどのようなテストを行うかを定義するもの」で、１プロジェクトで１計画作成されるイメージのドキュメントになります。 テスト全体計画 表紙 文書識別番号 変更履歴 システム概要 システム全体像 重要機能 ...

IEEE829-2008 個別テスト計画 (Test Plan) について、Webアプリケーション開発をベースにどのようなことを書いたら良いかが見当たらないのでまとめてみました。 テスト計画 (Level Test Plan) イントロダクション 文書識別番号 対象範囲 参考資料 テスト全体から見た位置づけ テストクラスとテスト条件の全体像 テスト計画詳細 テスト項目と識別番号 テスト追跡表 テスト対象機能 テストアプローチ テスト項目の合否基準 ...

今回は IEEE29119 part3 の テスト計画 (Test Plan) をベースにテスト計画に何を書くと良いかについてまとめてみました。 IEEE829-2008 と似ている部分もありますが…微妙に異なるようです。 テスト計画 (Test Plan) 概要 識別番号 発行団体 承認権限 変更履歴 イントロダクション テスト条件 サブプロセス テスト項目 テスト範囲 前提と制約 ステークホルダー コ ...

IEEE829-2008 Standard for Software and System Test Documentation に記載されている内容をベースに、テスト全体計画 (Master Test Plan) でどのようなことを記述すると良いかをまとめてみました。 以下の「目次」は IEEE に従って記載していますが、内容についてはWebアプリケーション開発を前提にかなり内容を仕立て直しています。 オリジナルは IEEE 829-2008 をご参照ください。 テスト全体計画 (Master Test Plan) 概要 文書識別番号 対象範囲 参考資料 システム概要 テスト概要 ...

他システム連携 (外部システム連携) を行う際、いきなり結合を行うのではなく順を追って連携レベルをあげていきます。 ここではそれぞれの段階でどのような確認を行うかをまとめました。 目次 概要 単体テスト（規約確認） 結合テスト（疎通確認） システムテスト 概要 一般に「開発」と言えば「ウォーターフォール開発」が基本になるかと思います。 図に示すと以下のようなものになります。 他システム連携のテストも通常の「ウォーターフォール開発」と同様に徐々に結合レベルをあげるようにテスト実施します。 単体テスト（規約確認） 結合テスト（疎通確認） システムテスト 以下ではそれぞれのテストでどのようなことを確認するか詳細に見ていきます。 単体テスト（規 ...