나는 생계를위한 웹 앱을 만듭니다.테스트 클라이언트를 얻는 방법
중요하지만 종종 고통스러운 프로세스는 클라이언트/사용자 수락 테스트입니다.
이 프로세스를 어떻게 관리합니까?
즉 테스트를 어떻게 받습니까? 테스트 스크립트를 제공합니까? 버그를 기록하고 요청/피드백을 변경하는 시스템을 제공하십니까? 버그와 기능 변경의 차이점을 고객이 이해하도록하려면 어떻게합니까?
어떻게하면 클라이언트가 버그/문제를 만드는 데 반복 할 수있는 단계를 제공합니까? 이 과정을 관리하기위한
모든 좋은 웹 애플리케이션
감사합니다,
에드
을 포기하지 마십시오 테스트 스크립트 (응용 프로그램 같은베이스 캠프 생각이 매우 uesful 될 것이다).
내게 테스트 프로세스를 무효로 만드는 것은 테스트 케이스를 생각할 때 소프트웨어가 생각했기 때문일 수 있기 때문입니다.
좋은 테스트 아이디어는 테스트에서 독립성이 있다는 것이므로 알려진 테스트 케이스를 처리 할 수 없으며 클라이언트는 사용자가하지 않을 시나리오를 생각할 가능성이 있으며 이는 전체 아이디어입니다 .
하지만 어떻게 동기를 부여합니까? 음, 솔직히 그들이 동기 부여가되지 않는다면 놀랄 것입니다. 필자는 일반적으로 func 사양, 요구 사항 및 기타 예비 문서에 대한 의견을 제시하도록 동기를 부여하는 것이 훨씬 어려운 전투임을 알게되었습니다. 테스트를 시작하면 소프트웨어가 이제 "진짜"라는 중요한 심리적 장애물을 제거했습니다.
이 문제를 어떻게 처리할지는 클라이언트와의 관계의 성격에 따라 크게 달라집니다. 동의 한 사양의 정식 프로세스가있는 경우 고객에게 실제로 서명하고 소프트웨어를 승인하는 일정 기간이 있으며 비 활동은 암시 적으로 수용한다는 의미입니다.
내부 클라이언트가 그렇다면 어렵습니다. 모든 것이 프로젝트를 주도하고있는 것일까 요? 이해 관계자는 누구입니까? 이들은 당신이 그러한 활동을하도록 동기를 부여하는 데 필요한 사람들입니다.
일반적으로 클라이언트 테스트를 위해 가장 잘 나온 방법은 문제의 스크린 샷과 그들이 만든 몇 가지 사항을 보내는 것입니다. 이 시점까지는 대부분의 테스트가 집에서 완료되어야하며 심각한 버그는 제거되어야합니다. 오류가 발생했다는 것을 자동으로 전자 메일로 알리는 시스템을 사용하면 테스트 중이라는 사실을 알게되고 전자 메일의 스택 트레이스에서 대부분의 세부 정보를 얻을 수 있습니다.
좋은 점 cletus. 감사 –