QAEはテストだけじゃない！じゃあテスト以外何をやっているの？(1)

はじめに

QAEは品質保証専門のエンジニアです。例えば、テストを通して定量化された情報を統計的なアプローチを使って分析を行い、品質における懸念や安堵を根拠を持ってチームに示すことができます。最近は定量化するまでの手段の一つであるテストを開発者がやっている組織も多いですよね。QAEは、まるで懐中電灯のような存在だと思います。前職に業務委託で入っていた会社で、そんな的確な比喩を使っていた人がいました。

僕たちはプログラマとは全くことなる職業であることが非常に大事です。QAEは独立性が高ければ高いほど力を発揮することが多いです。また、品質という視点からプロダクトを見ている特性上、プログラマとは異なる視点を持っていることで、よりビジネスサイドのサポートができたり、ビジネスとデベロッパの橋渡しをすることができるような存在だと思います。

では、QAEはどうやってどの存在を発揮しているのでしょうか。個人的に代表的だと思うことを書いてみました。

今回はパート１ということで、とりあえず２つ紹介してみたいと思います。
なるべくサクッと読んでもらえるようにしたいので、あんまり長ったらしくしてもしょうがないなあと思っているからです。

この記事は僕の今までのQAEの経験や今まで出会ってきたQAEとの交流から学んできたことを元に書いています。

QAEの業界はまだまだ新しくていろんな人がいると思います。他にもこんなこともあるよ！という事柄があればぜひコメント欄や私のTwitterアカウント(@MAX_QAE)までご連絡ください。ぜひ勉強させてください！

QAEがやっているテスト以外の活動とは

不具合分析

テストによって定量化される代表的な情報は下記です。

• テストケースの数
• テストケースにおける合格の数
• テストケースにおける不合格の数

これはテストという行為によって定量化された立派な分析のRAWデータです。
ローレベルテストケースであればあるほどRAWデータの信頼度は高くなるでしょう。
（ハイレベルなテストケースであっても、根拠のある数字であることを示れば問題ないと思います）

このRAWデータを用いて分析を行なっていきます。
代表的な手法はゾーン分析だと個人的に思っています。

ゾーン分析は何を基準に高いとするか・何を基準に低いとするか、という基準づくりが最も大切になります。基準値を作るには標準偏差を用いるのが代表的だと思いますが、それに加えて開発難易度や過去の開発や前工程の不具合の数から考えられる品質の懸念度合いといった定性的な情報を使って微調整する必要があります。今までの経験上、その微調整が結構大変でした。

CSチームとDevチームを繋げる役割

QAEが主にやっている活動としてテストは誰でも知っている代表的な活動だと思います。プログラマが行うテストは例えばRubyであればRSpecを使ったコードベースのホワイトボックス的なテストが一般的だと思いますが、QAEが行うテストはブラックボックスです。WFの文脈に当てはめるのであれば単体テストと統合テストといったところなのでしょうか？

ブラックボックスなテストをするには単なるドメイン知識だけでなく実際に顧客はどうやってそのプロダクトを使っているのかという情報や、現状の仕様やデザインに関わらずユーザの使い勝手はどうあるべきかというその人の哲学も大事なFBの軸になっていきます。

アジャイルにおいては仕様がまだ決まっていないという状況や仕様は決まっているが明確にドキュメント化されていないということがありますが、先々が見通せていないからこそ段階的な抽象度でプロダクトを捉えて、あってはならないプロダクトの振る舞いを想像する必要があります。

そのために上記に記載したようなFBの軸というものをQAEは持っている必要があるのです。

プロダクトに対してQAEが持っている視点は部分的には特にCSチームをはじめとしたビジネスサイドにも存在している視点ということができます。

QAEはこの視点を活かしてDevチームとCSチームの間に立ち、この2つのチームがコミュニケーションできるように立ち回ることができます。

例えば、下記のような情報をCSチームから収集して、Devチームの文脈の言葉に置き換えてFBをすることができます。

• CSチームからDevチームへの要望
• 実際に、Devチームが作った機能は顧客のペインを本当に解消したのか
• 作った機能は顧客に導入されているか。導入する予定がないのはなぜか。
• VoC
• Devチームの障害対応は適切だったのか

一方で、開発チームからCSチームへは以下のような事柄をFBすることができます。

• これからリリースされる開発成果物は具体的に顧客（場合によってはBiz）のどのようなペインを解消するのか
• 検討段階の仕様やデザインの壁打ち

このようなDevチームとCSチームのコミュニケーションを活発化するためにQAEは立ち回ることがあります。

※このような立ち回りはスクラムチームの体制や会議体によっては必要ない場合もありますね。しかし、例えばスクラムマスターがそのような役割を担っていた場合はスクラムマスターのサポートをすることができると考えることもできます。そもそも、QMファンネル上ではQAEの延長線上にはスクラムマスターがいるといわれいます。

おわり

さて、どうでしたでしょうか。
品質という言葉はとても抽象的な言葉なので、QAEができることは見方によって沢山ありそうだ、ということが少しわかっていただけたのではないでしょうか。

専門的な用語をついつい使ってしまっているのですが、解説してしまうととても長い記事になってしまうのでよろしければ調べながら読んでいただけると幸いだなと思っています。

今後はなるべく参考になるリンクをつけるようにしていきます。子育ての合間に書いているので、ちょっと難しいかもしれませんが。

また家族がどこかに遊びに行ったりしてひとりの時間ができたら第2弾を書いていきたいと思います。
ありがとうございました。

この記事は自作キーボードのキット「Corne V4 Cherry」を使って執筆しました。

筆者MAXは、自作キーボードの文化醸成のお手伝いと、自作キーボードをやってみたい人を応援しています！