初めに

この記事を開いていただきありがとうございます。
そろそろQAとして持つべきマインドを言語化できそうな気がしてきたので筆を執ります。
QAという職業は結構特殊な職種だと思っています。
母数が少ないからか、あまり「QAのあるべき姿」、みたいな書籍やサイトは見かけないのが実情です。
自分が考える理想のQAというもの深堀していきたいと思います

QAは特殊なビジネス

そもそもQAエンジニアの感謝され方は特殊

ビジネスとは

まず、ビジネスとは何でしょうか？
基本は「やってくれてありがとう」と感謝されるものがビジネスです。
要は、得られる喜びが多ければ多いほど、削減できた時間が多ければ多いほど、その対価としてお金を払いますよ、というのがビジネスです。
若干ツッコミどころはあるかもですが、基本的な部分は間違いないと思います。

そしてビジネスとして成り立たせるためには基本的には下記の2つのどちらかの要素が必要です

売上を増大させる(お金が入ってくるようなことをする)
費用を削減させる(お金が出ていかないようなことをする)

例えば、銀行員。
銀行員は一般人から預かったお金を、必要な人に貸してくれます。
借りた人は、感謝の気持ちとして金利を銀行に払います。
銀行はその金利を稼いできた銀行員にお金を払います。

例えばソフトウェア開発エンジニア。
彼らは動くものを作るのが仕事です。
その動くものが利用者の時間短縮につながればつながるほど多くの人に感謝されます。
利用者が多ければ多いほど収入も増えていきます。

価値というのは需要と供給によって成り立っています。
希少価値が高いスキルかつ、時代が求めているスキルであればあるほどもらえる感謝は大きいわけです。

QAの価値とは

で、QAエンジニアって、誰に感謝されるんでしょうか？誰の時間を削ることができるんでしょうか？
QAエンジニアって、基本的にはコーディングしないので、人が欲しいと思うものを作り出すことはできないし、人の生活を効率的にしたり楽しくしたりすることはしません。

じゃあ、誰から感謝されるのか？
それは プロダクトの作成にかかわる人 からです。

どんな感じで感謝されるか？
それは 「機会損失を防いでくれてありがとう」 です。

機会損失とは本来得られるはずの利益を失ってしまう部分のことです。
我々QAは機会損失が0になることを目指します。

具体的には、ユーザーの離脱による減収、顧客対応のコストをできる限りなくす、というものです。

離脱による減収を減らす

プロダクトの品質があまり良くないので同業他社の製品に乗り換えるといったユーザーを減らします。
これはわかりやすいと思います。

顧客対応のコストを減らす

また、ユーザーから文句を言われた場合、プロダクトの運営側はリソースを使って対応しなくてはなりません。
対応するにも、相手を不快にさせないような対応ができる人を雇って、多大なる時間をかけてユーザーの怒りを抑えなくてはなりません。
コストが多大にかかるわけです。それを未然に防ぐ、というのがQAエンジニアの使命です。

QAはユーザーから直接感謝されることはない

ユーザーからは直接感謝されませんし、プロダクトの関係者からも「めっちゃ便利な機能作ってくれてありがとう」とはなりません。
最高のバグチケット、というのが仮にあったとしても、それはそのプロダクトの開発に関わる人の中で消化され、世に出ることはありません。
プロダクトがリリースされても、ユーザーは1人も「最高のバグチケットの起票者」のことを知らないし、感謝の気持ちなんて1ミリも持ちません。

こんな感じで、QAエンジニアというのは結構特殊なビジネスであることがわかってくれたのではないでしょうか？

車のパーツでいうとブレーキ

上記のように、QAエンジニアというのは、動いているチームが次のプロジェクトにスムーズに取りかかれるようにすること、という役割を担っています。

これは例えると、次のコーナーを問題なく抜けるための姿勢づくりをしている、と考えられます。
車を思い浮かべてください。次のコーナーを気持ちよく抜けるために必要な部品は何ですか？
ブレーキですよね。

QAエンジニアはBremboやalconやAPレーシングのキャリパーのように、最高の姿勢づくりが出来るようなブレーキとなることを目指してください。

ただ、気を付けないといけないのは、ブレーキを強く踏みすぎて必要以上に失速させないことです。
あくまで、最速でコーナーを抜けるための最低限のブレーキが踏めるようなQAエンジニアを目指しましょう！

いったん、QAエンジニアとして持つべきマインドは以上とし、実務面で持つべきマインドについて書いていきます。

テスト実施

1ユーザーを代表して操作する

テスト実施はテストケースに書いてある通りにプロダクトを操作して、問題点があれば起票して開発エンジニアに直してもらう、ということが基本的に行うことです。
ここで気を付けるべきことは、あくまで、そのプロダクトの1ユーザーとして操作することを意識する、ということです。
老人向けのプロダクトであれば、老人の気持ちになって。
日本以外でも使うようなプロダクトであれば、外国人の気持ちになって。
片手がふさがっている状況で使うようなプロダクトであれば、自分もその状態で操作してみて。

あくまで、QAエンジニアってのは「ユーザーに文句を言われないようにする」ことが大事です。
なのでユーザーの一人として操作した時に「使いにくっ！！」と思うような事象を見つけてください。

エッジケースばかりが気になり、テスト実施の時間を浪費している人は、「この操作で問題が出たとして、ユーザーから文句言われるだろうか？」と一度立ち止まって考えてみましょう。
これはものすごいクレームが入りそうだ、と思えばもっと深堀してください。
むしろここで文句言うやつの方が変な操作してるじゃん、と思えば次のケースを進めましょう。

開発エンジニアが見落としている、盲点を突く！

開発エンジニアは、いわゆる理系出身者が多いです。
高校大学と物理、生物、化学、数学をメインで勉強してきた人がプロダクトを作っています。
しかし、ユーザーは理系出身とは限りません。

よって、開発時に考えつかなかった、思わぬ操作をされてしまうなんてことがあります。
要は考慮もれですね。

QAエンジニアは開発者とユーザーの間に立って、開発者が考慮してなかった操作を代わりにやってみる、ということも大事だったりします。
思わぬバグを掘り当てたら、それはグッジョブです。

QAエンジニアはユーザー代表であり、開発側にも所属しており、ユーザーが考えつくような操作を網羅できるスキルが必要、という感じで割と特殊なマインドが求められる職種だと思います。

テスト設計

基本的には1観点につき1期待値でテストケースを設計

テスト設計の基本的な考え方は「やれることを全部やる」です。
そのプロダクトが出来ることは全部操作して、期待結果を明確にしていきます。
イメージとしては、ここまではAさんの敷地、ここからはBさんの敷地、のように操作に対して白黒つけていく。
そのプロダクトができることとできないこと。処理することと処理しないことを明確にしていくような感じです。

で、「こんな操作をします」とテストケースに書いてあったとして、
期待結果に「適切な人の敷地にあること、また、いい感じに動くこと」って書いてあったとしたら、
おいっ！この期待結果！！白なのかい？黒なのかい？どっちなんだいっ?!！
ってなりますよね？

もちろん、ハイレベルなテストケースの場合はそれでいいときもあります。
しかし、基本的な考え方としては、誰がやっても同じ結果を出すことができることが大事です。
おかしな状況になって、それを再現できないとバグチケットも作成できないですよね。

また、2つ以上期待結果があると、何か問題があったときに何が原因なのかわからず、起票に時間がかかってしまうことがあります。
そのためにも基本は1観点につき1期待値のテストケースを作っていきましょう。

何度も言ってますが、これはあくまで基本的な考え方であって、慣れてくればその限りではありません。

無限にあるパターンをいかにminimizeできるか

開発エンジニアは基本的には目的を達成するための手段をプロダクトという形で提供してくれていますが、
我々QAエンジニアはその目的を誰が達成できて、誰は達成できないのかを明確に分類する、というのが主な仕事です。

達成できるはずの人が出来なそうであればそれはバグだし、達成できないはずの人ができちゃってもそれはバグです。

ここで、ポイントはテストできるパターンというのは無限に存在するということです。

テスト設計ではその無限にあるパターンをできるだけ少ない数で、同じだけの効果があるようにすることが大事です。
理由は、たくさんテストするのがめんどくさいからです。
無駄なことに使うリソースなんてありません。

限られたリソースで最大の効果を発揮するテストを設計する人、ってのが優れたテスト設計者なわけです。

終わりに

長々と書いてしまいましたが、QAエンジニアって、あんまり世の中で認知されてないし
ノウハウ本もあんまりないという状況なので、QAエンジニアになりたての人や、なんとなく仕事してるQAエンジニアの考えが整理されたらいいんじゃないかと思います。

自分もまだまだ発展途上なので、精進していきます。
読んでいただきありがとうございました。