프로그래머로 일하면서 나는 다양한 프로그래머와 테스터를 보았고, 많은 사람들이 서로를 좋아하지 않거나 싫어했습니다. 프로그래머들은 테스터의 직업이 "실제"직업이 아니라고 생각하고 테스터들은 프로그래머들이 너무 자랑스러워한다고 생각합니다.
이것이 올바른 결정입니까, 왜 그렇습니까? 이런 종류의 문제를 피하기 위해 무엇을 할 수 있습니까?
답변:
나는 그것이 일반화와 단순화에 대한 총체적이라고 생각합니다.
저는 현재 테스터입니다. 개발자 (테스트 단계에 따라 다름)로 작성한만큼의 코드를 작성하고 회사의 가장 친한 친구는 개발자이며 우리 모두는 함께합니다.
회사 문화와 팀이 서로에 대해 답변을 찾기 위해 노력하는 방식을 살펴볼 수 있습니다. 내 경험상, 다른 초점 포인트 나 "공격 벡터"에서 함께 작업 하는 대신 반응이 빠른 워크 플로우 (예 : 개발자가 "벽에 빌드를 던지고"버그를 다시 던짐 ")하는 경우 두 부서 모두 일반적으로 서로 싫어할 것 입니다.
내가 작업하는 모든 기능 팀 또는 디자인 팀에는 출력을 생성하기 위해 함께 작업하는 개발자 수만큼 테스터가 있습니다. 해당 출력은 테스트 코드에 명시된 요구 사항을 충족하는 생산 코드입니다.
편집하다
또한, 나는 둘 사이의 관계를 지원하기 위해 개발자보다 테스터에게 책임이 있다고 생각합니다.
개발자의 삶을 더 나아지게 만드는 것이 훨씬 쉽지만 목표는 단순히 "버그를 찾는 것"뿐만 아니라 잠재적 인 해결책을 찾는 것입니다. 내가 할 수 없다면, 할 수 없으며, 그 시점에서 버그 를 할당받은 사람과 함께 해결책을 찾기 위해 노력할 것 입니다. 그러나 간단한 솔루션이라면 다양한 요구 사항과 필자가 작성한 최종 회귀 테스트를 만족시킬 수있는 잠재적 인 해결책이라고 생각합니다.
나는 사랑 그들은 내가 문제를 해결하고 난 문제로 생각하지 않을 것이라고 물건을 발견 도움이되지만 우리의 고객들은 것 - 내 테스터. 그리고 나에게 가장 중요한 것은 나쁜 코드로 누군가를 죽이지 않도록 도와줍니다.
왜 문제가 발생합니까?
위의 특성과 위치의 특성을 결합하면 현재의 분노와 좌절을 서로 쉽게 제거 할 수 있습니다. 트랩에 빠지면 함께 일하는 것을 멈추고 서로 대항하기 시작합니다. 그것은 깨지기 어렵고 누구에게도 좋지 않습니다.
프로그래머가 프로그램을 작성하기 때문에 발생한다고 생각할 것입니다. 테스터가 실제로 최종 제품을 개선하는데도 불구하고 테스터가 결함을 찾으려고 생각합니다. 누군가가 많은 노력을 기울인 무언가에 결함이있을 때마다 부정적인 반응을 보이는 것은 자연스러운 반응 일 것입니다.
이를 완화하는 방법은 개발자와 테스터가 완성 된 제품을 전체 팀 의 출력 (테스터 및 개발자 포함)으로보고 테스팅이 독립형 결함 찾기 미션이 아니라 중요한 부분임을 이해하게하는 것입니다. 개발 과정. 개발자가 테스트가 실제 작업 이라고 생각하지 않거나 쉽지 않다면 테스트 매트릭스를 작성하고 수백 가지 테스트 사례를 실행하며 모든 단계 및 모든 결과를 문서화하도록하십시오.
나는 서로를 좋아하지 않지만 당신이 언급 한 이유가 아니라 서로를 위해 일하기 때문에 특정 프로그래머와 특정 테스터를 알고 있습니다.
짐승의 본질입니다. 내가 아는 특정 테스터 중 일부는 코드가 부주의 / 게으름 등을 통해 오류가 발생하기 쉽다고 생각하여 특정 프로그래머를 신경 쓰지 않는 사람을 알고 있습니다. 특정 테스터를 신경 쓰지 않은 특정 코더 중 일부는 엄청나게 고안된 테스트 조건을 사용한다고 생각하거나 (니트 선택) 스타일을 기반으로 코드에 대한 수정을 요청합니다.
나는 성격을 유지하지 말고 당면한 과제에 집중하면 긴장을 줄이는 데 먼 길을 갈 것입니다. 조직이 충분히 큰 경우 이중 맹검 테스트를 사용하는 것이 좋습니다.
문제를 명확하게 표현할 수있는 테스터와 솔루션을 명확하게 구현하는 코더는 훌륭한 팀입니다.
테스터와 긴밀히 협력 한 팀에서 우리는 환상적인 모습을 보였습니다. 테스터는 다양한 결정을 내린 결정을 이해하고, 개발자의 일정이 어떤지 알고, 두 그룹간에 관계를 구축합니다.
테스트가 일부 비정질 실체 인 해외 팀에서는 그렇지 않았습니다. 테스터의 결과는 진행 상황에 대해 많이 알지 못하기 때문에 관련성이 적습니다. 개발자는 두 가지 분야에서 다루지 않은 프로그램의 일부에있는 중요하지 않은 세부 사항으로 간주되는 홍수를 두려워하기 시작합니다. 몇 달 동안 테스트 팀은 제출 된 버그 중 어느 것도 수정되지 않았으며 (스케줄이 망가졌고 개발자가 데모 준비 또는 요청 된 기능 추가 등으로 바쁘기 때문에) 짜증이 나고 일반적으로 두 그룹 모두 서로 적대적이라고 생각합니다. "다른 사람"은 팀원과 반대입니다.
긴밀히 작업하면 문제가 해결됩니다. 누군가 두 팀이 모두 같은 페이지에서 조정되어 있는지 확인해야합니다. 나의 최고의 경험, 테스트 팀은 개발자 팀이 초대 된 모든 수준의 회의에 초대되었고 우리 모두는 일정을 알고 통일 우선 순위 목록을 가졌으며 개발자와 테스트는 모두 동일했습니다. 최신) 요구 사항 문서. 최악의 경험 (테스트 제외) 우리는 기본적으로 우리의 물건을 포장하고, 그것을 보려고 해외로 운송 한 다음 한 달 후에 우리의 것이 아닌 잘못된 것으로 표시된 것들 (새로운 것을 만난 타사 플러그인)으로 모든 것을 다시 얻었습니다. 요구 사항이지만 테스트 팀의 기대는 아닙니다).
dev 나 test는 다른 것 없이는 성공할 수 없습니다. 같은 기계의 두 반쪽처럼 일하고 더 즉각적인 팀 구성원을 존중하는만큼 상대방을 존중한다면 문제가 없습니다. 두 대의 기계처럼 행동하고 기계가 더 좋다고 가정하면 상황이 끔찍할 것입니다.
테스터와 개발자가 "테스트 팀"과 "개발 팀"이 아닌 동일한 팀에있을 때 이러한 문제가 크게 완화되는 것을 발견했습니다. 이것이 테스터로서 폭포 개발보다는 애자일 팀에서 일하는 것을 강력하게 선호하는 이유라고 생각합니다. 의사 소통이 더 많고 처리 시간이 더 빠르며 개발자는 작업이 더 투명 할 때 테스트에 참여하는 시간과 재능에 대해 더 큰 감사를 표합니다.
개별적으로도 할 수있는 일이 많이 있습니다. 테스터로서 나는 긍정적 인 피드백을 제공하고 버그를 발견 함으로써이 마찰을 줄일 수 있음을 발견했습니다. 나는 나에게 많은 것을 가르 칠 수없는 개발자를 테스트하지 않았으며 개발자가 실제로 코드를 이해하기 위해 노력하는 테스터를 높이 평가합니다. 훌륭한 장인처럼 개발자 는 자랑스러워합니다. 버그가 있다고해서 그다지 감탄하지 않는다는 것을 알려주는 것이 중요합니다
내가 찾은 개발자들은 좋은 품질로 작업하기가 가장 쉽다는 것을 알게되었고 예비 테스트 (주로 자동화 된 단위 테스트 및 수동 연기 테스트)를 포함하여 테스터가보기 전에 고품질 코드를 작성하기 위해 노력함으로써이를 입증했습니다. 또한이 개발자들은 테스트 가능성을 테스트하기 위해 코드 검토를 수행하도록 요청했으며 가능한 빨리 디자인을 제시하는 등 테스터를 가능한 빨리 프로세스에 포함 시켰습니다 (테스터는 테스트가 가벼울 때 테스트 전략을 조기에 계획 할 수있게합니다). 개발자는 서둘러 개발 된 영역 또는 단위 테스트가 어려운 영역을 알려 테스터가 코드에서 약한 영역을 찾도록 도울 수 있습니다. 일반적으로 개발자가 테스터의 업무를 더 쉽게하기 위해 할 수있는 모든 일에 감사하며 테스터의 시간과 자신의 시간을 소중히 여깁니다. 개발자가 이렇게하면
또 다른 문제는 QA가 종종 많은 회사에 의해 사후 생각된다는 것입니다. 마지막 순간에 프로젝트에 대해 많은 시간을 들었고 개발 팀과 비교할 때 심하게 인력이 부족합니다. 어떤 곳에서는 개발자 지원으로 기술 지원, QA, 개발자가 있습니다. 그래서 때로는 개발자가되기를 원하는 사람들과 직원이 있습니다 ... 그리고 그들이 결함을 발견하면 그들의 태도는 그 사람이 어떻게 개발자가 될 수 있고 내가 아닌 그런 실수를하지 않을 것입니다 ...
전반적인 품질 관리팀을 좋아합니다. 또한 단위 테스트는 QA와 별도로 소프트웨어 개발에 필요한 부분이어야한다고 생각합니다. QA에서 버그를 발견하면이를 테스트하기 위해 단위 테스트가 변경됩니다. 또한 단위 테스트를 수행하는 개발자는 QA가 무엇을 찾고 있는지 더 잘 이해할 수 있다고 생각합니다.
또한 많은 QA 팀이 수동으로 작업을 수행해야하며,이 경우에는 정말 지루한 작업입니다. 어떤 곳에서는 QA가 스크립트를 작성하고 (버튼 등의 화면에서 일종의 이미지 인식을 통해) 스크립팅 GUI를 허용하는 자동화 프로그램을 사용합니다. 그런 다음 처음에 큰 변화가 발생할 때 여전히 힘들지만 모든 것이 자동화되어 더 재미있게 보입니다 ...
또한 일부 개발자는 품질 관리를 살펴 봅니다. 여전히 품질 보증팀에서 고객보다 결함을 발견하고 싶습니다 ....
우리는 여기서 테스터를 좋아하지만, 많은 사람들이 테스터를 갖기 전의 모습을 기억합니다. 테스터에게 문제를 찾도록하는 것이 프로덕션에 갔다가 클라이언트가 찾도록하는 것보다 훨씬 낫습니다. 버그를 만들지 않았거나 요구 사항을 잘못 해석 한 개발자는 아직 없습니다.
핵심은 모든 전문가를 공손하게 대하고 그들이하는 일을하는지 여부를 존중하는 것입니다. 일단 당신의 직업이 그들의 직업보다 낫거나 더 중요하다고 생각하기 시작하면 당신은 잃어버린 것입니다.
이 질문을 바탕으로 : 소프트웨어 테스팅 기법 또는 범주 테스터와 일반적인 테스팅에 대한 태도 조정이 필요하다고 생각합니다.
개발자로서 테스터와의 긴장감을 경험했습니다.
한 직업에서 테스터는 "옳은 일"을 거의 테스트하지 않을 것입니다. 제품 서버에 새로운 기능을 구현했으며 테스터는 사용자 인터페이스에 대한 전체 오류를보고합니다. 이 제품에서 사용자 인터페이스는 코딩 되지 않은 상태 로 구성 되었으므로 개발 UI에 존재하는 문제의 존재 여부는 최종 사용자가 비슷한 문제를 가진 UI를 가질 지 여부와는 전혀 관련이 없습니다. 테스터는이를 알고 있었지만 외부 영역에 대한 버그를 계속 기록했습니다.
즉, 좋은 테스터는 금의 무게가 가치가 있습니다. 나는 좋은 테스터를 위해 눈에 띄는 개발자를 즉시 거래하고 싶습니다. 훌륭한 테스터는 우수한 제품을 제공하는 파트너입니다.
또한 테스터가 결함을 도입하는 것처럼 테스터를 적으로 취급하는 일부 개발자를 알고 있습니다. 개발자는 테스터가 절대 결함을 도입하지 않는다는 것을 인식해야합니다.
기분이 좋지 않은 것은 대개 의사 소통의 결과로, 프로그래머와 테스터가 코드의 관점이 다른 결과입니다. 프로그래머는 자신이 작업 한 비트를 잘 알고 있지만 전체 사양에 어떻게 적용되는지 알 수는 없습니다 (사양에서 알려주는 내용 이외). 테스터는 큰 그림을 보지만 코드를 자세히 알지 못합니다. 그룹들은 같은 것들에 대해 다른 용어와 절차를 사용할 수 있습니다.
이로 인해 잘못된 구성 요소에 대한 결함이 제기 될 수 있습니다 (구성 요소가 업스트림 장애에 응답하기 때문에). 올바르게 문제). 이런 일이 많이 발생하면 그룹 간의 관계가 긴장 될 수 있습니다.
그리고 11 시간 째에 결함이 발생하는 기쁨이 있습니다. 마감은 압력의 체인 업에 즉시 관리자에서 당신오고, 어렴풋한하고, 당신은 당신이 문제에 결함이의 신선한 배치를 얻을 알고 이미 고정했는데 정말 갈 시간이 걸릴 싶지 않아 그것을 증명하는 과정을 통해.
하나는 정말 당신의 QA 팀을 화나게하는 좋은 방법은 "당신의 우선 순위가 높은 결함 백 로그가 너무 크다는 것을 추론으로 100 즉결 가까운 몇 합법적하지만 우선 순위가 낮은 결함 (주로 다른 기능이었다 추한 또는 일관성 UI를 상대로)이다 우리는 결코 그런 일을하지 않을 것입니다. " QA 팀은 프로그램 관리자의 스프레드 시트에서 빨간색에서 녹색으로 이동하여 더 높은 경영진의 책임을 맡게되며 QA 팀은 많은 가짜 결함을 제기하는 데 필요한 통계를 얻습니다.
나쁜 주주.