고객이 사내 QA 테스트를 수행하도록 권장하는 방법은 무엇입니까?

업데이트 / 설명 내 고객 은 사내 테스트의 필요성을 이해하고 있으며 항상 "더 나은"일을한다고 맹세하지만 실제로는 그렇지 않습니다. 외부 테스트를위한 예산이 없습니다. "초기 테스트, 자주 테스트, 대상 머신의 테스트"에 무엇을 주입 할 수 있는지에 대해 묻고있는 것 같습니다 (모호하게도 인정합니다)?

질문 : 프로덕션 프로젝트에서 "테스트 할 때가 아니라"새로운 릴리스와 관련된 문제를 명시 적으로 테스트하고보고하도록 사용자를 격려하는 방법.

배경 : 멀티미디어 프레젠테이션 도구 모음을 작성한 소규모 클라이언트가 있습니다. 그들은 좋은 고객이며 우리는 좋은 관계를 맺고 있습니다. 프로젝트가 진행 중이며 진행하면서 기능이 추가되었습니다.

내가 가진 두 가지 문제가 있습니다.

1. 기능 정의는 전화를 통해 즉석에서 이루어지며 변경, 수정, 취소 될 수 있습니다. (케네디의 "우리는 달에 가서 다른 일을 할 것"과 비슷합니다. 저는 그 "다른 일"부분에 항상 즐거웠습니다)

2. 사실상 QA 테스트는 거의 완료되지 않습니다.

나는 # 1을 어느 정도 처리 할 수 ​​있습니다. 이것은 회의를하기 전에 사양을 읽는 고객이 아니며, 작성하지는 않습니다. 나는 그것에 익숙하다. 문제가있는 항목 # 2입니다. 새 릴리스를 테스트하지 않거나 테스트하지 않습니다. 그들이하는 일은 버그를 만들 때 버그를 발견 할 때 버그를 발견하거나보고하지 않거나 프로젝트를 진행하기 위해 서둘러 버그 보고서가 모호해 지도록 프로덕션에 사용하는 것입니다.

우리는이 모든 것에 대해 많은 토론을했지만 그것들을 조금만 움직일 수있었습니다. 근본 원인은 두 가지입니다. 소규모 컨설팅 회사이며 테스트 할 리소스가 없거나 아웃소싱 할 예산이 없습니다. 그리고 문화적 : 그들은 자신을 "개발자"라고 생각하지만 실제로는 멀티미디어 소프트웨어 패키지의 사용자 일뿐입니다. (예 : "실제"개발자의 세부 사항에 대한 강박 신경증의 관심 은 없습니다 ).

피드백이 없으면 기능이 완료되었는지 (# 1 참조) 다른 결과가 있는지 알 수 없습니다. 그것은 또한 나를 조금 게으르게 만들고 있습니다.

그들은 "진짜"개발자의 세부 사항에 대한 강박 신경증의 관심이 없습니다.

서문 : 여기에 사용한 언어는 일반적으로 저에게 붉은 깃발입니다. 사람들이 "실제"개발자 또는 "한 가지" "올바른"방법에 대해 이야기하는 것을들을 때, 나는 터널 비전 화물 컬트 개발자를 생각하기 시작 합니다.

자, 나는 당신이 분명히 이러한 개발자 중 하나라고 말하지는 않습니다 (나는 그것을 주장 할 충분한 증거가 없습니다). 그렇다면 당신은이 답변으로부터 이익을 얻을 수 있습니다.

대답

당신과 당신의 클라이언트가 다른 것들을 최적화하고있는 것처럼 들립니다. 소프트웨어 엔지니어링에서 비즈니스의 요구와 개발자의 요구가 반드시 일치하지 않는 것은 불행한 사실입니다.

소프트웨어 개발자는 종종 개선에 중점을 둔 열정적 인 사람들입니다. 소프트웨어 성능, 개발 프로세스, 비즈니스 프로세스, 통신 방법 등을 향상시키는 것을 좋아합니다. 이러한 것들에 초점을 맞추는 것은 장인과 장인을 마음이없는 키퍼에서 분리하는 것입니다.

그러나 고객은 소프트웨어 장인이 아닙니다. 고객은 완전히 다른 우선 순위를 가진 비즈니스입니다. 그리고 때로는 이러한 우선 순위가 우리의 소프트웨어 장인들에게는 어리석게 보일 것입니다. 그러나 그것은 우리가 다른 것들에 대해 최적화하고 있기 때문입니다.

비즈니스는 종종 초기 출시 및 단기 비용 절감과 같은 것들을 최적화하려고합니다. 그렇게함으로써 QA, 사용자 경험, 장기 비용 절감 및 개발자의 관심을 끄는 기타 사항을 희생해야 할 수도 있습니다.

그게 나쁜가요? 반드시 그런 것은 아닙니다. 모든 사업체에 대해 말할 수는 없지만 내 경험상 고객은 ROI (투자 수익)를 높이기 위해 이러한 일을합니다. QA, UX 개선 및 장기 계획과 같은 일을하면 ROI가 낮아집니다. 더 나쁜 것은 많은 기업들이 지속 가능한 접근 방식과 장기적인 승리와는 반대로 단기적인 승리 만 보상하는 투자 구조를 가지고 있다는 것입니다.

그래서, 당신은 동안 수 클라이언트 당신이 당신의 시간을 낭비하고 그들과의 관계를 긴장이있을 수 있습니다 QA의 아이디어를 판매하려고합니다. 가장 좋은 경우에는 누군가가 당신의 아이디어를 시험해보고 싶어 할 것입니다. 최악의 경우 QA와 같은 장기 투자에 대한 보상을 받으려면 회사 전체가 인센티브 구조를 재 작업하도록 설득해야합니다. 두 경우 모두 성공 확률이 낮습니다.

흥미로운 질문은 고객이 자신의 테스트를 수행하는지 여부가 아니라 급여를받는 시점입니다.

• 당신이 당신의 시간에 따라 돈을받을 경우 아무런 문제가 없습니다.
• 사전에 돈을받는다면 아무런 문제가 없습니다.
• 고객이 프로젝트를 "완료"라고 선언했을 때 돈을받는다면 큰 문제입니다.

문제는 고객이 언제 소프트웨어를 수락하고 비용을 지불하는지 알 수있는 방법입니다. 클라이언트가 막연하게 정의 된 새 요청으로 프로젝트를 지속적으로 수정하면 분명히 작동하지 않습니다. 만약 이것이 지불 일이 항상 연기되고 각 요청에 의해 더 가능성이 낮아진다는 것을 의미한다면, 이것은 당신이 해결할 수 없게됩니다.

모든 기능을 신중하게 지정하고 고객이 이러한 기능을 수용 할 조건을 정의하는 고정 계약은 매우 불편하지만 엄격하게 프로젝트를 미리 계획 할 수 있습니다 (다음 프로젝트). 또한 사양에 맞는 경우 제공 한 소프트웨어에 대한 비용을 보장합니다. 그러한 시나리오에서, 고객의 유일한 책임은 계약 정의 단계 동안, 그리고 최종적으로 수락 테스트에 대한 것 입니다.

고객이 수행 한 이러한 승인 테스트는 다른 형태의 테스트와 별개입니다.

• 단위 테스트
• 시스템 통합 테스트
• 유용성 테스트
• 부하 테스트
• 시험판 테스트

가능하면 수용 테스트를 예상하고 난처한 상황을 피하기 위해 기능을 제공하기 전에 직접 테스트를 수행해야합니다. 수락 테스트 ( 소프트웨어 품질이 아닌 계약 이행 만 측정) 외에 모든 품질 보증은 귀하의 책임입니다. 특히 고객에게 반드시 QA 사고 방식, 필요한 기술적 배경 또는 QA를 수행 할 계약상의 의무가있는 것은 아닙니다. 또한 클라이언트에게 버그 사냥을 아웃소싱하는 것은 매우 전문적이지 않습니다.

그것은 버그가 발생하지 않는다고 말하는 것이 아닙니다. 고객과 프로젝트 기반의 관계가 있다고 가정하면 정중하고 신속하게 수정 사항을 제공하고 현재 릴리스가 자신의 요구에 충분한 것으로 받아 들여 졌다고 설명합니다. 대규모 변경에는 새로운 계약이 필요합니다. 지속적인 지원 계약이있는 경우 물론 합의 된 서비스 수준을 준수해야합니다.

민첩한 환경에서 고객의 요구에 응답하는 것은 계약서에 충실하는 것보다 가치가 있지만 여전히 지불을 받고 싶을 것입니다. 따라서 많은 애자일 중심의 프로젝트 방법론은 고객이 팀의 일부가 될 수있을 정도로 고객과의 상호 작용을 중요하게 생각합니다. 그런 다음 언제든지이“제품 소유자”와 대화하여 필요한 사항을 명확히 할 수 있습니다. PO는 귀중한 기능에 대해 작업 할 시간을 사용자에게 부여 할 권한이 있으므로 모호한 고객 요구로 시작할 때에도 작동 할 수 있습니다. 그러한 긴밀한 의사 소통이 없다면보다 공식적인 접근 방식을 따라야합니다.

• 새로운 고객 요구에 대해 알게되면 고객과 협력하여 요구 사항으로 변환하십시오. 이를 통해 고객은 실제로 원하는 것을 얻을 수 있습니다.
• 요구 사항은 객관적으로 측정 가능합니다. 요구 사항이 충족되었는지 여부입니다. 이렇게하면 클라이언트가 일종의 작업 만하는 반 솔루션에서 제외됩니다.

• 모든 고객 요청은 청구서 작성을 위해 서면 양식으로 제공되어야합니다. 이렇게하면 버튼이 다르게 정렬되도록 요청할 때 전체 인터페이스를 다시 작성하는 것과 같이 작업하고 싶었던 물건에 대한 비용이 청구되지 않습니다.

  많은 의사 소통은 직접 또는 전화를 통해 이루어질 수 있지만, 결국에는 고객 이 이러한 요구 사항 에 대한 작업을 원한다고 문서화 할 종이가 필요합니다. 간단한 경우에는 전화를 요약하여 전자 메일로 보내서 요청한 내용을 확인하는 것으로 충분할 수 있습니다.

버그 리포트는 항상 어렵습니다. 고객이 자신의 요구 사항을 이해할 수 있기 때문에 도움이되는 개발자 인 경우 : 명확한 단계를 재현해야합니다. 강력한 통찰력을 얻는 간단한 방법은 배포 된 소프트웨어에서 로깅을 활성화하는 것입니다. 데이터 프라이버시 문제가 해결 될 수 있다면 모든 버그 보고서에 현재 로그가 첨부되도록 요구하면 일부 서면 통신을 보장 할뿐만 아니라 사용자가 실제로 무엇을했는지 생각해야합니다. .

버그 커뮤니케이션을 장려하는 방법은 기능을 자주 세분화하여 커뮤니케이션하는 것입니다. 의식이없는 것을 요구할 수있는 회사를 훈련 시키면 사소한 버그에도이 기능을 사용하게됩니다. 이러한 변경으로 인해 인생이 쉬워지지 않는 한 고객의 워크 플로 변경을 포기하십시오.

고객이 사내 테스트를 수행하도록하는 것은 어렵지만 실제로 버그를보고하도록하는 것은 어렵지 않습니다. 더 많은 피드백을 얻는 방법은 사용자 마찰을 줄이는 것입니다.

1. 도구가 부적절하고 부적절하더라도 더 간단한 도구를 사용하십시오. 예를 들어, BaseCamp는 프로젝트 관리를 목적으로하는 매우 끔찍한 버그 추적기이지만 사람들은 실제로 그것을 사용하려고합니다.

2. 우리가 사용하는 버그 추적기는 이미지 복사 붙여 넣기를 지원하지 않았기 때문에 실제로는 현재 클립 보드 이미지를 Guid로 디스크에 복사 한 다음 Guid를 클립 보드에 복사하는 간단한 프로그램을 작성했습니다. 최소한의 교육 후에 사용자는 인쇄 화면을 누르고 버튼을 클릭 한 다음 버그 제출 도구의 파일 선택기 대화 상자에 붙여 넣기 만하면 클립 보드 이미지를 문제에 첨부 할 수 있습니다.

MS Paint에서 주석으로 편집 한 스크린 샷과 1-2 개의 문장으로 대부분의 기능 / 버그를 정확하게 식별 할 수 있습니다.

이 두 제안은 내가 경험 한 마찰 점을 목표로 하고 있으며, 두 제안 모두보고를 10 배 이상 증가 시켰습니다. 그러나 자신의 마찰 점을 목표로해야합니다.

클라이언트 테스트는 쉬워 지지만 클라이언트는 테스트되지 않은 버전의 프로덕션에서 새로운 기능을 사용하기가 정말 어렵습니다. 이것은 다음과 같이 달성 될 수 있습니다 :

새로운 기능을 제공 할 때마다이를 "베타 버전"으로 구현하고 "생산 용이 아님"이라는 표시가 명확하게 표시됩니다. 테스트를 위해이 베타 버전을 클라이언트에서 사용할 수있게합니다. 또한 실제 제작에 사용할 최신 "제작 버전"(새 기능은 없지만 최신 버그 수정 포함)을 제공하고, 누군가가 피드백을받을 때까지 새로운 베타 기능을 프로덕션 버전으로 이전하는 것을 거부합니다. 클라이언트 쪽은 적어도 먼저 시도했습니다.

클라이언트가 프로그램을 시작할 때마다 항상 "제작 용이 아님"이라는 큰 메시지를 표시하지만 실제 프로덕션 데이터에서 베타 버전을 사용하기 시작하면 도움을 줄 수 없지만 최소한 프로덕션을 느슨하게 할 때마다 분명히해야합니다. 그가 잘못된 목적으로 베타를 사용했기 때문에 일한 것이 분명합니다. 클라이언트가 그로부터 배우지 않으면, 필요한 경우 결과를 "베타"에 디스크에 저장하는 것과 같은 일부 중요한 기능을 비활성화하여 프로덕션에서 "베타"를 사용하는 클라이언트의 기능을 비활성화하는 것을 고려할 수 있습니다.

별도의 "베타"를 제공하면 적절한 버전 제어 / 구성 관리를 설정해야하므로 프로덕션 지점과 베타 테스트 지점을 번거롭게 나란히 관리 할 수 ​​있습니다. 그러나 Github과 함께 작업하고 있기 때문에 이미 GIT와 같은 것을 사용하고 있기 때문에 이러한 종류의 관리가 매우 간단합니다.