社内でQAテストを実施するようクライアントに促すにはどうすればよいですか？
更新/明確化私のクライアントは社内テストの必要性を理解し、彼/彼らは常に「より良いことをする」と誓います"（つまり、何かをする）しかし、それは起こりません。彼らには、外部テストの予算がありません。何を「早くテストし、頻繁にテストし、ターゲットマシンの精神でテストするか」について、何を植え付けることができるかについて私は（漠然と認めます）質問していると思います。
質問：プロダクションプロジェクトで「test-as-they-go」ではなく、新しいリリースの問題を明示的にテストして報告するために時間をかけるようにユーザーに促す方法。
背景：マルチメディアプレゼンテーションツールのスイートを作成した小さなクライアントがいます。彼らは素晴らしいクライアントであり、私たちは良い関係を持っています。プロジェクトは進行中で、進行に応じて機能を追加しています。
私には2つの問題があります。
機能の定義はオンザフライで行われ、多くの場合電話で行われ、変更、修正、取り消しが行われることがあります。 （ケネディの「私たちは月に行って他のことをします」のようなものです-私はいつもその「他のこと」の部分で面白がっていました）
QAテストは実際には行われません。
私は＃1に対処できます。これは、会議の前に仕様を読んだり、仕様を書いたりするクライアントではありません。慣れてます。それは私が問題を抱えているアイテム＃2です：彼らは新しいリリースをテストしないか、テストしません。彼らがすることは、バグが発生したときに回避策を見つけてそれを報告しないか、プロジェクトに取り掛かるためにバグ報告が曖昧なほど急いでいるため、それらを本番環境で使用することです。
これらすべてについて多くの議論がありましたが、私はそれらを少しだけ判断することができました（たとえば、問題追跡にgithubを使用しますが、ほとんどは私が使用しています）。根本的な理由は2つあります。それらは小規模なコンサルティング会社であり、テストのためのリソース（またはそれを外部委託するための予算）がない（または持っているとは思わない）。そして文化的：彼らは自分自身を「開発者」と考えていますが、実際にはマルチメディアソフトウェアパッケージのユーザーにすぎません。 （例えば、彼らは 強迫神経症 「本当の」開発者の細部への注意）。
これはあなたが期待するように私に影響します：フィードバックなしでは、機能が完全であるかどうか（＃1を参照）、または他の結果があるかどうかはわかりません。それはまた私を少し怠惰にしています。
彼らは「本当の」開発者の細部にこだわる神経症の注意を払っていない
序文：ここで使用した言語の種類は、通常、私にとって危険信号です。 「実際の」開発者、または（唯一の）「正しい」方法について人々が語るのを聞くと、私はトンネルのビジョン cargo-cult開発者 について考え始めます。
さて、あなたが間違いなくこれらの開発者の1人であると言っているわけではありません（私はそれを主張するのに十分な証拠がありません）。
回答
あなたとあなたのクライアントはさまざまなことに最適化しているようです。ソフトウェアエンジニアリングでは、ビジネスのニーズと開発者の欲求が必ずしも一致しないことがよくあります。
ソフトウェア開発者はしばしば、改善に焦点を当てた情熱的な人々です。彼らはソフトウェアのパフォーマンス、開発プロセス、ビジネスプロセス、通信方法などを改善したいと思っています。それは素晴らしいことです。これらのことに焦点を合わせることが、職人と職人の女性を無知なキープッシャーから分離するものです。
しかし、あなたのクライアントはソフトウェア職人ではありません。あなたのクライアントは、まったく異なる優先順位を持つビジネスです。そして、時々、それらの優先順位はソフトウェア技術者にとってばかげているように見えるかもしれません...しかし、それは私たちがさまざまなことに最適化しているからです。
企業は頻繁に、市場への早期リリースや短期的なコスト削減などを最適化したいと考えています。そうすることで、QA、ユーザーエクスペリエンス、長期的なコスト削減など、開発者を悩ませるようなことを犠牲にする必要があるかもしれません。
それは悪いことですか？まあ、必ずしもそうではありません。私はすべてのビジネスについて話すことはできませんが、私の経験では、クライアントは自分のROI（投資収益率）を高めるためにこれらのことを行います。 QA、UXの改善、長期計画などを行うと、ROIが低下します。さらに悪いことに、多くの企業は、持続可能なアプローチや長期的な勝利とは対照的に、短期的な勝利にのみ報いる投資構造を持っています。
したがって、あなたがQAのアイデアをクライアントに売り込もうとしている間、時間を浪費し、クライアントとの関係に負担をかける可能性があります。最良のケースでは、誰かがあなたのアイデアを試してみたいと熱望します（そうではありません）。最悪の場合、QAなどの長期的な投資が報われるように、インセンティブ構造を再構築するように会社全体を説得する必要があります。どちらの場合も、成功の確率は低いです。
おもしろい質問は、いつ支払われるかであり、クライアントが独自のテストを行うかどうかではありません。
- あなたがあなたの時間に基づいて支払われるなら、問題ありません。
- 事前に支払いを受けても問題ありません。
- クライアントがプロジェクトの「完了」を宣言したときに給与が支払われると、大きな問題になります。
問題は、クライアントがソフトウェアを受け入れ、支払いをいつ受け取るかを知る方法です。クライアントが漠然と定義された新しいリクエストでプロジェクトを継続的に修正する場合、これは明らかに機能しません。これが支払日を常に延期することを意味し、各リクエストによって可能性が低くなる場合、これはあなたにとって受け入れられなくなります。
すべての機能を慎重に指定し、クライアントがこれらの機能を受け入れる条件を定義する固定契約は明らかに非常に不快なほど厳格ですが、事前にプロジェクトを計画することができます（次のプロジェクトも）。また、提供されたソフトウェアが仕様に準拠している場合は、そのソフトウェアからお金を得ることが保証されます。このようなシナリオでは、クライアントの唯一の責任は、契約定義フェーズ中、そして最後に受け入れテストです。
クライアントが行うこのような受け入れテストは、他の形式のテストとは異なります。
- 単体テスト
- システム統合テスト
- 使いやすさテスト
- 負荷テスト
- プレリリーステスト
恥ずかしさを避けるために、機能を提供する前に、可能な限り、受け入れテストを予想して自分で実行します。受け入れテスト（契約の履行のみを測定し、ソフトウェアの品質を測定しない）を除いて、すべての品質保証はお客様の責任です。特に、クライアントは必ずしもQAの考え方、必要な技術的背景、またはQAを行う契約上の義務を負っていません。また、クライアントへのバグハンティングのアウトソーシングは専門家ではないことがわかりました。
バグが発生しないと言っているのではありません。クライアントとプロジェクトベースの関係にあると仮定すると、丁寧な対応と迅速な修正の提供の間に線を引き、クライアントが現在のリリースをニーズに十分に応じていることを説明する必要があります。大きな変更には新しい契約が必要です。継続的なサポート契約を結んでいる場合は、もちろん、同意したサービスレベルを維持する必要があります。
アジャイルな設定では、クライアントのニーズに対応することは、契約書にこだわるよりも重要ですが、それでも報酬を受け取りたいと思うでしょう。したがって、多くのアジャイル指向のプロジェクト方法論では、クライアントがチームの一員になる可能性がある点まで、クライアントとの密接なやり取りを重視しています。その後、いつでもこの「製品所有者」と話し合って、必要なポイントを明確にすることができます。 POは、価値があると思われる機能に取り組む時間をあなたに与える権限を持っているので、あいまいなクライアントのニーズから始めても機能します。このような緊密なコミュニケーションがない場合は、より正式なアプローチに従う必要があります。
- 新しい顧客のニーズを知ったら、顧客と協力してそれらを要件に変換します。これにより、クライアントは実際に欲しいものを手に入れることができます。
- 要件は客観的に測定可能です–要件は満たされているか、満たされていません。これにより、クライアントは、ある種の作業のみのハーフソリューションから救われます。
すべてのクライアント要求は、請求できるように書面で提供する必要があります。これにより、ボタンを別の方法で配置するように要求したときにインターフェイス全体を書き換えるなど、作業をしたいだけの請求が発生するのを防ぐことができます。
多くのコミュニケーションは対面または電話で行うことができますが、最後に、クライアントがこれらの要件に取り組むことを望んでいることを記録した一枚の紙が必要になります。単純なケースでは、電話の内容を要約し、彼らにあなたに何を要求したかを確認するための電子メールを送るだけで十分かもしれません。
バグレポートは常に困難です。あなたのクライアントが開発者である場合、彼らはあなたのニーズを理解できるので助けになるはずです：再現するための明確なステップがあります。強力な洞察を得るための簡単な方法は、デプロイされたソフトウェアのロギングを有効にすることです。データプライバシーの問題を解決でき、すべてのバグレポートに現在のログを添付するよう要求することで、書面による通信が保証されるだけでなく、ユーザーが実際に行ったことを（ユーザーが行おうとしていたとは対照的に）伝えることができます。
バグの伝達を促進する方法は、機能の頻繁で詳細な伝達を促進することです。セレモニーなしでanythingを求めることができる会社を訓練する場合、彼らはマイナーなバグにもその機能を使用します。クライアントのワークフローの変更をあきらめないでください。これらの変更によってクライアントの生活が楽にならない限りです。
クライアントに社内テストを行わせるのは難しいですが、実際にバグを報告してもらうのはそれほど難しいことではありません。より多くのフィードバックを得る方法は、ユーザーの摩擦を減らすことです...たとえそれがその摩擦の一部を自分に転送することを意味する場合でも。
それらのツールが不十分で不適切であっても、より単純なツールを使用します。たとえば、BaseCampは（プロジェクト管理を目的としているため）かなりひどいバグトラッカーですが、実際に人々はそれを使用しようとしています。
使用していたバグトラッカーはイメージのコピーと貼り付けをサポートしていなかったため、現在のクリップボードイメージをディスクに（Guidとして）コピーし、次にGuidをクリップボードにコピーする簡単なプログラムを実際に作成しました。最小限のトレーニングの後、ユーザーは印刷画面を押してボタンをクリックし、バグ送信ツールのファイル選択ダイアログに貼り付けるだけで、クリップボードの画像を課題に添付できます。
スクリーンショット（注釈付きでMSペイントで編集されている可能性があります）と1〜2文で、ほとんどの機能/バグを特定できます。
これらの提案はどちらも[〜＃〜] i [〜＃〜]が経験する摩擦点をターゲットにしており、これらの提案はどちらもレポートを10倍以上増加させました。ただし、次のことを行う必要があります。自分の摩擦点をターゲットにします。
クライアントのテストを簡単にしますが、クライアントが本番環境のテストされていないバージョンの新機能を使用するのを非常に困難にします。これは次のようにして達成できます。
新しい機能を提供するときはいつでも、これを「ベータ版」で最初に実装し、「本番用ではない」という記号を明確に付けます。このベータ版をクライアントがテスト用に利用できるようにします。また、彼が実際のプロダクションに使用する最新の「プロダクションバージョン」を提供し（新機能なし、ただし最新のバグ修正を含む）、誰かからのフィードバックが得られるまで、新しいベータ機能をプロダクションバージョンに転送することを拒否します。クライアント側は、少なくとも最初にそれを試しました。
クライアントが実際の本番データでベータ版の使用を開始しても、プログラムを開始するたびに「本番用ではありません」という大きなメッセージが常に表示される場合、クライアントを助けることはできませんが、少なくとも本番データが失われるたびにそれを明確にした彼が間違った目的でベータを使用したので、それは明らかに彼のせいです。クライアントがそのことを学習しない場合は、必要に応じて、結果を「ベータ版」のディスクに保存するなどの重要な機能を無効にして、本番環境で「ベータ版」を使用するクライアントの機能を無効にすることを検討してください。
個別の「ベータ版」を提供すると、適切なバージョン管理/構成管理を確立する必要があるため、本番ブランチとベータテストブランチを面倒なく並べて管理できます。しかし、Githubを使用しているので、GITのようなものをすでに使用していると思います。これにより、この種の管理が非常に簡単になります。