私は生計を立てるためにウェブアプリを構築しています。
クライアント/ユーザーの受け入れテストは、重要ですがしばしば苦痛を伴うプロセスです。
このプロセスをどのように管理していますか?
すなわち、どのようにそれらをテストするのですか? 彼らにテストスクリプトを渡しますか? バグをログに記録し、要求/フィードバックを変更するためのシステムを彼らに提供しますか? バグと機能変更の違いをクライアントに理解してもらうにはどうすればよいですか?
バグ/問題を作成するための反復可能な手順をクライアントに提供してもらうにはどうすればよいですか?
このプロセスを管理するための優れた Web アプリ (これには Basecamp のようなアプリが非常に役立つと考えています)
ありがとう、
エド
テストスクリプトを提供しないでください。
私にとって、テストケースを考えている場合、ソフトウェアはおそらくそれらを考えているのでそれらを処理するので、テストプロセスを大幅に無効にします。
優れたテストの考え方は、テストにはある程度の独立性があるため、既知のテストケースに対応できず、クライアントはあなたが考えないシナリオを考える可能性が高いということです。これが全体のアイデアです。
しかし、どのように彼らをやる気にさせますか？まあ、正直なところ、やる気がなかったらびっくりします。私は一般的に、機能の仕様、要件、およびその他の予備的なドキュメントについてコメントするように彼らを動機付けることは、はるかに困難な戦いであることに気づきました。テストを開始するまでに、ソフトウェアが「本物」であるという重要な心理的ハードルを取り除きました。
これをどのように処理するかは、クライアントとの関係の性質に大きく依存します。合意された仕様の正式なプロセスがある場合は、クライアントがソフトウェアをサインオフして受け入れるための一定の期間があり、何もしないことは受け入れを意味するということを実際に言っているはずです。
それが内部クライアントである場合、それはより困難です。おそらく、プロジェクトを推進しているのは誰なのかということです。利害関係者は誰ですか？これらはあなたがそのような活動をやる気にさせるために必要な人々です。
通常、クライアントのテストで私が遭遇した最良の方法は、問題のスクリーンショットと、問題を作成するために行ったいくつかのことをクライアントに送信させることです。この時点で、ほとんどのテストは社内で行われているはずであり、ひどいバグは取り除かれているはずです。エラーが発生したことを自動的に電子メールで送信するシステムがあると、テスト中であることがわかり、電子メールのスタックトレースからほとんどの厄介な詳細を取得します。