peeks-blog

こちらの記事を参照

https://qiita.com/kawasima/items/1fed574e7456edbad727

テスト種別を考えることが重要。
→種別を理解すると、ケース作成時にも役立ちそう。

テストの分類

テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。
→UT、IT、STは、ウォーターフォール型の各段階に対応するものでしかない。
→「機能テスト」「シナリオテスト」は、この分類とは違ったもの？

ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになります
→なるほど

テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テストプロセスが構成されるようになっていて、両者はハッキリ区別されています。
→そうなんだ

テストのやり方

テスト種別に沿って、テストケースを書くわけですが、何もなしに複数の人にテストケースを書いてもらうと、粒度がまちまちだったり、漏れがでたりします。
→へえ
→以下のURLを理解した上で、ケースを作ってみた方がいいかもしれない。
http://labs.opentone.co.jp/wp-content/uploads/2010/02/8a7a1b428edc1ed170f8556838542f41.pdf


ここまで出来れば、あとはテスト種別ごとに、自動化の戦術を決めます。
→自動化できるか（PGが使えるか）は、常に考えたいところ。
「全てを自動化する/しない」のような極端な計画を立てるのではなく、「部分的に効果のあると思われるところを、手始めに自動化してみます」程度のほんのり自動化戦術でいくのが現実的なところ
→これは感覚的にわかる。

テスト種別【重要】

私が、タタキとしてよく使うテスト種別は、こんな感じのものです。
→種別が沢山ある：ソースコード、画面、機能、権限、CSRF、XSS
　→レンダリングエンジンについて確認しておく。
→クロスブラウザ、シナリオ、負荷、障害、他システムとの連携
　→シナリオテストは。画面遷移図を踏まえた上で、ケースを書くべきだった。


テスト工程における成果物も、このテスト種別に合わせて決めるようにしましょう。
→こういう事を提案できないとだめだね。

「結合テスト設計書」や「結合テストケース」なる成果物なんてナイのです
→なるほど。