にしさんが語るテスト設計チュートリアル
2018年10月5日（金）に行いましたテスト設計コンテストのチュートリアルの講義メモです。語る夕べのコンテンツではありませんが、語る夕べでも同じ領域を取り上げているため、こちらにも載せることにしました。以前公開していたものを転載しています。
なお、引用はすべてこの資料からです
「テスト設計チュートリアル（Open版）」
にしさんが語った内容の５割ぐらいです。最後は疲れてしまいメモの量が少なくなっています。
■はじめに
え～、みなさんこんばんは。決勝の審査委員長の西康晴です。無差別級の審査委員長をやっています。
テスト設計コンテストのチュートリアルですが、このチュートリアルはコンテストに勝つためのものではありません。ASTERはテストの高度な技術をみなさんに伝えようとしています。先日、ASTERでは無料でテスト研修のテキストを公開しました。今日の内容は公開したテキストの先の話になります。
皆さんが会社でいいテストをするためにこのチュートリアルがあります。タイトルをみてください。「テスト設計チュートリアル」です。コンテストのチュートリアルではありません。
■テスト開発プロセスが必要である
・大規模化・複雑化する一方で、高品質・短納期も求められるソフトウェア開発のために、柔軟で高速かつ精度の高いソフトウェアテストを開発することが社会的な急務になってきている。
－１０万件を超える様々な観点による質の高いテストケースを、いかに体系的にスピーディに開発するか、が課題である。
・しかしテスト計画やテスト戦略立案という工程は未成熟である
－テストケースという成果物の開発と、テストマネジメントが混同されている。
→テスト計画書にテストケースもスケジュールも人員アサインもすべて記載される
－テストケースの開発という工程が見えにくくなっており、そこで必要となる様々な工程が混とんとして一体的に扱われている
→テスト（ケース）開発という用語はほとんど使われず、テスト計画、テスト仕様書作成、テスト実施準備といった用語が使われている
→テスト戦略という用語もイマイチよく分からない
・そこで「テスト開発プロセス」という概念が必要となる
－テストケースを開発成果物と捉え、開発プロセスを整備する必要がある
→大規模化・複雑化・高品質・短納期に対応するテストケースを開発するために必要な作業を明らかにする
→本来はテスト実施以降やテスト管理のプロセスが必要だが、今回は省略する
対象者は、ちょっとバグを出せばいいや、という人ではありません。そういう人は帰っていいです。
・大規模で、高品質で、段階的に、反復的に、継続的に、短納期でリリースしていく、そういうテストをしている人
・ヨーロッパのある通信系の会社では、テストレベルが１４ぐらいありますが、そういうテストをしている人
たくさんのテストレベルを扱わないといけない人
・単一のテストレベルで自動化しているけれども、本当ならば複数のテストレベル、複数のテストタイプを自動化したいと思っている人
このような人を対象にしています。自分がそうだなと思った人は、今日の話の内容を理解していないといけません。
ひとつのイテレーションでしたら、数百件ぐらいのテストケースかもしれませんが、全部を合わせると１０万件を超えるようなテストケースを扱うような大規模なシステムが対象です。
産業構造で言えば、みなさんの会社で事業会社ですと、自分の会社のプロダクトが複雑でしたら、今日の内容は役に立ちます。
自社で作らず、外に依頼している場合、自分たちが今日話するような内容を知っていないと、依頼先が何をやっているのか理解できなくなります。
テスト会社は今日の話を使って、テスト開発方法論を作っていただきたい。発注する会社は、自分たちが理解して、次に発注先にこういう話をふってみて、できなければそういう会社なんだと判断していただければ。
■テスト設計とテスト開発は何が違うのか
・いきなりコーディングすることと、ソフトウェア開発を行うことの違いと同じである。
－コーディングはアルゴリズムとプログラミング言語を分かっていればできる
→（従来の）テスト設計も、テスト（詳細）設計技法と文書フォーマットを分かっていればできる
→経験豊富でセンスのある人が規模の小さいプログラムを書くのであれば別に構わない
－ソフトウェア開発は、要求を把握し設計原則を理解・適用して、段階的に詳細化しながら順序立てて進めていく必要がある
→テスト開発も、テスト要求を把握しテスト設計原則を理解・適用して、段階的に詳細化しながら順序立てて進めていく必要がある
→これまで皆の経験とセンスを結集して規模の大きなソフトウェアを開発することである
→経験とセンスを結集するために、様々なソフトウェア工学上の概念や技術、方法論や、モデリングスキル、抽象化／パターン化能力などが必要となる
みなさん、いきなり、テストケースを書きます。大項目、中項目、小項目と仕様書から転記していきます。こういうのは、いきなりコーディングをするようなものです。ちゃんと動くかどうかは分からないけれども、コンパイルは通るし、なんか動くし。みなさん、こういう仕事はしないでしょう。
しかし、テストではこういうことがやられています。それで良いテストはできません。
ソフトウェア開発をするように、段階的に順序だてて、様々なノウハウを順番に投入してテストを開発していく。テスト開発です。
自分たちが何をお客様に提供しているのか分かっていますか。テストスイートです。テストスイートというのは、テストケースの集合体です。皆さんはお客様にテストスイートを提供しています。
このテストスイートの良さを確保していく、それがテスト開発です。テスト開発というのは、インターネットで検索してもそんなにでてきません。
皆さんのなかには、JSTQBに定義されていない、ISTQBにも定義されていないという人がいます。姿勢が間違っています。ISTQBが出しているようなシラバスは妥協の産物です。全世界でシラバスをベースに高度な話がされています。今日はインターネットを検索してもでてこない話をします。
■テスト開発プロセスの基本的な考え方
・テストケースを開発成果物と捉え、ソフトウェア開発プロセスとソフトウェアテスト開発プロセスを対応させよう
ソフト要求分析 ＝ テスト要求分析
ソフトアーキテクチャ設計 ＝ テストアーキテクチャ設計
ソフト詳細設計 ＝ テスト詳細設計
ソフト実装 ＝ テスト実装
・テストケースがどの工程の成果物かを考えるために、各プロセスの成果物を対比させよう
ソフト要求仕様（要求モデル） ＝ テスト要求仕様（要求モデル）
ソフトアーキテクチャモデル ＝ テストアーキテクチャモデル
ソフトモジュール設計 ＝ テストケース
プログラム ＝ 手順／自動化テストスクリプト（テスト手順）
我々はテストをモデリングするための道具立てを提供します。ソフトウェア開発をするようにテストも開発をします。そうすると、工程ごとに成果物が決まります。テストアーキテクチャ設計はテストアーキテクチャモデルが成果物になります。テスト詳細設計の成果物がテストケースになります。
自社に展開するとき、スライドに載っているような４つの成果物が何かを決めることが必要です。自分たちで決めます。
コンサルを呼んだ所で、決めてくれません。自分たちで決める必要があります。
はい。チュートリアルなのに、こういう話をするのはどうかと思いますが、少なくとも無差別級のチュートリアルなので、どうやって技をかけるかという話はしません。
■旧来のテストプロセスでは粗すぎる
先ほどのテスト開発プロセスを横に並べると、こうなります。みなさんが使っているガントチャートよりも細かいんじゃないでしょうか。テストという矢羽が一本だったりしたら、その開発はやばいです。テストのエキスパートがいいテストしているのかもしれませんが、他の人はできません。
属人化を排除するというよりも属人化する領域をどんどん高度化すると考えたほうがよいでしょう。
■テスト観点とテストケースとテスト手順を区別する
・テスト観点とテストケースとテストスクリプトをきちんと区別する
－テスト観点
→何をテストするのか（テストケースの意図）のみを端的に記述したもの
－テストケース
→そのテスト観点でテストするのに必要な値などのみを特定したもの
→通常は、網羅基準に沿って特定される値などから構成される
→テストケースは基本的にシンプルになる
－テストスクリプト（テスト手順）
→そのテストケースを実行するために必要なすべてが書かれたもの
→手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある
→複数のテストケースを集約して一つのテストスクリプトにすることもある
・これらを区別し、異なる文書に記述し、異なる開発工程に割り当てることによって、テスト観点のみをじっくり検討することができるようになる
テスト観点というのは、U30チュートリアルの講師であるスター（山崎さん）も私（にしさん）もよく分かっていません。抽象的に考える道具がテスト観点です。
オブジェクト指向を考えてみましょう。何がクラスで何がクラスではないかというのは、手順化できませんし、皆が合意する定義もできません。テスト観点も同じです。それがテスト観点かどうかを気にしてはいけません。それよりも気になっていることを、テスト観点として書き挙げたほうがよいです。
具体的なテストケースを導き出すようなテスト観点ががんがんでますけれども、オープンクラスでは、そうでないものも考えます。テスト観点は何かというのは、オープンクラスでは自分たちで決めていいんだと思ってもらったほうがよい。
テストケースとテストスクリプトは明確に区別する必要があります。テスト観点とテストスクリプトをまるっと一緒に考えて、一つの成果物に書こうとしますけれども、書こうとすると自然言語で書くしかなくなります。ワードやエクセルで書くことになります。テストケースごとの関連性まで考えようとすると、自然言語で書かれていると分からなくなります。
■上流工程でテスト観点を構成要素としてモデリングを行う
・上流工程でテスト観点のモデリングを行ってテストを開発すべきである
－モデリングを行うと、テストで考慮すべき観点を一覧でき、網羅的かつビジュアルに整理できる
→１０万件を超えるテストケースなど、テスト観点のモデル無しには理解できない
→モデルとして図示することで、大きな抜けや偏ったバランスに気づきやすくなる
→複数のテストエンジニアでレビューしたり、意思を共有しやすくなる
－テスト要求分析では、テスト要求モデルを作成する
→テスト対象、ユーザーの求める品質、使われる世界などをモデリングする
→具体的なテスト条件が特定できるまで丁寧に段階的に詳細化する
→仕様書や設計書を書き写すのではなく、リモデリングする覚悟を行う
－テストアーキテクチャ設計では、テスト詳細設計・実装・実行しやすいようにテスト観点をグルーピングする
→テスト観点をグルーピングして、テストタイプやテストレベル、テストサイクルを設計する
→テスト観点をグルーピングして、テストケースの構造（スケルトン）を設計する
→見通しのよいテストアーキテクチャを構築する
→テストスイートの品質特性を考慮して適切なテストアーキテクチャを設計する
→よいテスト設計のためのテストデザインパターンを蓄積し活用する
先ほど工程の話をしましたが、ソフトウェア要求定義のような工程の時間を決めていないでただ開発としてあったら、横からとっととプログラムを書けという人がでてきます。テストも同じです。テストという矢羽が一つだと、どこにバグがあるかなあっと考えていると、誰かが時間がないんだ、早く手を動かせという人がでてきます。ですから、テストにも工程を分けないといけません。
また、工程ごとに使う頭が異なります。どのような作りをするとバグがでやすいのか、などをテスト要求分析では考えます。どのようにテストレベルやテストタイプを分けたら、脳みそを行ったりきたりしないで、仕事ができるか。どういうツールがあるのかどういうテスト会社がいて、どのように分けると、丸ごと発注できるのか。このようなテスト全体の立て付けを決めていく。
テスト設計は物事を網羅的に考えることになります。
テスト実装は、操作に関する様々な知識が必要になります。ショートカットキーがあるのか、OSがどこまでサポートしてくれるのか、UIとかインタフェースなどの知識が必要になります。自動化をまわしていくための知識が必要になります。
工程ごとに使う脳みそが違います。ただドキュメントが違うのではなく、抽象度が違うこと、使う脳みそが違う、そのために分けています。場合によっては機械に代行させられることが見えてきます。テスト詳細設計は自動化できたりします。
世の中には、テスト開発方法論がいくつもあります。HAYST法やゆもつよメソッドとかそういう方法論があります。どの方法論を使われてもいいです。今日はVSTePみたいな話をしますが、説明をするときに、説明する概念がVSTePがそろっているので、VSTePの道具立てで説明します。みなさんが社内で他の方法論を使っているのであれば、その方法論に読み替えてください。
■テスト観点の例
テスト観点はテストすべきことといってもよくわからない。俯瞰してビジュアルに捉えること。テスト観点で大切なことはこの２つ。
テスト要求モデル、テストアーキテクチャモデルを作っていきます。テスト観点の定義はしませんが、なんとなくこんなものだなというものをテキストに挙げています。テスト観点の議論をすると、宗教論争になってしまうので、やりません。
バグの種類も挙げていたりします。多面的に広げて考えられるか、これがテスト設計の質になります。テスト観点が、仕様書に紐付けられていて、それ以外に無い場合は、仕様書のコピペなのでそういうテスト観点を書く会社には発注しなくてもよいです。
テスト観点という「観」に引っ張られている人たちがいます。実行結果を観測する、この観測するところを観点といっている会社があります。観測する側と、パラメータなどのテスト条件側があります。両方をテスト観点といってもいいし、区別してもよいです。でも、経験上区別しないほうがいいです。
観点の「観」は目で見ているわけではなく「心の中でみている」のです。
観測していることだけを観点というのは足りない感じ。
テストケースの意図を表すのがテスト観点です。皆さんの現場には非常に大量のテストケースがあるとして、どうして無駄なことをやっているんだろうと思うかもしれませんが、これは、明示的にどんなことをテストするのか、その意図、理由、目的が分からないからです。これを紐付けるのがテスト観点です。
■TRA－テスト要求の源泉の準備
・入手できるなら、テスト要求の源泉を準備する
－テスト要求の源泉の例）
→動いているテスト対象や動作の結果・状況
→要求系文書、開発系文書、ユーザー系文書、マネジメント系文書など各種文書
→テストに関して使うべき社内・社外の標準や規格
→ヒアリングできるステークホルダー
など
－一つも入手できないなら、自分たちでステークホルダーになりきってブレーンストーミングや仮想ヒアリングなどを行う
→あくまで入手できないなら仕方が無い、という意味合いであり、要求の源泉が無くても大丈夫、という意味ではないことに注意する
－テスト要求は、システムやソフトウェアの要求のサブセットではなく、むしろ広い情報が必要となる
→例）テスト対象の途中経過に関する情報
テスト要求の源泉の準備というと難しいと思うかもしれません。難しいことを言っているんではないです。どこを見ればいいですか？ どこに聴きに行けばいいですか？ そういうことが分かっていれば、いいですということです。
■TRA－テスト要求の獲得と分割
・テスト要求の源泉からテスト要求を獲得する
－ヒアリングや観察など様々な手段がある
・テストケースを導くエンジニアリング的テスト要求とテストケースを導かないマネジメント的テスト要求に分ける
－エンジニアリング的テスト要求：システムの完成像とテスト対象の途中経過
→システムの完成像への要求の例
・システム要求
・ソフトウェア要求
・機能要求
・非機能要求
・理想的な使い方
・差別化要因
・目的機能
→テスト対象の途中経過に関する情報の例
・良さに関する知識
・テスト対象のアーキテクチャや詳細設計、実装、自信があるところ
・悪さに関する知識（バグが多そうなところ）
・構造上問題が起きそうなところ
・前工程までの検証作業（レビューやテスト）が足りなかったり滞ったところ
・類似製品や母体系製品の過去バグ、顧客クレームから分析した知識
・スキルの足りないエンジニアが担当したところ、設計中に不安が感じられたところ
・進捗が滞ったりエンジニアが大きく入れ替わったりしたところ
－マネジメント的テスト要求：品質リスクなどに反映させる
→工数、人数、スキル分布、作業場所、オフショアか否か、契約形態など
→機材利用可否（シミュレータや試作機など）、ツール利用可否（ツールの種類とライセンス、保有スキル）など
→目標残存バグ数、信頼度成長曲線
→テストスイートの派生可能性や保守性など
テスト要求というのは、テストが分かっていない人は、ソフトウェア要求仕様のサブセットだと思っているかもしれませんが、そうではありません。ソフトウェア要求仕様に反映されていないものがテスト要求に入ってきたりしますので、余裕がある会社は別々に作っています。
ソフトウェア要求仕様を作った時点で、これは書かなくてもいいや、とか書くと面倒だなあとか、そういうのをテスト要求分析に使うとメモを残しておく。フロントローディングして作っていく。そういうわけで、テスト要求分析の源泉が分かります。
良さに関する知識、プログラミングパターンとか、このあたりは凄い人が作っているとか、検証作業が足りていないところとか、進捗が滞ったところとか、ほかに完成像の知識とか。
そのほかにテストマネージメント系の要求もあります。テストのスキルとか、信頼度成長曲線とか、マネジメント系のテスト要求はありますが、テスト観点に入らないので、区別して扱います。たまにテスト観点に予算と挙げる人がいますが、予算を挙げてどうしようとするのか、私にはちょっと分かりません。
■TRA－テスト要求モデルの構築と納得
・テスト要求モデルの構築と納得
－テスト要求モデルを構築し、自分たちとステークホルダーが納得するまでリファインする
－エンジニアリング的テスト要求を基に、テスト観点を列挙していく
－階層構造やマトリクス、一覧表などでテスト要求モデルを記述する
－エンジニアリング的要求を基に、テスト観点を詳細化したり関連を追加していく
－モデルのリファインを行う
→MECE分析、親子関係分析による網羅化
→整理
→確定
－自分たちで十分に充実したと実感できたら、そのテスト観点図を囲んで、ステークホルダーが納得するまで一緒にリファインする
→ステークホルダーに不十分・不完全・不正確な把握が無いようにする
→ステークホルダーに、本当はこれだけテストしなきゃいけないんだ、という実感を持ってもらうことが重要である
私は個人的に絵が好きなので、テスト観点を図で書いていますが、マトリクスで書いていてもいいですし、マインドマップが好きな人はそれを使ってもらっていいです。好みですから。
テスト要求分析の大事なことは、ある作業で完璧なテスト要求モデルを一気に作られると考えないほうがよい。ウォーターフォールのように完璧なテスト要求モデルをかけると思わないほうがよい。ちょっとさきに書いて、学習して、探索して、モデルを反復的に書いていく。
書いていくと構造が歪むので、そのとき整理する。何度も何度もリファインする。
テスト詳細設計を書いているときに気づくこともあるし、テストアーキテクチャ設計をやっていて気づくときもあるし、テスト実施してバグがでて分かることもあります。テストケースだけアドホックで増やすなんてことをしないで、必ずモデルまで戻ります。これ大事。
■TRA－テスト観点を挙げる時の注意点
・仕様書に書いてある仕様や文、単語を書き写してもテスト観点は網羅できない
－仕様書は通常不完全で（もしくは存在せず）、（特に致命的な）バグは仕様書に書かれていないテスト観点でしか見つけられないことがある
→ここまで例に挙げたテスト観点は、皆さんの組織の仕様書に全て書いてありましたか？
・テスト観点は多面的に挙げる
－入力に関するテスト観点だけを挙げたり、期待結果やその観測に関するテスト観点だけを挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する
→「観点」だから期待結果やチェックポイントだけを挙げるのはテスト観点を理解していない証左である
・テスト観点を挙げただけでバグが見つかることがある
－開発者が考慮していなかったテスト観点はバグの温床であり、テストしなくてもバグだと分かることも多々ある
－期待結果に関するテスト観点を挙げたり詳細化すると、仕様の抜けが分かることがある
→テストケースにも期待結果を必ず書くのを忘れないこと
→「正しく動作すること」は期待結果ではない！
・網羅した風のテスト観点の文書や納品物を作ろうとせず、網羅しようと多面的に様々なことを考えつくそうとする
－あーでもないこーでもないとワイワイ議論したアイデアのリポジトリがテスト観点図である
→見逃したバグを見つけるテスト観点を気軽に追加して整理することも大事である
－最初から網羅しようと気張ると大事なテスト観点を見逃す
→そもそも網羅することが必要なのか
テスト観点のモデルは抽象化されているので、多くの場合、模造紙とかで全体像を一覧できます。（ツールを用いて）マインドマップで書いていますと、枝を閉じたり開いたりしながら理解することができます。
やってはいけない話は、テスト観点を早い段階で分解して、担当者に考えさせるはダメ。ぎりぎりまでみんなで納得するまで議論して、こんなものだねと共感させる。何かの理論を使えば、判定できるかとかありえないから。
テスト要求モデルは、もうこれ以上いいものができないと考えたら、それがモデルになります。どこまでのレベルのものをかけるかどうかは、自分たちの技術力次第です。技術力を鍛えなければ、外から買ってきても定着しない。自分たちの技術力のMAXはこうなんだということを知る。一生懸命テスト要求分析しても、バグがでます。このバグの分析をします。
そうしてテスト観点のモデルをアップデートします。何度も書き直して、技術力を高めていく。
テスト観点図を描いてきました、見てくださいというのでみると、機能仕様書の目次を転機していたりします。仕様書の単語を書き写してもテスト観点になりません。QAの人って網羅したことにしたいらしいです。VSTePではモデルの中に網羅できていないマークをつけるようにしているんですけど、そんなことをしたら要検討というマークが残っていたら、レビューが通過しないので、取ってください。といわれたりします。
不幸ですね。
できることしかできないし、できないことはできない。できないことを明示する。レベルアップするために議論する。整理したテスト観点図があると、開発者を引き込みやすい。テストケースを開発者に見てもらっても、Excelシートが１００ページあったら、げんなりするでしょう。部下からテストケースのレビューをしてくださいといわれたら、レビューしますか？ 無理でしょう。テスト観点図が無いテストケースはそもそも整理されていないし。
ここまで込み入った話はまだ早いという会社もあるでしょう。テストケース表を並び替えて、グループ化するところから始めましょう。ポストイットにおんなじようなことと書いておきましょう。ここで言っていることの中身は、皆さんのようなエキスパートがやっていることを集めているだけです。
テスト観点図を描くと、全部網羅したいと思うみたいですけど、全部は網羅しません。網羅しようとすると、トレーサビリティという文字が気になると、テストの場合は仕様書のコピペになりやすいからです。
■TRAーテスト観点モデリングの２つのアプローチ
・トップダウン型
－おもむろにテスト観点を挙げ、詳細化していく
→三角形のテストには、三角形の構造に関する観点が必要だ
→三角形の構造には、成立、直線、不成立の３つがあるな
→成立する場合には、正三角形、二等辺三角形、不等辺三角形があるな
－実際にはトップダウンとボトムアップを循環させながらモデリングする
→いまあるものをリバースしながら進めるのが実践的だろう
・ボトムアップ型
－まず思いつくところからテストケースを具体的に書き、いくつか集まったところで抽象化し、テスト観点を導き出していく
→（１，１，１）なんてテストどうかな
→（２，２，２）とか（３，３，３）もあるな
→これって要するに「正三角形」だな
→他にも似たようなのあるかな、う～ん、二等辺三角形とかかな
－実際にはトップダウンとボトムアップを循環させながらモデリングする
→いまあるものをリバースしながら進めるのが実践的だろう
トップダウンもボトムアップも両方テスト観点を書くときには必要。抽象の階段をいったりきたり、上げ下げを自由にします。
■テスト要求モデルの全体像の種類
・テスト要求モデルの全体像をどう整理すればいいか、に唯一絶対の解はない
－一面的な全体像のモデルは考慮が足りないことが多い
→仕様ベースモデル
→機能ベースモデル
→画面ベースモデル
→正常系異常系モデル
－多面的な方が考慮されている可能性が高いが、お仕着せのものを流用したのは考慮が足りないことが多い
→品質特性モデル
→一般テストタイプモデル
→CIBFWモデル
Condition／Item／Behaviour／Fault／World
→三銃士モデル
世界観－コンテキスト・実装＋ユーザ勘定
→システム構想モデル
そのシステムお構想がそのまま全体像になる
・全体像の構造によってモデリングの質がかなり左右される
－大事なのはどれを採用したかではなく、考慮が十分かどうかである
テスト設計コンテストでもそうですけれども、テスト要求モデルの全体像は様々です。唯一全体の解はありません。
一面的なものはいまいちです。機能ばかり書いている、画面ばかり書いている、または、正常系、異常系で書いていたります。Aと￢Aで挙げる人もいます。正常系、異常系で書く人は、多面的なテスト観点モデルを理解できないことがあります。
お仕着せのものを流用しようとする人もいます。国際規格を使おうとする人もいます。いいですか、国際規格は網羅していませんし、皆さんがやろうとしているソフトウェアをターゲットにしていません。品質特性みたいなものを増やしていくんならいいんですけどね。
一般的なテストタイプモデというのがありまして、システムテストのテストタイプを列挙しています。その会社がやっていることをテストタイプに列挙しているので悪くはありませんが、今の皆さんの会社にあっているかどうかはわかりません。
どれを採用するかではなく、考慮が十分なのかどうかが大切です。他の人が言ったことをそのまま使ってもうまくいきません。
■TRA－テスト観点モデルのリファイン
・質の高いモデルにするために様々なリファインを行う
－網羅化：MECE分析
→子観点がMECEに列挙されているかどうかをレビューし、不足している子観点を追加する
→MECEにできない場合、必要に応じて「その他」の子観点を追加し非MECEを明示する
→子観点をMECEにできるよう、適切な抽象度の観点を親観点と子観点との間に追加する
－網羅化：親子関係分析
→MECE性を高めるために、テスト親子関係を明示し子観点を分類する
－整理
→読む人によって意味の異なるテスト観点を特定し、名前を変更する
→テスト観点や関連の移動、分割、統合、名前の変更、パターンの運用、観点と関連との変換、観点と網羅基準との変換などを行う
→本当にその関連が必要なのかどうかの精査を行う必要がある
－剪定
→ズームイン・ズームアウト、観点や関連の見直し、網羅基準や組み合わせ基準の緩和によってテスト項目数とリスクとのトレードオフを大まかに行う
－確定
→子観点および関連が全て網羅的に列挙されているかどうかをレビューすることで、テスト要求モデル全体の網羅性を明示し、見逃しリスクを最小化する
リファインのスライドを理解できるのであれば、かなり本質的なモデリングをやっています。
親子関係分析。ある親に対して具体化していない子供をつけようとしていたります。性能の下に負荷を置く人が多いけれども、親子関係分析が十分にできていません。負荷は別の親にします。
親子関係分析は、兄弟関係の分析もやります。兄弟は本当に兄弟ですか？ 「和食」の直接の子供が「べったら漬」だったら、「和食」と「べったら漬」の間に「漬物」をいれたいじゃないですか。間のノードとか、観点とか入っていきます。
子観点は７つぐらいにしたほうがよいでしょう。
テストレベルを跨いで同じテスト観点がでてきたらどうしたらいいですか？ という質問がよくありますが、本当に同じテスト観点かどうか疑ったほうがよいでしょう。
テスト観点の組合せも、限度がありません。心配なんです。新たに組合せを考えるのであればいいんですけど、リファインしようとして、この組合せでいいかどうか疑問に思ったとしたら、正しい問いかけです。
でも、疑問に持ったことを指摘して、バグがでたらどうするんだって言われる残念な組織もあります。なんでこの組合せが必要なのかを考えてください。中には、組合せの背景にある、別のテスト観点が潜んでいることが多いです。経験上ですが。入力パラメーターに無いので、入力できないので、組み合わせているというケースが多いです。
組合せをすべてやろうとすると何年もかかるとき、剪定します。あきらめて、ズームアウトします。カバレッジ数を減らしたりします。
やってはいけないのは、時間が無いのでやらないだろうとテスト観点を挙げないということです。テスト観点を挙げる時間が無いという人がいますが、テスト実行に比べれば微々たるものです。テスト実行に比べれば、たいした時間は必要ありません。
テスト観点をすべてあげきれていない場合、最後の最後まで不安が残ることなります。大事なことは、挙げてから削る。
確定。テスト観点を書きながら十分検討したなというものは確定マークを書いていきます。確定マークが増えていくと、検討が進んでいるなと思います。
■テストアーキテクチャ設計（TAD）
・テストアーキテクチャ設計とは、テストスイートの全体像を把握しやすくしつつ後工程や派生製品、後継プロジェクトが作業しやすくなるようにテスト観点をグルーピングしてテスト要求モデルを整理する工程がある
－１）テストコンテナモデリング
→テスト要求モデルを分割し、同じまとまりとしてテストすべきテスト観点を同じグループにまとめることで整理する
・グループの例：テストレベルやテストタイプ、テストサイクル
・テストレベルやテストタイプに何が含まれるかを、テスト観点を用いて設計する
・テスト観点のグループを、VSTePではテストコンテナと呼ぶ
→グルーピングすると粒度が粗くなるので、テストスイートの全体像の把握や全体に関わる設計がしやすい
→自社で定められているテストレベルやテストタイプの趣旨を理解し、きちんと全体像を設計できるようになる
→テストにも保守性など特有の「テストスイートの品質特性」や「テストコンテナの責務」があるが、どのような品質特性や責務を重複するかによって異なるテストアーキテクチャとなる
－２）テストフレームモデル
→複数のテスト観点を同じグループにまとめてテストケースの構造（スケルトン）を定義し、テスト詳細設計をしやすくする
・テストケースのスケルトンを、VSTePではテストフレームと呼ぶ
※コンテナモデリングとフレームモデリングはどちらから始めても構わない
・現実的には反復的に進めることになるだろう
これから本題。テストアーキテクチャ設計。ぐぐってもでてこない。検索すると、テスト実行のインフラをテストアーキテクチャと言ってる場合もあります。今日の話はテスト実行のインフラではありません。
テストレベルやテストタイプとは何かを考えさせること。テストレベルやテストタイプのことを、このテキストではテストコンテナと呼んでいます。初心者のうちは、テストレベルもテストタイプも明確に区別できますが、腕が上がると区別できなくなります。
機能性テストというテストタイプがあり、機能テストというテストレベルがあり、この区別を延々と議論したりしていて、無駄ですよね。
何をテストレベルか、テストタイプかは勝手に決めてかまいません。このチュートリアルのテキストにテストタイプを区別して書くと、
「これってテストレベルじゃない？」って言われてうざいのでテストコンテナといっています。
テストフレームモデルというと難しいかもしれませんが、エクセルの列見出しを考えることです。フレームを作っていると、コンテナを分けたほうがいいなと思うこともあります。
■TAD－テストコンテナとは
・大規模なテスト設計では、複数のテスト観点をグルーピングして扱いたいときがある
－複数のテスト観点をグルーピングしたものをテストコンテナと呼ぶ
→テストタイプやテストレベル、テストサイクルなどを表現する
・機能性テストと機能テスト、機能テスト段階など、タイプなのかレベルなのかサイクルなのか分からないものの区別に時間を取られないで済む
－テストコンテナを包含関係を持つことができる
→テストコンテナに含まれるテスト観点を比べるとテストコンテナ間の役割分担を明確に把握できる
・負荷テストと性能テストなど、違いがよく分からないテストタイプを区別する
・単体テストと結合テストなど、役割分担がよく分からないテストレベルも区別できる
・テストコンテナを用いてテストアーキテクチャを表現するメリット
－テスト観点よりも粒度の粗いテストコンテナを用いるので、俯瞰して把握しやすい
－テストコンテナ間に含まれるテスト観点を比べると、役割分担を明確に把握できる
→現場で経験的に用いてるテストコンテナの妥当性を評価したり改善できるようになる
・負荷テストと性能テストなど、違いがよく分からないテストタイプを区別する
・単体テストと結合テストなど、役割分担がよく分からないテストレベルを区別できる
－複数のテストタイプからなるテストレベル、サブレベルを持つテストレベルなどのように、他のテストコンテナを包含しながらまとめることもできる
－テストコンテナの順序や依存関係、設計時期（や実施時期）を適切に考慮することができる
→ＣＩなどツールチェーンを構築したり、フロントローディングしたり、シフトライトをする際には必要となる
－テストスイートの品質特性（保守性や自動化容易性など）やテストコンテナの責務を意識してテスト設計に反映できるので、納得しやすいテストアーキテクチャになる
・テストコンテナモデリングのポイント
－テストが小規模で単純な場合、テスト要求モデルの大まかな分類をそのままテストコンテナにしてしまってよい場合もある
－テスト要求モデルでは単一だったテスト観点を分割したり統合したり意味の違いに気づいて名前を変えたりすることもある
→現実的には、テストコンテナモデリングとテスト観点モデリングは反復的に行うことになるだろう
－マネジメント的要求からテストスイートの品質特性やテストコンテナの責務を抽出し、それらを達成できるようにモデリングする
→例）保守性を高めたいというマネジメント的要求がある場合、変更要求があまり入らないテストコンテナと変更要求が頻繁に入るテストコンテナに分割する
・同じ時期にテストすべきテスト観点をテストレベルとしてまとめる
－テスト観点には、テスト観点動詞の順序依存関係や欠陥特定の絞り込みのための順序依存関係、プロジェクトの制約として時期依存関係がある
→例）機能テスト観点の実施情報を用いて負荷テストを設計したい
→例）モジュール内設計の照すおｔを実施した後に、モジュール間設計のテストを実施しないと欠陥特定の工数がかかりすぎてしまう
→例）特殊なテスト環境が揃うのが後半なので構成テストは最後に回したい
→例）性能に関わるバグのうちシステムアーキテクチャに関わるバグは早めに検出したい
→例）リリース後にもテストしたい
・同じ趣旨を持っているテスト観点をテストタイプとしてまとめる
－例）負荷テストタイプは複数のテスト観点からなるが、負荷をかけるという同じ趣旨を持っている
・繰り返しおｎテストや回帰テストが必要なテスト観点、スプリントやイテレーションごとのテストをテストサイクルとしてまとめる
－同じテスト観点を栗化しているようでいて、実は意味が異なったりすることがあるので注意すること
・テストコンテナ間の関係がなるべく少なくなる（疎になる）ようにまとめる
－結合度を低く、凝集度を高く（同じテスト設計意図のテスト観点をまとめるように）設計する
→テスト設計意図（Test Design Intention）はテスト観点やテスト観点の趣旨とは異なることを理解する
テストコンテナはテストケースをグルーピングしたものですが、テストケースといってしまうと抽象度が低すぎなので、間にテスト観点をかましています。
テストコンテナは、子コンテナをもつことができます。テストレベルの中にテストタイプがあっても普通のことですよね。包含関係といったりすると、偉い人をごまかせます。
大規模なテスト設計の場合、このような構造を表しています。テストの場合は、このような内容がテスト計画書の中に書かれています。でもおかしな話です。プロジェクト計画書の中に、システムアーキテクチャを入れますか？ 入れませんよね。
テスト計画を作るときに、テストアーキテクチャのことをあんまり考えずに、過去に作ったテスト計画書をコピペして作ります。でも、規模が大きくなると、そんな簡単ではありません。
単体テストのようなテストレベルでは、テストタイプというのは、よく分からないです。サイクルはおおむね同じことを繰り返す。または、時間で区切ったものをいいます。イテレーションごとに区切ったものをテストコンテナと言ってもいいんです。みなさんは、現場でいろいろなコンテナのまとめ方をしています。それを前半とか後半とか言っているからノウハウがたまらないのです。
全体を俯瞰して理解しやすい。コンテナごとに役割を明確にする。このあと責務の分担といっています。
ある会社の標準には、負荷テストが書いてあります。その説明にはテスト対象にストレスをかけると書いてある。ストレステストの説明に負荷をかけると書いています。その会社の技術が低いわけではありません。現場のテストマネージャがいい感じで区別しているんです。だから現場では問題は無いのですが、標準を見るといい加減なことが書いてある。
いい加減な組織だと、モデリングで負荷テストというコンテナにストレスと入れて、ストレステストというコンテナに負荷といれるかもしれないけど。
テストスイートの品質特性を考える必要があります。小規模で単純なものは、単純に考えればいいです。複雑なものに対しては、複雑なことを考える道具立てが必要になります。
テストコンテナの順序は、
・機能テスト観点の後に、負荷テスト観点をする
・同じ時期にテストしたいものをまとめる
・同じ趣旨のテストをまとめる
でもいいんです。
負荷をかけるというものをまとめることにしたら、性能テストは負荷をかけるというわけではないので、そのグループからはずしてもいいし。
テスト観点間の関係が少なくなるようにまとめます。負荷と性能を分けると、性能測定をどちらに入れるか悩むようになったら、
依存関係が無いようにします。疎にします。
■TAD－SoEやSoRのテストコンテナが混在することがある
某所で誰かが経験で、ゲームではテストコンテナがあるんじゃなかろうかっで挙げたテストコンテナがスライドに書いています。人によってはこれぐらいと思いますし、人によっては、これぐらい粗いほうが扱いやすいなと思うかもしれません。このテストコンテナにはSoRとSoEを区別していて、SoRは網羅重視とかしています。
自分のシステムはSoRだからSoRのテスト観点しかないというわけではありません。SoEのテスト観点もあります。その区別が必要だと思います。
■TAD－テストコンテナの粒度も自分なりでよい
コンテナは自分で考えろ。いろいろなコンテナがあるぞ。粒度はいろいろあるぞ。
去年までのチュートリアルと、今年では変えています。去年までは知っていることを教えていません。教えた内容のとおりに書かれても困るので。でも、教えていないことを参加者ができるようになったので、全部教えてもいいじゃんになりました。
■TAD－テストアーキテクチャ設計における責務の分担
・テストスイートの品質特性が満たされテストコンテナの責務が適切に分担されるようテストアーキテクチャを設計する必要がある
－アーキテクチャを検討するほど大規模で複雑なテストスイートではスイート自信の品質特性やコンテナの責務を考慮しなければならない
→全く同じテストスイートでもコンテキストやフォーカス、制約条件などによって変わる
－テストコンテナには適切に責務を表す生をつける必要がある
・テストスイートの品質特性やテストコンテナの責務には色々ある
－Coupling（結合度）
－Cohesion（凝集度）
－Test design intention（テスト設計意図）
・Detection
・Assurance
・Traceability
・Evidence-making
・Learning
・Exploratory
・Trial-and-error
・Rhithm-making
・Requirement decomposition
etc.
－Maintainability（保守性・派生容易性）
－Automatability（自動化可能性）
－Circumstance consistency（環境類似性）
－Development consistency（開発工程類似性）
－Describability（記述性）
－Execution velocity consistency（実行速度類似性）
－Stability / Change frequency（安定性 ／ 変更頻度類似性）
－Design type（設計種別類似性）
・Design direction
・Design positiveness
etc.
・コンテナの責務を考える。
・結合度を低く保つ。
・コンテナを跨ぐようなものを減らす。なくす。
凝集度、いい感じでまとまっている。テスト設計意図でまとまっています。テスト設計は難しい。理由は、テスト目的、テスト観点、テスト目標、同じようなでも違うような、似たような言葉がたくさんあるから。
テスト観点は、要するにどんなテストケースを実行するか。テスト設計意図は、そのテストを何のために設計するか。このように言われても違いは分からないでしょう。
負荷をかけるテストのテスト設計意図はバグを見つける、保証する。これだけの負荷をかけても落ちませんでした。というふうに保証する。
トレーサビリティをとるためにテストする、エビデンスが欲しいというテスト設計意図と、バグを取りたいというテスト設計意図をあわせるとろくなことがありません。
ラーニングのためのテストと、保証するテストを合わせる、リズムを合わせる。
ユニットテストをどのようなテストするかによって異なります。
保証のため、粗っぽい詳細設計仕様、仕様を分析し、落とし込んでいる。設計意図が同じようなものでないと、
メンテナビリティ、自動化可能性。自動化が難しい場合は、コンテナレベルで自動化可能性を考慮していないからかもしれません。
開発工程と一致したほうがよい。
記述性は、ひたすら書くものと、探索的テストは分けたほうがよい。実行結果が早い場合と、遅い場合をあわせないほうがよい。
仕様変更が多いところと少ないところは分けたほうがよい。
■TAD－テストスイートに求められる品質特性によって異なるテストアーキテクチャの例
テストには２つの方向性があります。条件を先に考えるタイプとこういう動作があると考えるタイプの種類です。前者をフォワードデザイン、後者をバックワードデザインといいます。
順設計と逆設計を混ぜると混乱します。逆設計は網羅しにくいので、網羅率を高めようとするテストと合わせないほうがよい。動かないテストは動かなそうな知識をふんだんに必要となります。
仕様どおりに動くかどうかを確認するテストと、バグがでるかどうかをテストする場合では、使う頭が違います。テスト設計するとき、技術者はいろいろ考えるんですけど、ワードに落とし込むときに書かないので、後で分からなくなるし、他人に伝えられなくなります。
■TAD－探索的テスト
・エキスパートによる非記述的なテストを探索的テストと呼ぶ
－テストエンジニアが五感と経験（によって得られたパターン）と感受性を駆使することでバグを出すことに集中しながら学習し探索することで創造性を発揮するテストの方法である
－「ただ触るだけ」のモンキーテストやアドホックテストではない
→素人に触らせて品質が向上するほどQAは甘くない
・「素人がしそうな操作ミス」「素人はどう思うか」という明確なテスト観点に絞る場合は例外だが、その場合でも探索的テストやアドホックテストとは呼ばない
・チャーターとセッションでマネジメントを行う
－大まかにどの辺をテストするか、どんなことをテストするか、を伝える「チャーター」を用いてマネジメントを行う
→チャーターを細かく書きすぎると創造性が減るし、粗すぎてもマネジメントできない
→チャーターを使わないフリースタイルというやり方もある
－テストエンジニアが集中力を高めておける時間を１つの「セッション」という単位で捉え、マネジメントを行う
→60～120分程度と言われている
・テストアーキテクチャ設計時に考慮しておく必要がある
－チャーターをテスト観点として扱い、いくつかのテストコンテナとしてまとめ、記述的テストと区別してテストアーキテクチャを設計するとよい
－記述的テストとの棲み分けをきちんと考慮しないと、「その他のテスト」コンテナに成り下がる
・探索的テストで何に着目するかはエキスパートに依存する
－バグの出そうな仕様やつくりに着目する
－プロジェクトの状況やエンジニアの納得度に着目する
－バグの出方に着目する
－ユーザーの使い方や、そう使うとは想像しない使い方に着目する
－出てほしくないバグや起こってほしくないハザード・アクシデントに着目する
－ふるまいの一瞬の揺れなど怪しい動作に着目する
etc.
・探索的テストは万能ではない
－探索的テストと記述的テストは補完させるべきである
→探索的テストだけでテストアーキテクチャを構成するのは極めて危険である
・アジャイルだから探索的テスト、という短絡的に考える組織はおそらくアジャイル開発がちゃんとできていない
→記述的テストを受注する第三者テスト会社でも５０％近くを探索的テストで行う場合がある
－探索的テスト中にテストエンジニアがテスト対象について学習し、野生に還ったかどうか（感受性を鋭敏にしたかどうか）をマネジメントするとよい
→網羅性や一貫性などを求めない方がよい
－探索的テスト後にテストエンジニアが仲間とそのセッションについておしゃべりするとよい
→学習した結果や気付いた怪しい動作、言語化しにくい経験ベースのパターンを言語化するチャンス
→高い感受性で開発者と対話ができるように心理的安全を確保しておく必要がある
探索的テストは、テストアーキテクチャ設計で何を探索的テストをするのかをざっくりと考えておいたほうがいいです。
テストの工程って、決められたことを生産性、単位時間あたりにどのくらい消化したかをマネジメントするんですけど、探索的テストは、何かを感じたのかをおしゃべりで聞きとってあげるのが大切。
モデリングだけでは、野生の人のノウハウが落ちちゃう。誰々さんの勘とかのコンテナを用意して、そこにぶち込むのがいい。できないことはできない、野生は野生って書けばよい。感受性が高いんですけど、言語化能力が低いとレベルが低いと見られたりします。マネージャから理由を言えといわれて困っちゃう人がいる。こういう人は救わないと。
■テスト設計コンテストの応募作のテストアーキテクチャ
・テスト設計コンテストの応募作を分析すると、テストアーキテクチャの構成要素は様々だった
－多くのチームが以下のようなテスト観点を抽出していた
→テスト条件／ふるまい（期待結果）／見つけたいバグ
→テスト対象（の要素）／Test Item
－多くのチームが２つの書き方で構造を記述していた
→モデルっぽい書き方
→表（マトリクス）っぽい書き方
・テスト設計コンテストの応募作を分析すると、様々なテストアーキテクチャが構築されていた
－（伝統的）テストタイプ型アーキテクチャ
－レイヤー型アーキテクチャ
－フィルター型アーキテクチャ
－複合型アーキテクチャ
ここからは少しコンテストの話。
評価が低くなるのは、過去の成果物から切り貼りしたり、誰かの言ったことをまねしたりすることです。
モデルを書けというと、複雑なよく分からないモデルを書いてきたりします。この複雑なモデルというのは、全部いれちゃったりしたりします。ケースと手順の違いを区別していないとそうなっていたりします。
バグがでるでない、故障したいかしたくないか、テストケースとして考えるべきものと、テストケースに書いておかないと実行できないことの区分けが分からなくなってしまって、事前条件はテスト意図ではないけれども、事前条件が無いとテスト実行できないために、テスト意図と考えてしまうような感じです。
テストモデルは４つあるとテキストでは言っていますが、他のモデルも当然あります。基本４つは知っておけよというもの。
テスト実装は、テストケースと手順を区別しろよと。見た目、テスト観点とあるテスト観点を一気に実行することができる。集約は、意図の異なるものを一緒に実行しても、影響しないから一緒に実行するということを理解してやること。
大事なことは、表を埋める単純作業から、複雑なことを考えることだと認識することです。できることから小さくやって、小さく回して、効果を得ながらやっていきます。テスト観点を整理して、１時間とか２時間とかやって、効果を感じてもらいます。
テスト観点からテスト実行まで自動化することは可能だけれども、そうではなくて、顧客とのコミュニケーションの道具として使ってもよいです。テスト観点を共有する場を用意するとか。
モデリングスキルを高めてください。実際には、小さく回していくときには、リバースエンジニアリングしていくのがいいでしょう。
過去の応募作に気になっていることを書いています。（テキスト読んでね）
最近のトピックスを取り入れたりするんですけど、取り入れ方が中途半端なんですね。
テストはエンジニアリングです。テストモデリングは業務での熟考度を反映します。テスト開発には、ソフトウェア開発に必要な様々な知識を知見が必要になります。
以上になります。
この記事が気に入ったらサポートをしてみませんか？