開発エンジニアがQAの社内勉強会を開いた結果...

# 概要
数ヶ月前に社内勉強会を開いたので、そのレポートを残しておきます。
<script async class="speakerdeck-embed" data-id="22786bab3cd54676995cb1489cee8445" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>

元ネタは[How to Think Like a Tester](https://medium.com/@blakenorrish/how-to-think-like-a-tester-7a174ff6aeaf#:~:text=It%20requires%20critical%20thinking%2C%20creativity,and%20exploratory%20nature%20of%20testing)という記事です。
全文訳は[こちら](https://qiita.com/kei3524848/items/aec6ae950d86f5d9dc58)

全1回、60分の構成で実施しました。
リアルタイム参加者は20名前後です。

# 目的
社内のQAエンジニアが不足しているという背景があります。
そのため、開発者もテストのお手伝いをするという場面が多々ありました。

* 開発エンジニアもQAの知識を身につけておいて損はない
* 一方で自分自身はQAエンジニアではないので、テスト技法については勉強会を開けるほどの知識を持っていない
* じゃあマインドセットぐらいだったら語ってもよいのではないか？
* それとQAエンジニア足りなさすぎ😡😡

というところで、QAの心得というテーマで勉強会を開きました。
しかもマインドセットがテーマならプロダクトを作る側に限らず、営業やカスタマーサクセスなどの職種の方にも転用が効くというところもあり、幅広く参加者を募ることができるというのも利点の1つでした。

また、その時ちょうど自分の所属しているチームリーダーかつQAエンジニアの方が退職されるということもあり、その方に何か最後に楽しく学べるものを提供したいという意図もありました。

## 内容
### はじめに

記事の内容通り、
* テストの才能は生まれつきのものではない。
* テストはスルメのように噛めば噛むほど味が出てやみつきになる、つまりやればやるほど奥深さを知りハマっていく。
* 5つの特徴的なマインドセットの紹介をする。

という導入部分のお話をしました。

### 心得其の壱 逆転の発想を持て

「Inverted Thinking and the Burden of Proof」 -> 「推論と反証」の時点ですでに意訳がされていますが、心得っぽさを出したかったことから、タイトルはさらに意訳しています。

ここでは
* ソフトウェアはバグだらけ。リリースされているソフトウェアであってもバグはあるのだから、開発中のものなんかはそもそも動かないことがほとんど。
* 開発者は騙そうとしているわけではないが、QAに対して「これ動きます！」といってソフトウェアを出してくる。でも動かない。
* だから、QAはソフトウェアは動作しない前提で動かす。
    * 動かないテストがNGになるということ = ソフトウェアが動く = 否定の否定 = 肯定

というお話をしました。

これに対して開発者は
* プログラミングにも応用できる。
* 一応動かす努力しているから、そこまで疑わなくても😢
* 開発者は楽観的というステレオタイプがある。
    * バグがあるのはしょうがないから、それをいかに素早く直すかのほうが重要って考えているから楽観的なのでは？

という感想でした。

またQAは
* 開発者に大丈夫と言われると逆に疑う。

といった意見でした。

参加者からは「重点的にテストしてほしい場合は、あえて『ここ大丈夫です』といえばいいのか」といった意見も出ました。

### 心得其の弐 ユーザーになりきれ

ここでは、
* [クオリア](https://ja.wikipedia.org/wiki/%E3%82%AF%E3%82%AA%E3%83%AA%E3%82%A2)の考え方にあるように、自分と他人の見ているものはまったく異なっている場合がある。
* ユーザーはソフトウェアを使うとき、だいたいネガティブな感情を持ちながら使っている。
* アンケートやアイトラッカーなどでユーザーの思考や動きを調査。
* ロールプレイやゲームなどで想像力を鍛える。

というお話をしました。

これに対して開発者からは
* 対象となるユーザーが極度に専門的な内容(医師、弁護士など)だと想像するのは難しくね？？

という疑問が出ました。

またQAは
* ユーザーのやりたい操作=重要度が高い操作を想像して、そこから優先的にテストをしてバグを出す。
* 専門的な知識を持っていても、初心忘れるべからず

といった意見でした。

### 心得其の参 思い込め、そして思い込むな
ここでは、
* 思い込みによってバグを見逃してしまう。
* 思い込み＝悪いものではない。
* 思い込みによってケースを絞り込める。
    * 単純なソフトウェアでも組み合わせを考え出すと無限にテストケースが発生してしまうから。
* いい思い込みはうまく活用、わるい思い込みは捨て去る。
    * いい思い込み、わるい思い込みを正しく判断する。

というお話をしました。

これに対して開発者は
* 思い込みで実装ミスをすることが多いので気をつけます。

という自戒の念を改にしました。

またQAは
* 思い込まないものに関しては、キーをランダムに叩いてみるなんてことも重要

という意見でした。

参加者からは「うちの猫はよくキーボードの上を歩くけど、自分のバグはなくならない」と嘆きの声も上がりました。
また「どちらの思い込みかの判断は経験値？」という疑問も出ました。
確かに難しいところで、経験値あっての判断力かと思われます。
1つの対策として、認知心理学に関する本を読むことで知識に基づき判断力をカバーできるという意見も出ました。

### 心得其の肆 勘を働かせよ
ここでは、
* テストはチェックリストにOK or NGをつけるだけの仕事ではない
* 探索テスト(テストをやりながらテストケースを設計していく)が必要
* ↑の性質を知らない人たちは、チェックリストにOKNGをつける仕事をやらせたがる
    * テストなんて一回設計すれば、あとは誰がやっても一緒。テスト実行者は安い単価でいいだろという発想。
* 探索テストに必要なのは勘。

というお話をしました。

これに対して開発者は、
* 勘が発揮できるのは経験値のあるQAだからこそ。

という意見でした。

またQAからは
* 勘にはデメリットもある。
    * 勘によって品質が保証されることは属人化。
    * 言葉にしにくいものも言語可したほうがよい。

という反論も出ました。

参加者からは「え？ここ！？というところのバグも見つけてもらっている」と、探索テストの効果を実感しているという感想も出てきました。

### 心得其の伍 人を大事にせよ

ここでは
* ソフトウェア開発は基本的にチームで行われるもの。
* 人間は体調や感情に左右される。
    * バイアスによってソフトウェアにバグが発生することもある。
* ソフトウェアにバグが発生するときは、たいてい人間のわるい性質によって混入する。
* チームの人を知ることでバグを早期発見。

というお話をしました。

これに対して開発者は、
* 過程は人なので、そこを疎かにしてはいけない。

と賛同しました。

またQAは
* 人の性格やその日の体調等も考慮する。

と賛同しました。

### まとめ
* これらの心得をうまく活かして良い仕事をしていきましょう。
* そして「バグを憎んで人を憎まず」です。
という締めでした。

## 反省
アンケートで気になった意見を以下にピックアップします。
それに対する回答も記載します。

* QAの意見が個人に偏りすぎ？
    * 今回1名から意見を募る形になってしまったので、もう数名にも依頼できればよかったです。

* あとから見返したときに内容がわかりにくいスライドでは？
    * 勉強会の録画を残しているのでそれでカバー。
    * 今回は実験的です。マインドセットということもあり、文章の箇条書きによる説明よりは一枚絵 + キーワードにしてインパクトを与える構成にしてみました。
        * ちなみにスライドの背景画像は無料で配られているものから選んできています。
    * 結果としてスライド一枚の情報量が少ないため、プレゼンターがしゃべりにくいというデメリットもありました。こういうスライドの場合はある程度原稿を用意したほうがよかったです。

* 質疑が生まれやすい仕組みにしたほうがよい。
    * その通りです。タイムマネジメントが雑でした。
    * ある程度の余白が必要だと思っています。時間的な余白(1時間想定なら、内容は45分程度になるようにするとか)に加え、内容の余白(質問、意見を言えることができる隙)を作ることも重要かなと。
    * 個人的には参加者に意見の強制をしたくないので、今後も指名しようとは思いません。
    * 意見をいいやすい雰囲気作りは難しいですね。笑いどころがもっとあると、気持ちがほぐれて意見もつい書きたくなるとかですかね。

* 固い内容がかみ砕かれいてわかりやすかった。
    * 意訳とスライドのインパクトが功を奏したようです。

* それぞれの心得に対する開発者、QAの意見があるところがよかった。
    * 2つの立場からの意見で納得感がうまれやすいようにできていたようです。

個人的には英文記事を元ネタとした内容にしたこともよかった点かなと思っています。
日本語記事ならそれを紹介して「これ読んでみて」で終わってしまいますが、英文記事だとまず英語のハードルがあり読もうと思う人が限られてくるので、そのハードルが取り除かれるなら説明を聞いてみたいとなるかなと。
プレゼンター側も英文訳してそれをもとに資料や構成を考えればいいだけなので、元の知識が深くなくても勉強会を開催して成立させられるという点がお手軽でした。

以上、社内勉強会のレポートでした。