とあるQAのテスト活動＋α　〜組織に合ったいい塩梅を探る〜

QAエンジニアのこやみです。

今回は、とあるQAエンジニアが開発エンジニアと一緒にどのようなテスト活動をしているのかをご紹介します。
こんなテスト活動をしているQAエンジニアがいるのだなと、肩の力を抜いてお読み頂けると幸いです。

## 前提
- QAエンジニアが全てのチームに専属で配置されていなので、開発エンジニアもテスト設計、テスト実施することがあります。
- そんな組織でのインプロセスQAエンジニアのお話です。

## 初のチーム専属QAエンジニア
これまでチームにはQAエンジニアが存在しておらず、開発エンジニア数名でテスト(コンポーネントテストからシステムテストまで)も担っていました。

そのため、**実装者目線でテストケースを作成してテスト実施し、後に思わぬところから不具合が発生する**ということがあったそうです。

そこでテストについての知見を開発エンジニアに広げて、プロダクトの品質を安定させる！開発エンジニアのレベルアップを図る！という目的で、初のチーム専属QAエンジニアとして参画しました。

## 「どのテストレベルでどんなテストをしたらいいの？」
これはチームに参画して1週間くらいの経過した頃に、尋ねられた言葉です。

テストエンジニアと言われる職種の方は、おそらくすぐに答えられるかもしれませんが、開発エンジニアから見ると理解するのが難しい場合があるのです。

単体テスト、結合テスト、システムテスト、システム統合テスト、受け入れテスト等、「◯◯テスト」という言葉ですが、

- 「単体テスト」と「単体結合テスト」で何が違うの？

- 「システムテスト」と「システム統合テスト」でそれぞれ何をするの？

と疑問符が湧いてくるのです。

そしてこれらの「テストレベル」と言われる名称とその内容は数年単位で変化しているため、より混乱してしまうのです。

ちなみに、2024年12月現在の「[最新のJSTQB FL シラバス((ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02))](https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf)」では、コンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストという名称に変化しています。

なるほど。まずはそこから始めよう！

## 四方山テスト話シリーズ爆誕！
隔週1回30分程度でテストの話をしよう！と始めたのが「四方山テスト話」です。

開発エンジニアのメンバーにテストの知見を広めてもらうために始め、現在はチームの勉強会の中でテストの回として運用しています。

テストの知見を増やしてもらおうとJSTQBの FLシラバスを元にテストの話をイチから実施するのも１つの方法ですが、敢えてその方法は取りませんでした。

なぜなら、興味のない話を集中して聞き続けるのは、人間誰しもがつらいからです。
（私が聴講者なら眠くなる）

**開発エンジニアが今疑問に思っていることから話す** を基本的な考えとして四方山テスト話の資料を作っています。

気になっていることなら、集中して聞いてみよう！と思ってもらえますし、内容を踏まえてより詳しく聞いてみたい！と質問も増えるからです。

今疑問に思っていることをベストなタイミングで提供するには、事前にそれなりの種類の資料を準備しておくことが必要です。

また、**テストレベル毎にこの会社ではどんなテストをどこまで実施しているのか**、「一口メモ」として紹介することで、疑問だったことが少しクリアになったようでした。


その他、四方山テスト話シリーズとしては、

- ディシジョンテーブルが上手く描けないお悩みから、「様々なテスト技法のお話」

- APIテストで何をしたらいいのか（WebAPIの勘所）「WebAPIテストのお話」

- テストケースをどう作成すると効率良いテストができるのかというお悩みから「テスト観点のお話」

などを実施しました。

## 「欠陥がより高いテストレベルまで見逃されることの防止」の取り組み
さて、テストレベルのお話をすると、受け入れテストを除いて各テストレベルで **「欠陥がより高いテストレベルまで見逃されることの防止」** を求められます。

コンポーネントテストやコンポーネント結合テストは割と開発エンジニア側で実施してもらうことが多く、システムテスト以降でテストエンジニアが参入するケースが多いのではないでしょうか？

その場合、バレーボールのお見合い(味方のプレーヤー同士がラリー中に、ボールを譲りあってコート内に落とすこと)のようなことが発生しやすいのです。

- 開発エンジニアからすると「システムテストで実施してくれると思っていた」
- テストエンジニアからすると「コンポーネントテストで担保されていると思っていた」

**双方が相手側で実施していると思い込み、「欠陥がより高いテストレベルまで見逃されている」状態**です。

場合によっては、コンポーネントテストを開発の責任範囲で実施してもらうため、テストエンジニアはコンポーネントテストの内容を詳細には把握しないという組織もあると思います。

しかし、このように各テストレベルで欠陥がより高いテストレベルまで見逃されてしまう場合は、そのテスト活動を見直した方が良いと考えます。

そこで取り入れたのは、**テスト観点の洗い出しを開発エンジニアと一緒に行う**スタイルです。

- **スプリント開始直後の1時間をテスト観点の洗い出しタイム**として設定します。
  - メリット：開発に入る前（実装以前）に、開発エンジニアと目線を合わせてテスト観点を洗い出すことで、「開発し忘れていた」「開発対象から漏れていた」を防ぎます。
- テストエンジニアは**ファシリテータとしてインタビュー形式**でテスト観点を整理します。
  - メリット：インタビュー形式でテスト観点を整理することで、開発エンジニアに「そういえばアレも必要かも？」という気づきを与えられ、テスト観点として考える必要性を伝えられます。「実は気になっていたんだけれど・・・」という開発エンジニア目線での気づきを教えて貰えることもあります。
(個人的にはとしては、開発エンジニアと一緒にテスト観点の洗い出しをすることで、隠れた仕様など、よりプロダクトの勉強にもなるので、とてもメリットとして感じています)
  - テストエンジニアが最初から「答え」を埋めてしまうと、テストエンジニアに任せておけば安心！という心理から、テストの知見はいつまでも伝播しません。
- テスト観点の洗い出しには**ズームインとズームアウトを多用**します。
  - テスト観点の洗い出しをするとまずは対象の細かいところに目が行きがちです。そして細かいところに集中しすぎてしまうことで、周囲が見えなくなってしまうことも度々あります。そこで、一眼レフカメラのようにズームイン・ズームアウトをテスト観点の洗い出しの時に多用します。
  - 開発エンジニアとお話するとズームインは観点の洗い出しがスムーズ(開発エンジニアが実装をイメージして話すので、詳細については澱みなく出てきてスムーズ)なのですが、ズームアウトの視点が疎かになりがちなので、個人的にはここを注視しています。
    - リリースする環境差異はないか？
（A環境ではxx機能が利用できるが、B環境ではxx機能が利用できないようになっているなど）
    - ユーザーの利用想定環境での振る舞いの差異はないか？
（iphoneとiPad、MacbookとWindowsなど）
    - 想定ユーザーの権限による振る舞いの差異はないか？（管理者権限とユーザー権限での表示方法・操作方法など）
    - 今回改修する機能と連携している別機能への影響はないか？（連携先での表示方法・操作方法など）
    - 今回改修するシステムと連携している外部システムへの影響はないか？（連携先での表示方法・操作方法など）
 - ズームアウトの視点にこそ、不具合は起きやすかった経験から、個人的には大事にしています。
 - テスト観点の洗い出しをする際に、**テストレベルを意識した洗い出し**をしています。
    - コンポーネントテストではどこまでみるか（xxのバリデーションを担保する）
    - コンポーネント統合テストではどこまでみるか（GaugeでAPIテストのxxは担保する）

といった具合です。 

「欠陥がより高いテストレベルまで見逃されることの防止」を実現するために、**今の組織に合ったテスト活動**として行なっています。
組織のテストにおける熟練度が上がり、プロダクト品質が一定保たれている段階になったら、そこでまたテスト活動のやり方を見直せば良いと考えています。

## 日々「組織に合ったいい塩梅」を探る旅
QAエンジニアとして今改めて思うことは、**「組織に合ったいい塩梅」を模索し続けることが大事である**。

今回ご紹介しました内容は、あくまでも今の組織に合った**丁度良いと思われる**スタイルです。

開発エンジニアのスキルがとても高く、テスト活動にも精通している場合は、おそらくQAエンジニアと一緒にテスト観点の洗い出しはしないと思います。

もしかしたらその場合のテストエンジニアのメイン作業として、テストケースレビューに重きを置くかもしれません。

もしもご自身が所属されている組織にて、同じような課題に直面されていたら、こういう取り組みもあるんだなと参考にして頂ければと思います。