テストタイプの定義
テストタイプの定義はJSTQBでは「コンポーネントやシステムの特定の特性を狙った、特定のテスト目的に基づいたテスト活動の塊」です（少し意訳なので正式には英語参照してください）。
ここの「特定の特性を狙った」（aimed at specific characteristics）の解釈でテストタイプの解釈自体が左右されそうです。また、JSTQB FLシラバスではテストタイプの例が書かれています。少し長いので省略して記載します。
・機能の品質特性を評価する
・非機能の品質特性を評価する
・構造またはアーキテクチャーが仕様通りであることを評価する
・変更による影響を評価する
章としては、機能テスト、非機能テスト、ホワイトボックステスト、変更部分のテスト、が記載されています。
テスト目的はプロジェクトによって（テスト要件によって）大きく異なります。また、テストの特性についても、仕様通りであることや変更影響の確認も含んでいることを考えると、広めの概念であることがわかります。
実は僕自身、テストタイプは「特定の製品の品質特性をテストするもの」だと考えていました。それは、特定の特性（specific characteristics）を狭義でとらえていたからです。ただ、JSTQBの従うとそれは間違い（狭すぎる）ことになります。
乱暴に言うと、何らかの基準でテストがグルーピングされているもの＝テストタイプ、と言ってしまってよさそうです。
一方で、定義は「何でもあり」だとしても、テストタイプのベストプラクティスはありそうです。僕がこれまでの経験の中で気づいていることを書いておきます。
・「仕様通りテスト」というテストタイプはなるべく使わない方がよい
「仕様通りテスト」は仕様通りであることを確認するテストです。名称自体は「仕様塗りつぶしテスト」とか、「仕様確認テスト」とかかもしれません。このテストタイプの何が困るかというと、仕様に書いてあるものの特性が特定できない点です。仕様には機能要件も非機能要件も書いてある可能性があります。これらが混じって考えられてしまうため、避けた方がよいと考えています。ただ、場合によっては仕様通りであることを保証する必要性があるとおもいます。その場合はその他のテストタイプ分類と仕様通りテストというテストタイプを同居させることがよい、と考えています。
・一つのテストケースは複数のテストタイプに所属しうる
これは、前述の「その他のテストタイプ分類と仕様通りテストというテストタイプを同居させることがよい」ということと深く関連します。テストタイプは単純に詳細化、分割管理されるものではなく、複数の視点を持ちえます。代表的なものが「仕様通りテスト」であり、「リグレッションテスト」です。リグレッションテストの例だとわかりやすいですが、リグレッションテストは過去に実施したテストを（多くの場合）部分的に再実施します。これはつまり、何らかのテストタイプに属している過去に実施済のテストが、再度リグレッションテストというテストタイプに属することになります。
この考え方は、テストアーキテクチャという文脈ではビューと呼ばれたりします。興味ある方は↓などをご覧ください。
ということで、テストタイプの定義と経験的なプラクティスについて話しました。あと何個かありそうなので、また書きますね。