はじめに
2019/07/18に、BizReach QA Meetupというイベントに参加しました。
（イベントの参加レポートはこちら）
そのイベントで、ブロッコリーさんという方が、自分が開催した新人向け研修の内容を発表しており、それを聞いて私は「この研修、自分も受けてみたい！」と思いました。
受けてみたいと思ったポイントは、2日間でテストに関する知識を体系的に学べそうだなと思った点です。しかし実際にその研修を受けるわけにもいかない。じゃあ自分で調べてみるか！と思い立って書いたのがこの記事です。
基本的にはブロッコリーさんのスライドに書いてあるカリキュラムに沿っていろいろ調べています。しかし、私はあくまでテストについて知りたかったので、以下については割愛しています。
・モブワーク
・ソフトスキル
・見やすいコード
・クラス設計
・読みやすいコード
・テストケース名の大切さ
・レガシーコード
・リファクタリング
・Code Smell
・TDD
TDDはテストというよりはプログラムの設計手法と私は解釈しているので、これについては書いていません。
当記事で取り上げた一つ一つの項目について、それぞれを深く解説しているサイトはよく見るのですが、全体を説明しているサイトはあまり見かけなかったので、広く浅くのイメージで当記事を書いています。深く知りたい方は項目ごとに参考資料へのリンクをつけていますのでそちらを参照してください。
本題
ここからが本題です。
品質とは
言われてみれば、品質ってなんですかね？
バグがないこと（少ないこと）でしょうか・・・？
偉い人たちはこんな風に考えるらしいです。
ソフトウェア工学の分野で名高い人たちも、「品質」とは何かについて述べています。
・クロスビー氏(Philip B. Crosby)の定義：
品質は「要求」に対する適合である
・ワンバーグ氏(Gerald M. Weinberg)の定義：
品質は誰かにとっての価値である
・ケイパース氏(Capers Jones)の定義：
ソフトウェアを完全に停止させたり、容認できないような結果を出す欠陥が全くないこと
・バリー氏(Barry W. Boehm)の定義：
顧客満足度、移植性、保守性、強度、そして使いやすさが高いレベルで達成されていること
・ワッツ氏(Watts S. Humphrey)の定義：
使いやすさ、要求への適合度、信頼性、保守性において、卓越したレベルを達成すること
これを見ていて思ったことがあります。ソフトウェア開発で品質というと、私はまずテストを最初に連想します。しかし、テストというのはあくまで品質を確認するための手段の一つにすぎないのかなと思いました。
ソフトウェア開発活動全体（管理、要件定義～テスト）が品質活動そのもので、テストはその中のあくまで一つ。作ったものが要求を満たしているか確認する手段の一つに過ぎないのかなと。
参考資料
・品質を見直そう(1) 品質とは
・外部品質、内部品質とは？ソフトウェア品質特性について
http://www.rsch.tuis.ac.jp/~tamaki/software_engineering/Chap_05.pdf
※リンク切れ
テストの目的
テスト技術者資格制度の資料では、テストには以下のような目的があるとされています。
目的１：欠陥を摘出する。
開発でのテスト(コンポーネントテスト、統合テスト、システムテストなど)では、なるべく多くの故障をたたきだし、ソフトウェア中の欠陥を特定して修正することを主目的とする。
目的２：対象ソフトウェアの品質レベルが十分であることを確認する。
受け入れテストの場合、システムが期待通りに動作し、要件に合致することの確認が目的となる。
運用テストでは信頼性や可用性などのシステム特性をチェックするのが主目的である。
目的３：意志決定のための情報を示す。
また、別のケースでは、ソフトウェアの品質をチェックし(欠陥の修正は目的とはしない)、所定の時期にソフトウェアをリリースすればどんなリスクがあるかという情報をステークホルダ(利害関係者)に提供することもある。
目的４：欠陥の作りこみを防ぐ。
保守テストでは、ソフトウェアの変更時に、新たに欠陥が混入していないかチェックするテストも実施することが多い。
参考資料
・テスト技術者資格制度 Foundation Level シラバス 日本語版
・テストエンジニアが教える JUnitを書き始める前に考えるべきテスト
テストの7原則
テストの7原則とは？
テストの7原則とは、JSTQB（日本ソフトウェアテスト資格認定委員会）と言うソフトウェアテストに関する組織で規定されているものです。
これまで50年以上にわたり、ソフトウェアのテストに関する様々な原則が提唱されてきました。それらをガイドラインとして規定したものです。ソフトウェアのテストに関するこれまでの叡智の結晶と言ってよいものと思っています。
実際の内容
各原則の名前と概要を以下に記載します。
詳しい記載はJSTQBのシラバスの「1.3 テストの 7 原則」を参照してください。
原則1.テストは欠陥があることは示せるが、欠陥がないことは示せない
テストを実施してバグが発生した部分には確かにバグがあったということは示せる。
しかし、いくらテストをしてもバグがない事は示せないという話です。
悪魔の証明に似ていると思います。
原則2.全数テストは不可能
すべてのパターンを網羅的にテストすることは、テストケース数が膨大な量になり非現実的という話です。（単純なソフトウェアを除く）
リスクを考慮して適切なテスト技法を選択しましょう。
原則3.早期テストで時間とコストを節約
バグを検知するタイミングが、ソフトウェア開発工程の前工程であればあるほどテストにかかる時間を低減できます。
原則4.欠陥の偏在
バグはシステムの全体に均等に散らばっているのではなく、特定の少数のモジュールに集中しています。
原則5.殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと新しい欠陥を見つけられなくなります。
同じ殺虫剤を繰返し使用すると耐性ができて効果が低減するのに似ているのでこの名前になっています。
原則6.テストは状況次第
状況が異なればテストの方法も変わります。
安全性が重要な医療系のソフトウェアとECサイトではテストの方法が異なります。
アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なります。
原則7.「バグゼロ」の落とし穴
原則1と原則2の話もありますが、それだけではありません。
大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。
例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
参考資料
・JSTQBのシラバス
⇒1.3 テストの 7 原則
・7つの原則を一つ一つ丁寧に考察しているブログ（秋山さんのブログです）
原則１：テストは欠陥があることは示せるが、欠陥がないことは示せない
原則２：全数テストは不可能
原則３：早期テストで時間とコストを節約
原則４：欠陥の偏在
原則５：殺虫剤のパラドックスにご用心
原則６：テストは状況次第
原則７：「バグゼロ」の落とし穴
・最近の事例から考察した記事
7payの会見から学ぶソフトウェアテストの7原則
基礎知識としてこのあたりが参考になると思います。
・テスト担当者なら絶対に覚えておきたい『ソフトウェアテストの7原則』
・ソフトウェアテストの7原則について経験と照らし合わせて考えてみる
・システムテストの観点と七原則
・ソフトウェアテストの基礎：ソフトウェアテストの7原則
Vモデル、Wモデル
Vモデル
下図のように、ウォーターフォールモデルの工程を、開発工程とテスト工程を横に並べたものです。
Vモデルの利点
V モデルとは、開発工程とテスト工程の対応関係をはっきりと表したモデルのため、各工程で何のテストを行うかが分かりやすいという利点があります。開発工程とテスト工程の対応関係が曖昧な場合、テストによる品質の保証が難しいため、ソフトウェア開発を行う場合は開発工程とテスト工程を明確にしておくことが重要です。そうすることで、どの段階でどの部分を、どれくらいの細かさでテストするのかが明確になり、テスト工程をよりスムースに進めることができるのです。
Wモデル
W字モデルは、開発の上流工程からテスト設計を開始し、開発プロセスとテストプロセスを同時併行に進めるプロセスモデルです。
Wモデルの利点
伝統的なソフトウェア開発ではソフトウェアテストを、要求－設計－実装などの開発作業が終了した後に行うものと規定し、開発プロセスとテストプロセスの関係はVモデルの形で考えてきた。しかし、同時に誤りやバグを持ち越して後工程で修正するのは大幅なコスト高となるため、早期にデバッグすべきだという指摘も古くからなされていた。
この問題を解決する方法として、テスト計画とテスト設計を上流工程に移して、要求定義や設計工程、実装工程と同時に行うプロセスが提案された。V字型の開発プロセスと並行にV字型のテストプロセスを配置した図で示されることから「Wモデル」という。
テストの7原則の原則3を狙ったものなんだと思っています。
参考資料
・テストはいつ行っているの？ソフトウェア開発の流れとテスト工程
・Wモデル（だぶりゅーもでる）
・W字モデルとは？
テスト観点
テスト観点とは？
「テスト観点」はJSTQBの用語集には出てこない用語です。VSTePにちょっと出てきたのでこれを抜粋。
この「何をテストすればいいか」を“テスト観点” と呼ぶ
大まかにはわかりますけどちょっと大まかすぎますね・・・。
もうちょっと具体的に知りたいと思ったので探してみたら、このサイトで以下のような説明を見つけました。
ソフトウェアのテスト観点とは、ソフトウェアが正しく動作するかを確認するための項目、着眼点、発想の仕方といった、いわばテストを行う上での「切り口」のようなものです。
～中略～
また、テスト観点は画面単位での確認項目だけでなく、同時にたくさんの処理を行った場合に誤動作を起こしたり、処理速度が著しく遅くならないかといった、システム全体に関わるテスト観点もあります。
このサイトの図を抜粋
テスト観点をどうやって洗い出すのか？
先ほどの説明でテスト観点というものはちょっとわかった気がします。しかし、これらの観点をどうやったら漏れなく洗い出せるのでしょうか？
一つ参考になりそうなものを見つけましたので抜粋してみます。
高信頼化ソフトウェアのための開発手法ガイドブック
⇒6.2 テスト観点とテストアーキテクチャ設計
テスト観点の 4 つのタイプ
代表企業10社のテストの現状を分析した結果、テスト観点は以下4つのタイプに分類できるようです。
テスト観点1：基本構造を組み立てるもの
「～する」という動詞で表現されるものでソフトウェアに対する「入力トリガー」から見つけ出します。具体的には「登録する」、「照会する」、「検索する」などを探します。テスト観点 1 は、機能そのものにあたります。
テスト観点2：基本構造から派生構造を作り出すもの
テストデータや機能のバリエーションを増やすために、それらを修飾する形容詞や副詞で表現されるものです。ソフトウェアの「異常を誘発するための要因」を挙げます。例えば「大量の・少量の」、「連続して・飛び飛びに」、「素早く・ゆっくりと」、「超過して・不足して」といったものがテスト観点 2 にあたります。
テスト観点3：組み合わせ
「集合、関係、組み合わせ」を示すものです。このテスト観点は、ソフトウェアというよりもシステム全体としてのテスト観点となります。例としては、「エンド・ツー・エンド型で」、「同時に組み合わせて」、「連結・連動中に」などです。
テスト観点4：期待結果の網羅性の観点
「どうなる」という期待結果の属性を表すものです。テスト観点 1、2、3 は、見つけ出したテスト観点自体をさらに整理・分解してテストを詳細化することが可能です。例えば「登録する」という観点に対して、様々な登録方法を見つけることで分解することができます。
ところがテスト観点4 は結果系の観点なので、例えば「出力の読みやすさ」という観点を見つけたときに、それを「文字の大きさ」、「文字の種類」、「文字の配置」と分解してもそこから直接にテスト設計することはできません。
資料の151 pageより抜粋
この分類を意識しながらテスト対象のシステムではどんな観点が必要なのかを洗い出していくイメージですかね。
しかし抽象的ですね・・・。
もう少し具体的なところが知りたかったので調べていたところ、VSTePの資料に記載がありました。
http://qualab.jp/materials/VSTeP.130510.color.pdf
⇒「NGT: テスト観点とは何か」(23 page)より
テストには、様々な「観点」が必要だと言われている
– 例）Ostrandの4つのビュー
» ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー
– 例）Myersの14のシステムテスト・カテゴリ
» ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回復、操作性、セキュリティ、サービス性、文書、手続き
– 例）ISO/IEC 9126(ISO/IEC 25000s)の品質特性
» 機能性、信頼性、使用性、効率性、保守性、移植性
テスト観点とは、テスト対象のテストすべき側面や、テスト対象の範囲やつくり、テスト対象が達成すべき性質である
これをもうちょっと掘ってみました。
Ostrandの4つのビュー
「User-view（ユーザー視点）」、「Spec-view（仕様視点）」、「Fault-view（バグ視点）」、「Design-view（設計・実装視点）」
例えば、データ登録機能のテストを行う場合。
**User-view（ユーザー視点）**では、実際のユーザーの動きを想定した、正しいデータの入力をした場合、間違ったデータを入力した場合などをテストします。
**Spec-view（仕様視点）**では、求められている仕様をきちんと満たしているか、正しい動きをするのかをテストします。
**Fault-view（バグ視点）**では、入力途中で通信が切れた場合や、異なる形式のデータが送られてきた場合など、考えられるバグや、わざとバグが起こりそうなことをテストします。
**Design-view（設計・実装視点）**では、設計の構造自体にバグはないか、動作していても脆弱な実装になっていないか、などをテストします。
Myersの14のシステムテスト・カテゴリ
ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回復、操作性、セキュリティ、サービス性、文書、手続き
(VSTePの資料より)
ソフトウェア・テストの技法 第2版という、Myersさんが書いた本の 128 page ～138 page にも、システムテスト・カテゴリについて記載があったので抜粋してみました。この本では15個に分類されているけど多分同じものだと思います。
この本では、以下15の観点をテスト設計の際に調べる必要があるとされています。
（「システムテストの目的は、そのプログラムが目的仕様にあっていないことを示すこと」というスタンスで書かれています）
1. 機能部分テスト(facility testing)
仕様書に書かれていることが満たされているかを調べるもの。
2. 大容量テスト(volume testing)
プログラムに大量データを扱わせるテスト。
大容量テストの目的は、プログラムがその目的仕様書で指定されたデータ量を扱うことができないことを示すこと。
3. ストレステスト(stress testing)
プログラムに重い負荷または力を書けるテスト。重い負荷とは、短い時間に最大容量のデータ。
4. 有用度テスト(usability testing)
- 各ユーザ・インタフェイスは、エンド・ユーザの知識・教育的背景・環境面からの圧力にあわせて作られているか
- プログラムの出力は意味のあるもので、濫用されず。”コンピュータのちんぷんかんぷんなおしゃべり”を避けた、等々のものであるか。
- エラー診断書（たとえばエラー・メッセージ）は、単刀直入であること。
- ユーザ・インタフェイスの全セットは、すべてかなりの”概念上の統一性”をしめているか。そこに存在する一貫性と、構文・規約・意味・形式・スタイル・略号の統一など
- 正確さが重要であるところ（たとえば、オンライン銀行システム）で、入力に十分な冗長性をもたせてあるか
- システムは、過度にオプションや使われそうにないオプションを含んでいないか。
- システムは、すべての入力に対してある種の即答を返しているか
- プログラムは使いやすいか。
5. 秘密保護テスト(security testing)
秘密保護テストは、プログラムの秘密保護に対するチェックをくつがえすテスト・ケースを準備する過程。
6. 効率テスト(performance testing)
ある実働負荷と構成条件のもとでの応答時間や出力処理といった性質がその効率目標を示さないことを示すようなものでなければならない。
7. 記憶域テスト(storage testing)
場合のよっては、プログラムは記憶域についての目的使用が定められている。たとえば、プログラムで使用する主記憶域と2次記憶の量と、必要な一時的なファイルの大きさについてである。テスト・ケースは、このような記憶域の目的仕様がみたされていないことをしめすようなものである。
8. 構成テスト(configuration testing)
オペレーティング・システム、データ・ベース管理システム、メッセージ交換プログラムと言ったものは、いろいろな種類のハードウェア構成をサポートしている。可能な構成の組合せがあまりにも多くて、それぞれについてプログラムをテストすることができないことがあるが、少なくとも各型式のハードウェア機器と最小・最大に構成でプログラムをテストしなければならない。
9. 互換性／構成／変換テスト(conpatibility/configuration/conversion testing)
開発されるプログラムの大部分は、完全に新規なものは少ない。これらは、不十分なシステムに対する書き換えであることが多い。そんな場合、プログラムは、既存のシステムとの互換性と変換手順にかんする目的仕様をもつことが多い。この場合も、これらの目的でプログラムをテストするときは、テスト・ケースの方針は、互換性を持つという目標が満たされていないこと、変換手順が働かないことをしめすことである。
10. 設置テスト(installability testing)
ある種のソフトウェア・システムでは、複雑な導入手順がいる。導入手順をテストすることはシステムテストの過程では重要な部分である。
11. 信頼性テスト(reliability testing)
プログラムの目的仕様書に、信頼性について特別な記述があれば、特別な信頼性テストが行われる。
12. 回復テスト(recovery testing)
プログラミング・エラー、ハードウェアの故障、データ・エラーからどのようにシステムを回復させるかについて述べたもの。システム・テストの1つの目的は、これらの回復機能が正しく働かないことをしめすことである。
13. サービス性テスト(serviceability testing)
プログラムは、サービス性つまり保守能力の性質についても目的仕様をもっている。この種の目的仕様もすべてテストしなければならない。
・このシステムによってもたらされるほじょサービス機能（たとえば、記憶域のダンプ・プログラム、診断プログラム）
・あるはっきりした問題をデバッグするための平均時間、維持のための手続
・内部文書の文書の質
など
14. 文書テスト(documentation testing)
システム・テストは、ユーザの書いた文書の正確さも調べる。これを行う基本的な方法は、ユーザ文書を、これまで述べてきた1～13のシステム・テスト・ケースの表現を決めるのに使うことである。たとえば、あるストレス・テストをおこなうとき、ユーザ文書をそのテスト・ケースを書くための指針として使う。
15. 手続きテスト(procedure testing)
多くのプログラムは、人手による手続きをふくんだ、大きな完全には自動化されないシステムの一部分になっている。たとえば、データベース管理者は、データベース・システムのバックアップと復元のための操作を文書化すべきである。もし、可能なら、そのデータベースの管理に関係しない人物がその操作をテストすべきである。
ISO/IEC 9126(ISO/IEC 25000s)の品質特性
次の「品質特性」の章参照。
参考資料
・テスト観点とは
・ソフトウェアテストの知恵袋
・テスト観点～概要と具体的な観点～
・ソフトウェア・テストの技法 第2版
・テスト観点に基づくテスト開発方法論 VSTePの概要
・高信頼化ソフトウェアのための開発手法ガイドブック
品質特性
品質特性とは、ISO/IEC 9126（ソフトウェア製品の評価 品質特性とその適用に関するガイドライン）という規格で定義されている、ソフトウェアの品質の指標を分類して体系的にまとめたものです。機能性・信頼性・使用性・効率性・保守性・移植性の6つの品質特性があり、さらにその中で合計21の副特性に細分化されます。
6つの品質特性
| 品質特性 | 説明 |
|---|---|
| 機能性 (functionality) |
ソフトウェアを指定された条件のもとで動作するとき、要求されている仕様を満たす能力のこと。 |
| 信頼性 (Reliability) |
ソフトウェアを指定された条件のもとで動作するとき、達成水準を維持し続ける能力のこと。誤作動時の復旧や、障害に対する許容性をあらわす場合もある。 |
| 使用性 (Usability) |
ソフトウェアを指定された条件のもとで動作するとき、利用者が理解、習得、利用がスムーズにおこなえる能力こと。いわゆる「使い勝手」や「使いやすさ」、「操作性」のこと。 |
| 効率性 (Efficiency) |
与えられたリソースに対して、適切な性能を発揮する能力のこと。たとえば、決められた処理時間の中でいかに早く、数多くの処理ができるか、などがあります。 |
| 保守性 (Maintainability) |
できたソフトウェアの修正のしやすさの能力のこと。作った本人しか理解できないプログラムでは、改修が発生した際に多くのコストがかかってしまいます。これは利用者には直接は関係しない特性のように見えますが、最終的なサービスリリースまでにかかるコストの軽減は、利用者へのメリットにつながることが多くあります。 |
| 移植性 (Portability) |
別な環境へ移すことになった際に、容易に移せる能力のこと。サーバーの移行や、使うフレームワークが変更になった場合などに重要になってくる。 |
品質副特性
機能性(functionality)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 合目的性 (suitability) |
ソフトウェアがユーザの目的に合致している機能を提供するか | 預金者が過去１年間の取引内容を照会できること。 |
| 正確性 (accuracy) |
ソフトウェアが必要な正確さで結果をもたらす能力を表します。 画面や帳票でユーザに提供する計算結果が正しいだけでなく、必要とされる精度で計算されているかも含まれます。 | 取引金額の計算は、1 円未満切り捨てで計算すること。 |
| 相互運用性 (interoperability) |
相互接続性や、そのままインターオペラビリティと呼ばれることもあり、ソフトウェアが指定された他のシステムとやりとりをできる能力を表します。 非機能要求としては、データ転送や処理の依頼など他システムとの必要なやりとりが示されます。 相互接続では、Web サービスなど取り決められた通信プロトコルで直接やりとりをするのから、DAT などのメディアを介してやりとりするのまで考えられますが、要求の実現方法が選択できる場合は要求では指定しません。 | 外部の決済システムと Web サービスを介して、必要な決済ができること。 |
| 機密性 (security) |
ソフトウェアが関係のない人に使用されたり、機能を実行する権限のない人に実行されたりしない能力を表します。 非機能要求としては、必要なセキュリティポリシーやセキュリティ強度が示されます。 インターネットを使ったシステムが多くなり、最近は特に要求が厳しくなっています。 | ・預金者本人以外が、口座の情報や取引履歴を参照できないこと。 ・運用担当者が、DB に保管されている情報を参照して預金者を識別できないこと。 |
| 標準適合性 (compliance) |
機能性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 | - |
信頼性(Reliability)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 成熟性 (maturity) |
障害が発生した時にソフトウェアが故障 (機能停止) しない能力を表します。 非機能要求では、単位として MTBF (平均故障間隔) が多く用いられます。 MTBF は、故障から次の故障までの時間を表します。 | MTBF は、8000 時間以上であること。 |
| 障害許容性 (fault tolerance) |
障害が起きてもソフトウェアが機能を提供し続ける能力を表します。 フェールセーフ機能も含まれます。 | 各コンポーネントは多重化され、いずれかのコンポーネントに障害が起きてもサービスを 24 時間提供できること。 |
| 回復性 (recoverability) |
障害が発生した後にソフトウェアの機能が正常に復帰する能力を表します。 非機能要求では、MTTR (平均復旧時間) が多く用いられます。 MTTR は、1 回の修理にかかる平均時間です。 | DB との接続エラーが発生した場合、再接続し 10 分以内に復帰すること。 |
| 標準適合性 (compliance) |
信頼性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 信頼性に関する適法性は、ソフトウェアだけでなく、システム全体としてセキュリティもあわせて策定された業界標準が多くあります。 例は、「品質副特性：セキュリティ」の例を参照してください。 | - |
使用性(Usability)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 理解性 (understandability) |
ソフトウェアの使用法をユーザが理解しやすいかを表します。 | ・パソコンやインターネットの初心者である預金者が理解できること。 ・社内標準ソフトである経費管理システムと同じ操作性であること。 |
| 習得性 (learnability) |
ユーザがソフトウェアの使い方を学習しやすいかを表します。 | ユーザが学習しやすいように、チュートリアルを提供すること。 |
| 運用性 (operability) |
ユーザがソフトウェアを使う時のユーザインターフェイスの使いやすさを表します。 | ・ユーザの作業の順序にあわせて、次に必要な機能が連続して実行できること。 ・ユーザが中止したい時にいつでも実行を中止できること。 ・すべてのメニューおよびツールバーに、ツールチップで短い説明を表示すること。 |
| 魅力性 (attractiveness) |
ソフトウェアがユーザにとって魅力があるかを表します。 ユーザを引きつけるような画面の色彩や特異なユーザインターフェイスなどの要求が含まれます。 | ユーザインターフェイスのスキンが定義でき、ユーザが自由に取り替えられること。 |
| 標準適合性 (compliance) |
使用性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 この非機能要求には、ウインドウシステムや GUI のスタイルガイドが含まれます。 | GUI は、サン・マイクロシステムズの「Java Look and Feel Design Guidelines 2nd Edition」に準拠していること。 |
効率性(Efficiency)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 時間効率性 (time behaviour) |
指定された条件下で、ソフトウェアが適切な応答時間、処理時間、スループットで機能を実行する能力を表します。 | ・注文の確定は、ユーザが選択してから 10 秒以内で完了すること。 ・外部の決済システムへのデータ転送は、20 分以内に終了すること。 |
| 資源効率性 (resource behaviour) |
指定された条件下で、ソフトウェアがメモリやハードディスクなどのコンピュータ資源を適切に利用しているかを表します。 | 最大でもメモリ 32M バイト、HDD 128M バイトまで有効に使用すること。 |
| 標準適合性 (compliance) |
効率性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 | - |
保守性(Maintainability)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 解析性 (analyzability) |
ソフトウェアに障害が発生した時に、その原因を判別し、修正の必要な箇所を特定しやすいかを表します。 | ・運用者に対して障害監視機能を提供すること。 ・アプリケーションサーバや DBMS の障害エラー、プログラムの例外を稼働ログに残し、障害の内容や箇所が特定できること。 |
| 変更性 (changeability) |
稼働後の変更要求など、やらなければならない修正をソフトウェアにできるかを表します。 修正内容は未知ですので、ソフトウェアが変更を受け入れられるようなプログラミング言語、構造、アーキテクチャになっていることが要求されます。 | ・コンポーネントベースで実現され、修正にかかるコストおよび期間が現行システムの 70% 以下であること。 ・技術者の多い Java で記述されること。 |
| 安定性 (stability) |
ソフトウェアを修正した時に、影響が予想外の箇所に及ばないことを表します。 | コンポーネントベースで実現され、コンポーネントの修正が他のコンポーネントに及ぼす影響が最小限であること。 |
| 試験性 (testability) |
ソフトウェアを修正した時にテストがしやすいかを表します。 | 市販あるいはオープンソースのテスティングツールで、システムテストを自動化できること。 |
| 標準適合性 (compliance) |
保守性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 保守性に関する適法性は、ベンダーからの開発者向けのガイドラインが要求されるケースが多いです。 | マイクロソフト「ASP ガイドライン」の保守性に関するガイドラインに準拠していること。 |
移植性(Portability)の品質副特性
| 品質副特性 | 説明 | 例 |
|---|---|---|
| 環境適応性 (adaptability) |
ソフトウェアを別の環境へ移す時の手間を表します。 | リコンパイル無しに Windows から Linux へ移行できること。 |
| 設置性 (installability) |
ソフトウェアを指定された環境へインストールする時のやりやすさを表します。 | ・クライアントソフトウェアは、顧客自身がインストールできるように、専用の対話型インストーラを用意すること。 ・サーバソフトウェアは、運用担当者が 3 時間以内にインストールできること。 |
| 共存性 (co-existence) |
ソフトウェアを同じ環境で他のソフトウェアと共存できることを表します。 後から他のソフトをインストールしたために正常に動かないということは、みなさんもご経験があると思います。 | MS Office2003 のインストールされた環境で、共に正常に稼働すること。 |
| 置換性 (replaceability) |
互換性と呼ばれることもあり、同じ環境で、同じ目的を持った他のソフトウェアと置き換えられる能力を表します。 「品質副特性：インストールのしやすさ」とよく似ていますが、古いバージョンや他の製品とそのソフトウェアを置き換える場合の要求である点が異なります。 | ・古いバージョンをアンインストールせずに新しいバージョンをインストールできること。 ・Ａ社の製品ａと置き換えられ、製品ａのデータファイルをそのまま読み書きできること。 |
| 標準適合性 (compliance) |
可搬性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 可搬性に関するガイドラインは、例 39 や例 40のように稼働環境である OS などのベンダーで用意されている場合があります。 | ・マイクロソフトの「Windows Server 2003 アプリケーション仕様書」に準拠し、Certified for Windows ロゴを取得できること。 ・ソフトウェアは、サン・マイクロシステムズの「100% Pure Java Cookbook」に準拠し、100 % Pure Java ロゴを取得できること。 |
参考資料
このサイトがわかりやすいかな
・非機能要求とISO9126
・ソフトウェアの品質特性モデル JIS X 0129-1(ISO/IEC9126)
・外部品質、内部品質とは？ソフトウェア品質特性について
・ソフトウェアの品質
テストレベル
JSTQBの用語集での定義：
テストレベル（test level）： 系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
・・・ソフトウェア開発の工程と捉えればだいたい合ってそうだけど、コンポーネントテスト？ってなんだ？？
JSTQBの用語集での定義：
コンポーネントテスト（component testing）： 個々のソフトウェアコンポーネントのテスト。
・・・よくわからん。
このサイトによると、「JSTQBでは単体テストはコンポーネントテストに含まれる。」らしい。へー。
このサイトでは、「分離してテストが可能な単位の欠陥を摘出し、正しく作動することを検証するテスト。」とあります。
あまり深く考えずにクラス単体テストと捉えればいいんですかね。
参考資料
・JSTQBの用語集
※上のJSTQBの用語集はバージョンあがるとリンク切れるので、大もとのサイトのリンクも張っておきます。
http://jstqb.jp/syllabus.html#glossary_download
・ソフトウェアテストの種類とは？テストレベル別にテスト対象、実施内容を解説
・２．ソフトウェアライフサイクルを通じてのテスト（２）
・2.2.1 コンポーネントテスト
・JSTQB 2章 ソフトウェアサイクルを通じてのテスト
・コンポーネントテスト
Checking と Testing
Checking と Testingについては、あなたがやっているのはテスティングかチェッキングか？というサイトでは以下のように説明されています。
チェッキング（チェックすること）とは、すでにある信念を確認するという動機から実施するものです。チェッキングは確認、検証、妥当性確認というプロセスになります。すでにそれが正しいと信じているときに、チェッキングによってその信念を確認します。コードを変更してもこれまで同じようにすべて動作することを確かめたいときに、私たちはチェックします。
テスティング（テストすること）とは、新しい情報を見つけるという動機から実施するものです。テスティングは探索、発見、究明、学習というプロセスになります。評価するつもりで、あるいは想定外の問題を見つけるつもりで、製品を設定して、動かし、観察するときに、私たちはテストします。
Michael Boltonという方のブログでは以下のように書かれています。
Checking is something that we do
with the motivation of confirming
existing beliefs
• Checking is a process of
confirmation, verification,
and validation. When we already believe
something to be true, we verify our belief by
checking
• Checking is a highly automatable process
Checking Is Confirmation
Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking. We check when we’ve made a change to the code and we want to make sure that everything that worked before still works. When we have an assumption that’s important, we check to make sure the assumption holds. Excellent programmers do a lot of checking as they write and modify their code, creating automated routines that they run frequently to check to make sure that the code hasn’t broken. Checking is focused on making sure that the program doesn’t fail.
Testing Is Exploration and Learning
Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. We’re testing when we’re trying to find out about the extents and limitations of the product and its design, and when we’re largely driven by questions that haven’t been answered or even asked before. As James Bach and I say in our Rapid Software Testing classes, testing is focused on “learning sufficiently everything that matters about how the program works and about how it might not work.”
自分の理解
・Checking：既存の振る舞いを壊していないか、仕様通りの動きをしているかを確認する。
自動テストで自動化できそうな範囲のもの。
・Testing：・・・正直よくわからん。探索的テストをイメージしたけどそういうことでいいのか？
ちょっとググってたら、このページで和田さんがソフトウェアテストの技法を元にTestingについて説明していた（TestingとChecking（和田さん）のところ）。
【Myersの14のシステムテスト・カテゴリ】のところでも書きましたが、ソフトウェア・テストの技法 第2版という本は持っているので本棚から引っ張り出してみた。(6 page)
プログラムをテストするときは、そのプログラムになんらかの価値を付加することになる。テストによって価値を付加するとは、プログラムの品質・信頼性を向上させることである。プログラムの信頼性を向上させるとは、エラーをみつけ、それをとりのぞくことである。
だから、テストとは、プログラムが作動することをしめすものではなく、むしろ、プログラムはエラーを含んでいるという仮定のもとでテストをはじめるべきである。そして、できるかぎり多くのエラーをみつけるためにプログラムをテストするのである。
テストとは、エラーをみつけるつもりでプログラムを実行する過程である。
参考資料
・プログラマーも手動テストしようぜ 〜 忍者式テストのすすめ 〜
・テスト、設計、自動化と。
・ソフトウェア・テストの技法 第2版
・『クックパッドにおけるテストエンジニアのあり方』参加レポート
・Blog: Testing vs. Checking
・あなたがやっているのはテスティングかチェッキングか？
Validation と Verification（勝手に追加）
ブロッコリーさんの資料にはない項目ですが、Checking と Testing の中で出てきたので勝手に追加しました。
ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践という本では以下のように記載されています。(10page)
Verification（検証）
開発仕様書（ソフトウェアの設計図）のとおりにソフトウェアが作成されているかを確認することです。Verificationを行う場合は、ソフトウェアを実際に動作させます。開発仕様書は開発工程ごとに作成されるので、Verificationも開発工程毎に行います。
Validation（妥当性確認）
ユーザーの要求どおりにソフトウェアが作成されているかを確認することです。Validationでは、ソフトウェアを動作させるだけでなく、開発仕様書の妥当性チェックも行います。
～中略～
一般的に、開発者はソフトウェアを作るという立場上、開発仕様書を重視して製品を見ます。それに対してテスト担当者は、Verification and Validation の視点をもってテストを行うことが必要です。そのためにも、テスト対象のソフトウェアに対して、常に「ユーザーの要求は何か」、「ユーザーにとって問題にならないか」といった疑問を持つようにしましょう。
このブログでは以下のように説明されています。
２つの単語違いについてまとめます。
① "verify"
詳細なテストや調査によって、それが正しいかを検証すること
② "validate"
ある一定の規格・基準に沿っているか、顧客の要求に合っているかを検証すること
作った機械が正しく動くかテストをして検証するのは "verify" で、そのテスト方法が有効かも含めて一定の規格を満たしているかをチェックするのは "validate" になります。
"verify" は下流工程で、"validate" は上流工程で使われるというイメージで良いかと思います。
このサイトでの説明は以下の通り。
PMBOKガイド第5版に以下の様に名詞形で説明されている。
Verification (検証)
プロダクト、サービス、システムなどが規制、要求、仕様、指定された条件などに適合しているかどうかを評価するプロセス。内部プロセスである場合が多い。
Validation(妥当性確認)
プロダクト、サービス、システムなどが顧客や特定のステークホルダーのニーズを満たしているということを確認すること。外部顧客による受け入れと適合性に関連することが多い。
参考資料
・ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
・VerifyとValidateの違い （verification と validation）
・Verify(検証する)とValidate(妥当性確認する)
テスト設計の目的
テスト設計
目的の前に、そもそもテスト設計って何？と思ったので調べてみました。
ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践という本の 52pageでは以下のように記載されています。
テスト設計
そのテスト工程で実施すべきテストの種類や目的、テスト対象機能、使用するテスト技法、テストの入力・出力に何を使用するかなどを定める。また、テスト実施に必要な機材や合否判定基準などをより具体的に定める。
調べてる途中でテスト計画とごっちゃになって混乱したので一緒に整理。（同じ本より抜粋）
テスト計画
テスト工程の目的と範囲を明確にし、どのようなアプローチでテストするのかを検討する。テストに必要な設備や環境、人員といったリソースの調達やスケジュールなども定める。
JSTQBの用語集には以下のように記載されています。
テスト設計（test design）：
(1) test design specification を参照のこと。
(2) 概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。
テストケースを作成するプロセスをテスト設計と言っているみたいですね。
関連する用語も抜粋しておきます。
テスト設計仕様（test design specification）： テストアイテムのテスト条件（カバレッジアイテム）、詳細なテストアプローチ、及び、関連する高位レベルテストケースを記述したドキュメント。[After IEEE829] test specification も参照のこと。
テスト仕様書（test specification）： テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。
テストアイテム（test item）： テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。test object も参照のこと。
テスト対象（test object）： テストすべきコンポーネント又はシステム。test item も参照のこと。
テストアイテム（test item）： テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。test object も参照のこと。
テスト条件（test condition）： コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
カバレッジアイテム（coverage item）： テストカバレッジの基礎となる実体や属性。たとえば、同値分割やステートメント。
テストアプローチ（test approach）： 特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
テスト設計の目的
「テスト設計の目的」についてばしっ！っと答えてくれるものは中々見つからなかったが、これは参考になると思った。
ソフトウェアテストにまつわるよくある疑問 テスト設計をするってどういうこと？
⇒テストを設計することとは？
テストを設計することとは、テスト対象について書かれている仕様書や設計書から、テストケースをテスト目的に沿って抽出することです。抽出するためには、単純に右から左に流すのではなく様々な工夫が必要であり、それこそがテストにも設計が必要な理由となります。
テスト設計をする上で必要そうな考え
以前この記事に書いた、**【テスト対象となるシステムをどのように認識するか】**がテスト設計する上で必要な考えだと感じたので転記。
- ・目的－手段の階層構造、または目的－機能－手段の階層
- 構造で認識する 機能階層でシステムを表現する 要求工学のゴール指向アプローチでよく用いられる
- ・システム全体の能力をそれを構成する個々の部分の相互作用で認識する。
- 上位システムを下位システムの相互作用に分解し、その個々の下位システムをさらにその下位に分解していく。 機能は複数のサブ機能で構成されていると認識する 機能一覧表、機能階層図としてシステムを表現する
- ・データの流れ、データの変換過程として認識する
- システムを入力から出力への変換変換と認識する 複数ステップを踏んで変換する場合、データの流れとして認識する 通称「バケツリレー」と言う場合には、この見方をしている データフロー図でシステムを表現する
- ・刺激－反応のモデルとして認識する
- リクエスト－レスポンスするものとして認識する トリガーによって、どのような反応をするのかに興味がある 状態遷移でもイベントが関係するが、この刺激－反応モデルは、状態に関心を持っていない ユースケース仕様書などでシステムを表現する
- ・状態の変化として認識する
- 状態が変化するもの、遷移するものとして認識する 状態遷移図、状態遷移表としてシステムを表現する
- ・写像、関数として認識する
- 入力と出力の対応関係とみなす。 マトリクスを用いた表現が多い テスト技法の同値分割を使用する場合は、この見方をしている
- ・論理の集合として認識する
- ルールが集まったものとして認識する ビジネスルールの集合としてシステムを認識する デシジョンテーブルとしてシステムを表現する
- ・手順、手続き、イベントの連鎖として認識する
- データの流れとは異なり、イベントの連鎖や実行順序に関心がある ユースケース仕様書や、システムシナリオなどでシステムを表現する
- ・静的な構造として認識する
- クラス（補集合なし）、セット（補集合あり）としてシステムを表現する
参考資料
・ソフトウェアテストにまつわるよくある疑問 テスト設計をするってどういうこと？
・ゆもつよメソッドを語る夕べで語られたことまとめ
※自分の記事です
・ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
・JSTQBの用語集
テスト設計の紹介
これを解説しているサイトは腐るほどあると思うので、ここはリンクを張るだけにしておこうかと思います。
同値分割
境界値分析
・境界値分析（きょうかいちぶんせき）
・同値分割・境界値分析の解説
状態遷移
・より良いシステム開発のために、状態遷移設計のことを知ってほしい
・「状態遷移図」と「状態遷移表」で見えるもの
・テストを変える2つのコツ「状態遷移図」と「状態遷移表」
デシジョンテーブル
・デシジョンテーブルの解説
・仕様整理に「デシジョンテーブル」を使ってみよう
・入力データや入力条件の組み合わせを考える「デシジョンテーブルテスト」
CFD(Cause Flow Diagram)
・ソフトウェアテストの本質を振り返る の13 page目
・テスト技法「CFD」実践ワークショップ ワークショップの取り組み～ 現場での実践を目指して ～
・CFD法の流れ図の見つけ方
その他テスト設計
逆にこれだけだと物足りない気がしたので追加
テスト設計技法
このサイトのこの辺は押さえておきたい
・ホワイトボックステスト設計技法
- ステートメントテスト
- ブランチテスト
・経験ベースのテスト設計技法
- エラー推測
- 探索的テスト
カバレッジについて
・ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について
・ソフトウェアテストにおけるカバレッジ(C0/C1/C2)
・テストカバレッジの概念の紹介（C0/C1/C2）
とにかくいろんな手法を知りたければまずここから
・テスト設計技法を活用する
あとはこれも
・AppTest
- テスト設計技法の紹介(1)：技法の種類と分類
- テスト設計技法の紹介(2)：削減型・標的型のブラックボックス型技法
- テスト設計技法の紹介(3)：網羅型のブラックボックス型技法
参考資料
・ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
ハイレベルテストケースとローレベルテストケース
ソフトウェアテスト標準用語集より抜粋
高位レベルテストケース（high level test case）： 具体的な（実行レベルの）入力値や予測結果を使
わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった
状態にある。low level test case も参照のこと。
低位レベルテストケース（low level test case）： 入力データと期待結果が具体的（実装レベル）なテ
ストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き
36
換えられる。high level test case も参照のこと。
このサイトが具体例も一緒にかかれていてわかりやすいです。
・1.ハイレベルテストケースとローレベルテストケース
・3.ハイレベルテストケースの書き方と作り方
・テストケースの表現と粒度（マニアック編～ISTQB（JSTQB）の情報から考える）
何のために？
ローレベルテストケースはテスト実施のために必要なものだと推測できますが、ハイレベルテストケースはなんのためにあるのか？
テスト条件とは何かの解説ぽい記事が参考になると思います。
テスト観点からテストケースに落とすに当たって、いきなりローレベルテストケースを作ると、そもそもどういうことをテストしたいのかという点について認識相違が発生しやすいから一旦ハイレベルテストケースに落として認識を合わせてからローレベルテストケースに落としておきましょう。ってことですかね。
参考資料
・1.ハイレベルテストケースとローレベルテストケース
・3.ハイレベルテストケースの書き方と作り方
・テストケースの表現と粒度（マニアック編～ISTQB（JSTQB）の情報から考える）
・テスト条件とは何かの解説ぽい記事
・ソフトウェアテスト標準用語集
自動テストのピラミッド
以前読んだ初めての自動テスト ―Webシステムのための自動テスト基礎という本の中の説明をベースに書いてみます。
テストのピラミッド
| 層によるテストの分類 | 特徴 | メリット | デメリット |
|---|---|---|---|
| UIテスト | アプリケーションをUI層からテストする | UI～サービス～ロジックまで、システムをエンドツーエンドで動かすことができる。アーキテクチャのすべての層を通過し、すべてが繋がっていることを保障する。 | ・UIテストは遅く、不安定で壊れやすい傾向にある（不安定なテストについては後述）。 ・素早い反復型の開発において他の何よりも重要である「フィードバックとスピード」にUIテストは適していない(P85) ・UIテストは「何らかの問題がある」ことを見つけるのには適していますが、「どこに問題があるか」について明らかにするのには全く向いていません。(P86) |
| 統合テスト | UIを通過せず、一層下にあるサービス層をテストする。（WebサービスとAPIのテスト） | ・複数の層がつながって動いていることを確認する機能を持ったまま、UIの壊れやすさにも影響されない強みを得ている。 ・統合テストはUIテストの堅牢性とユニットテストの機動性のバランスを取ってくれます(P55) |
・結合テストの唯一の欠点は、それほど詳細でない事です。「何か」が壊れていることはわかっても「どこ」が壊れているかまでは、わかりません。 |
| ユニットテスト | 正確さ、スピード、カバレッジにおいて頼りになるのはユニットテスト | ・ユニットテストは非常に高速で正確。また、失敗した時にはどの部分がうまくいかなかったのかを厳密に教えてくれます。 ・素早く反復を繰り返す開発では極めて重要な存在であり、ユニットテストを書かないということはあてずっぽうで開発を進めるような事です。 |
・このスピードと正確さに対する唯一の欠点は結合部分にあります。ユニットテストは「全体が繋がっているか」という観点では、見落としをすることがあります。 |
親指の法則 P10
- UIよりもユニットテストを優先すること。
- ユニットテストで埋められない部分を結合テストでカバーすること。
- UIテストは限定的に使うこと。
・新しいテストを追加するときには、常に「ユニットテストでカバーできないか」を最初に確認しよう。
・常に、テストをできる限りピラミッドの下の層に入れること。
・すべてを自動化しようとしないこと。代わりに、過不足なく自動化しよう。
アンチパターン：逆ピラミッド又はアイスクリームコーン P138
どうすればいいか？
不安定なテスト
信頼性を持ってテストできないテストのこと。 P140
100回のうち99回成功するようなテストは不安定なテスト。
このテストが時々失敗するとそのたびに手を止め、テストを再実行し、成功を祈る必要がある。
全くの時間の無駄でしょう。
不安定になるのはテストその者だけとは限りません。テストに関わる周辺のものすべてが不安定さの原因になります。
不安定なテスト⇒不安定なテスト結果
テスト結果が不安定になるのは、一般的にはテストのせいだけではありません。原因はどこにでもあります。
多くの場合、最も疑わしいのはテスト対象のシステムですし、もちろんテスト環境も怪しいものです。
その他にも可能性は考えられます。
不安定なテストに立ち向かうための3つの手法 P141, 142
・テストを書き直す
・テストをピラミッドの下の層へ移動させる
・価値のないテストとみなし、テストを止める
Google の言う Flaky Tests も不安定なテストのことだと思っています。
Flakyとその判別方法の解説
参考資料
・アジャイルテストの4象限とテスト自動化のピラミッド
・初めての自動テスト ―Webシステムのための自動テスト基礎
・Flakyとその判別方法の解説
自動テストの8原則
詳細はこちらを見て下さい。
テスト自動化研究会テスト自動化の8原則
1. 手動テストはなくならない
ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。
システムに対してはじめて実行されるテストはテストケース自体の成熟度の観点から、手動で実施したほうがテスト実行の品質が高いケースが多い。
また、自動化がうまく進行している機能テストの残り数％など、テストを自動化するコストとベネフィットが釣り合わないケースもある。これらの事情によって、手動で実施されるテストが無くなることはない。
2. 手動でおこなって効果のないテストを自動化しても無駄である
そもそも、テストプロセス（e.g.テスト分析、テスト設計、テスト実装、報告）、特にテスト分析、テスト設計が適切に行われていないテストは、優秀なテスターが手動でテストを実施したところで、テストに期待される動作の保証やバグの検出といった効果を発揮しない。いわんや、自動テストにおいておや、である。
3. 自動テストは書いたことしかテストしない
人間による手動テストは、テストケースの記述に対して驚くほど広範な要素を暗黙的にテストしている。これに対し、操作、合否判定を厳密に記述する必要がある自動テストにおいては、おのずと視野は「記述された様に」限定される。ユーザ名とパスワードを入力してログインする、といったテストが自動化されていたとして、その自動テストは仮にログイン画面に表示されているロゴが競合他社のものであったとしても、それに気づくことはない。
4. テスト自動化の効用はコスト削減だけではない
もし、テスト自動化によってなんらかのコストが削減できるとしたら、十分に成熟しているテストケースが既に存在しており、そのテストは今後何度も実行される予定があり、自動テストの開発を円滑に進めるための準備が完了している場合と、テストの手順が同じで、テストすべきデータが膨大に存在する場合の「テスト実行」のコストである。テスト自動化には、繰り返し型開発におけるセーフティネットとしての役割や、バグ修正日数の低減、影響範囲レビュープロセスの代替、といった、開発アクティビティへの効用も存在するため、冒頭にあげたひどく限定された局面を狙うより勝ち目があるかもしれない。
5. 自動テストシステムの開発は継続的におこなうものである
テスト自動化に関わる苦労を10とすると、自動テストシステムが完成するまでが3、残りの7は運用に関するコストである。テスト対象の変化への追従、テストケース、テストタイプ自体の追加、変更に対する適応、といった、今あるものが継続的に効果を発揮するための活動はもとより、自動テストのターンアラウンドタイムの向上、信頼性の向上、などなど、システムの価値を向上させていくための活動など、やるべきことは多岐に亘る。テスト自動化システムの提供はプロジェクトというよりサービスとしてとらえるべきである。
6. 自動化検討はプロジェクト初期から
自動化を考慮せず「出来上がってしまった」システムに対して自動テストを書いていくことは、よくあるテスト自動化エンジニアの苦行のひとつである。自動テストシステムがシステムをよりよく操作、判定できるように、ひいてはセーフティネットを最適なコストで構築するためにはシステム側で最初から検討して設計に織り込んでおく必要がある。また、繰り返し実行されるテストが予めわかっているなら、自動化を前提として、テスト計画を策定すれば効果的である。
7. 自動テストで新種のバグが見つかることは稀である
運用に乗った自動テストは基本的に「枯れた」テストケースを対象とするため、ほとんどの種類のバグはテストケースを枯らす過程、あるいは自動テストを実装する過程で既に人間によって発見されているはずである。多くの運用に乗った自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見することにある。ただし、手順が同じでデータの種類が膨大なテストを自動化する場合、ファジング、テストパターンを有機的に生成できるAPIレイヤのテスト、ブラウザやRDBなどのバージョンアップの影響を受けていないことを確認するテストなど、いくつかの例外もある。
8. テスト結果分析という新たなタスクが生まれる
マニュアルテストでバグが発見された場合、その再現手順は明らかであるから人間はある程度の最適化ののち、即座にバグ登録を行う。しかし、自動テストがFAILEDを出してきた場合、何が起きたのかを改めて人間が確認する必要がある。これが1日数件ならまだかわいいものであるが、自動テストが無事？拡大した結果、数万件のテストケースに対して数千件のFAILEDが検出されたとしよう。それを種類ごとに仕分ける作業だけでも憂鬱である。自動テストが拡大した結果、テスト結果分析のコストがそれに伴ってリニアに伸びないような施策、例えばコールスタックやAPIコール履歴などから、ある程度自動的にFAILEDを仕分ける機構などを検討する必要がある。
参考資料
・開発者としての「テスト自動化」の基礎
・テスト自動化研究会
E2Eテストとは
E2Eというのは、「End to End（エンドツーエンド）」の略で、「端から端までテストしましょう」という意味です。
Webサイトならブラウザを操作して行うテストのことですね。
自動テストのピラミッドのところで書いた通り、壊れやすいなどのデメリットがあります。
JJUG CCC 2019 Spring の発表で「品質と自動化コストの損益分岐点みたいなものが存在するはずだからそれを見極める必要がある」ということを言っている発表があった。（資料はこちら）こういう考え方が必要なんだと思う。コストなどのデメリットをちゃんと把握した上で自動化する／しないを見極めるという考え方。
[JJUGの発表資料](https://www.slideshare.net/DaikiKawanuma/sicicd)より抜粋
参考資料
・E2Eテストの導入から学んだこと
・SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜
探索的テスト（勝手に追加）
先に書いた初めての自動テスト ―Webシステムのための自動テスト基礎という本の中で以下のような記載(16 page)があります。
自動テストによって再テストに費やす時間が削減できたら、探索的テストに多くの時間を費やしましょう。
～中略～
自動テストでは見つからない問題を見つけられる点で、探索的テストは強力な技術です。
自動テストは、人がより多くの探索的テストを行えるようにしてくれる手段でもあります。
しかし私が探索的テストについてあまりよく知らないのでここで整理してみたいと思いました。
wikiによると、探索的テストという言葉は1984年からあったんですね。へー。
探索的テスト（exploratory testing）： 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]
こんな資料もありまして。これから抜粋してみます。
[資料](https://www.slideshare.net/tosikawa/wacate-56868585)より抜粋
[資料](https://www.slideshare.net/tosikawa/wacate-56868585)より抜粋
[資料](https://www.slideshare.net/tosikawa/wacate-56868585)より抜粋
アドホックテストとの違いがよくわかっていなかったのですが、テスト設計をするかしないかがポイントなんですかね？上記の引用部分から見ると、テスト対象について学習⇒テスト設計⇒テスト実施を繰り返すのがポイントなんですかね。
やってみよう！探索的テスト～ハイクオリティな妄想の高速ループ～
⇒「探索的テストとは･･･」のところより引用
「対象を動かしながら、テスト設計～実行～フィードバッ
クを行っていく（ハイクオリティな妄想のループ）対話型
のソフトウェアテスト」だと思っています。
参考資料
・初めての自動テスト ―Webシステムのための自動テスト基礎
・Exploratory testing
⇒右クリック→日本語に翻訳
・ソフトウェアテスト標準用語集
・探索的テストはじめの一歩
・やってみよう！探索的テスト～ハイクオリティな妄想の高速ループ～
その他参考
・品質をワンランク上げる！テストケースのない「探索的テスト」
・探索的テストとそうでないテストのJSTQB的まとめ
・探索的テストはベテランがやるものだと思ってた
探索的テストの参考資料
・探索的テストってなんですか？
・探索的テスト入門
・探索的テストとそうでないテストのJSTQB的まとめ
・テストの中の探索的テストの位置づけ
・探索的テストとは
・探索的テストとそうでないテストのJSTQB的まとめ
・Exploratory testing
⇒右クリック→日本語に翻訳
・探索的テストの文献一覧
最後に
以上。疲れました。