가장 일반적인 것이 있다면 단위 테스트 이외의 테스트에 개발자가 책임을 져야합니까?

현재 다소 큰 프로젝트를 진행하고 있으며 JUnit과 EasyMock을 사용하여 기능 테스트를 상당히 광범위하게 수행했습니다. 이제 다른 유형의 테스트에 관심이 있습니다. 개발자로서 기능 테스트 또는 회귀 테스트와 같은 것에 대해 걱정해야 할 책임이 있습니까? Maven / Ant / Gradle과 같은 도구에 유용한 방법으로 통합 할 수있는 좋은 방법이 있습니까? 테스터 또는 BA에 더 적합합니까? 누락 된 다른 유용한 테스트 유형이 있습니까?

결함이없는 코드를 제공하기 위해 노력하는 것은 귀하의 책임입니다. 제공하는 코드에 대한 확신을 가지려면 테스트를 작성, 작성 또는 작성해야합니다.

참고 : 결함이없는 코드를 제공해야한다는 말은 아닙니다. 오히려 주어진 요구 사항에 맞는 최상의 코드를 작성해야합니다. 그렇게 할 수 있다는 것은 코드를 테스트해야한다는 것을 의미합니다.

이것이 기능 및 회귀 테스트에 대한 개인적 책임인지의 여부는 대부분 회사 구성 방식의 기능입니다. 내가 아는 모든 숙련 된 프로그래머는 스스로 "X 형 테스트를 작성하는 것이 나의 책임인가?"라고 묻지 않습니다. 대신, "자신의 코드가 제대로 테스트되도록하려면 어떻게해야합니까?"라고 스스로에게 묻습니다. 답은 단위 테스트를 작성하거나 회귀에 테스트를 추가하거나 QA 전문가에게 문의하여 어떤 테스트를 작성해야하는지 이해하는 것을 의미 할 수 있습니다. 그러나 모든 경우에있어, 코드가 제대로 테스트되었는지 확인하기 위해 작성중인 코드에 충분히 신경을 쓴다는 것을 의미합니다.

결론 : 고품질 코드를 제공해야합니다. 그것이 기능 또는 회귀 테스트를 작성해야한다는 것을 의미한다면 그렇게하십시오.

이것은 당신을 도울 수 있습니다 :

Q1은 개발자가 작성합니다.

Q2는 개발자가 자동화하고 비즈니스 및 / 또는 테스터와 공동으로 작성합니다.

누락 된 다른 유용한 테스트 유형이 있습니까?

Gherkin 언어 : JBehave (Java), Cucumber (Ruby), Behat (PHP) 등 을 사용하는 BDD 스타일 프레임 워크를 권장하는 승인 테스트가 있습니다 . 이러한 유형의 테스트는 단위 테스트보다 몇 가지 장점이 있습니다.

• 비 개발자가 테스트를 쉽게 읽을 수 있으므로 고객에게 테스트를 보여줄 수 있습니다.
• 테스트는 구현 세부 사항으로 가지 않고 비즈니스 프로세스를 명확하게 설명합니다 (구현이 중요하지 않다는 것을 의미하지는 않지만 비즈니스 요구 사항을 코드 자체와 분리 할 때 더 좋습니다).
• 테스트는 사용자가 응용 프로그램을 사용하여 수행 할 작업을 수행합니다.
• 작성하기가 더 쉽습니다 (IMHO, 언어 및 프레임 워크에 따라 다를 수 있음).

기능 테스트는 단위 테스트와 마찬가지로 자동화 할 수 있으며 프로젝트의 여러 구성 요소가 함께 작동하는 방식과 시스템이 비즈니스 규칙을 얼마나 잘 반영하는지 테스트하는 데 매우 유용합니다.

또한이 자동화 된 테스트는 소프트웨어에서 수행해야하는 주요 (또는 사소한) 변경 (버그 수정, 리팩터링, 비즈니스 변경, 새로운 기능 등)에 대한 회귀 및 승인 테스트 스위트 역할을합니다. 이를 통해 개발자는 더 많은 자신감을 갖게됩니다.

이러한 종류의 테스트에는 몇 가지 프레임 워크가 있으며, 우리는 fitnesse 를 매우 좋은 결과로 사용하고 있습니다. 웹 페이지 테스트를위한 매우 좋은 라이브러리를 보유하고 있으며 (웹 응용 프로그램 및 웹 서비스를 테스트하기 위해 사용) Maven 및 Jenkins 와 매우 잘 통합 됩니다.

우리는 또한 개발자들 사이에서 "교차 기능 테스트"를했지만 이러한 종류의 테스트는 "반복 할 수있는"것이 아니므로 그 유용성은 제한적입니다 ...

개발자로서 나는 모든 코드의 단위 테스트를 책임지고 결함이 없음을 최대한 보장 할 책임이 있다고 생각합니다. 그래서 우리는 조롱과 같은 많은 도구를 사용할 수 있습니다. 테스트에서 모의 ​​객체를 생성하는 목표는 코드를 "외부"세계와 정확하게 분리하여 코드가 제대로 작동하고 제대로 작동하는지 확인하고 실패한 것이 있으면 "오류가 아닙니다"라는 것입니다.

그것은 당신의 잘못이 아니며 코드가 정상적으로 작동한다는 사실에도 불구하고 나머지 테스트에서 도울 수 없다는 것을 의미하지는 않습니다. 또한 다른 사람이 만든 작업에 대한 작업을 돕고 통합하는 것이 귀하의 책임이라고 생각합니다. IT 개발 팀은 신뢰할 수있는 소프트웨어를 제공하기 위해 더 큰 팀으로 다른 부서 (QA와 같은)와 협력하여 기름칠이 잘 된 기계로 매번 작업해야합니다.

그러나 그것은 당신뿐만 아니라 팀의 일입니다.

분명히 통합 테스트 ; 그것들은 단위 테스트보다 더 중요하고 쓰기가 어렵습니다. 집을 짓는 것과 같습니다. 단위 테스트를 통해 벽돌이 단단하고 압력, 온도, 습도 및 기타 조건에 견딜 수 있다는 사실 만 보증합니다. 그러나 당신은 집이 벽돌을 합친 모습과 행동에 대한 단서가 없습니다.

대규모 프로젝트, 특히 컨테이너에 상주하는 Java 프로젝트의 문제점은 통합 테스트가 어렵다는 것입니다. 따라서 대규모 프로젝트에서 시스템 통합 테스트를 용이하게하려면 개발자가 코드를 작성하는 프로젝트 인 테스트 프레임 워크가 필요합니다. 최근이 분야에서 크게 개선되었으며 Arquillian 과 같은 플랫폼 은 테스트 프레임 워크 작성을 크게 단순화합니다 (또는 대체).

실제로는 팀 / 보스가 책임을지는 것만으로도 책임이 있습니다. 당신이 모든 구석과 성가신 사건을 찾기 위해 끊임없이 노력하고 돈을 지불하거나 사업 논리 버그에 대한 상사 (또는 더 나쁜 마케팅의) 해석의 변덕에 뛰어 들었다면, 모든 책임은 귀하에게 있습니다.

다시 말해, 당신에게 주어진 범위에서 요구되는 것을하십시오. 일반적인 상식을 던지거나 다른 사람들이 사용중인 제품과 사용 가능한 문제를 해결하기 위해 개발중인 제품을 사용하는 것을 볼 수있는 좋은 추가 기능입니다. 여기에는 선택한 도구가 포함됩니다. 모든 노력은 모두가 함께하는 일이어야합니다.

귀하의 질문에 유용한 버그 추적이 있다면 통신 시스템 측면에서 bugzilla, google docs, zendesk 또는 basecamp를 좋아합니다.

나는 이것이 이미 다루어 지지 않았다고 생각 합니다-그것을 놓쳤다면 미안합니다.

한 가지 문제는 개발자 시간을 효율적으로 사용하는 것입니다.

개발자는 종종 특정 유형의 테스트에 능숙한 기술이 부족합니다. 부분적으로 이것은 자연 스럽습니다. 저자에게 편집자가있는 것과 같은 이유입니다. 너무 가까이 있으면 부족한 부분을보기가 매우 어렵습니다. 그러나 그것은 또한 다른 기술과 다른 전문성에 관한 것입니다.

이 경우 개발자가 시간을 테스트하는 데 비용이 많이 들지 않습니다. 개발자는 다른 작업을 수행하면 생산성이 높아지고 전문 테스터는 테스트를 수행하면 생산성이 높아집니다.

물론 그것은 반드시 유효하지 않은 다양한 가정을 만들고 있습니다. 예를 들어 소규모 회사에서는 테스트 전문 인력을 고용하는 것이 적합하지 않을 수 있습니다. 추가 지원 직원을 고용하고 테스트를 받거나 적어도 사람들이 직접 작성하지 않은 코드를 테스트하도록하는 것이 더 합리적 일 수 있습니다.

QA를 위해 릴리스되기 전에 가능한 모든 테스트 시나리오를 포함하는 것은 개발자의 책임이라고 생각합니다. QA의 목적은 소프트웨어의 유효성 을 검사 하는 것입니다. 또한 오류에 대한 자신의 코드를 망치면 QA 시간이 항상 좋아 보일 것입니다.

어떤 테스트 사례가 가장 적합한 지 아는 것이 개발자보다 낫습니다. 개발자는 모든 단위 테스트를 수행해야하며 가능한 경우 테스트 스크립트 작성 및 실행을 도와야합니다. 대규모 프로젝트에서는 이러한 가능성이 거의 없기 때문에 개발자가 모든 테스트 사례를 검토 할 시간이 주어져야합니다. 또한 개발자는 지식이 있어야하며 다양한 자동화 된 테스트 도구를 사용해야합니다.

개발 경력에서 개발 팀과 테스트 팀이 긴밀하게 통합되어 프로젝트가 더 나은 결과를 얻는다는 것을 알게되었습니다.

각 팀의 구성원 중 최소 한 명은 다른 계획 및 구현 회의에도 참여해야합니다.