QA 팀에서 버그를 신고하는 경우도 있지만 버그를 재현하는 방법에 대해서는 전혀 모르고 있습니다. 이로 인해 때때로 결과가 나오지 않는 매우 길고 실망스러운 디버깅 세션이 발생합니다.

내 소프트웨어는 독점 하드웨어와 밀접한 관련이 있으므로 버그는 한 번에 여러 방향에서 나올 수 있습니다.

"버튼을 눌렀을 때 소프트웨어가 다운 된 것"보다 더 많은 것을 기대해야합니까?

편집하다:

저의 동료 중 한 명이 우리 모두가 여기에있는 모든 개발자 일 것이라고 지적했으며 결과에 약간의 편차가 생길 수 있습니다

품질 보증팀에서는 항상 버그를 최대한 쉽게 재현 할 수 있도록 노력해야하며 버그 설명에 단계가 포함되어 있어야합니다.

그러나 버그를 쉽게 재현 할 수없는 경우에도 적절한 제목 / 제목과 버그의 원인에 대한 자세한 설명을 버그 데이터베이스에 입력해야합니다. 버그 설명에 버그를 재현 할 수 없다고 명시해야합니다 (아마도 "5 번 시도했지만 한 번 발생했습니다"). 이 방법으로 다른 사람이 동일한 버그를 발견하면 발견 한 내용을 버그 데이터베이스에 추가 할 수 있으며 가능한 한 많은 정보를 얻을 수있어 문제를 추적하는 데 시간을 절약하는 데 중요한 정보를 얻을 수 있습니다.

또한 정보를 필터링 할 수 있습니다. 다른 시스템에는 코드의 한 영역에 모두 연결된 것으로 알려진 많은 버그가있을 수 있습니다. 품질 보증팀에서 아무 것도보고하지 않으면 (재 작성할 수 없으므로) )이 정보는 당신에게 도착하지 않습니다.

품질 관리 부서에서 너무 많은 탐색 테스트를 수행하고있는 것 같습니다 (예 : 테스트 계획이 적합하지 않음).

탐사 테스트는 훌륭하고 문제 영역을 식별하지만 거기에서 특정 버그를 드러 낼 재현 가능한 테스트 사례 (예 : 테스트 계획)를 정의해야합니다.

올바른 재현이 필요한 이유는 여러 가지가 있습니다 (좋은 것만이 아니라 필요한 것).

1. 원인을 디버그 / 추적 할 수 있도록 재현해야합니다.
2. 완료되면 QA에서 수정 사항을 확인할 수 있어야합니다.
3. 추가 테스트 패스는 이전 버그에서 회귀를 수행해야합니다.
4. 노출이 너무 작거나 재현성이 너무 낮 으면 알려진 버그를 버릴 수 있습니다.

SteveCzetty는 다음과 같이 지적합니다.이를 재현하지 않고 닫고 다시 작업하십시오.

버그를 일관되게 재현 할 수 없다면 QA는 버그가 수정되었는지 어떻게 알 수 있습니까?

예, 더 많은 것을 기대해야합니다. 그들은 말할 수 있어야합니다.

1. 새로운 프로그램 시작
2. 버튼 A를 눌렀습니다
3. 양식 # 1의 테스트 이름 필드에 "테스트 텍스트"를 입력했습니다.
4. 버튼 B를 누름
5. 프로그램이이 메시지와 충돌하는 것을 관찰했습니다 (첨부 된 스크린 샷 참조).

그들이 말하는 모든 것이 "충돌 된"것이라면, 그들은 좋지 않습니다. 위의 단계를 100 % 재현 할 수 없더라도 패턴이 감지되면 이러한 크래시를 충분히 크게 샘플링하여 원인을 좁히는 데 도움이 될 수 있습니다.

내 충고는 그 버그를 읽고 좋은 생각을하는 것입니다. 잠재적 인 원인을 파악할 수 없다면 지금 당장 잊어 버리십시오.

품질 관리는 문제가 어떻게되는지 모를지라도 발견 한 모든 문제를 문서화해야합니다. 문제를 시도하고 재현하는 것은 QA의 임무이지만 현실적으로 항상 가능하지는 않습니다. 때로는 지난 10 분 동안 수행 한 작업과 관련이 없습니다. 하루 전에 잘못된 상태가되었고, 최근 10 단계 중 하나 때문에 문제가 분명해졌습니다.

이러한 "1 in 1000"버그로 인해 QA는 약간의 버그를 재현해야합니다. 성공하지 못하면 버그를 문서화 한 다음 조금 더 시도해야합니다.

버그를 상당히 일찍 입력해야하는 이유는 프로그래머가 QA보다 코드를 훨씬 잘 알고 문제를 즉시 알 수 있기 때문입니다. 리팩토링 된 코드 일 수 있습니다. 그들이 절반 구현 한 다음 잊어 버린 기능 일 수 있습니다. 그들은 알지 못할 수도 있지만 테스터가 코딩하는 사람에게 명백한 문제를 재현하기 위해 몇 시간을 낭비하는 것은 의미가 없습니다. 테스터는 나중에 버그에 더 많은 정보를 추가 할 수 있습니다.

버그는 가능한 많은 정보를 포함해야합니다. 테스터가 문제에 대한 리드 업에 대해 기억할 수있는 것은 무엇이든 고통스럽게 자세하게 기록해야합니다. 충돌 로그, 데이터베이스 스냅 샷 또는 관련 스크린 샷도 첨부해야합니다.

버그가 다시 재현되지 않으면 훌륭합니다! 데이터베이스에 넣는 것이 아프지 않습니다. 프로그램이 릴리스되고 사용자가 나중에 유사한 버그를보고하면 해당 경험을 보고서의 내용과 비교하고 유사점을 찾을 수 있습니다.

내 경험상 다음 테스트 계획에서 가장 치명적인 버그를 찾을 수 없습니다. 때로는 달과 별이 정렬되어 불쾌한 벌레를 일으키기 위해 몇 주 동안 물건을 끓여야합니다. 품질 보증팀에서 형사 작업을 수행하고 가능한 원인을 찾을 수 있으면 뒷면에 두드려주세요. 그러나 때때로, 누가 무슨 일이 있었는지 알고 있습니까?

해결 방법을 알기 전까지는 많은 버그를 재현 할 수 없습니다. 그렇다고 수정 될 필요는 없습니다. 작년에 여전히 재현 방법을 모르는 버그를 수정했습니다 . 스택의 특정 메모리 위치에있는 매우 가비지 데이터와 함께 정확하게 시간이 지정된 전송 오류의 기괴한 조합이 필요합니다. 불행하게도, 우리 고객 중 한 명이 항상 그 상황에 처할 정도로 "행운"입니다.

따라서 가능한 한 QA가 재현성 단계를 포함하도록 권장하지만 실패 할 수는 없습니다. 때로는 로깅을 추가 할 위치를 파악하는 데 도움이됩니다. 때로는 버그를 일으키는 원인 을 알려주 는 것이지만 버그 보고서는 항상 유용합니다.

QA에 버그를 재현 할 수있는 단계를 포함시켜야한다면 대답은 '예'입니다. 그들이 재현 할 수있는 버그만 기록해야한다면 절대 그렇지 않습니다. 버그는 보름달 자정에만 또는 버그를 볼 때마다 발생하는 버그입니다. 일부 버그는 결정적이지 않습니다 (클래식 예제는 초기화되지 않은 변수이며, 수집 된 값이 반 무작위 임). 이는 버그를 기록, 조사 및 가능한 경우 수정해서는 안된다는 의미는 아닙니다.

재현 할 수없는 버그는 일반적으로 우선 순위가 낮지 만 반드시 기록해야합니다.

IMO, 당신은해야합니다. QA는 재생산 단계를 수행 할 수없는 경우 업무를 수행하지 않습니다. 할 수없는 것을 재생산하는 데 시간을 낭비하지 말고 "재생할 수 없음"으로 닫고 계속 진행하십시오.

당신의 시간은 그것보다 훨씬 더 가치가 있습니다.

버그 보고서에는 다음이 포함되어야합니다.

• 재현 단계
• 실제 행동
• 예상되는 행동

예 :

• 데이터베이스에서 모든 공급 업체를 삭제하고 (을 사용하여 DELETE * FROM tSuppliers) 공급 업체 대화 상자를 열고 공급 업체 드롭 다운 목록을 클릭했습니다.
• 이 목록에는 다음 메시지가 포함되어 GUPOS ERROR #0000000: SOMETHING WENT WRONG!있습니다.. 메시지를 클릭하면 화면과 작업 관리자에서 앱이 사라졌습니다.
• 빈 목록이나 "공급 업체를 찾을 수 없음"과 같은 메시지가 표시 될 것으로 예상했습니다. 빈 목록이나 메시지를 클릭해도 효과가 없습니다. 어떤 상황에서도 경고없이 앱이 사라지지 않아야합니다.

따라서 예-재현 단계가 포함되어야합니다. 그들이 이것을 포함 할 필요가 없다고 생각한다는 사실은 그들이 결함을 식별하는 것이 아니라 "소프트웨어를 파괴하는 것"이라고 자신의 임무가 있다고 생각하는 것 같습니다.

품질 보증팀은 입력 한 단계에 따라 버그를 재현 할 수 있어야합니다. 열심히 노력했지만 여전히 재현 할 수없는 경우에도 개발자는 타임 스탬프에 포함 된 세부 정보만큼 버그를 입력해야 개발자가 자세한 내용을 보려면 응용 프로그램 및 디버그 로그를 살펴볼 수 있습니다.

돈이 여기에 있습니다. 왜 모든 팀원이 (고의로) 고액의 개발자에게 부담이되는 잘못 정의되고 성공 가능성이 낮은 작업을 만들어야합니까?

이것은 쪼아 순서, 계층 구조, 오만, 우리 대 그들 또는 그와 비슷한 것이 아닙니다. 이는 제품에 가치를 더하는 활동에 투자하는 것입니다.

문제가 제품의 가치에 부정적이며 측정 가능하게 영향을 미치는 것으로 입증 될 수있는 경우, 문제를 조사, 재현 및 수정해야합니다. 제품 결함 파이프 라인을 수정하여 노이즈를 필터링하십시오.

품질 관리팀이 짜증나

그들에게 가서 전문적인 테스터를 잘 뇌 안에 인쇄 한해야한다는 문서를 읽고 그들에게 (I 번 테스터가 있었고, 난 여전히 내 머리에, 바로 그것을 가지고) 어떻게 효과적으로 버그 리포트에 .

특히, "나 자신을 보여주는 방법보기" 섹션을 가리 킵니다 .

인터넷 시대입니다. 이것이 전 세계 커뮤니케이션 시대입니다. 지금은 버튼을 한 번만 누르면 러시아의 누군가에게 소프트웨어를 보낼 수있는 시대가되었습니다. 그러나 그가 내 프로그램에 문제가 있다면 실패 할 때 그 앞에 서있을 수 없습니다. "나를 보여줘"는 할 수있을 때 좋지만, 종종 할 수 없습니다.

직접 참석할 수없는 프로그래머에게 버그를보고해야하는 경우, 연습의 목적은 문제 를 재현 할 수 있도록하는 것 입니다. 프로그래머가 자신의 프로그램 사본을 실행하고 동일한 작업을 수행하며 동일한 방식으로 실패하게하려고합니다. 문제가 눈앞에서 발생하는 것을 볼 수 있으면 문제를 해결할 수 있습니다.

"버그가 한 번에 여러 방향에서 나올 수 있다 " 고 불평하는 소리가 들리면 이전에 생각했던 것보다 더 많이 빨아 들인다. 테스트 가능성 은 다른 프로젝트 기능 중에서 평가해야하는 기능 이며이 기능을 올바르게 사용하기 위해 노력해야한다고 말합니다 .

• 전문 테스터가있을 때 얻을 수있는 테스트 가능성 향상은 마술과 매우 흡사 할 수 있습니다. 나는 몇 달 전에 나 자신을 배웠다. 우리 팀과 함께 일하는 QA 엔지니어는 응용 프로그램의 일부 구성 요소에 대한 몇 가지 테스트 가능성 요청을 받았습니다. 그가 물어 본 것들이 나에게는 거의 이해가되지 않았지만, 나는 그가 전문가로서 더 잘 알고 있다고 가정하고 그에게 주었다. 내가 끝내 자마자 그는 테스트 노력을 대폭 줄여주는 툴을 고안했다 . 그는 대부분이 내가 구현 한 이러한 암호 요청에 기초한 것이라고 말했다.