테스터-개발자 커뮤니케이션

개발자-개발자, 개발자-클라이언트, 개발자-팀 관리자 커뮤니케이션에 대해 많은 글을 썼지 만 테스터-개발자 커뮤니케이션 및 관계에 대한 지침을 제공하는 텍스트를 찾을 수 없었습니다.

테스터와 개발자가 별도의 팀인지 또는 동일한 팀인지 (제 경우에는 민첩한 개발 프로젝트에서 고독한 테스터입니다) 테스터를 잘 수용하기 위해서는 테스터의 인식 방법이 매우 중요하다고 생각합니다. 프로젝트의 질을 향상시키는 데 목표를 두어야합니다 (예 : 경찰로 간주해서는 안 됨).

테스터가 개발자와 통신하는 방법에 대한 조언이나 연구가 있습니까?

업데이트 : 답변 해 주셔서 감사합니다. 그들은 모두 내가 생각했던 것을 확인했습니다. 지금까지, 우리 팀은 제 역할을 잘 받아들였으며 결국 우리는 실질적인 진전을 이루었습니다. 나는 하나 이상의 답을 선택할 수 있었지만 나는 결정을 내려야했다.

의사 소통을 향상시키는 가장 쉬운 방법은 개발자 (및 설계자 및 설계자 등)와 함께 작업하여 이러한 바보 같은 역할을 천천히 분류하고 결국 우리 중 일부는 다른 사람보다 더 많은 경험을 가지고 있다는 점을 제외하고 우리 모두 가 테스터 임을 인식하는 것입니다.

민첩한 경우 "책으로"수행하십시오. 테스터는 팀의 일원이며 외부 작업뿐만 아니라 작업이 완료되면 물건을 넘겨줍니다. 귀하의 소중한 전문 지식은 전체 개발 과정에서 사용됩니다 . 먼저 사용자 스토리를 만들 때 승인 테스트를 도출하여 자동화하는 데 도움이됩니다. 이러한 테스트는 개발자가 작업에서 사용합니다. 또한 부분 및 완료된 작업에 대한 탐색 테스트를 매일 수행하고 PO와 대화하여 지속적으로 테스트를 명확하게하고 개선합니다.

그것이 "함께 일하는 것"에 대해 이야기 할 때의 의미입니다. 이것이 팀의 의사 소통이 어떻게 작동하는지 완전히 확신합니다. 이 기사에서는 btw에 대해 잘 설명합니다.

이와 반대로 많은 조직은 모든 ​​테스터 (및 DBA, 디자이너 및 프로그래머)를 별도의 부서에 배치하여 개발을 처리하는 것을 좋아합니다. 이것은 의사 소통에 대항하여 작동하며 단계적 개발이라는 아이디어를 강화하는 역할을합니다. 이러한 상황에서 의사 소통을 향상시키는 것은 가능하지만 약간의 개선은 그만한 가치가 없습니다. 적어도 실제로 사람들을 같은 방에 배치하고 부서 간 팀을 만드는 것과 비교해서는 안됩니다.

나는 개발자와 테스트 사이의 모든 종류의 의사 소통에 대한 확고한 신자입니다.

나는 너무도 자주 각 팀 사이에서 번갈아 싸우는 것을 보았습니다. "디자인으로 닫히고"다시 열었습니다.

나는 항상 테스터들에게 의심의 여지가 있다면 나와 함께 이야기를 나누라고 말합니다.

내가 정말로 싫어하는 것 중 하나는 테스트에 대해 모든 거만함을 느끼고 그것에 대해 이야기하는 개발자입니다. 그래서 테스트 팀과 좋은 관계를 조성하기 위해 할 수있는 모든 일을하려고합니다.

테스터는 오류 및 테스트에 대해 의사 소통 할 때 개발자에게 명확하고 정확해야합니다. 오류를 재현하는 자세한 단계 목록, 필요한 경우 스크린 샷 ... 재현 할 수 없거나 오류가 분명하지 않은 오류에 대한 모호한 설명은 개발자와 테스터 관계를 매우 빠르게 불러 일으킬 것입니다.

나는 개발자와 테스터 사이에 항상 불일치가 있다고 생각하지 않았지만 가장 친한 친구 중 하나가 내가 일하고있는 회사에서 테스터 역할을하고 테스트 할 동일한 모듈이 할당되었을 때이 상황에 직면해야했습니다. 제가 개발 FUN중이 어서 실제로 그와 함께 일하고 있었고 그러한 상황에서 다른 사람의 의견을 이해하고 자신의 자아를 통제하는 것이 매우 중요하다고 말해야합니다. 이것은 저에게 많은 도움이되었고 우리 전문가들은 잘 지 냈습니다. 개인적인 우정 수준뿐만 아니라 약속.

귀하가 Agile 환경 (Scrum 가정)의 유일한 테스터라고 말 했으므로 회고 회의를 공개 포럼으로 활용하여 의사 소통 과정을 정의 할 수 있습니다.

당신이 알다시피 restrospective 회의는 스크럼 과정 내에서 주름을 해결하는 것입니다. 이 개발자 시간은 중단 시간, 이메일 월요일과 맞는 어떤 일주일의 나머지 부분, 구두에만 통신의 XY 수 있도록 같은 항목이 될 수 귀하의 팀; 의사 소통은 결코 모든 접근에 맞는 단일 크기가 아닙니다.

개발자로서 이니셔티브를 보여주는 테스터에게 감사합니다. 그들은 선을 그리지 않습니다 ... 결함이 해결되기를 원합니다. 근본 원인에 관계없이 개발자와 테스터는 감정을 비즈니스와 분리해야합니다. 인간이 관여하기 때문에 결함은 사업의 일부입니다. 결함 해결에 대한 최선의 접근 방식은 결함을 전체적으로 해결하도록 조정 된 팀입니다. 선이 표면에 나타나기 시작하면 테두리가 배치됩니다. 통신이 중단됩니다.

매일 열리는 회의를 활용하십시오. 가능한 많이 참여하십시오. 테스트뿐만 아니라 제품 전체를 사용합니다. 하루가 끝나면 개발자와 테스터가 하나의 목표를 위해 노력하고 있으며 항상 초점을 유지해야합니다.

나는 같은 팀의 일원으로 테스터를 보는 것을 선호합니다. 이와 관련하여 의사 소통의 문제는 없습니다.

테스터가 개발자에게 이야기하거나 다른 방법으로 대화해야 할 때마다 대화를 나눕시다. 일상 생활

그러나 양 당사자는 서로를 존중하고 올바르게 일해야합니다.

테스터는 버그 조건에 대한 철저한 세부 정보를 제공해야하며 의도적으로 버그로보고하지 않아야합니다. 특히 그 사람에게 의심스러운 기능처럼 보이는 것에 대해 물어볼 때 특히 그렇습니다.

5 번의 클릭으로 버그를 재현하지 않으면 개발자는 버그 보고서를 심각하게 검토하고 문제를 자세히 조사하지 않아야합니다.

전문적인 태도 만 있으면됩니다.

내가 테스터 (SDET)로서 개발 테스트 관계를 개선하기 위해 활용할 수있는 1 번 도구는 특히 개발자로부터 멘토링을 추구하는 형태로 정직한 아첨입니다.

바라건대, 내가 함께 일하는 개발자가 나보다 나은 개발자입니다. 그들은 완벽하지 않거나 직업이 없지만, 나보다 잘 알고있는 것들이 많이 있습니다. 그것들은 순수한 개발이었고, 나의 관심은 부분적으로 테스트에 집중되었습니다. 나는 그들이 더 잘하는 것들에 주목하고 자주 언급합니다. 코드를 읽을 때 우아한 세부 사항이나 디자인 패턴의 깔끔한 사용을 주목하고 대화에 참여시킵니다. 가능한 경우 유사한 코딩 규칙을 사용하여 개발자를 모방하고 적절한 경우 프로덕션의 구성 요소를 테스트 도구에 통합합니다 (예 : 로깅). 나는 그들의 전문 지식을 인정하고 결과적으로 그들은 내 것을 인정하게되어 기쁩니다. 일을하는 더 좋은 방법이 있다고 생각하면 절대로 말을하지만, 부정적인 것보다 더 긍정적 인 피드백을주는 것을 목표로합니다. 사무용 겉옷. 일반적으로 부정적 피드백을보다 공식적이고 비 개인적 (예 : 버그 보고서) 만들고 긍정적 인 피드백을 덜 공식적이고 개인적 (예 : 대화)으로 만들려고합니다.

품질에 대한 긍정적 인 피드백과 부정적인 피드백을주고 조언을 구하는 것은 논쟁에서 팀워크 및 상호 학습에 대한 관계로 바뀌고 방어력을 떨어 뜨립니다. 개발자들은 내가 항상 나쁜 것보다 더 좋은 말을한다고 믿을 수 있기 때문에 내 말을 잘 들어줍니다. 또한 개발에 대한 통찰력있는 질문을하면 저에 대한 의견이 제기되고 "SDET은 실패한 개발자"라는 고정 관념이 여전히 존재합니다.

개발자와 테스터 간의 원활한 의사 소통이 중요하다고 확신합니다. 가장 좋은 방법은 많은 좋은 접근 방법이 있다는 것이 확실하지만 여기에 나에게 가장 잘 맞는 것이 있습니다.

직접 / 개인 커뮤니케이션! 이메일이 아닌 개인 커뮤니케이션이 항상 가장 효과적이라는 것을 알았습니다. 개발자와 테스터는 개인적인 관계를 형성 할 수 있습니다. 일단 당신이 그 일을 더 잘하고 흐름 경향이있는 것 같습니다. 그들은 특별한 테스트를 실행하거나 당신을 위해 여분의 마일을가는 데 아무런 문제가 없습니다. 개발자도 마찬가지입니다. 항상 도움이 필요하거나 문제가있는 부분을 살펴 보려면 시간이 더 걸립니다. 내 경험상 문제 해결이 빨라지고 시간 낭비가 줄어 듭니다.