株式会社GENZが運営する技術ブログです。

  1. QA・テスト
  2. 84 view

改善要望案をどこまで開発に投げるべきか

前の記事はこちら
テスト実施期間において実施者からの改善要望が上がってくることがあると思います。
その際、スケジュールに余裕があったり、開発側も忙しくない時は「一旦上げてみよう」となるかもしれません。

ですが、スケジュールがタイトでかつ開発も忙しい時はどうでしょうか。

以前テストケースの実施期間中において、スケジュールもタイトでかつ開発側も忙しく、実施者からの改善要望があった際にどこまで投げるべきか悩んだことがあります。

今回はその時にどんな対応したのか、また板垣社長に相談した際のことを書こうと思います。

リリース日が近い+開発が忙しい→どこまで開発に投げるべき?

先程も述べましたが、比較的スケジュールの余裕がある場合は「一旦改善要望としてチケットを切っておこう」ということもあるかと思います。
ですがこの時は、リリース日が近い+開発が忙しいという状況で、改善要望のチケットを確認する事自体に時間を取らせるのもどうなのかという状況で、普段上げていたような内容の改善要望であっても上げるのに躊躇することが何度かありました。

ではこの時どのように対応したのかと言いますと、

okラインまでもっていく事を優先するため、下記基準で主に判断しておりました。

【改善要望として上げると判断したもの】
・現状でも大丈夫だと思われるが、実際にユーザー側で不便や支障(お客様の作業を止め得るなど)が出得る可能性がもしかしたらある事。また対応してくれる事でユーザビリティが明らかに改善する事。

・仕様上は問題ないが、対応してくれる事で意図しない設定となるのを防ぐのに繋がること(ユーザー側の思い込みなど)。

【上げないと判断したもの】
・気にはなるが対応してもしなくても明らかな誤操作や不便につながらないと思われる事(デザイン上は見栄えは良くなるかもな事)

ですが正直、この対応が良かったのか自信がなかったため、板垣社長に相談させいただきました。
(一語一句が貴重なアドバイスなので、なるべく加工せず、やり取りしたままの形で載せてあります)

自らの判断でその場に応じた適切な対応をする

板垣社長:
「まず概ね判断してるポイントに関しては特に絶対的に間違っているとか、足りてないってことがある、というわけではないと考えます。

開発のスピード感やQAから上がってくる細かい指摘をすべて反映していたらいくら開発工数があっても足りなくなるのは明白ですし、かといって何もしないとなるとUI/UXが置き去りになってしまうので、そう言う意味では誰しもが悩むポイントではあります。

これに関しては極論で言うと、お客様先が何を望むのかを可能であればヒアリングする、見極めることが必要不可欠です。
もっと言うと相手の担当者がどこまでを望んでいるのかっていうところにどこまで我々が寄り添えるかって話になってきます。

そういう意味では今回の対応はお客様のリリースやその他の状況を考慮して、あえて上げないものも許容するって言う判断をしているので、これはこれでむしろ正解です。
なんなら、ちょっと前までなら「全部あげなきゃ」って言ってホントに全部を律儀にあげようとしてたんじゃないかな、とか思ってみたりしますけど、取捨選択を自分の意思で対応できるようになってることが素直に嬉しいですな。

これ僕からの答えとしては、自らの判断でその場に応じた適切な対応をする。で、一回決めた対応はよっぽどのことがない限り曲げない、これをケースバイケースで行う、ということです。」

板垣社長のご回答の通り、確かに以前なら「こういう改善案を出すのもQAの仕事なんだからとりあえず上げなくちゃ」となっていたと思います。
ですが今回はスケジュール的に優先するべきタスクを終わらせなきゃという事もあり、上げるべき理由がはっきり説明できるものに絞っていました。

なのでこのようにFBをいただいたことで、この時自分が行った対応の方向性が間違っていないと少し自信がついたと同時に、正解がないからこそ日々の業務の中でその場に応じた自分なりの判断基準をもつことの大切さを再認識しました。

また、「この時は上げないと判断したが後日上げるというのもありかな?」と思ったりもしましたが、
いただいたお言葉の通り、よっぽどのことがない限りはその時に決めた対応でそのまま進める、という方針でいこうと思いました。

それと個人的なことですが「素直に嬉しい」とのお言葉をいただけたことが物凄く嬉しかったです。

「これが正解」がないのがQAの世界。その時に正しいと思う対応をできたか、できなかったか、の差しかない

板垣社長:
「以前から何度も言ってる通り、数学やプログラムみたいに「これが正解」っていうのがない世界なのでQAっていうのは。そのときに正しいと思う対応をするか、できなかったか、の差しかないです。
これも難しいと思いますが、少しずつ慣れていって自分の基準を作るってのが近道であり王道であり、です。」

これからもきっと、どのように判断するべきか、その時に応じた最適解とは何か、沢山迷う場面が出てくると思いますが、
QAとして何を求められているのか、そしてその時に正しいと思える判断基準を自分の中でしっかりつくれること、
その感覚をこれからも磨いていきたいと思います。

 
 
<過去の記事>
テストケース作成で明確に仕様が決まっていない場合の「期待値」作成について
メンターとして何から始める?まずは相手を知ること!
メンターとなった経緯と意気込み
GENZ、メンター制度始めます

採用サイトはこちら

QA・テストの最近記事

  1. 改善要望案をどこまで開発に投げるべきか

  2. テストケース作成で明確に仕様が決まっていない場合の「期待値」作成について

  3. 自動化だけがすべてじゃない?!テストプロセス効率化の最適解

  4. GASでGoogleチャットに流すリマインダーを作ってみた

  5. ソフトウェアテスト品質を高めるためのテスト会社活用方法

関連記事