테스트 대상은 누구입니까?

Question

이 질문은 커뮤니티 위키로 표시되어 있으며 주관적이지만 닫지 마십시오. 좋은 질문이라고 생각합니다. 개발 커뮤니티가 테스트에 관해 무엇을 말하고 있는지 알고 싶습니다.

저는 10 년 넘게 개발자로서 일해 왔으며 아직 전용 테스트 부서가있는 회사에서 일했습니다. 수년 동안 테스트에 대한 태도가 꾸준히 악화되는 것을 보았습니다. 최근에 경영진은 빠른 결과와 신속한 배포를 거친 후 개발 팀을 많이 잃어 버렸고 심각한 테스트는 생략했습니다.

최종 결과는 처음에는 개발 속도에 만족하지만, 앱은 프로덕션 환경에서 잠시 동안 안정적으로 실행될 수도 있지만 그 이후에는 뭔가 달라 붙을 수 있습니다. 앱의 복잡성에 따라 많은 문제가 발생할 수 있으며 때로는 한꺼번에 해결할 수 있습니다. 대부분의 경우 이러한 문제는 환경에 영향을 주어 격리 및 수정하기가 어렵습니다. 클라이언트는 궁극적으로 스트레스 테스트의 역할을 맡고있는 실체입니다. 왜냐하면 좋든 그렇지 않든 결국 누군가가 결국 앱을 테스트해야했기 때문입니다.

이 단계에서 관리자는 개발자가 실망했다고 느낍니다. 개발자는 처음에는 경영진이 중요한 테스트에 대한 청원을 듣지 않았으며 고객은 소프트웨어에 대한 신념을 잃어 버렸다고 생각합니다. 일단 주문이 최종적으로 복원되면 제품이이 상태를 유지할 수 있습니다. 개발자는 궁극적으로 개발자가 안정적으로 제품을 출력하지 못해서 비난 받기도하고, 개발자가 앱을 테스트하는 데 2-3 시간을 더 소비했기 때문에 인력으로 예산을 초과하게되었습니다.

이 시점이 현실적입니까? 다른 누구도이 긴장감을 느끼나요? 개발자는 테스트에서 전문 과정을 수강해야합니까? 왜 테스트가 남겨져 있습니까? 아니면 내 경력의 지난 10 년 동안이 경험을 한 것은 나의 불행입니다.

의견을 환영합니다. 제발 질문을 닫지 마십시오.

Answer 1

제 생각에는 개발자가 "테스트가 작동합니까?"라는 테스트를해서는 안됩니다.

테스트 엔지니어는 "작동하지 않는"것이 있는지 테스트합니다. 이는 내 의견에서 매우 중요한 차이입니다.

그래서 다른 사람들이 테스트를 할 수 있도록, 테스트 엔지니어, 바람직하게하거나 기능 분석가, 지원 엔지니어, 프로젝트 관리자, 등등 ...

Answer 2

는 개인적으로, 내가 쓰는 모든 단위 테스트는 어떤 의미가있는 경우입니다. 일단 그런 종류의 테스트를 통과하면, 나는 보통 그것을 친구에게 넘겨주고 사용하도록 요청합니다. 예기치 못한 일을하거나 사용자가 직관적으로 설계 한 인터페이스가 실제로 복잡하다는 사실을 발견하는 것은 항상 최종 사용자입니다.

많은 관리자가 실제로 테스트에 더 집중해야합니다. 나는 개인적으로 코드의 일부가 소름 끼치게 여겨져 적절한 테스트없이 문 밖으로 나옵니다. 실제로, 여러 회사에서 사용하는 여러 응용 프로그램을 생각해 볼 수 있습니다.이 응용 프로그램은 유용성 테스트뿐 아니라 훌륭한 단위 테스트를 사용할 수있었습니다.

내가 궁금해하는 회사를 상상해 보니 테스트를 위해 전담 직원을 고용하거나 피할 수없는 문제를 나중에 해결하고 제품을 출입하는 데 드는 비용이 적습니까?

Answer 3

는 난 단지 테스터 전용 한 하나 개의 조직에서 근무했습니다 - 그것은

사용 TDD 1983 년이었고, 그것은 문제가되지 않습니다 - 플러스 개발주기를 가속화 할 것이다.

예를 들어 이번 주에 복잡한 응용 프로그램에 대해 3 가지 자동 수락 테스트를 작성했습니다. 이러한 테스트를 수동으로 수행하는 데는 약 4 시간이 걸립니다. 자동 테스트는 3 분 이내에 실행됩니다. 오늘 50 번 이상 테스트를 실행하여 크고 작은 버그를 모두 제거했습니다.

최종 결과 : 최종 사용자에게가는 것이 좋으며 팀의 능력에 대한 확신이 있습니다. 또한 자동화 된 테스트로 약 200 시간의 수작업 테스트가 오늘 으로 단축되었습니다. 그들은 미래의 향상이 이루어질 때 회귀 테스트로 훨씬 더 많은 것을 절약 할 것입니다.

일부 사람들은 TDD가 추가 오버 헤드를 부과한다고 주장합니다. 이는 가장 근시안에서만 사실입니다. 테스트 스크립트를 작성하는 데 약 2 시간이 걸렸습니다. 그들이 발견 한 20 개의 버그를 수정하면 나머지 작업 일이 걸렸습니다. 테스트를 거치지 않았다면, 나는 여전히 수동으로 테스트를 시도했을 것입니다. (기껏해야!) 버그를 추적합니다.

Answer 4

많은 다른 사람들처럼 (지금까지 당신은 너무 부끄러워서 인정할 수 없었습니다.)하지만 내 소프트웨어를 테스트 할 사용자가 있습니다. 나는 이것이 최선의 관행이 아니라는 것을 읽었지만 경영진이 가지고 있는지 확실하지 않습니다.

Answer 5

필자가 근무한 마지막 두 회사는 수동 테스트와 자동화 된 테스트 스크립트를 작성하는 전담 전문 테스터가있었습니다. 테스터는 개발주기가 끝날 때 (단순히 대대적 인 변경을하기에는 너무 늦었을 때) 단순히 제품을 테스트하지 않았으며 요구 사항을 테스트 케이스로 변환하고 개발 된 각 기능을 테스트 할 때부터 참여했습니다. 테스터는 별도의 부서가 아니었지만 개발 팀의 필수 요소 였고 매일 프로그래머와 함께 작업했습니다.

전담 테스터없이이 회사와 다른 점이 많습니다. 테스터가 없다면 두 회사 모두의 발전이 오래 전에 중단 될 수 있다고 생각합니다.

단위 테스트도 중요하지만 개발자는 코드가 올바르게 작동하는지 테스트하지 않습니다.

Answer 6

우리에게는 전용 테스터가 있습니다. 그러나 개발자의 경우보다 공식 테스트를 위해 테스터에 제출하기 전에 먼저 자신의 비공식 테스팅을 수행해야합니다.

Answer 7

회사에서 :
프로그래머는 모든 것을 테스트합니다.> 컴파일을 계속하면 (개발이 거의 끝났으므로 실제 환경에 변경 사항을 적용 할 필요가 없으므로) 수정하지 않으면 때까지. 아, 단위 테스트는 너무 오랜 시간이 걸리기 때문에 사용하지 않습니다.

나중에 버그는 일반적으로 사용자 및/또는 프로젝트 관리자가 프로젝트가 괜찮은 것처럼 보이지만 심층적 인 테스트를 수행하는 데 너무 많은 작업이 있는지 확인하는 사용자 또는 프로젝트 관리자가 발견합니다.

현재 1 년 동안 통보 /보고되지 않은 전혀 작동하지 않은 프로젝트의 일부를 수정합니다.

Answer 8

개발자가 단위 테스트를 수행합니다.하지만 단위 테스트는 애플리케이션에 충분하지 않습니다. 개발자가 실수를 절대 받아들이지 않고 자신의 코드를 보호하기 때문입니다. 좋은 품질의 제품을 제공하려면 QA 팀이 응용 프로그램을 테스트하게하십시오. 그들은 사용자의 관점에서 애플리케이션을 테스트하여 조직이 올바른 애플리케이션을 제공 할 수 있도록 도와줍니다.

Answer 9

우리 회사에는 테스터가 있습니다. 나는 테스터 중 한 명이다.

개발자는 코드를 사용하여 수행 한 작업을 테스트하고 정상적으로 작동하는지 확인하는 데 중점을 둡니다. 그러나 Tester의 관점에서, 그들은 버그를 찾으려고 노력하고 있습니다 - 그래서 테스트는 결함 식별을위한 것입니다.