재오픈하면 조치 5일이 처음부터인가

계약이나 시험 계획에 적힌 규칙을 따릅니다. 규칙이 없으면 같은 증상은 재오픈일부터 합의 일수를 다시 세고, 그 문장을 조서에 남깁니다.

새 번호를 따면 잔여 결함이 늘어 보이지 않나

다른 기대 결과면 늘어 보이는 것이 맞습니다. 같은 증상을 새 번호로 쪼개면 건수만 늘므로, 세 칸이 같으면 원래 번호를 유지합니다.

사인 후에 다시 열리면 검수가 취소되나

그 결함이 묶인 시나리오만 다시 엽니다. 전체 사인 취소는 조서에 적어 둔 심각도 예외일 때만 합니다.

재현이 안 되는 티켓은 당일 닫아도 되나

시도와 입력값을 남기기 전에는 닫지 않습니다. 날짜를 달리한 재현 실패가 찬 뒤에 닫아야 다음 날 같은 제목이 돌아오지 않습니다.

결함 재오픈 기준 정리 - 닫힌 티켓이 다시 열릴 때 조치 기한

닫힌 결함을 다음 날 다시 열면, 조치 기한 5일은 등록일부터일까요, 재오픈일부터일까요. 같은 티켓을 살리는 팀과 새 번호를 따는 팀이 한 프로젝트에 같이 있으면, 검수 잔여 건수가 매일 달라집니다. 재현 절차가 비어 있으면 재오픈은 감정 표시가 되고, 감정 표시는 기한을 멈추지 못하죠. 하지만 증상과 요구 변경을 같은 상자에 넣으면 시계가 더 꼬입니다. 이번 포스팅에서는 재오픈의 기산점과 새 결함으로 가를 기준을 자세히 다뤄보도록 하겠습니다. 검수 직전 결함 건수가 출렁이는 현장이라면, 시계 규칙을 조서에 적는 데 도움이 될 것입니다.

들어온 증상	번호	기한	남길 기록
같은 화면, 같은 기대 결과	원래 번호 재오픈	재오픈일부터 다시 계산	재오픈 시각
기대 결과가 다름	신규 번호	신규 등록일	연관 번호
재현 두 번 실패	닫기 후보	기한 정지	시도 계정과 입력값
환경 차이로만 보임	환경 이슈	결함 기한 아님	환경 이름
기준선 이후 규칙 변경	변경 번호	결함 기한 정지	회의록 또는 공문

다시 열린 증상을 보내는 곳

닫힌 결함을 다시 열면 기한은 어디서 세나?

같은 증상으로 다시 열리면 기산점은 재오픈일입니다. 처음 등록일을 유지하면 이미 만료된 결함만 쌓입니다.

조치 기한 5일을 처음 등록일에 묶어 두면, 한 번 닫혔다가 다시 열린 결함은 열리는 순간 이미 지각입니다. 지각인 결함은 아무도 순서를 안 정하죠.

같은 증상, 같은 화면, 같은 데이터 조건이면 원래 번호를 유지하되, 기한은 재오픈일부터 다시 셉니다. 남은 일수가 아니라 합의된 일수 전체를 다시 주는 현장도 있고, 남은 일수만 주는 현장도 있습니다.

어느 쪽이든 조서에 한 문장으로 적혀 있어야 합니다. 문장이 없으면 개발은 남은 일수를 주장하고, 현업은 새 5일을 주장합니다.

QA vs QC가 매일 보는 숫자는 열린 건수이지, 기분에 따라 늘어난 기한이 아닙니다. 재오픈 시각을 티켓에 안 남기면, 그 건은 보고마다 나이가 달라집니다.

주간보고에는 최초 등록일과 최근 재오픈일을 둘 다 두세요. 한 날짜만 있으면 그 건의 나이가 회의마다 갈라지죠.

같은 결함과 새 결함은 무엇으로 가르나?

재현 절차와 기대 결과가 같으면 같은 결함입니다. 화면만 비슷하고 기대 결과가 다르면 새 번호입니다.

제목이 비슷하다는 이유로 옛 티켓을 다시 열면, 서로 다른 버그가 한 줄로 뭉칩니다. 반대로 댓글이 길다는 이유로 새 번호를 따면, 같은 버그가 검수 건수를 부풀리죠.

가르는 칸은 세 개면 됩니다. 화면 또는 시나리오 ID, 재현에 쓴 데이터, 기대 결과.

세 칸이 같으면 재오픈입니다. 하나라도 다르면 신규이고, 연관 번호만 적습니다.

기대 결과를 비워 두면 가르기가 불가능합니다. 비어 있는 기대 결과는 결함이 아니라 문의에 가깝죠.

문의는 기한을 세지 말고, 답을 적은 뒤 닫습니다. 검증(Validation) 시나리오에 기대 숫자가 있으면, 그 숫자를 티켓 첫 줄에 붙여 주세요.

숫자가 없는 불만은 재오픈 규칙으로 닫히지 않습니다.

재오픈이 검수 사인 날짜를 미루나?

사인 항목에 묶인 결함만 사인 날짜를 밉니다. 다른 시나리오의 재오픈으로 전체 검수를 열지 않습니다.

결함 하나가 다시 열렸다고 검수 전체를 미결로 되돌리면, 이미 사인된 시나리오가 매주 풀립니다. 풀린 사인은 다음 주에 또 받느라 현업 일정이 사라지죠.

조서의 합격은 시나리오 단위로 유지하고, 재오픈된 번호가 그 시나리오의 합격 조건에 들어 있을 때만 그 시나리오를 다시 엽니다. 다른 시나리오의 결함은 잔여 목록에 남기되, 전체 사인을 취소하지 않습니다.

심각도가 높은 결함은 예외로 전체 오픈을 막을 수 있습니다. 그 예외도 등급 기준이 조서에 있어야 합니다.

기준이 없으면 모든 재오픈이 오픈 차단이 되죠. 차단이 잦으면 사람들은 결함을 닫힌 척 두기 시작합니다.

닫힌 척은 잔여 건수를 0으로 만들고, 오픈 다음 날 같은 증상을 장애로 바꿉니다.

재현이 안 되는데 현업이 다시 열면 어떻게 닫나?

재현이 안 되면 즉시 종결하지 않습니다. 재현 시도와 사용한 데이터를 남기고, 재현 실패 횟수가 찬 뒤에 닫습니다.

현업 화면에서만 보이고 시험 환경에서 안 보이는 증상이 있습니다. 그걸 재현 불가로 당일 닫으면, 다음 날 같은 제목으로 다시 열립니다.

다시 열린 건의 기한을 누가 세는지가 그때 싸움이 되죠. 재현 시도는 최소 두 번, 서로 다른 날짜에 남기는 편이 현장에서는 덜 반복됩니다.

각 시도에 계정, 시각, 입력값, 환경 이름을 적습니다. 두 번 모두 재현이 안 되고 현업도 같은 절차로 재현을 못 하면, 그제서야 닫습니다.

환경이 달라서 못 본 것이면 결함을 닫지 말고 환경 차이를 이슈로 올립니다. 환경 이슈에 결함 기한을 돌리면, 데이터 준비 시간이 개발 지각으로 집계됩니다.

집계가 틀린 기한은 다음 산정에서 결함 여유를 엉뚱한 곳에 붙입니다. 재현에 쓴 계정은 개인 계정이 아니라 시험 전용 계정으로 적으면, 다음 사람이 같은 권한으로 따라 할 수 있고, 재현도 빨라지죠.

계정 이름은 조서 각주에 남기세요.

요구가 바뀌어서 생긴 증상은 결함인가?

기준선 이후의 규칙 변경이면 결함이 아닙니다. 변경 번호를 적고, 결함 기한은 멈춥니다.

시험 중에 정산 규칙이 바뀌면, 어제 합격한 화면이 오늘 오답이 됩니다. 그 오답을 재오픈으로 넣으면 개발 조치 기한만 닳죠.

규칙이 바뀐 근거가 회의록이나 공문에 있으면 변경관리 번호로 보냅니다. 결함 티켓은 연관만 남기고 상태는 변경 대기로 둡니다.

변경 대기는 결함 기한에서 뺍니다. 빼지 않으면 변경 심의 날이 전부 결함 지각이 되죠.

근거 문서가 없으면 변경도 결함도 아닙니다. 기준선에 그 규칙이 있었는지부터 확인합니다.

기준선에 있었는데 구현이 다르면 결함입니다. 기준선에 없고 회의에서 새로 나왔으면 변경입니다.

이 한 줄 확인을 재오픈 버튼보다 먼저 두면, 검수 직전 건수가 감정 따라 출렁이지 않죠. 변경 대기 건수는 결함 잔여와 다른 열에 두어야 검수 숫자가 개발 지각으로 오해되지 않습니다.