【新卒研修】教えてくれそうで教えてくれないソフトウェア産業の常識（テストチームのお仕事編）

こんにちは、 @illypon です。
QAは待つのも仕事だからねー。

さて、この度、弊社の2020年新卒研修の講師を仰せつかったのですが、
このご時世ということもあって新卒研修もフルリモートで実施することになりました。
そのために大量の講義のネタを仕込んでいる最中なのですが、せっかくなのでいい感じに仕上がったものは
Qiitaにも「教えてくれそうで教えてくれないソフトウェア産業の常識」というタイトルで投稿していくことにしました。
新卒の方に限らず、どなたかの参考になれば幸いです。

初回はエンジニアにとってとても身近な存在、テストチームのお仕事についてです。

## 検証と妥当性確認の概念を理解しよう

テストチームのお仕事は、**検証**と**妥当性確認**のふたつです。

- 仕様通りのふるまいであるかを確認するのが**検証**
    - 製品・サービスが仕様通り作られていることを確認します
- 要求通りのふるまいであるかを確認するのが**妥当性確認**
    - 仕様(つまり製品・サービスそのもの)が要求を満たしていることを確認します

検証に関しては、ある意味、当たり前のことが当たり前にできているかの確認にすぎません。
どちらかというと注意してもらいたいのが妥当性確認です。
いくら検証をしっかりしたところで、妥当性確認をしておかないと**バグはないけれど売れない製品・サービス**になってしまいますので要注意です。バグは後から直すことが可能ですが、要求漏れは実装漏れそのものであるため、プロジェクト後半に要求漏れに気づいてしまうとプロジェクトへのインパクトは極めて大きいものとなります。

早め早めの妥当性確認がプロジェクトを悲劇から救います。

## テストの目的は時期によって異なる

テストの目的はふたつあり、これは時期や状況によって異なります。

- バグを見つける
- 正しく動くことを確認する（バグがないことを確認する）

バグを見つけたい時期にバグが見つけられなければ、テストの仕方が悪いかもしれません。
正しく動くことを確認したい時期にバグが見つかれば、設計や実装が成熟していないかもしれません。

## 要求と仕様を理解しよう

仕様を理解しないことには仕事になりません。
ただし、仕様だけを理解をしようとしても、どうしてそのような仕様であるのかを理解するのは困難です。
ですので、仕様と同時に、その背景にある要求やユースケースをあわせて理解する必要があります。
さらに要求やユースケースはドメイン知識に基づいています。いわゆるユーザーの業界における常識というものです。

## 仕様の確認をしよう

テスト設計をするだけで仕様バグに気づくことがあるはずです。これも静的テストといってテストのひとつです。
早めに仕様バグのチケットを発行してください。企画担当者が「そういう仕様でいい」と判断すれば、それはそれでOKです。確認するプロセスが大切です。
テスト実行中に仕様バグに気づくこともあります。その場合も同様に仕様確認のチケットを発行してください。

## テストできるところからテストしよう

- テスト設計できたところから部分的にでもどんどんテスト実行していきます。早くバグを見つけて、早く報告したほうが全体のスケジュールが楽になります。
- 期待動作が不明でも、テスト条件が決まっていてテストを阻害するバグがないのであれば、テスト実行します。

## チケット化することを悩まない

- チケットは積極的に発行してください。
- 完璧なチケットにしようとするよりも、まずは課題を共有することが大切です。
- バグトラッカーであれば、あとからチケットを訂正することもできます。

## テスト結果の確認方法について明確にしよう

機能テストであれば、どのテストケースも以下のような流れになります。

1. テストの条件に基づいて各種設定をする
1. テストの条件に基づいて処理を実行する
1. テスト結果が期待動作になっていることを確認する

このときテスト結果の確認をどのようにするべきかは、仕様全体を把握しておかないと網羅できません。
たとえば以下のような確認箇所があるはずですが、これは狭い範囲のテスト設計をしているだけではわからない点に注意が必要です。

- 画面上での値の反映 (複数個所)
- 操作ログ
- 処理結果のログ
- 反映された値が別の箇所で取り扱われるもの
	-  エクスポートしたとき正しいデータになっているか
	-  機能の設定に関するものであれば、実際に動きが変わるか
	-  非同期処理などに影響がないか

また、値が正しいかどうかに加えて、即時性または適用タイミングも確認します。(これらは非機能要件ではありません)

- すぐに反映されなければならないもの
- 一定間隔ごとのバッチ処理を待たないといけないもの

## テスト実行の優先順位の考え方①

### 通常のテストの場合

1. 限りなくバグが出ないパターンでテストをします。正常系ど真ん中を真っ先に実行します。これはワンパターンでOKです。<br>
このときに動かない機能があるとテスト実行に支障をきたすので、大急ぎでチケットを発行してください。<br>
このパターンをたくさん集めるとSmoketestが完成します
1. 次に正常系/準正常系を網羅します。
1. 正常系/準正常系で問題がなければ、最後に異常系のテストをします。

正常系/準正常系で見つかったバグが残っている状態で異常系テストをしても意味がありませんので注意が必要です。

### 探索的テストの場合

- エラー推測に基づき、バグが出そうなパターンでのみテストする。
- ファジングなどの技法を合わせて使用するとテストの幅が広がります。
- 先にテスト工数を決めておくのが大事。(たとえば週のうちx時間)

## テスト実行の優先順位の考え方②

上から優先順位が高い。

1. 基本機能のうち、かならず使われるもの
1. 基本機能のうち、利用者が限られているもの
1. 便利機能のうち、よく使われる機能
1. 便利機能のうち、利用者が限られているもの

## 正常系/準正常系/異常系テストの定義

|系統|説明|
|:----|:----|
|正常系|仕様上取りうる値をテスト条件とするものは正常系テストです。仕様上のMAX値も正常系です。|
|準正常系|想定しうるエラー(仕様上のMAX値+1など)を入力値とするテストは準正常系です。|
|異常系|設計者が考慮していなさそうなテストパターンのみが異常系です。やってほしくない操作とも言い換えられます。(いわゆるいじわる系) 

### 異常系の例

- キャッシュからの操作や、フォーム再送信などのシーケンス破綻
- 複数ブラウザーから同時にロックされていないものを操作するなどの競合
- 同一の処理に対して複数の処理依頼をキューイングする場合
- 連打系
- etc.

## テスト工程における、各工程のコストと効果

|工程|コスト|必須かどうか|
|:----|:----|:----|
|仕様把握|中|必須|
|テスト設計|中|必須|
|テストケース作成|やや大|エビデンスを残す必要がある場合や、多くのテスターに実施させる場合は必須|
|テスト手順作成|特大|テスト実行者のスキルレベルによってどの程度作成するか判断する|

## 仕様であるかどうかを確認しよう

- バグトラッカーを検索する (特にステータスが**仕様**になっているものは他の人も同じように疑問に思った箇所です)
- 各種Wikiや過去資料を漁る
- 詳しくそうな人に聞く
- バグトラッカーで質問チケットを発行する (確実な手段。もしそれがバグであれば、チケットのタイプを変えるだけでいいというのもある。)