2011-03-10 6 views
1

저는 30 명이 넘는 개발자 팀과 QA 테스터 팀으로 이루어진 대기업 소프트웨어 회사의 품질 보증 테스트 리드입니다. 우리는 현재 SVN을 사용하여 모든 코드와 스키마 검사를 수행합니다.이 코드는 매일 밤마다 작성됩니다.개발/품질 보증/생산 환경

나의 딜레마는 다음과 같습니다. 모든 개발 코드는 머신에서 중앙 저장소로 매일 하나의 분기로 승격됩니다. 이 지점은 다음 소프트웨어 릴리스를위한 프로덕션 코드입니다. 코드가 체크인 될 때마다 QA가 테스트를 수행 할 수있을 때까지 stable 브랜치가이 새로운 코드로 안정화됩니다. QA가 특정 코드 조각을 테스트하는 데 몇 주가 걸릴 수 있습니다. 이 모든 것의 가장 나쁜 부분은 표준 릴리스로 들어가는 코드가 앞으로 몇 개월인지를 식별하고 다음 분기로 어떤 코드가 부딪히는지를 확인하는 것입니다.이 코드는 실제 출시까지 거의 모든 코드를 코딩합니다 날짜.

나는이 프로세스의 효과를 보았고 (전임자들에 의해 제정 됨) 개발을 열망하지 않는 방법을 고안하여 QA로 코드를 승격시킬 수 있습니다. 환경, 다른 개발자의 코드 조각을 들고하지 않고. 많은 코드가 라이브러리를 공유하고 있기 때문에 앞서 언급했듯이 가끔 QA를 사용하여 테스트 할 코드 조각을 얻을 수 있습니다. 코드 일부가 테스트되기를 기다리는 동안 특정 영역에서 개발을 보류하고 싶지 않습니다.

제 질문은 지금 채택 할 수있는 가장 좋은 방법은 무엇입니까? 이것으로 도움을 줄 수있는 것보다 소프트웨어가 있습니까? 내가 정말로하고 싶은 것은 QA가 시험 될 때까지 새 코드를 입력하지 않고 릴리스를 테스트 할 수있는 충분한 시간을 확보하는 것입니다. 나는 많은 사람들에 따르면 "QA가 진절머리 나는 일을하고 있기 때문에"새로운 일자리를 찾기 위해 거리에서 끝내기를 원하지 않는다.

모든 제안 사항은 대단히 감사 드리며 테스트 및 제품에 도움이됩니다.

답변

1

빌드 및 테스트 및 배포를 자동화 할 수있는 연속 통합 서버가 필요합니다. Apache Hudson, JUnit (DBUnit), Serenium 및 Sonar와 같은 코드 품질 도구의 조합을 살펴 보겠습니다.

0

분기없이 SVN을 사용하면 낭비되는 것처럼 보입니다. 그들은 안정된 지점과 시험 지점 (즉, 일일 빌드)을 설정해야합니다. 코드가 매일 빌드에서 테스트되면 개발 릴리스 분기로 푸시 될 수 있습니다.

당신의 코드에 따라 알버트가 언급 한 것처럼 일부 공유 라이브러리 (개발중인 지역에 따라 실제로 많이 변경하지 않아야 함) 또는 개발 팀이 조직 imho의 진절머리 나는 일을하고있다).

개발자 팀 리더 (또는 관리자)와 대화하여 QA를 보는 위치와 QA가 최선을 다할 수있는 방법에 대해 토론 할 수도 있습니다. 다음과 같이 질문하십시오. 귀하의 개발 팀은 릴리즈 이전에 시간이 정해져 있습니까? 모든 단일 코드 행을 테스트합니까? 당신은 너무 많은 상세한 시간을 테스트 할 수있는 장소가 있습니까? QA, QA 및 개발자 모두가 제품을 출시하기 위해 함께 노력해야합니다.

+0

우리는 현재 릴리스와 다음 릴리스를 안정화 지점으로 분기하지만 다음 릴리스로 진행되는 버그 수정은 일반적으로 현재 릴리스로 다시 포팅됩니다. – vwgti

4

넓은 대답이 필요한 광범위한 질문입니다. 테스트 관리자가 아닌 개발자 리드 및 설계자로 일하고 있습니다. 나는 당신이 설명하는 과정에서 몇 가지 문제를 참조 각각의 솔루션이 필요합니다

  1. 테스트 팀은 중간 버전
    작업이라는 의미의 반복에 자신의 작업 노력을 분할에 dev에 사람 (작업에 의해 처리되어야한다 민첩한 방법론에서의 스프린트), 몇 주마다 작동하는 버전을 제공합니다.또한 기능이 우선 순위에 따라 구현되어야한다는 사실이 입증되어야합니다. 이렇게하면 "테스트 간격"이 고정되어있는 이점이 있습니다. 항상 몇 주 전에 최신 버전을 테스트하면 devs는 다음 버전의 새로운 기능보다 더 중요한 문제가 있음을 이해합니다.

  2. 비 안정 버전 작업 팀
    테스트 팀이 "도착시 죽었습니다"버전에 시간을 투자해야하는 이유는 없습니다. Continuous Integration은 가능한 한 빨리 "코드 깨뜨리기"가 발견되는 방법론입니다. 이것은 허드슨이나 자생적 인 솔루션과 같은 제품에 대한 투자가 필요합니다. 빌드 실패는 발생시 통지가되며, 일부 "연기 테스트"가 적용됩니다.

  3. 테스트주기가 길다.
    자동화 테스트에 투자하십시오. 테스터가 프로그램을 배우는 것이 필요하다고 말하는 것은 아닙니다. 오히려 안정적인 자동화 된 테스트를 작성하는 데 지식과 열정을 가진 사람들을 모집하거나 성장시키는 데 투자해야합니다.

  4. "실제 출시일까지 거의 모든 코드 작성"을 선택하십시오.
    맞아요. 그것은 당신과 당신의 경영진이 선택한 선택이며, 안정성과 품질에 대한 더 많은 특징을 선호합니다. 가능한 빨리 시장에 출시하거나 핵심 고객을 만족시킬 필요가있는 일부 회사에서는 훌륭한 선택입니다. 그러나 장기간에 걸친 투자는 좋지 않습니다. 일단 당신이 당신의 경영진에게 확신을 갖게했다면, 그것은 정말로 필요하지 않을 때 그것을 취하는 것을 멈출 수 있습니다.

또 다시 내 두 센트입니다.

1

QA가 테스트하는 코드가 고유하고 지속적으로 변경되지 않도록하려면 태그를 사용해야합니다. 태그는 내용이 불변이라는 점을 제외하면 가지와 같습니다. 파일 집합이 체크 인/커밋 된 후에는 변경 및 커밋 할 수 없습니다. 이렇게하면 품질 보증은 그들이 작업하고있는 안정적인 버전의 코드를 갖게됩니다.