この記事の目的
日々を泥船のゆりかご（？？？）で過ごす深海魚である私が
何故テストは要求から考えたほうがよいのか、何故、アーキテクチャを作った方が良く、レベルやタイプを分けた方がいいのか、自分の中で立ち戻るために書きます。
何も参考にしないで書くため、正解探しのお役には立ちません。
テストの目的はなんだったか
（JSTQBシラバスを読めば一発ですが勘で書きます）
？バグを出すこと
○ある範囲・粒度について目的の動作が目的通り動作していることを担保すること
バグを出すことが目的のところもあるかもしれない。
（実際JSTQB FLシラバスにも「故障を引き起こし、欠陥を発見する」って書いてあった。いまいちこれが目的っていうのでしっくりこない感はある）
バグを出すという言葉がキャッチーすぎてそれ自体で完結でいいじゃん感を出しているが
バグを出すというのは、リリース後に起きて欲しくないこと（＝プロダクトの価値を損なうこと）の原因になりうる要素を
より早い段階で見つけて少ないコストで直すきっかけを作るってことですよね？？
時期的に早く見つければ直すコストが少ない＝うれしい
露見しなければプロダクトの価値を損なうことが無い＝うれしい
テストを作るプロセスを段階的にした方が良いのは何故だったか？
いきなりテストケース書く！（いわゆるテスト実装）だと、テスト対象の分析が足りず確認に抜ける場合がある。
この場合の「抜け」っていうのは、意図しない考慮不足の仕様や暗黙の「こうやって動作してほしかったなあ」とい要求などなど。
こういうところを考え抜いてなるべく減らし、がっかりを減らすために、段階的に考えることが必要となる。
考え方の順序で「大きい範囲から順に細かくしていった方が良く考えられるじゃ？」みたいなところで
段階的に考える手段を取ろうって話だったと思う。
なんでテストは要求から考えた方が良かったか
理由の掘り下げが足りないことは、目的が分からないテストの作成に繋がるから（勘）
テストの要求っていうのは、「これは出来て欲しい」「これは起きて欲しくない」から
「これは出来るよね」「これは起きないよね」とかを考えることだったと思う。
たとえば、仕様で定められてることを確認したとして、その仕様が何のためにあるか分からないことを
仕様だからってテストするのは、プロダクトの価値に直結しないかもしれない（ってことに、分析している時に気づいた方がよいのかもしれない）
あとは、品質特性で定められているからといって、プロダクトを使う人にはあんまり気にならないことかもしれない。
だから、品質特性に書かれてるからこれを拾おう、でいくと、無関心品質や逆品質の量産になるのかもしれない。
目的が分からないものを全部撲滅するってのは無理だけど、分からないものは工数や人の見えない何かを蝕むし
よく考えると無駄なので、なるべくほんとは無い方がよい。プロダクトの何を確認するためにやるかを遡れないテストは、無い方がいい。
テストアーキテクチャは何で必要だったか
何を確認したいか・何を確認しているかを俯瞰して表すことによって
テストの意図を表し、何を確認できているかを説明できるようにするため。
たぶん小規模（社内ツールとか、単機能のアプリとか）だと確認意図がそんなに複雑にならないから
アーキテクチャ作るまでもないんだと思うけど、複数のシステムで構成されているとか
ある程度の規模をもっているときに、全体にしろ一部にしろ確認意図がわかるように
アーキテクチャを作るのかなーなんて思う。
テストアーキテクチャ自体が「テストをもっと良くしたいよね」を目的として議論されているものであって
何か公の規格とかなわけではないから、「何々に定められているから」を根拠にプロセスを定めるような感じだと結構辛みがあると思う。
IVECのレベル5はアーキテクチャが頻出するけれど、それが「根拠に本当に遡れているのか」の洗礼なのかもしれない。
テストレベルは何で分かれてるんだったか
いろいろ意味があるのは大前提においておくとして、自分の中では結合度で理解しているイメージが強い。
たとえばWindowsの電卓で1+1が3と表示されたとして、電卓の形になってるもので原因をつきとめるには
表示の生成がおかしいのかとか、押したボタンと表示の値がずれているのかとか、内部の計算がおかしいのかなど色々原因が考えられてしまう。
これを、押したボタン通りの値を返す関数、内部の計算をする関数などなどそれぞれ単体でテストしていれば原因を突き止めるのも簡単になる。
あとは、責務の分割。
このレベルではここまでみますよ、と明示することでそれぞれで重複しないテストをして
無駄を省くこと＆漏れをなくすことが目的なんじゃないかなって思ってます。
自分の中ではこれはあの4段階のレベルの図ではイメージしてないです（同じ結合レベルに結合している固まりが色々いるようなイメージ）
分けて考えることと分業？を混同しない
分けることってのは分けたことに対して「ここは考えないし、やりもしないし、自分の範囲外です」ってすることじゃなくて
フォーカスを絞ることで、よりそこでの課題を考えやすくすることだと思う。
テストプロセスを分けた方が良いっていうのも、プロセスごとの課題を明確化してくことが目的なのかなと。レベルもまたしかり
日々の深海魚生活では全く何も追い付かず、悲しみにあふれることも多いけど、完璧は目指せなくとも
結局なんだったっけに立ち戻れることは忘れずに行きたいなと思います。泥船が沈む日がきても。
