메뉴

버그보고 기술 : 마케팅 및 버그 수정 방법

art bug reporting

문제를 제거하기 위해 도구를 사용해보십시오

버그 마케팅이 필요한 이유는 무엇입니까?

이 기사를 쓰기 시작하면서 가장 먼저 떠오르는 것은 Cem Kaner - “최고의 테스터는 버그를 가장 많이 발견하거나 대부분의 프로그래머를 당황하게하는 사람이 아닙니다. 최고의 테스터는 대부분의 버그를 수정 한 사람입니다. '

지금 – 차이점은 무엇입니까 대부분의 버그 찾기 과 대부분의 버그 수정 ?

로그인 한 버그가 분명하지 않습니까? 버그 관리 시스템 개발자가 수정해야합니까? 대답은 아니오입니다. 제품 출시 시간, 일정에 따라 프로젝트를 완료하는 데 걸리는 시간, 작업중인 개발자와 같은 요소 비현실적인 빡빡한 일정 등으로 인해 기업은 사용자에게 큰 영향을 미치지 않는 버그가 거의없는 제품을 출시해야합니다.

버그보고 아트

(영상 출처 )

제품에 존재하는 버그가 고객의 신뢰, 신뢰성 및 이해 관계자의 관심에 영향을 미치지 않을 것이라고 경영진에게 확신을주는 사람은 누구입니까? – 테스트 엔지니어 또는 테스트 팀 – 제품 품질에 부정적인 영향을 미칠 수있는 버그를 수정하는 것은 각 테스트 엔지니어의 의무입니다.

버그의 우선 순위 , 제 생각에는 주로 테스터가 개발 및 관리 팀에 문제를 제시하는 방법에 달려 있습니다.

문제를 광고하거나 마케팅하는 것처럼 생각하십시오. 여기에는 2 단계가 포함됩니다.

  1. 쓰기 또는 버그를 올바르게보고
  2. 버그에 대한 모든 것을 알고 있으므로 자세한 내용을 더 잘 설명 할 수 있습니다.

학습 내용 :

버그보고의 기술

예, 버그보고는 예술입니다 . 버그가 작성되는 방식은 테스트 엔지니어의 기술, 도메인 전문성 및 커뮤니케이션 능력을 보여줍니다.

일반적으로 버그에는 다음 정보가 포함되어야합니다.

  • 버그 요약
  • 재현 단계
  • 첨부 파일 (스냅 샷, 로그 파일 등)
  • 버그 재현성
  • 버그 심각도
  • 소프트웨어 버전, 환경 정보
  • 조직 요구 사항을 기반으로 한 기타 정보.

중요한 참고 사항 : 항상 문제의 근본 원인을 찾고보고하기 위해 더 깊이 파고 듭니다. 예를 들어, 사용자 이름과 비밀번호의 올바른 조합으로 인한 간단한 로그인 실패는 다음과 같은 다양한 이유와 관련이있을 수 있습니다.

  1. 로그인 자격 증명이 전혀 확인되지 않았습니다.
  2. 원격 로그인의 경우 네트워크 시간 초과 문제
  3. 시스템은 모든 대문자를 비 대문자로 간주 할 수 있습니다.

따라서 테스터는 버그 요약 설명을 따르면서 차이점을 해독 할 수 있어야합니다.

  • “올바른 사용자 이름과 암호로 로그인 할 수 없습니다.”
  • '사용자 이름 또는 암호에 CAPS 및 비 CAPS 알파벳이 혼합 된 경우 올바른 사용자 이름 및 암호로 로그인 할 수 없습니다.'

후자는 문제에 대한 매우 명확한 설명이며 모호하지 않습니다. 이를 통해 테스터로서의 신뢰도를 높일뿐만 아니라 증상 대신 실제 문제를보고하게됩니다.

이제 버그 보고서와 관련된 각 필드를 살펴보고 각 필드의 중요한 측면에 대해 논의하겠습니다.

#1. 버그 요약

버그 요약은 문제가 정확히 무엇인지에 대한 빠른 스냅 샷을 제공해야합니다. 정확하고 잘 지시되어야합니다.

예 :

이론과는 별도로 예를 들어 설명하겠습니다.

간단한 로그인 모듈을 가정 해 보겠습니다. 웹 사이트를 방문하는 신규 사용자가 기본 비밀번호로 로그인 할 수없는 문제라고 가정 해 보겠습니다. 교육 초기 단계에서 교육 한 많은 학생들에게 동일한 시나리오를 제시했을 때 버그 요약으로 몇 가지 답변이있었습니다. 다음은 요약이 어떻게 보이는지에 대한 몇 가지 샘플입니다.

Windows 10 용 무료 데이터베이스 소프트웨어

' 새 사용자는 로그인 할 수 없습니다.”

'사용자 로그인이 예상대로 작동하지 않습니다'

“사용자가 올바른 암호로 로그인 할 수 없습니다.”

버그 요약 잘못 및 옳음

위의 샘플에서 실제로 문제를 설명하는 문장을 하나 선택할 수 있습니까? 그렇게 생각하지 않습니다. 요약은 항상 실패한 시나리오에 대한 완전한 정보를 제공해야합니다.

다음 진술을 고려하십시오.

“새 사용자는 이메일이나 SMS를 통해 제공된 기본 암호로 로그인 할 수 없습니다.”

보시다시피 위의 설명에서 개발자는 문제가 무엇인지, 문제가 어디에 있는지 명확하게 이해할 수 있습니다.

따라서 정보를 직접 제공 할 요약을 설명하는 데 적합한 단어를 찾으십시오. '올바르게 작동하지 않음', '예상대로 작동하지 않음'등과 같은 일반적인 표현은 피해야합니다.

# 2. 복제 및 첨부 단계

재현 불가능한 버그는 중요 할 수 있지만 항상 뒷자리를 차지합니다. 따라서 단계를 정확하고 설명 적으로 작성하도록주의하십시오.

단계는 정확하고 문제를 일으킨 단계와 정확히 동일해야합니다. 기능 관련 버그의 경우 다음 샘플이 가장 좋은 예입니다.

예 :

이전 섹션에서 설명한 것과 동일한 문제를 고려하십시오.

  1. 홈 페이지에서 가입 옵션을 사용하여 새 사용자를 만듭니다. (샘플 사용자 이름 : HelloUser)
  2. 이메일과 SMS는 기본 비밀번호로 수신됩니다. SMS 용 이메일 ID와 휴대폰 번호는 1 단계에서 사용자 생성시 제공됩니다. (샘플 이메일 : HelloUser@hello.com , 샘플 휴대폰 번호 : 444-222-1123)
  3. 홈 페이지에서 로그인 옵션을 선택하십시오.
  4. 사용자 이름 텍스트 필드에 1 단계에서 제공 한 샘플 사용자 이름을 제공합니다.
  5. 비밀번호 필드에 이메일 또는 SMS를 통해받은 기본 비밀번호를 입력합니다.
  6. 로그인 버튼을 클릭하십시오
  7. 예상 결과: 사용자는 제공된 사용자 이름과 비밀번호로 로그인하고 사용자 계정 페이지로 이동할 수 있어야합니다.
  8. 실제 결과: '잘못된 사용자 이름 / 암호'메시지가 표시됩니다.

결함보고 단계

위 샘플에 제공되지 않은 정보가있는 경우 의사 소통의 격차를 초래 개발자는 문제를 재현 할 수 없습니다. 단계는 테스트 중에 사용하는 샘플 데이터로 구체적이고 상세해야합니다.

가능한 경우 또는 해당되는 경우 스냅 사진 화면에서 정확히 보는 것의. 이렇게하면 개발자에게 문제에 대한 좋은보기를 제공 할뿐만 아니라 테스트 결과의 증거도 제공합니다.

그만큼 비 기능 스트레스, 안정성 또는 성능 테스트 사례와 같은 테스트 사례는 위의 세부 사항 외에도 시스템에 스트레스를 유발하는 시나리오에 대한 정보를 그대로보고 할 수 있습니다. 또한 수행되는 모든 작업에 대한 로그를보고하는 시스템이 거의 없습니다. 로그는 일반적으로 개발자가 코드에서 제공하는 인쇄 문입니다. 모듈이 실행될 때마다 해당 로그가 인쇄되거나 표시됩니다. 로그를 사용할 수 있으면 개발자가 문제를 재현하는 데 큰 도움이됩니다.

#삼. 버그 재현성

크거나 작은 문제는 재현성에 따라 우선 순위가 지정됩니다. 항상, 가끔, 드물게 또는 한 번만 볼 수 있습니다. '항상'으로 재현되는 문제는 나머지 문제보다 우선 순위가 높습니다.

결함을 재현 할 수 없다

따라서 항상 재현되는 문제에 대한 시나리오를 정확하게 추적하는 것은 테스트 엔지니어의 의무입니다. 때로는 테스트 엔지니어가 통제 할 수없는 문제가 거의 없어서 문제가 몇 번만 재현되지만 여러 번 시행 될 수 있습니다. 이러한 경우에는 항상 시행 횟수를 언급하고 특정 시나리오가 해당 시행 중에 문제가 발생한 횟수와 함께 실행됩니다.

이것은 차례로 당신이 언급 한 버그 보고서에 신뢰성을 더할 것입니다. 다시 말하지만 이것은 테스터로서의 명성을 향상시킬 것입니다. 나중에 좋은 평판을 얻은 이유를 말씀 드리겠습니다.

# 4. 버그 심각도

심각도는 의심 할 여지없이 버그의 우선 순위를 정하는 데 가장 큰 영향을 미치는 요인 중 하나입니다.

다음은 다양한 심각도 범주입니다. 이는 일반적인 샘플 일 뿐이며 회사마다 다릅니다.

  1. 심각도 1 – Show Stopper – 치명적인 버그의 경우 수정하지 않고 사용자는 소프트웨어를 계속 사용할 수 없으며 가능한 해결 방법이 없습니다.
  2. 심각도 2 – 높음 – 심각도 1과 유사한 버그이지만 해결 방법이 있습니다.
  3. 심각도 3 – 중간
  4. 심각도 4 – 낮음
  5. 심각도 5 – 사소합니다.

예를 들어 두 가지 유사한 문제를 비교해 보겠습니다.

셋톱 박스에서 현재 조정 된 서비스의 주파수 정보를 제공하는 서비스 제공 업체는 거의 없습니다. 주파수가 100.20MHz 대신 100MHz로 표시된다고 가정 해 보겠습니다. 이는 사용자의 서비스보기에는 영향을주지 않지만 셋톱의 진단 모니터링 측면에서는 영향을 미칠 수 있습니다. 따라서 이것은 심각도 3 문제로 제시 될 수 있습니다.

은행 도메인에서 유사한 문제가 있다고 가정합니다. 계정 잔액이 $ 100.20 대신 $ 100로 표시되면 문제의 영향을 상상해보십시오. 심각도 -1 결함이어야합니다. 두 경우 모두에서 볼 수 있듯이 UI가 소수점 뒤에 숫자를 표시하지 않는 문제는 매우 유사합니다. 그러나 영향은 관련된 도메인에 따라 다릅니다.

소프트웨어 버전 관리 회의에 효율적으로 참여

일반적으로 모든 조직에는 버그를 조사하고 우선 순위를 지정하는 자체 프로세스가 있습니다. 일반적으로 버그를 논의하고 우선 순위를 정하기 위해 프로젝트 중에 특정 간격으로 회의가 열립니다.

이러한 회의 중 프로세스는 다음과 같습니다.

  1. 심각도에 따라 버그 관리 시스템에서 버그 목록을 쿼리합니다.
  2. 요약을보고 소프트웨어 제품 사용에 대한 사용자 경험에 대한 버그의 영향에 대해 논의하십시오.
  3. 위험 및 영향 평가에 따라 우선 순위를 설정하고 버그를 적절한 개발자에게 할당하여 수정합니다.

2 단계에서는 버그가 당연한 우선 순위를받지 못하면 모든 테스트 엔지니어가 사용자 환경에 미치는 버그의 영향을 옹호해야합니다. 결국 사용자의 관점을 고려하여 테스트 케이스를 작성하고 제품을 테스트하는 것은 테스트 엔지니어입니다.

은행 도메인에서 소수점 이하 자릿수를 표시하지 않는 위의 예제 문제를 고려하십시오. 개발자에게는 덜 심각한 문제처럼 보일 수 있습니다. 그는 변수를 정수로 선언하는 대신 문제를 해결하기위한 부동 소수점으로 선언하므로 덜 심각하다고 주장 할 수 있습니다.

그러나 테스터로서 귀하의 역할은 고객의 상황을 설명하는 것입니다. 요점은이 시나리오에서 사용자가 불평하는 방식이어야합니다. 테스터는 고객이 센트 단위로 돈을 잃기 때문에 사용자들 사이에 패닉을 일으킬 것이라고 말해야합니다.

버그를 제대로 마케팅하지 않을 때의 영향

버그가 제대로 마케팅되지 않으면 다음과 같은 문제가 발생합니다.

  • 잘못된 결함 우선 순위
  • 중요한 문제 해결 지연
  • 심각한 결함이있는 제품 출시
  • 부정적인 고객 피드백
  • 브랜드 가치 평가 절하

버그를 제대로 마케팅하지 않을 때의 영향

위에서 언급 한 모든 이유를 제외하고는 테스트 엔지니어로서의 명성 . 자신을위한 브랜드 가치를 개발하는 것과 비슷합니다.

경력의 초기 단계에서 '재생산 불가'또는 '추가 정보 필요'또는 '유효한 버그가 아님'의 수를 유지하거나 심각도 변경을 가능한 한 낮게 유지할 수있는 경우 한 단계에서 버그를 면밀히 조사하지 않습니다. 수정을 위해 적절한 개발자에게 직접 할당됩니다.

이러한 브랜드 가치를 개발하고 팀과 개발 / 또는 관리 팀의 신뢰를 얻으려면 지식, 도메인 및 커뮤니케이션 기술을 테스트하는 측면에서 몇 가지 기술 기술을 개발해야합니다.

결론

크든 작든 모든 제품이나 서비스는 적절한 광고 없이는 항상 실패 할 수 있습니다. 일단 브랜드가 확립되면 어떤 작은 제품도 청중에게 큰 인기를 끌 수 있습니다.

그러나 제품을 과도하게 광고하면 평판이 손상 될 수 있습니다.

따라서 버그는 광범위하고 포괄적 인 소프트웨어 맵에서 버그의 정확한 위치를 제공 할 수 있도록 항상 명확하고 간결하며 정확한 방식으로 작성되어야합니다. 이것은 소프트웨어의 품질을 향상시킬뿐만 아니라 소프트웨어를 테스트하고 개발하는 데 드는 비용을 상당히 줄여 준다는 것을 반복합니다.

지금은 너무 늦지 않았습니다! 계속해서 버그를 바로 수정하세요!

YouTube 비디오를 mp3로 가장 잘 변환

추천 도서

^