はじめに

KINTOテクノロジーズでQAグループのリーダーをしている遠藤です。
今回は、QA業務を日々行っていく中で、QA業務に携わっている人であれば誰しもあるあると思われる事柄を題材に、普段我々が行っている取り組みを通して、QAの作業風景をご紹介できればと思います。
既にQAの作業に関しては、

• マネージャーのzumeが記述しているQAグループ紹介
• メンバーのokapiが記述しているQA業務の認知度向上

がありますので、合わせて読んでもらえればと思います。

本記事をきっかけに、
『自分たちの現場はこう対応しているよ』
『この作業はどう対応しています？』
など、いろいろご意見いただけると幸いです。

QA作業の流れと注意している視点

QAの作業については、主に

• 開発プロジェクトのQA実施
• 保守改修のQA実施
• テスト自動化
• QA内部改善
  • QA作業の改善活動
  • 勉強会

があります。　
今回は、この中で、プロジェクトに対して行うQA作業の流れを以下に示し、意識している視点についてご紹介します。

それぞれのQAへの思い

QA作業の概要に関しては、入社時のオリエンテーションや、各プロジェクトのkickoffで説明しています。ですが、プロジェクトに携わるメンバーは誰もが経験豊富な社員なので、それぞれの経験に基づいたQAへの理想イメージを持っています。そのため、QAではこういうところまで見てもらえるのでは？といった認識相違は担当者間でもしばしば起こります。ただ、QA範囲の認識違いはあっても、根本的には共通して

「品質で漠然と不安が残る部分を、QAのタイミングで何とかしたい」

と思っている方が多いかなという印象です。この不安部分にいかに寄り添い、不安を解消し、無事リリースを迎えるかがポイントになるかと思います。

まず最初に、Kickoffのタイミングで関係者にQA作業をイメージしてもらえるように、大きく下記の3点を説明しています。

①全員で一緒に品質を作りこんでいきましょう！！
②品質面で何か不安を感じたらいつでも遠慮なく相談してください
③QAの指摘は絶対ではなく、プロジェクトとして対応可否を検討しましょう

品質は「一緒に」作りこむ！！

①は、言わずもがなですが、QAだけの力では品質は向上しません。前述の認識相違の結果として、

• 単体レベルの細かい部分の確認
• ソース、データの流れを意識した確認

等の、ホワイトボックステスト寄りの依頼が出てくることがあります。
QAの作業はブラックボックステストが中心であり、ホワイトボックステストはQAよりむしろ開発側での実施が適しているので、そうお伝えしています。

このような依頼があるのは、今までQAで対応してもらった経験があったり、自分達では気づかない品質の不安をQAなら「きっと」見つけてくれる、という期待があるからかと思います。

QAの役割として、システムテスト、受け入れテスト、各工程のタイミングで確認することについては、関係者間での認識がある程度一致していても、その人の経験によっては、QAがソースやデータの流れを意識したシステム寄りな確認をしていた、ということもあれば、QAがユーザー視点を意識した確認を中心にしていた、ということもあります。
ただ、全般的には、QAとは開発全工程の標準化を含め、独自の指標を持って品質管理をサポートしてチェックしている部署、として幅広く認識されていると思います。

QAとしてそれぞれのその思いに応えたいとは思うものの、QAの気づきも限界がありますし、テストの期間も無尽蔵にあるわけではないので、限られた期間の中で、目標の品質を保証するべく、品質を「一緒に」作りこむという意識をもってもらうことが必要です。
ただ、QAが認識した要件を検証、指摘し、それを淡々と解消してもらうという関係ではなく、QAの仕様理解やテスト計画、テスト観点のタイミングで、
要件を 『一緒に』 すり合わせ
確認観点を 『一緒に』 認識合わせを実施し
改善内容を 『一緒に』 考える
ことで、品質にとって良い効果が生まれると思って活動しています。また、そこでしっかりお話しをすることでテスト設計にいかすことができます。

開発側の不安は、品質向上のヒントの泉

テスト観点のレビューなどで、開発側が思っている不安の内容が具体的になっているものは認識できるのですが、漠然とこの処理が怖いという内容のものもあります。この、具体的には言えないけどここの機能が品質的に不安、という情報は、QAがテスト観点を纏めたり、テスト設計をする上で重要です。根拠はないが、漠然とこの処理が不安というのは、例えば、コーディングが複雑とか要件がきちんと定まってない（処理としては要件を定めたつもりでも、細部まで詰め切れたか不安）など、特に問題なく開発できているので言葉にはできないけれども、なにかしら品質上不安に感じるところがある、という開発に携わっている方の 『勘』 ではありますが、意外とテストをしてみると想定していなかった不具合が発生したりするので、軽視できません。

QAとしては、要件を確認し、具体的な不安点に対して、テスト計画＆設計を行いますが、こういうお話こそが、QAとして試験を強化できるヒントであり、想定より厚めにテストを実施する対策を講じることができます。
QAの工程では、本来、単体・結合レベルの不具合を見つけるというよりは、要件に基づいて何百ケースを実施して、重要、もしくは、致命的な不具合を1件見つけることが腕の見せどころではあるので、この『勘』が外れることの作業の無駄を考えるより、そのヒントを多く聞き出せる雰囲気づくりをして、自由に意見を言ってもらい、確認観点の想定以外で強化できる点を認識することで、品質向上に向けたテスト設計を行うことができます。

例えば、テスト観点の打ち合わせの段階で、
「こういう観点で進めます何かあればご連絡ください。」
で終わるのではなく、一言、
「今回の仕様でどこか気になる点はあります？」
と付け加えることで、「そういえばね・・・」みたいな話しになることがあります。不安点はあるものの、漠然としていて、何を伝えればよいのかわからない、伝えることは無いなと思うより、QAにとりあえず話してみよう！！という雰囲気づくり、そこには、前述した、「一緒に」という姿勢も合わせて対応することで、検証観点の強化、ヒントの泉がそこには隠されています。

QAの指摘に惑わされず、本来のゴールを見失わない

一方的にQAの作業スコープしかテスト実施しないとお伝えすると、QAは

『コードも理解せず、要件をなぞるだけ、細かい指摘ばかりで、リリーススケジュールに影響を与えるところ』

というような誤解をされやすい部分もあります。
ですが、前述のような説明を事前に行うことで、QAは『一緒に』品質を作り上げていく集団であると、180度違った見方をしてもらえることにも繋がります。

とはいえ、見方が変わったからこそというのもありますが、逆に、信頼してもらえることによって、QAの意見を全て受け入れ、テスト実施時に『指摘』したものを全てクリアしないとサービスインできないのでは、と不安に思う方もいます。

ここでいうQAがテストを実施して『指摘』するのは、下記の三つになります。

• 不具合：QAが認識している仕様と異なった動作（表示）を指摘
• 改善要望：仕様としては問題なく、機能として改善したほうが良いのではないかという提案
• 質問：仕様で不明確な点を質問

不具合に関しては、こちらが認識している仕様と異なっていた場合に指摘を行い、開発側で確認の上、改修し、改修後にQAの確認作業が入ります。改善要望に関しては、仕様としては問題ないが改善したほうが良いのでは、という提案になります。例えば、その他の画面は右上にボタンがあるのに、途中の1画面だけ左上にあったりした場合、ボタンの機能としては問題ないが、右上の方が良いのではないか？といった内容です。質問に関しては、テストを実施してみると不明確な仕様部分に気づき、不具合として挙げる前に確認、という点から指摘します。

リリースまでにこれらの指摘を全てクリアにするべきかというと、そうではありません。全ての指摘の改修対応を行い、質問も解消されることが一番望ましいですが、プロジェクトの状況によっては何らかの理由で全て対応することが難しい場合があります。全ての対応が難しい場合、指摘した事象の重要度、優先度を加味して、サービスインまでに対応すべきかそうでないかの判断をQAではなく、プロジェクトとして判断してもらいます。

QAの作業は、要件をもとに
『本来こうあるべきだ』
という内容のもと、テスト実施をしていきます。当然、要件をしっかり詰めたはずでも、仕様が不明確な部分が出てくることもあります。それらの全てが対応されることも望ましいですが、限られた時間の中で、QAの指摘を通じて、最終的な仕様を確認し整理することで、本来のゴールを見失わないことが重要になります。

そこで、③のお話しになり、プロジェクトとしてどういったサービスをどのタイミングで提供するかを整理し、ゴールを見据えたうえで、そこに向かって目標の品質を作りこむ。そこにQAは、しっかり品質面でサポートしていくことが重要になります。
ここで、時間が無いのでやりたい要件だけ満たせばその他の品質に目をつぶって妥協してサービスを提供する、とも聞こえるかもしれませんが、そうではありません。

QAは、定義された要件が十分満たされているか、というプロジェクトのゴール設定に向かって対応するとお伝えしましたが、あわせて、使用されるお客様に不利益になるような問題に関しては粘り強く関係者と議論します。決して妥協するのではなく、また、QAの指摘を一方的に押し付けるのではなく、プロジェクトのゴールやサービスの提供を受けるお客様を意識して、プロジェクトとしてどう対応するのかを『一緒に』考えて、対策を講じます。

万が一、リリース後に致命的な不具合が出ると影響が大きいので、QAもしっかり付き合い品質向上に貢献していきます。とはいえ、規模の大きい案件ほど、懸念部分は②のヒアリングで早めに対処していくのと、開発工程の特性上、最後の最後で致命的な不具合が発生することはまずないので、QAの作業が理由でリリース日が変更されることはほぼありません。
あくまで目標のリリース日に向かって、『一緒に』目標の品質を作りこんでいく姿勢が大事になります。
なので、繰り返しにはなりますが、QAとしては、ただ指摘して改修を求めるのではなく、プロジェクトの本来のゴール、例えば、目標の期間までにお客様に提供したいサービスを確認し、そこを見失わず、お客様に不利益やご不便が無いことを配慮しつつ、プロジェクトで合意した品質の確保のため、とことん付き合い『一緒に』品質を作りこみます。

さいごに

今回は、QAとして取り組む姿勢や、コミュニケーションで気を付けている点を中心にご紹介しましたが、技術的な側面で言いますと、QAは各プロジェクト、プロダクトを横串でかつ、俯瞰して見れる唯一の部署です。その点ならではのサポートや、その他、テスト計画やテスト観点、テスト設計の仕方などについて、機会があればご紹介しようと思います。

今回、ご紹介した作業の流れで、恐縮されながらQA依頼を受けることがあります。ここは『一緒に』の姿勢なので、遠慮せずに協力し合える関係性を築いていきたいと考えています。そしてリリース後には、
『とても助かりました！！』
『ありがとう！！』
と声をかけられます。その時私はいつも、いえいえ、QAの指摘に対して、真摯に向き合って対応してもらってありがとうございます。と、プロジェクト関係者全員の取り組む姿勢に頭が下がるとともに、感謝をしています。提供するサービスに対して、QAが品質面でしっかりサポートする、という信頼関係をしっかり築けるよう、日々QAとして精進し、そうやって『一緒に』つくったサービスがお客様にとっても役立つものになれば、それこそがQAの醍醐味というものではないかなと私は思っています。今回の記事でQAという仕事に興味を持っていただければ幸いです。また、同じQAという立場で意見交換できればと思いますので、ご意見お待ちしています。ご意見はTwitterまで。

https://twitter.com/KintoTech_Dev/status/1619979941856280577?s=20