개발자도 테스터의 역할을해야합니까? [닫은]

우리는 3 명의 개발자, 1 명의 디자이너, 스크럼 마스터 및 제품 소유자로 구성된 스크럼 팀입니다. 그러나 우리 팀에는 공식 테스터가 없습니다. 항상 우리와 함께하는 문제는 응용 프로그램을 테스트하고 테스트를 통과하고 버그를 제거하는 것이 PBI (제품 백 로그 항목)를 완료 한 것으로 간주하는 기준 중 하나로 정의되었다는 것입니다.

그러나 문제는 우리 (3 개발자와 디자이너 1 명)가 얼마나 많은 응용 프로그램을 테스트하고 사용 사례를 구현하려고하더라도 여전히 일부 버그가 보이지 않고 이해 관계자 의 프레젠테이션 ( Murphy의 법칙 )을 망칠 수 있다는 것입니다.

구제책으로 회사는 새로운 테스터를 고용하는 것이 좋습니다. 일을하는 사람은 테스트 만하고 테스트 만합니다. 공식적인 전문 테스터.

그러나 문제는 스크럼 마스터와 이해 관계자가 개발자 (또는 디자이너)도 테스터 여야한다고 생각합니다.

그들이 맞습니까? 개발자 (또는 디자이너)도 테스터 여야합니까?

예를 들면 : 테스트가 아닌 것으로 간주되는 것에 대해 많은 혼란이있는 것 같습니다. 물론 모든 개발자는 코드를 작성할 때 코드를 테스트해야하며 코드가 작동하는지 확인해야합니다. 그녀는 그것이 완료되고 충분하다고 생각하기 전에 테스터에게 건네 줄 수 없습니다. 그러나 개발자는 모든 것을 볼 수는 없습니다. 버그를 인식하지 못할 수 있습니다. 이러한 버그는 철저한 테스트를 수행 할 때 개발주기 후반에 발견 될 수 있습니다. 문제는 개발자가 이러한 종류의 테스트를 수행해야하는지 여부이며, 겸손한 견해로는 프로젝트 관리자의 관점에서 볼 필요가 있습니다.

개발자는 테스터가 될 수 있지만 테스터가되어서는 안됩니다 . 개발자는 의도하지 않게 / 부주의하게 응용 프로그램을 손상시킬 수있는 방식으로 사용하지 않는 경향이 있습니다. 그것은 그들이 그것을 작성하고 주로 사용해야하는 방식으로 테스트하기 때문입니다.

반면에 좋은 테스터는 응용 프로그램을 고문하려고합니다. 그의 주요 의도는 그것을 깨는 것입니다. 그들은 종종 개발자들이 상상하지 못한 방식으로 응용 프로그램을 사용합니다. 개발자보다 사용자에게 더 가까우며 종종 워크 플로를 테스트하는 다른 방법이 있습니다.

또한 개발자를 테스터로 사용하면 개발 비용이 증가하고 전용 테스터를 보유하는 것만 큼 제품의 품질에 도움이되지 않습니다. 테스터가 저렴한 가격으로 더 잘 할 수 있다면 개발자가 자신의 작업을 교차 테스트 할 수는 없습니다. 개발자와 테스터 사이의 피드백 루프가 너무 비싸면 개발자가 서로의 코드를 교차 테스트해야하지만 내 경험상 거의 그렇지 않으며 프로세스에 크게 의존합니다.

그렇다고 개발자가 느슨하고 모든 것을 테스터에게 맡겨야한다는 의미는 아닙니다. 소프트웨어는 단위 테스트로 백업해야하며, 소프트웨어를 테스터에게 전달하기 전에 기술적 오류를 최소화해야합니다. 아직도, 당신은 때때로 여기에서 고쳤습니다. 개발자가 볼 수 없었던 문제 나 다른 버그를 해결하십시오 . 또한 통합 테스트는 대부분 개발자가 수행해야합니다. 테스터의 주요 목표는 요구 사항이 충족되는지 확인하는 것입니다.

이러한 소규모 팀 (및 응용 프로그램의 크기에 따라 다름)에서는 테스터가 하이브리드 역할, 단위 테스트 및 UI 테스트 작성에서 볼 수 있습니다. 당신은 확실히 하나를 고용해야합니다 .

그러나 테스터보다 더 중요한 것은 정기적 인 동결 / 분기입니다. 제대로 테스트되지 않은 것을 제시하지 마십시오. 기능을 추가하거나 변경 한 경우 주변의 모든 사항을 다시 확인해야합니다. 회사가 그렇지 않으면 평판이 나빠질 것입니다. 불안정한 것을 놓지 마십시오. 고객이 특정 날짜까지 소프트웨어를 보유하고 싶을 때는 개발을 조기에 중지하고 올바르게 테스트하여 버그를 수정하십시오. 마지막 기능 요청을 제대로 구현하지 않거나 적절한 테스트없이 릴리스하는 것보다 마지막 기능 요청을 거부하는 것이 종종 좋습니다.

개발자는 다른 개발자 코드의 테스터가 될 수 있습니다.

그러나 자신의 코드를 테스트하는 것은 좋은 방법이 아닙니다. 개발자는 자신의 코드에 대한 정신적 블록을 가지고있는 경향이 있으므로 포괄적이거나 적절한 테스트를 설계하는 데 어려움이 있습니다.

항상이 작업을 잘 수행한다고 생각하는 개발자가있을 수 있지만 대개는 그렇지 않습니다 (그리고 많은 사각 지대가 있다는 것을 알고 있습니다).

정말 테스터를 고용하면 개발자가 서로의 작업을 교차 테스트하도록하십시오. 즉, A가 코드를 작성하고 단위 테스트를 수행하는 경우 B가 해당 단위 테스트를 살펴보고 추가 할 수있는 것이 있는지 확인하십시오. . 그리고 B가 코드를 (사용자로서) 시도하고 테스트하고 결함을보고하도록하십시오.

이것은 완벽하지는 않지만 모든 것을 시도하는 단일 개발자보다 낫습니다.

때로는 동료가 소프트웨어를 즐기는 데 능숙 할 수 있습니다. 소프트웨어에서 즐거움을 얻고 크게 신경 쓰지 않기 때문입니다. THEIR 코드가 아니기 때문입니다.

기자는 올바르게 쓰는 경향이 있습니까? 모든 문법 오류를 찾는 것은 교정자와 편집자 일입니다.

그럼에도 불구하고 언론인들은 스스로 철자를 검사합니다. 그럼에도 불구하고 교정자는 별개의 중요한 직업입니다.

QA가 개발에서 더 중요한 부분이라는 사실을 제외하고 개발자와 테스터에 대해서도 동일합니다. 훌륭한 개발자라도 제품이 지원하는 모든 환경, 브라우저, OS를 포괄하기 위해 모든 테스트 사례를 철저히 테스트 할 시간이 없습니다.

하나는 개발 외에도 지속적으로 그 일을하는 것이라면 단순한 사실을 의미합니다. 그는 파트 타임 테스터입니다.

우리 (3 명의 개발자와 1 명의 디자이너)가 응용 프로그램을 테스트하려고 시도하고 사용 사례를 구현하려고 시도하더라도 여전히 일부 버그가 보이지 않고 이해 관계자에게 프레젠테이션을 망칠 수 있습니다.

스프린트를 위해 "제어 된 달리기"를 수행하고 개발 및 테스트 노력을 개별적으로 추적하십시오. 이러한 실행이 끝나면 수집 된 데이터를 분석하여 테스트에 얼마나 많은 노력을 기울이고 있는지 알아보십시오.

테스트에 많은 노력이 필요하다는 것을 알게되면 해당 데이터를 경영진에게 전달 하십시오. 요청을 뒷받침 하는 강력한 증거 가 될 것입니다 .

그렇지 않은 경우 (테스트에 시간이 거의 걸리지 않는 경우) 더 나은 작업을 수행하기 위해 추가 노력을 기울이는 방법을 배우십시오. 테스터를 고용하는 것이 좋을 수도 있으므로 경영진과 함께 계획 한 추가 노력 을 협상 하십시오. :)

... 새로운 테스터를 고용하는 것이 좋습니다. 일을하는 사람은 테스트 만하고 테스트 만합니다. 공식적인 전문 테스터.

그러나 문제는 스크럼 마스터와 이해 관계자가 개발자 (또는 디자이너)도 테스터 여야한다고 생각합니다.

인정해야합니다, 회사의 관리는 나에게 꽤 절름발이합니다. 내 말은-좋아, 프로젝트에 몇 명의 테스터가 최선 인지 알아내는 것이 정말 어려울 수 있습니다 .

그러나 가지고 적어도 하나의 테스터 것은 그들이 정말 재미 - 단지 안전한 내기 주저 스스로 주장하면서, 그것을 시도를 제공하기 위해 / 스크럼을 민첩 .

글쎄, 우리는 처음 두 사람이 입장 화면을 약간 변경 한 후에 두 명의 개발자가 교차 테스트를했습니다. 이것은 우리의 정규 테스터가 출산 휴가를 떠났을 때였습니다.

기본적으로 "편집"버튼을 통해 편집하기 위해 확대하기 전에 사용자가 송장을 선택하는 데 사용되는 송장 목록 화면을 변경했습니다. 원래 목록이 삭제되고 필터링, 그룹화, 정렬 및 모든 종류의 멋진 기능을 갖춘 새로운 gridview가 삽입되었습니다.

테스트는 훌륭했고 다음 날 고객에게 변경 사항을 업로드했습니다. 2 주 후 고객이 전화를 걸어 "우리는 새로 입력 한 것을 정말 좋아합니다. 이제 모든 종류의 정보를 볼 수 있습니다.하지만 ... 어 ..... 송장을 편집하려면 어디로 가야합니까? ?? "

개발자가 체크 박스 (선택)와 편집 버튼을 꺼내고 개발자가 항상 항목을 선택하기 위해 두 번 클릭했기 때문에 아무것도 발견하지 못했습니다 ...

개발자와 사용자는 서로 다른 세계에 살고 있으므로 교차 테스트를하는 것이 개발자가 자신의 작업을 테스트하는 것보다 낫지 만 여전히 똑같은 것은 아닙니다.

다른 사람들이 말했듯이 개발자는 서로의 코드 (단위 또는 기능 테스트)를 교차 테스트 할 수 있으며 스크럼 마스터 및 제품 소유자는 통합 테스트를 도울 수 있지만 사용자 승인 테스트를 위해서는 반드시 테스트를 받아야합니다. 피드백을 많이 로부터 고객의 테스트를 의미 - 자주 배포 가 실제 사용자가 수행하는 방식과에서 작업 할 수 있습니다 정말 개방 통신 채널을.

테스트 가능성을 염두에두고 설계해야하지만, 전용 테스터가없는 경우, 하루 중 소프트웨어를 설계, 구현 및 테스트하기에 충분한 시간이 없기 때문에 균열이 발생하기 쉽습니다.

테스트 소프트웨어는 정규직 전문직입니다. 좋은 테스터가 되려면 좋은 두뇌, 재능 및 많은 경험이 필요합니다. 테스트가 일상 업무의 작은 구성 요소 일 때 소프트웨어 개발자가 아무리 영리하더라도 전문 테스터에게 가까이 갈 수 있다고 가정하는 것은 우스운 일입니다.

그 위에 소프트웨어 개발자가 무의식적으로 버그를 찾고 싶지 않은 문제가 발생합니다 .

개발자 / 디자이너가 코드를 테스트해야한다는 점에 동의합니다. 코드 섹션을 수행 한 디자이너 / 개발자가 해당 코드에 대한 유일한 "눈"이 아니라는 사실에 동의했습니다. 그것이 모든 것을 잡을 수는 없지만, 개발하는 동안 자신의 코드를 테스트하고 다시 테스트 할 때 발생하는 실명을 피하는 데 도움이 될 것입니다.

유스 케이스에 대한 언급에서 코드 커버리지 도구를 사용한다고 가정합니다. 그렇지 않은 경우 테스트되지 않은 코드를 확인하는 데 도움이되고 특정 조건에서 예기치 않은 버그가 발생할 수 있습니다.

즉, 충분한 작업이 있거나 조직의 규모가 적당하면 전문적인 QA 담당자가 필요하며 모든 사람의 역할에 좀 더 집중하는 데 도움이 될 것이며, 더 중요하게는 수정 방법이 누락되었습니다.