テストの種類を定義する目的
- 問題
- 多くの場合、テストや品質の話を誰かと行うとき、互いのテストや品質に対する認識範囲が異なるため、議論が平行線や発散することが多い
- そこで
- ある程度認識範囲を限定するために用語の定義を行う
- これにより、テストや品質に対して事前に共通の認識範囲を持った上で話すことができるようになり、議論の発散などを防ぐ
- また、その範囲内で効率的な方法をとることができるようになり、他の重要なことに力を割くことができるようになる
テストのライフサイクル
- 開発に設計/実装というライフサイクルがあるように、テストにも設計/実装（実施）というライフサイクルがある
- なので、テストを設計し、実装し、そのフィードバックを持って次回のテストへ反映するというサイクルが実は必要
テストの区分
テストの認識をそろえるためには、以下が代替要素として分けられる。
- テスト設計技法
- テストタイプ
- テストレベル
テスト設計技法
必要なテスト条件やデータを効率的に選択してテストケースを作成する技法
- テスト”技法”に関するポジショニングマップ
- http://www.hayst.com/Pages/positioning.aspx
- 実際に、テストケースを効率的に削減したり、テストの網羅性を担保する為に発達してきた技術
- 銀の弾丸が無いのは開発と同様だが、効率的なテストを実装に落とし込む上で、有用な技法も多々
- ブラックボックス/ホワイトボックス
- 実装の内部構造をどれだけ理解してテストを設計・実装するかを表す用語
- 開発者が実装する開発者テスト（Developer Test）の多くはホワイトボックステスト
- リリース前試験やディレクターがビジネスロジックを最終的に確認したりする時は、多くは見た目から判断する。その場合、内部構造は特に意識されないのでブラックボックス
- ある程度、開発者から内部構造をヒヤリングなどして、内部処理を理解した上で行われるテストはグレーボックス
テストタイプ
- テストの目的にフォーカスを当て、xxテストとして表現されるテストの区分
- Functional test
- Non-Functional test
- Reliability test
- Regression test….
- テストタイプは、だいたいはテストの目的を示す為によく使われる
- 企業独自の定義も多々（私は知らない）
流れとしては、
テストタイプ => テスト技法 => テスト実施への落とし込み => 結果
という流れで具体化、実施、結果を得る。
ここでは、さらに
- テストケース作成
- テスト実施
- フィードバック
に区分されることもあるが、今回はその粒度の話しではないので省く。
テストレベル
- テストの対象や責任範囲を定め、どのような欠陥を予防/見つけるためのテストを実施するかという枠組みを表現することば
- A group of test activities that are organized and managed together.
- Unit test
- integration test
- system test
- acceptance test
個人的な感想 regarding テストレベル
- 個人的な問題意識
- V字型の開発プロセスに対応して用語の定義が使われることが多く、今、開発のxx段階だからこのテストをやるというように、目的から行うべきテストを導くのではなく、今どのような開発段階だからこのテストを行おうという、目的あってのテストの話にならないイメージが強くなる可能性が高そう。
- GoogleのS/M/L
- テストの責任範囲を、開発プロセスとは区別してとらえる簡単な区分として理解しやすい
- 少なくとも、”何を目的にテストをするか”ということに、他の開発段階がどうこうという言葉から切り離すことができる所に、独自の用語でレベル設定する価値がありそう
- LEANなどのように、開発プロセスを明確に分けていない開発スタイルをとっている現場
- 特にSOAを主軸としている現場では、サービスで閉じるか、他サービスにも影響がある範囲に実装がかぶるか、システム全体として振る舞いを保証したいか、というくらいの区分で分けるのも良いかも
- モバイルではさらに区分が変わりそうだが、レベルの区分としては大枠では同じ感じで扱えるようなレベル区分を探りたい
テストアプローチ
どのようにシステムに対してテストを考えていこうかという姿勢を示す言葉
- リスクドベーステスト
- リスク分析をもとに、リスクを最小限に抑制する、もしくは回避していく為に実施までするテスト
- 探索的テスト
- 振る舞いを観察しながら、動的にテストを考え、実施していく
- ビックバンテスト
- 小さなテストは行わず、いきなり大きなテストを実施する、非常に勇敢なテストのアプローチ
参考: http://www.slideshare.net/krsna_crespo/ss-11144954
モバイルやWebの業界の特徴
- Webやモバイルのビジネスでは、UI/UXが非常に大きなビジネス要素を持っている
- 純粋なビジネスロジックも内部処理として重視されるが、特にモバイルではビジネスロジックはUIに寄る傾向にある。
- UI/UXがおろそかになれば、どんなにすばらしいシステムでも使われないことも多い
- 一方、UIに対するテストは難しいとよくいわれる
- まして、”そのUI/UXが本当に妥当なのか”ということはテストで評価することが困難
- LEANでは外部の指標をもとに、それがそのときに妥当なのかを判断し、評価を繰り返す
疑問: Web/Mobileの品質管理？
- この時代の品質管理はどういうものを管理すれば良い？
- 製造業のような品質管理は、おそらく今時点ではWeb/Mobile業界では重視されない
- そもそも、サービス産業は製造業と同一の品質管理が必要？どこを参考にし、取り入れれば良い？
- テストの存在は、サービスの成長とその速度を支えることに重点が置かれる
- 基本、サービス産業なのですから、ユーザの不利益を最小限にする対策を実施しつつ、サービスの価値を向上させることに価値を置く？
- “Quality is value to some person.” by Gerald Weinberg
- ネットワークやOSSなど、自身のコントロール外の要因があることを認めている上で、ユーザに何か不利益が被る状態が発生したら、ユーザの不利益を最小限にするような対策を敷き、それらが現実的な形で動作するような仕組みを敷いたり、その動作を高い確度で保証するような管理が重視される？
- というか、そもそも、ネットワークの世界は組み合わせにより成り立っているシステムですね。
~ my tech diary ~ 