【テストを段取る!】QAとしての信頼の失い方(やってはいけない)[続き]

コミュニケーションは大切

みなさんこんにちは。HC村谷です。

前回は、QAはまず相手からの信頼がベースでそのうえで実務がないと余計なオーバヘッドが発生しますよ、そして、信頼を損ないそうなケースにはこういうものがありますよ、という内容でした。

そして今回はその対策としてのアプローチを考えてみようと思います。

——–
起:QAが信頼を失ったら相手は何を信じたらよいのか分からない(前回)
承:QAが「失敗してしまう」ケース(前回)
転:「やらかさない」ためのアプローチ
結:まとめ
——————————————————————-

◆「やらかさない」ためのアプローチ

前回「やり方を失敗する、機嫌を損ねる行為って何か?」の項で挙げた、それぞれの例について、
アプローチ方法を考えてみます。

◇コミュニケーション
—————————————-

  • 関係者との情報伝達や意思疎通が取れていない(この場合、最悪のケースはリリース遅延を起こすかテスト漏れのままリリースされる)
  • 要求を決めていたり、権限を持っているキーマンが誰かを把握していない
    (ステークホルダ特定失敗。これを掴んでいなければ、現場の一意見に振り回されていつまでもコミットできない状況が続き、QAはどうなっているんですかと言われそう)
  • ヒヤリングすべき情報を誰が持っているのかを把握していない
    (又はどの資料に記載されているのか)

—————————————-—————————————————————————-

想定される関係者には様々なステークホルダー(経営幹部、マネージャ、ディレクター、開発担当者)がおり、権限の範囲も様々ですが、一般的に大きな権限を持っている関係者との情報共有に齟齬があるほど、影響は大きくなります。

それぞれで担当している役割や範囲が異なるため、一部の情報だけを正として業務を進めた
結果、上記のような悲惨な結果が待っていることがあります。

現場や業務のスタイル、人、訊くタイミングによっても内容が変わったり、関係者間においても認識の違いがあるかもしれませんから、面倒でもいちいち確認を取っておくことが必要です。

言った言わないの無駄な議論もよく発生しますから、ベタな方法ですが、議事録などの記録を後で回覧しておくのが自分の認識漏れも防止できて良いと思います。

私たちのような外部企業がお客様の傍で業務する時には、全体的な体制や窓口を把握することが最初の重要な仕事になります。場合によっては担当者が複数人いたり、明確に窓口が決まって
いない場合もありますから、早く情報を正確に把握できるルートを確立することが非常に大切だと
思います。

ちなみに、以上のことは、こちらから出す報告や連絡事項を伝える宛先についても同じです。
情報の出し先を間違ったり、出しっぱなしにしていると、本来伝えるべき相手に見てもらって
いなかったという状況が起こります。
必ず相手の反応をこまめに確かめておくことで、齟齬を防止できると思います。

◇スコープ
—————————————-

  • 相手の要求を理解していない、または浅い 

    (気づくのが遅くなればなるほど、手戻りが大きくなりテストやり直しに繋がる)

—————————————-—————————————————————————-

相手の要求を理解していない、または浅いというのは、話を聞いた後のどこかで発覚し、後になればなるほど影響が大きくなります。

こうならないために、要求が出てきた時点で「こういう事を言っていますか」などと、確認を取って
相手の向いている方向と同じ方向にベクトルを合わせておかないといけません。
要求に対しどういうテストを行うかなどの戦略を決めるのはQAですので、要求されている内容を
掴むことと、行うテストの根拠を分かりやすく説明して合意するようにします。

—————————————-—————————————————————————-

  • QAとして何をやって、現場でどう動かしていくのかをイメージ立てできない場合、相手からQAをどのように考えているのか、と言われかねない

—————————————-—————————————————————————-

ここもヒヤリングができているかどうかに関係しているのですが、今回のQAをどこまで行えば
良いのか、つまり、どこからQAとして入って、どの辺のことを押さえて、開発のどんな情報を見て
品質をコントロールして、いつまでにどこまで行けば一旦終わり、などの一連の流れについて、
大まかに考えることができるか、できないかということです。

また、テストを実施するフェーズを考えた場合、プロジェクトの最初から何らかのテストが稼働して
いる場合もあるでしょうが、プロジェクトも後半戦に入った頃に本格的なテストが開始され始める
ということも多いと思います。

そういった場合には、プロジェクトも佳境を迎えていて、テストの範囲やスケジュールが予め決まって(決められて)いる場合もあります。しかし、そういった場合でもQAとしてそれが妥当なのかどうかの判断は必要です。
こちらの想定とピッタリであれば言う事はありませんが、不足していた場合は時間との鬩ぎあいに
なります。

どうしてもそれ以上取れ(引き延ばせ)ない場合には、どういう方法があるでしょうか。
すぐに思いつくのは、以下のような手段ですが、下に行けばいくほど、リスクが大きいような気が
しました。

まず
示して (テスト削減によるリスクを責任者に)、

ⅰ.延ばす (リリースを)
ⅱ.削る  (テスト不足の機能を)
ⅲ.増やす (テストの人員を開発から)
ⅳ.増やす (テストの人員を外部から)
ⅴ.削る  (優先度の低いテスト項目を)

一方、とられている予定が想定より多い場合は、どうでしょうか。
想定の根拠を確認したほうが良いと思います。ひょっとすると単に多く取られていただけかも
しれないですが、そうでなければこちらの認識しているスコープに漏れが出ているかもしれません。

いづれにしても理由を聞く、理由を示すということが非常に大事だと感じます。

—————————————-—————————————————————————-

  • 相手に訊くべきことと、QAで考えるべきことが整理できていない

—————————————-—————————————————————————-

テストへの要望事項には「△△機能と□□機能についてお願いします」や「○○周りを中心に全体の
テストを万遍なく」など比較的、範囲やポイントが決まっている場合もありますが、新規リリース時や、「アプリがちゃんと機能するか検証」のように全てに対して動作を確認しなければならない場合も
あると思います。

特に前者の場合ですが、範囲が決まっているのには理由がありますので、まずはその理由をこちらも理解しておく必要があります。

○○機能だけと言われていても、その機能の影響が今回特に範囲に含まれていない機能に及んで
いる場合もありますので、それの考慮が相手にあるかどうかの確認とテスト実施の有無は確認する必要があります。もし、これらの確認を行っておかなかったら、テスト漏れのリスクが高まります。

一方、必要情報を取得してからのテストの実施方針や、どれくらいの規模で実施ができるかなどはこちらで考えて提案していくものです。

この辺のさじ加減を間違うと、QAの役割を問われるというか、信頼性が下がるかもしれないなと
感じます。

今回で全て書き切るつもりでいましたが、1つ1つが少し長くなってしまったため、残りは次回以降へ持ち越します。書いたことが一部でもお役に立てば幸いです。

このエントリーをはてなブックマークに追加