Getting Test World

自己紹介名前：橘田 隼一 TwitterID：hayabusa333 興味：カーネル、GC、Erlang、Elixir お仕事：派遣ウェッブプログラマ 所属：Joel教、翔鶴瑞鶴仲良し姉妹同盟

本スライドについて

本スライドはJSTQBときょんさんのブログ・スライドをまとめた内容になります。 参考文献に載せておりますが、興味を持たれた方は参考文献に当たった方がよいかと思います。

本スライドの用語解説・JSTQB：ソフトウェアテスト技術のスキルを証明するテストの資格

・Beizer：アメリカのソフトウェア開発者でありソフトウェアテストについての論文を記載し、テスト関連の本で引用される人

目次

・ソフトウェアテストの言葉の定義 ・ソフトウェアテストの原則 ・ソフトウェアテスト ・テストの振り返り ・テストのテスト ・参考文献

ソフトウェアテストの言葉の定義プロジェクト内部で使用する言葉の定義についての話。

言葉の定義だけなので、別に本スライドに記載されている内容と違っていても問題はありません。

プロジェクトにかかわる人の全員と同意できており、全員が同じ言葉で話せるのならば問題はありません

ソフトウェアテストの言葉の定義

・テストレベル ・テスト技法 ・テストタイプ ・テスト対象 ・テスト目的 ・テストプロセス ・テスト観点

テストレベルJSTQBに定義されているテストレベルの定義

・コンポーネントテスト：スタブを使うようなコンポーネントやクラスなどのテスト

・結合テスト：コンポーネント間やシステム間を統合して動作させるテスト

・システムテスト：ステージング環境などでプロジェクトのスコープにあたるソフトウェアの動作をさせるテスト

・受け入れテスト：要求を出した人の意に沿ったものであるかを確認するテスト

テストレベルBeizerが定義しているテストレベルの定義

・ユニットテスト：1ファイル内で動作が可能なテスト

・コンポーネントテスト：あるユニットが動作するのに必要なユニットを含めたテスト。ある機能を達成するための再帰的なテスト

・統合テスト：コンポーネント間のテスト。

・システムテスト：システム全体を動作させてのテスト。コンポーネントテストや、統合テストでは検出されないようなバグを検出するためのテストであり、JSTQBのステージング環境が想定される。

テスト技法入力パラメータや出力結果の列挙や組み合わせを、どのように決定するかの手法のこと

・同値分析 ・境界値分析 ・デジションテーブル ・直交表 ・etc

テストタイプどのような目的でテストを実施するのかを分類したテスト。 テストレベルと同じくプロジェクト毎に同意していれば問題はない。 実際のテストタイプについては後述

テスト対象ソフトウェアテストの対象物 機能毎に分割でも、インフラ面で分割でも問題なし。 テストタイプごとに対象となるテストを分割して明示的に残すし、テスト対象が他の人にもわかるようにしておくことが大事

テスト目的どのような理由でテストを実施するのかでの分類 JSTQBでは、V字モデルの各ドキュメントに沿っていることを目的にしている。

テストプロセス・テスト要求分析：テスト目的を導入したり、リスク分析を行ったりする。

・テスト戦略策定：テスト観点をベースにしてテストのアーキテクチャを作ったり、人的リソースや手段を考慮してテストのライフサイクルを考える

・テスト設計：テスト実装がうまくいくように設計する

・テスト実装：テスト仕様書の作成やテストケースの作成

・テスト実施：テストを実際に報告し、欠陥があればレポートにする

・テスト報告：テスト結果の報告

テスト観点日本のソフトウェアテスト業界におけるテスト観点は「テスト対象とテスト目的のペアである」らしいです。 テストにおける関心毎

上記のようなテストの言葉の定義をしっかりと行い、プロジェクトごとに話が噛み合うようにすることが重要

ソフトウェアテストの原則JSTQBで定められている7つの原則

・テストは「欠陥がある」ことしか示せない ・全数テストは不可能 ・初期テスト ・欠陥の偏在 ・殺虫剤のパラドックス ・テストは条件次第 ・「バグゼロ」の落とし穴

テストは「欠陥がある」ことしか示せない

テストにより故障を見つけることができれば、ソフトウェアに欠陥があることはわかる

しかしテストにより故障が見つからなかった場合は、欠陥がなかったとはいえない

テスト自身に不備があった場合には、欠陥は見つからない

コラム「テストは品質をあげない」

家が傾いているかテストしても、その行為では品質は上がらないように、品質はソフトウェアを作るときに上下するものである。

テストは品質の担保をするだけで、テスト単体では品質をあがらない。

全数テストは不可能

正常系のテストとして100×100のテストパターンがあった場合に、テストケース数は10000通りとなる。

テストは正常系だけではなく、エラー系も重要である。 通常のテストパターンはもっと複雑であり時間のかかるものである

ソフトウェアの性質や目的、使われ方などから重点的にテストをする場所を絞り、優先順位を決めてテストを行うことが重要である

初期テスト

欠陥が開発の早い段階で見つかるよりも、リリース前に見つかる方が修正のコストは高くつく

時間がたてばたつほど、修正のコストは指数関数的に増大する

システム開発のなるべく早い段階からテストを開始し、欠陥を見つけるようにするのが得策である

欠陥の偏在

ソフトウェアの品質は均一なものでなく、欠陥は一部に集中している。

ソフトウェアの欠陥の8割は全体の2割の箇所に集中して存在している。

欠陥の偏在は過去の不具合分析や、直近のテスト結果によって予測可能である

効果的なテストを行うためには、その予測結果に基づいてテストする箇所を絞り込む必要がある

殺虫剤のパラドックス

1つのソフトウェアに対して同じテストを何度もなんども繰り返すと、最終的にはそのテストでは新しい欠陥は見つからなくなる。

そのためソフトウェアのテストに対しては新しいテスト内容を常に作っていく必要がある。

パターンを追加するごとに欠陥が減っているのならば、ソフトウェアの品質が向上しているといえる

テストは条件次第

ソフトウェアが使われる状況、目的によってテストの方法を変える必要がある

すべてのソフトウェアに共通するテストはない

ユーザーの特性、どのような環境で動作するのか、などなど、様々な条件を見極めてテスト設計とテストの方法を決める必要がある

「バグゼロ」の落とし穴

ソフトウェアテストで欠陥を見つけて、すべての欠陥を直したとしてもソフトウェアとしては役に立たないことがある。

インシデントの報告をうけ、欠陥をなおしたとしても10倍遅くなってしまっては意味がない

修正を行う際に、機能や性能、システム全体に影響はないかといったことを確認することも修正する上で重要である。

テストをするためにまず行うことは

そうですね テスト計画ですね

テスト計画書の概要(IEEE Std 829-1998)・テスト計画識別番号 ・はじめに ・テストアイテム ・テストすべき機能 ・テストしない機能 ・アプローチ ・テストアイテムの合否判定基準 ・中止/再開基準 ・テスト成果物 ・テストのタスク ・環境要件 ・責任範囲 ・要因計画とトレーニング計画 ・スケジュール ・リスクと対策 ・承認

テスト計画書の概要(IEEE Std 829-1998)・テスト計画識別番号 テスト計画書につける文章番号

・はじめに テストの目的や戦略を明文化し、テストアイテムをどのようにテストしていくかを要約する

・テストアイテム テスト対象となるソフトウェアのバージョン/リビジョンを記す。またはソフトウェアがテストされる環境についても記載

テスト計画書の概要(IEEE Std 829-1998)・テストすべき機能 テストすべき機能のリストアップ

・テストしない機能 テストしないと判断した機能の列挙とその理由

・アプローチ 品質目標や方針に合わせて、どのようにテストレベルを組み立てるか、誰が担当するかテストの進め方を記載

テスト計画書の概要(IEEE Std 829-1998)・テストアイテムの合否判定基準 テストアイテムごとにテストに合格したか、テストの終了判断を明示的に記載

・中止/再開基準 テストを中止、再開する基準を明示的に記載

・テスト成果物 テストで作成するドキュメント類のリストアップ

・テストのタスク 準備も含めてテストで必要な作業を列挙

テスト計画書の概要(IEEE Std 829-1998)・環境要件 テストを実施する環境について記述

・責任範囲 テストにかかわる関係者と各関係者の責任範囲について

・要因計画とトレーニング計画 テストに必要なスキルを明らかにして要因計画について記載

テスト計画書の概要(IEEE Std 829-1998)・スケジュール テストのマイルストーンを決めて、それまでのスケジュールを作成

・リスクと対策 テストにかかわるリスクと対策について記述

・承認 計画書の承認者の名前を記述

テストマネジメント詳しくは次回以降

・テスト計画策定 ・開始基準について ・終了基準について ・テスト見積もり ・テスト戦略 ・テストアプローチ ・テストの進捗のモニタリングとコントロール

では、どのようなテストを行っていけば良いのか？

品質プロセスのV字モデル

要求定義

要件定義

基本設計

実装

詳細設計 コンポーネントテスト

統合テスト

システムテスト

受け入れテスト

テスト実施内容

機能テスト以前にテスト技法をまとめているので、そちらを参照 ・「ブラックボックステストの技法」 http://www.slideshare.net/hayabusa333/ss-44959739 ・「ホワイトボックステストの技法」 http://www.slideshare.net/hayabusa333/ss-45271446

非機能テスト・性能テスト ・ロードテスト ・ストレステスト ・ユーザビリティテスト ・相互運用性テスト ・保守性テスト ・信頼性テスト ・移植性テスト

性能テストソフトウェアのパフォーマンスを測定するためのテスト

パフォーマンスとは、システムやコンポーネントが処理時間やスループット制約内で、定義した機能の度合いを果たす割合

ロードテストコンポーネントやシステムの動作を測定するテスト。

負荷（実行ユーザ数やトランザクション数）を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるかを測定する。

ストレステスト要件で定義した限界、またはそれを超えた条件でシステムやコンポーネントを評価するテスト

ユーザビリティテストソフトウェア製品が指定された条件下で理解され、学びやすく、使用しやすくユーザにとって魅力的である能力を判定するテスト

相互運用性テスト相互運用性とは、1つ以上の指定されたコンポーネントやシステムと情報を交換できるソフトウェア製品の能力のこと

保守性テスト保守性とは、ソフトウェア製品の変更の容易さ。

変更には欠陥の修正、新しい要求を支援するための変更、将来の保守性をあげるための変更、稼働環境の変更に対応するための変更などがある

信頼性テスト信頼性とは、あらかじめ決めた運用回数、指定された期間、決められた条件下で必要な機能を実施できるソフトウェア製品の能力

移植性テスト移植性とは、ソフトウェアを別のハードウェア環境やソフトウェア環境に対して容易に移植できる度合い

機能テストと非機能テストの実施タイミングは決まっているわけではない

コンポーネントテスト・結合テスト・システムテスト・受け入れテストごとに実施するべきであるし、テストタイプごとにテストの内容も変わる

テストを実施していると問題になるのが テストが正しいことをいかに証明するか

テストのテスト

・証明プログラミング - Coq、SSReflect、Agda

・モデル検査 - Alloy

・仕様記述言語 - VDM++、B-method

・ミューテーションテスト - RIT

・レビュー

テストをしたら やりっぱなしはダメ

インシデント管理

・テスト中に発生したあらゆるインシデント（調査が必要な事象）を報告するドキュメントの作成管理

・システムの動作不良の問題を明確化し、原因の特定と解決に導くために記載 ・テストリーダーにたいしてシステムの品質やテストの進捗を追跡する手段を提供 ・テストプロセス改善のためにヒント

テストの振り返りテストがどのくらい意味のあるものだったか振り返る必要がある テストの振り返りを行い、次回のテストに反映させ、よりよいテストを行うことが重要

テストの振り返り

・テストコード行数 / テスト件数 ・テスト規模 / バグ数 ・リリースバグ数 / 全バグ数 ・テストスイートサイクルタイム ・TDDサイクルタイム ・計画的テストケース数 / アドホック的テストケース数 ・バグタイプ

ソフトウェアのテストは片手間に できるものではありません

アメリカではテストエンジニアは、 それ単体が独立したキャリアとして

存在している

テストエンジニアになるために

ソフトウェアテストの学習対象

・マネジメント ・ストラテジー、アーキテクチャ ・デザイン ・レポート ・アプリケーションドメイン ・ソリューションドメイン

参考文献

・JSTQB Foundation ・テストエンジニアの品格 ・ソフトウェアテストのレトロスペクティブ ・うさぎ組

ご静聴ありがとうございました