시스템 테스트 용 소프트웨어를 출시 할 때 새로운 기능을 추가하지 않고 버그를 수정하는 것이 맞습니까?

이 질문은 숙련 된 테스터 또는 테스트 리드에 대한 것입니다. 이것은 소프트웨어 프로젝트의 시나리오입니다.

개발자 팀이 10 가지 기능의 첫 번째 반복을 완료하여 시스템 테스트에 출시했다고 가정 해보십시오. 테스트 팀은이 10 가지 기능에 대한 테스트 사례를 작성했으며 테스트를 위해 5 일을 예상했습니다. 물론 개발자 팀은 5 일 동안 유휴 상태로있을 수 없으며 다음 반복을위한 10 개의 새로운 기능을 만들기 시작합니다. 이 시간 동안 테스트 팀은 결함을 발견하고 몇 가지 버그를 제기했습니다. 버그의 우선 순위가 정해지고 다음 반복 전에 버그를 수정해야합니다. 문제는 모든 버그가 수정 될 때까지 새로운 기능이나 기존 기능의 변경 사항이 포함 된 새 릴리스를 수락하지 않는다는 것입니다. 테스트 팀은 버그 수정과 함께 새로운 기능을 도입 할 경우 안정적인 테스트 릴리스를 보장 할 수있는 방법이라고 밝혔다. 또한 반복 할 때마다 모든 테스트 사례에 대한 회귀 테스트를 수행 할 수 없습니다.

이것은 개발팀이 버그 수정만을위한 코드 브랜치와 개발을 계속하는 다른 브랜치를 만들어야한다는 것을 의미합니다. 리팩토링 및 아키텍처 변경과 관련하여 특히 병합 오버 헤드가 더 많습니다.

이것이 일반적인 테스트 원칙인지에 동의 할 수 있습니까? 테스트 팀의 우려가 유효합니까? 실제로 프로젝트에서이 문제가 발생 했습니까?

대신 새 기능의 각 릴리스는 별도의 브랜치에 있어야한다고 말합니다. 이를 통해 개발 및 릴리스를 분리 할 수 ​​있습니다.

최종 사용자를위한 릴리스는이 프로세스에서 어떻게 작동합니까? 시스템 테스트 팀은 개발 일정에 관심을 두지 말고 고객 출시 일정에 중점을 두어야합니다.

다음 10 가지 기능이 동일한 기능에 영향을 미치고 해당 영역을 다시 테스트해야 할 가능성이 높기 때문에 개발이 계속되는 동안 새로운 기능을 공식적으로 테스트하려는 시도는 거의 의미가 없습니다.

개발 중에 비공식적으로 임시 내부 릴리스를 테스트하고 테스트 디자인을 구체화 할 수 있지만 (새로운 기능의 버그를 대부분 잡아 내기 위해) 개발 종료시 새로운 기능 및 회귀에 대한 공식 테스트를 위해서는 추가 기간이 필요합니다. 테스트.

고객이 10 개의 새로운 기능을 테스트하는 데 5 일이 소요될 것으로 예상 할 경우, 고객에게 릴리스하기 전에 개발주기가 끝날 때 5 일이 지나야 새로운 기능을 검증하고 (그리고 아마도 더 많은 시간이 소요될 수 있음) 버그가 발견되면). 이 기간 동안 테스트를 위해 고객 릴리스를 분기 할 수 있으며 다음 릴리스에서는 새로운 기능 개발을 계속할 수 있습니다.

우리는 하이브리드 접근법을 사용합니다. 고객 릴리스의 경우 중요한 버그 수정만을위한 자체 브랜치가 있습니다.

여러 소프트웨어 버전에서 정기적 인 개발이 계속됩니다. 예를 들어, 최신 안정 릴리스 버전은 2.0이라고 가정하겠습니다. 위험한 모든 기능이 3.0 지점에 추가됩니다. 버그 수정 만 2.0 지점으로 이동합니다. 전담 QA 팀의 테스트는 안정적인 지점에서만 수행됩니다. 고객 릴리스는 물론 2.0을 기반으로하는 다른 지점에서 수행됩니다. 차세대 플랫폼 개발과 같은 장기 실행 기능은 4.0에서 3.0까지 수행 될 것입니다.

이 모든 것이 종이에 잘 어울립니다. 그러나 고객이 특정 기능을 원하면 3.0 지점이 고객에게 출시 될만큼 안정적이지 않기 때문에 2.0 지점 자체에 추가해야합니다. 이는 QA 팀이 전체 회귀 제품군을 다시 실행해야 함을 의미합니다.

우리가하는 한 가지는 각 회귀 테스트 사례에 대한 코드 적용을 수행하는 것입니다. 해당 회귀 테스트 사례 만 실행되며 기능의 코드 변경에 영향을받습니다. 물론 고객 릴리스의 경우 전체 회귀 스위트가 실행됩니다.

이는 새로운 기능이 버그 수정이 필요한 부분과 얼마나 밀접하게 결합되어 있는지에 달려 있습니다. 예를 들어 UI의 작은 부분에 새로운 드래그 앤 드롭 기능을 추가하면 사용자가로드 한 파일의 구문 분석과 관련된 버그에 영향을 미치지 않아야합니다.

그러나 테스터가 수정 사항 'Ceteris paribus'(모든 '다른'것은 동일한 것)를 테스트하려는 것이 이해할 만합니다 (반드시 정당화 될 필요는 없음).

릴리스 및 최종 사용자의 예상 방식에 다른 문제가있을 수 있습니다. 예를 들어 사용자는 새로운 기능이있을 때만 다시 설치하거나 업그레이드하기를 원하기 때문에 버그 수정 + 테스트 및 새로운 기능 + 테스트를 한 번 반복 한 후에 만 ​​릴리스해야 할 수도 있습니다. 일부는 최우선 순위로 수정을 요구할 수 있습니다.

두 팀을 병합하여이 (일반적인) 문제를 해결할 수 있습니다.

기능이 생성 될 때 테스트하는 개발 팀 내의 테스터는 대부분의 팀이 출력 품질을 높이는 데 도움이 될 수 있습니다.

나는 당신이에서이 우수한 블로그 게시물을 읽어 제안 헨릭 Kniberg 설명 요 시타 가방을 . 스크럼 프로세스 ( Henrik Kniberg 의 무료 책) 에서 많은 아이디어를 찾을 수 있습니다.

그는 또한 자신의 블로그에 훌륭한 Kanban VS Scrum 기사를 썼습니다 .

즐겨.

테스트 팀은 분명히 유효한 우려 사항이 있지만 각 릴리스마다 여러 번의 테스트 반복이 필요한지 의문입니다. 사용자가 볼 수없는 코드 버전에서 전체 테스트를 수행해야하는 이유는 무엇입니까?

테스터가 고객에게 정의 된 릴리스를 가져 오려고 시도하는 경우 (새로운 기능을 기대하지 않는 경우) 해당 요청은 합리적이고 정당하며 ​​요청을 뒤로 구부려 전달해야합니다.

이것이 정상적인 개발 단계에서 "프로세스"를 지원하고 버그 목록을 제어 할 수없는 문제가되지 않도록하려면 문제를 해결하지 않으면 서 테스트 책임자에게 문의하십시오. 출시 지점에 가까워집니다.

소스 제어 시스템을 분산 제품으로 변경하십시오. 이렇게하면 그러한 릴리스를 훨씬 쉽게 전달할 수 있습니다.

"이것이 일반적인 테스트 원칙인지 동의 할 수 있습니까?

Yes

테스트 팀의 우려가 유효합니까

Yes

실제로 프로젝트에서이 문제가 발생 했습니까? "

Yes

:

and Yes Merging is the downside of it 

누구의 책임인지 묻지 않았지만 구성 관리자의 책임입니다. 이 스트림 전략은 그의 CMP에 있어야합니다. 그렇지 않으면 그를 해고하십시오. 피에르 303의 답변은 매우 훌륭하지만 기술적으로 (예 : Siebel 릴리스에 대한 생각과) 조직적으로 가능할 것입니다.

문제는 지점에서 버그를 테스트하는 경우 다시 병합 된 트렁크에서 버그를 다시 테스트하고 회귀 테스트해야한다는 것입니다. 이것은 개발자를위한 더 많은 일을하는 것이 아니라 테스터를위한 더 많은 일을하는 것입니다.

여기에는 정답이 없지만 몇 가지 고려해야 할 사항이 있습니다.

• 새로운 기능없이 이러한 버그 릴리스가 사용자에게 제공 될 수 있습니까? 그렇다면 예, 분기되고 테스트되어야하며 모든 사람이이를 오버 헤드로 받아 들여야합니다.

• 응용 프로그램의 완전히 별도의 영역에 존재하는 방식으로 새로운 기능을 작업했던 이전 청크로 분할 할 수 있습니까? 그렇다면 테스터는 응용 프로그램의 버그 재 테스트 및 회귀 테스트 부분을 수행 할 수 있습니다. 이상적이지는 않지만 작동하여 원하는 것을 제공 할 수있는 타협입니다.

• 릴리스를 분기하는 것이 실제로 얼마나 많은 작업입니까? 일반적으로 고통 스럽지만 실제 작업량은 일반적으로 그렇게 크지 않습니다. 분명히 당신은 그것이 그들에게 더 많은 일이 아니라는 것을 확인하기 위해 필요할 것입니다 (첫 번째 말을 참조하십시오). 그러나 내가이 일을하는 곳을 보았습니다.

• 여기에 버전 관리를 사용하는 더 좋은 방법이 있습니까? Mercurial ( http://hginit.com/ 참조 -잘 읽어보십시오) 또는 다른 분산 버전 제어 시스템과 같은 것이 다른 방식으로 분기되고 병합되어 문제를 해결할 수 있습니다. 실제로, 그것이 당신의 문제에 대한 답이라고 생각하기 때문에 그것을보십시오.

그러나 행운을 빕니다, 그것은 고통입니다. 무엇보다도 최선의 방법은 회사, 제품 및 상황에 크게 좌우 될 것이므로 기억하십시오. 선반에서 무언가를 꺼내지 말고 100 % 준수해야한다고 생각하십시오.

설명하는 버그가 실제 결함 이며 설계 최적화가 아니라면 새로운 기능에 대한 작업을 시작하기 전에 실제로 수정해야합니다.

알려진 버그 위에 새로운 기능을 구축하면 카드 하우스를 생성하게됩니다. 깨지기 쉽고 예측할 수없는 소프트웨어를 개발할 수 있습니다. 버그가있는 코드와 새 기능 간의 격리 수준에 따라 버그가 새 기능에도 영향을 줄 수 있습니다. 그렇다면 새로운 기능이 올바르게 작동하는지 어떻게 알 수 있습니까?

버그를 먼저 수정하면 추가 한 새로운 기능의 기반이 더욱 강화됩니다.

분명히, 외세가 더 나은 판단에 반대하도록 압력을 가하는 경우가 있습니다. 의사 결정자들이 조치 중 어느 결과 (즉, 해결되지 않은 결함 대 기능 전달 날짜 누락)의 결과를 인식하고 판단을 내릴 수 있도록 정보에 근거한 결정을 내릴 수 있도록하십시오. 때로는 바람직하지는 않지만 조치가 필요한 법적, 재정적 이유가 있습니다.

새로운 기능을 추가하기 전에 항상 버그를 수정하십시오!

내가 일하는 곳에서 프로덕션으로 출시되는 각 릴리스마다 자체 지점이있는이 시나리오를 처리합니다. 예를 들어, 6 월 말에 릴리스가 있고 7 월 말에 또 다른 릴리스가 있다고 가정 해 봅시다. 6 월 릴리스에는 자체 지점이 있으며 모든 기능이 추가되어 QA로 전송됩니다. 이 시점에서 7 월 릴리스와 6 월 지점에서 작업을 시작합니다. QA가 버그를 발견하면 6 월 지점에서 버그를 수정하고 일단 수정 사항이 QA로 푸시되면 7 월 릴리스 지점으로 병합됩니다. 이렇게하면 이러한 병합을 처리하는 데 약간의 오버 헤드가 발생하지만 일반적으로 병합은 상당히 고통스럽지 않습니다. 가끔 큰 어려움을 겪는다는 것을 알고 있지만, 이는 도매 변경이 이루어질 때만 발생하며 QA주기 중에는 발생하지 않아야합니다. 내가 인정하고 싶은 것 이상). 그러나 우수한 테스트 (단위 및 통합), 코드 적용 범위 및 기타 모든 TDD 용어를 사용하면 위험이 약간 완화됩니다. 이를 돕기 위해 일반적으로 각 프로젝트마다 한 사람이 병합을 처리합니다.