クライアントに社内QAテストを行うよう促すにはどうすればよいですか？

更新/明確化私のクライアントは社内テストの必要性を理解しており、彼らは常に「より良い」（つまり何かをする）ことを誓いますが、それは起こりません。彼らは外部テストのための予算を持っていません。「テストを早く、頻繁にテストし、ターゲットマシンのエトスでテストできるのは何なのか」と質問しているのでしょうか（漠然と認めていますが）。

質問：実稼働プロジェクトで「そのままテスト」するのではなく、新しいリリースの問題を明示的にテストして報告する時間をユーザーに促す方法。

背景：私には、マルチメディアプレゼンテーションツールのスイートを作成した小規模のクライアントがいます。彼らは素晴らしいクライアントであり、私たちは良い関係を持っています。このプロジェクトは進行中であり、機能を追加しています。

私には2つの問題があります。

1. 機能の定義はオンザフライで行われ、多くの場合電話で行われ、変更、修正、逆転の対象となります。（ケネディの「月に行って他のことをする」みたいなものです。私はいつもその「他のこと」の部分に面白がっています）

2. 実質的にQAテストは行われません。

私は＃1に多かれ少なかれ対処できます。これは、会議の前に仕様書を読むだけでなく、仕様書を書き上げるクライアントでさえありません。慣れてます。私が問題を抱えているのはアイテム＃2です。彼らは新しいリリースをテストしないか、テストしません。彼らがしているのは、それらを本番用に使用して、バグが発生したときに回避策を見つけて報告しないようにするか、プロジェクトに取り掛かるのが急いで、バグ報告が曖昧になるようにすることです。

私たちはこれについて多くの議論をしましたが、私はそれらを少しだけ調整することができました（たとえば、問題追跡にgithubを使用していますが、ほとんど使用しています）。根本的な理由は2つあります。彼らは小さなコンサルティング会社であり、テストのためのリソースを持っていません（または、外部委託する予算もありません）。そして文化的：彼らは自分たちを「開発者」と考えていますが、彼らは本当にマルチメディアソフトウェアパッケージのユーザーにすぎません。（例えば、彼らは「本物の」開発者の詳細に対する強迫神経症の注意をまったく持たない）。

これはあなたが期待するように私に影響を与えます：フィードバックなしでは、機能が完全かどうか（＃1を参照）または他の結果があるかどうかわかりません。また、私は少し怠け者になっています。

彼らは、「本物の」開発者の詳細に神経質な強迫観念を持たない

序文：ここで使用した言語の種類は、通常私にとって危険です。「本物の」開発者や（唯一の）「正しい」やり方について人々が話すのを聞くと、私はトンネルビジョンのカーゴカルト開発者のことを考え始めます。

今、あなたは間違いなくこれらの開発者の一人だと言っているわけではありません（それを主張する十分な証拠はありません）。

回答

あなたとあなたのクライアントはさまざまなことに最適化されているようです。多くの場合、ビジネスのニーズと開発者の欲求が必ずしも一致しないことがソフトウェアエンジニアリングの不幸な事実です。

ソフトウェア開発者は多くの場合、改善に焦点を当てた情熱的な人々です。彼らはソフトウェアのパフォーマンス、開発プロセス、ビジネスプロセス、コミュニケーション方法などを改善したいと思っています。それは素晴らしいことです。これらのことに焦点を当てることが、職人と職人を心のないキープッシャーと区別するものです。

しかし、あなたのクライアントはソフトウェア職人ではありません。あなたのクライアントは、優先順位がまったく異なる企業です。そして、時々、それらの優先順位は私たちのソフトウェア職人にとってばかげているように見えます...しかし、それは私たちがさまざまなもののために最適化しているからです。

ビジネスは、市場への早期リリースや短期的なコスト削減などの最適化を頻繁に望みます。その際、QA、ユーザーエクスペリエンス、長期的なコスト削減など、開発者の気を引くものを犠牲にする必要があります。

それは悪いことですか？まあ、必ずしもそうではありません。すべてのビジネスについて話すことはできませんが、私の経験では、クライアントは自分のROI（投資収益率）を高めるためにこれらのことを行います。QA、UXの改良、長期計画などを行うと、ROIが低くなります。さらに悪いことに、多くの企業は、持続可能なアプローチと長期的な勝利とは対照的に、短期的な勝利のみ​​に報いる投資構造を持っています。

だから、あなたがしながら、可能性があなたの時間を無駄にし、彼らとあなたの関係を緊張することができる、あなたのクライアントにQAのアイデアを販売してみてください。最良のケースでは、誰かがあなたのアイデアを試してみたいと思います（そうではないでしょう）。最悪の場合、QAなどの長期投資が報われるように、会社全体にインセンティブ構造を作り直すよう説得する必要があります。どちらの場合でも、成功する可能性は低くなります。

おもしろい質問は、あなたがあなたのクライアントが彼ら自身のテストをするかどうかではなく、あなたが支払いを受ける時です。

• 時間に基づいて支払いを受ける場合、問題ありません。
• 事前に支払いを受ければ問題ありません。
• クライアントがプロジェクトを「完了」と宣言したときに支払いを受ける場合、大きな問題です。

問題は、クライアントがソフトウェアを受け入れて支払いを行う時期を知る方法です。クライアントがあいまいに定義された新しいリクエストでプロジェクトを継続的に修正する場合、これは明らかに機能しません。これが、給料日が常に延期されることを意味する場合-そして、各リクエストによってより可能性が低くなる-これはあなたにとって受け入れがたいものになります。

すべての機能を注意深く指定し、クライアントがこれらの機能を受け入れる条件を定義する固定契約は明らかに非常に不快なほど厳しいものですが、事前にプロジェクト（次のプロジェクトも）を計画することができます。また、仕様どおりであれば、提供したソフトウェアの費用を確実に受け取ることができます。そのようなシナリオでは、クライアントの唯一の責任は、契約定義フェーズ中、および受入テストの最後です。

クライアントが行うこのような受け入れテストは、他の形式のテストとは異なります。

• 単体テスト
• システム統合テスト
• ユーザビリティテスト
• 負荷試験
• プレリリーステスト

できる限り、受け入れテストを予想して、機能を提供する前に、恥ずかしさを回避するために自分でテストを実行します。受け入れテスト（ソフトウェアの品質ではなく、契約履行のみを測定する）を除き、すべての品質保証はお客様の責任です。特に、クライアントにはQAの考え方、必要な技術的背景、またはQAを行う契約上の義務があるとは限りません。また、クライアントへのバグハンティングのアウトソーシングは非常に専門的ではありません。

バグが発生しないと言っているわけではありません。クライアントとプロジェクトベースの関係があると仮定すると、丁寧で迅速な修正を提供し、現在のリリースをニーズに応じて十分に受け入れていることを説明します。大きな変更には新しい契約が必要です。継続的なサポート契約を結んでいる場合は、当然、合意したサービスレベルに固執する必要があります。

アジャイル設定では、クライアントのニーズに応えることは契約書に固執することよりも重要ですが、それでも支払いを受けたいと思うでしょう。したがって、多くのアジャイル指向のプロジェクト手法では、クライアントがチームの一員になるまで、クライアントとの密接なやり取りを重視しています。その後、いつでもこの「製品所有者」に相談して、必要な点を明確にすることができます。POには、価値のある機能に取り組む時間を与える権限があるため、あいまいなクライアントのニーズから始めても機能します。このような緊密なコミュニケーションがない場合は、より正式なアプローチに従う必要があります。

• 新しい顧客のニーズを知ったら、顧客と協力してそれらを要件に変換します。これにより、クライアントは実際に必要なものを取得できます。
• 要件は客観的に測定可能であり、満たされているかどうかのいずれかです。これにより、クライアントはその種の作業のみの半分のソリューションから救われます。

• すべてのクライアントリクエストは、請求できるように書面で提供する必要があります。これにより、ボタンを別の位置に配置するように要求するときにインターフェイス全体を書き換えるなど、作業していると感じたものに対して請求されることから保護されます。

  多くのコミュニケーションは直接または電話で行うことができますが、最後に、クライアントがこれらの要件に取り組むことを望んでいたことを文書に記録する必要があります。単純なケースでは、電話を振り返り、メールを送信して、彼らがあなたに何をするように頼んだかを確認するだけで十分かもしれません。

バグ報告は常に困難です。クライアントが開発者自身である場合、彼らはあなたのニーズを理解できるので、助けてくれるはずです：再現するための明確なステップを持っています。強力な洞察を得るための簡単な方法は、展開されたソフトウェアのログを有効にすることです。データプライバシーの問題を解決できる場合は、すべてのバグレポートに最新のログを添付する必要があり、書面によるコミュニケーションを保証するだけでなく、ユーザーが実際に何をしようとしていたのかを伝えます（彼らがしようとしていたこととは対照的に） 。

バグのコミュニケーションを促進する方法は、機能の頻繁で詳細なコミュニケーションを促進することです。セレモニーなしで何かを要求できるように会社をトレーニングすると、マイナーなバグにもその機能を使用します。これらの変更によりクライアントの作業が楽になる場合を除き、クライアントのワークフローの変更をあきらめます。

クライアントに社内テストを行わせるのは困難ですが、実際にバグを報告するように依頼することは、思ったほど難しくありません。より多くのフィードバックを得る方法は、ユーザーの摩擦を減らすことです...たとえそれがその摩擦の一部を自分自身に移すことを意味するとしてもです。

1. これらのツールが不適切で不適切であっても、よりシンプルなツールを使用してください。たとえば、BaseCampはかなりひどいバグトラッカーです（プロジェクト管理を目的としているため）が、人々は実際にそれを使用したいと思っています。

2. 使用していたバグトラッカーはイメージのコピーと貼り付けをサポートしていなかったので、実際には、現在のクリップボードイメージをディスクに（GUIDとして）コピーし、GUIDをクリップボードにコピーする簡単なプログラムを作成しました。最小限のトレーニングの後、ユーザーは、印刷画面を押してボタンをクリックし、バグ送信ツールのファイル選択ダイアログに貼り付けるだけで、クリップボード画像を問題に添付できます。

ほとんどの機能/バグを特定するには、スクリーンショット（注釈付きでMS Paintで編集されている可能性があります）と1〜2文で十分です。

これらの提案はどちらも、私が経験した摩擦点を対象としています。これらの提案は両方とも、レポートを10倍以上増やしました。ただし、独自の摩擦点を対象とする必要があります。

クライアントのテストを簡単にしますが、実稼働環境でテストされていないバージョンの新しい機能をクライアントが使用するのを本当に難しくします。これは次のように実行できます。

新しい機能を提供するときはいつでも、最初に「ベータ版」でこれを実装します。「ベータ版」には、「本番用ではない」という記号がはっきりと示されています。このベータ版をテスト用にクライアントが利用できるようにします。また、彼は実際の生産に使用する最新の「プロダクションバージョン」（新機能なし、ただし最新のバグ修正を含む）を提供します。クライアント側は少なくとも最初に試してみました。

クライアントがプログラムを開始するたびに「本番では使用できません」という大きなメッセージを常に表示しているにもかかわらず、実際の本番データでベータ版を使用し始めた場合、彼を助けることはできません彼は明らかに彼のせいであるという誤った目的のためにベータを使用したため、動作します。クライアントがそれから学習しない場合、結果が「ベータ」でディスクに保存するなどのいくつかの重要な機能を無効にすることにより、クライアントが実稼働で「ベータ」を使用する機能を無効にすることを検討できます。

個別の「ベータ」を提供すると、適切なバージョン管理/構成管理を確立する必要があります。そのため、実稼働ブランチとベータテストブランチを手間をかけずに並べて管理できます。しかし、Githubで作業しているので、すでにGITのようなものを使用していると思います。これにより、この種の管理が非常に簡単になります。