시스템 테스트를 민첩한 프로세스에 어떻게 통합합니까?[닫은]

Question

민첩한 개발에 대한 고전적인 설명에는 반복이 끝나면 릴리스 가능한 코드가 있습니다.출시 가능한 제품을 만들기 위해 추가 테스트와 검증이 필요한 경우 이를 프로세스에 어떻게 통합합니까?

Answer 1

자신만의 프로세스를 만드는 것을 방해하는 것은 무엇입니까?더 나은 것을 찾으면 ...그냥 해.효과가 있으면 힘내세요..그렇지 않다면 다른 것을 시도해 보세요.민첩성을 원한다면 정해진 프로세스가 없습니다.
더 자주 사용되는 용어는 '배송 가능' 코드는 모든 반복이 끝날 때마다 발생합니다.즉, 이를 최종 사용자에게 제공할 수 있으며(공유를 복사하거나 개인적으로 CD/DVD를 전달하기 위한 DLL 묶음으로) 최종 사용자는 이를 사용하여 가치를 얻게 됩니다.이러한 코드 모든 단위 테스트(개발자) 및 승인 테스트(고객/QA/분석가)를 통과했습니다. 그것은 "완료"에 필요한 것으로 간주되었습니다. 수락 테스트는 엔드 투 엔드 고객 시나리오 시뮬레이션입니다.

'추가 테스트 및 검증'이 무슨 뜻인지 잘 모르겠습니다.다른 '출시 전' 활동도 생각해볼 수 있겠네요

• "교육 컨퍼런스" 및 관련 콘텐츠 제작과 같은 특정 활동.
• 고객 배포가 드물거나 자주 수행할 수 없는 경우 릴리스 전 한 달 동안 데모 또는 베타 사이트에 배포합니다.
• 잠재 고객/전문가/서비스가 이미 들어본 신제품을 직접 엿볼 수 있습니다.

마지막 반복 끝점 끝에 쌓으면 됩니다. (나처럼 특별히 비관적인 사람이라면..역사적 평균을 취하세요..일찍 풀면.예!) 따라서 비즈니스에서 Iteration#14가 릴리스될 수 있는 좋은 기능 세트의 범위를 결정한다고 결정한 경우..Iteration#14가 끝난 후 'n주 추가'일 뿐입니다.그 시점에서는 복잡한 수학이나 불확실성이 없습니다.핵심은 그거다. 이해관계자/고객과 정기적으로 소통하고, 피드백을 통합하고, 허용 가능한 수준의 품질을 유지했다면 마지막 순간에 놀랄 일이 있어서는 안 됩니다.

필요하다면, 심지어 순조롭게 출발하다..즉.교육팀은 개발팀이 Iteration#13에 진입하면서 작업을 시작합니다.2주 반복을 가정하면 한 달이 됩니다.마지막 반복에 많은 기능이 추가되지 않기를 바랍니다.따라서 Iteration#14 이후 최대 2주가 지나면 모든 천체/조직 정렬이 적용되며 릴리스와 적절한 휴식을 취해야 합니다.

Answer 2

먼저 당신이 말하는 테스트의 폭/넓이를 인식하십시오. 증가하다 프로젝트가 진행되면서 소프트웨어의 범위 및/또는 복잡성이 커집니다.이 때문에 이러한 노력을 반복에 투입하려고 하면 한두 번의 반복 후에는 효과가 없습니다.반복에 대한 기분 좋은 규칙은 프로젝트 속도에 따라 결정되는 각 반복의 작업 수준이 일정하다는 것입니다.

이에 대한 해결책은 다음 두 가지 방법 중 하나를 취할 수 있습니다.자동화 유무에 관계없이.더 높은 테스트 수준의 자동화는 테스트 실행 노력을 줄여 각 반복이 점진적인 범위/복잡성 증가에만 초점을 맞추기 때문에 작업을 반복 내부에 다시 ​​적합하게 만듭니다.우리가 원하는 경우에도 모든 프로젝트 상황에서 이것이 항상 달성 가능한 것은 아닙니다.높은 수준의 테스트 자동화를 과대평가하는 것은 진지하게 받아들여야 하는 함정입니다. 즉, 합리적으로 경험이 풍부한 탐색적 테스터가 테이블에 가져오는 것을 과소평가하지 마십시오.

자동화가 없으면 문제는 테스트 관리를 기반으로 하는 문제로 전환됩니다.병렬적인 시간 이동 테스트 반복이 하나의 후보 솔루션입니다.예를 들어 개발 반복과 동일한 주기로 관리되지만 전체 반복 기간만큼 지연되거나 시간 이동되는 시스템 테스트 작업에 대한 테스트 백로그를 설정하도록 선택할 수 있습니다.이를 통해 테스터는 자신의 샌드박스에서 자신의 우선순위에 따라 새 릴리스에 대해 전체적으로 작업할 수 있습니다.

나는 개발자 반복 백로그가 테스터와 협력하여 구축되는 것처럼 테스트 반복 백로그가 개발자와 협력하여 구축되어야 한다고 주장하고 싶습니다.또한 자동화 경험이 있는 테스트 팀이 지루함을 자동화하고 보다 탐구적인 방식으로 작업할 수 있도록 옹호하고 싶습니다.자동화된 테스트 포트폴리오는 반복할 때마다 증가해야 합니다.또한 개발자 단위 테스트에 액세스할 수 있어야 하며 테스트 샌드박스의 릴리스에서 이를 실행할 수 있어야 합니다.

이와 같이 단계적으로 작업한다고 해서 증가하는 테스트 범위/복잡성 문제가 사라지지는 않지만 팀이 백로그 항목을 생성하고, 우선 순위를 조정하고, 일부를 자동화하고, 체크리스트를 생성하는 등의 작업을 수행하므로 복잡성을 관리하기 위한 메커니즘을 제공합니다.그들이 다음에 해야 할 일을 집단적으로 생각하는 것에 기초합니다.그들은 큰 항목을 칠 가능성이 있습니다.

테스터가 전체적으로 작업하고 이해를 발전시키며 자동화된 테스트를 통해 시스템에 대한 지식을 공유할 수 있는 능력을 유지하는 것은 모두 노력할 가치가 있는 것으로 보입니다.

Answer 3

각 자동화된 빌드 이후의 자동화된 테스트는 최소한 일부를 제공합니다.

Answer 4

스프린트 백로그(스크럼) 또는 이에 상응하는 항목에 시스템 테스트를 추가하세요.

Ditto 사용자 문서.

Answer 5

시스템 테스트 실행은 일반적으로 애자일 개발에 긴밀하게 통합하기에는 너무 느립니다.(여기에는 예외가 있습니다.잘 설계된 브라우저 테스트는 일반적인 단위 테스트보다 훨씬 느리게 실행될 수 있습니다.)

통합 방법 중 하나는 항상 실행되고 모든 테스트를 빌드하고 실행하는 데 몇 시간이 걸릴 수 있는 야간 빌드 또는 연속 빌드를 사용하는 것입니다.빌드가 모든 테스트(단위 테스트 + 시스템 테스트)를 통과하면 릴리스 가능해지며 해당 바이너리 또는 소스 코드의 스냅샷을 전달할 수 있습니다.아이디어는 x 버전의 바이너리/코드 스냅샷을 갖고 이를 비동기적으로 확인하고 친환경 빌드를 제공하는 것입니다.이는 자동화된 시스템 테스트와 수동 시스템 테스트 모두에서 작동합니다.