메뉴

소프트웨어 테스트에서 사고 추적 및 관리 시작하기 (샘플 템플릿 포함)

getting started with incident tracking

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

오늘의 기사에서 우리는 '사고 추적 및 관리'프로세스 – 샘플 템플릿을 사용하여 소프트웨어 테스트에서 사고를 추적하고 관리하는 방법.

“STH는 많은 콘텐츠를 게시했습니다. 결함 / 버그 추적 , 그러면 어떻게 달라 지겠습니까”? 그것이 바로 우리가 사건이 의미하는 바를 먼저 살펴 봐야하는 이유입니다.

사고 추적 및 관리

학습 내용 :

사고 란 무엇입니까?

사건 검토가 필요한 테스트 중에 발생한 이벤트로 간단한 단어로 정의 할 수 있습니다.

실제 결과가 예상 결과와 다른지 테스트하는 동안이를 버그, 결함, 오류, 문제, 결함 또는 사고라고합니다. 대부분의 경우 이러한 용어는 모두 동의어입니다.

그러나 인시던트는 잘못된 구성, 손상된 데이터 또는 서버 충돌 등으로 인해 발생할 수있는 특별한 범주의 문제입니다. 예 : 디스크 공간 가득 참, 실행 오류 (런타임 오류), 서비스를 사용할 수 없음 등.

소프트웨어 개발, 하드웨어 사용 또는 서비스 요청 오류의 일부 문제로 인해 사고가 발생할 수도 있습니다.

오류, 결함, 버그 및 사고의 차이점 :

  1. 오류 : 예상치 못한 시스템 동작을 초래하는 사람이 수행하는 작업입니다.
    지.; 잘못된 구문, 부적절한 값 계산, 소프트웨어 오해
    요구 사항 등
  2. 결함: 테스터가 일반적으로 사용하는 용어입니다. 테스터가 실수 나 문제를 발견하면 결함이라고합니다.
  3. 곤충: 버그는 개발자의 용어입니다. 테스터가 발견 한 결함을 개발자가 수락하면이를 버그라고합니다. 시스템의 모든 버그를 수정하는 프로세스를 Bug-Fixing이라고합니다.
  4. 사건: 사고는 계획되지 않은 중단입니다. 활동의 작동 상태가 작동에서 실패로 바뀌고 시스템이 계획되지 않은 방식으로 작동하게하는 것은 사고입니다. 문제는 가능한 한 빨리 해결해야 할 하나 이상의 사고를 유발할 수 있습니다.

이제 몇 가지 관련 용어를 살펴 보겠습니다.

  1. 사고 저장소 : 인시던트 리포지토리는 시스템에서 발생하는 모든 인시던트에 대한 중요하고 관련된 모든 데이터를 포함하는 데이터베이스로 정의 할 수 있습니다. 이 정보는 이후에 사건 보고서를 만드는 데 사용됩니다. 여기에는 데이터, 예상 결과, 실제 결과, 날짜 및 시간, 사고 상태 등과 같은 필드가 포함됩니다.
  2. 심각성: 사고의 잠재적 영향에 따라 심각도가 결정됩니다. 즉각적인 해결을 위해 Major, Minor, Fatal 또는 Critical이 될 수 있습니다.
  3. 우선 순위 : 시스템의 작동 상태에 대한 심각도와 영향에 따라 설정합니다. 값은 높음, 중간, 낮음, 매우 높음 또는 긴급 / 즉시 일 수 있습니다.
  4. 사고 상태 : 인시던트를 처리하는 현재 상태입니다. 신규, 진행 중, 해결 및 마감일 수 있습니다.

사고 관리 란 무엇입니까?

인시던트 관리는 비즈니스 프로세스 또는 서비스를 정상으로 복원하기 위해 인시던트를 최대한 빨리 기록, 기록 및 해결하는 프로세스입니다.

사고 관리 프로세스

인시던트 관리는 인시던트 로깅부터 해결까지의 전체 프로세스입니다.

사고가 체계적이고 효과적인 방식으로 처리되도록 보장하기 때문에 매우 중요한 프로세스입니다. 또한 전체 프로세스를 간소화하면 문제를 조기에 수정할 수있는 좋은 기회가 있습니다.

다음은 프로세스의 다이어그램 표현이며 다음에 각 단계에 대해 자세히 설명합니다.

사고 관리 프로세스

#1. 사고 식별 및 로깅 :
사고 식별은 테스트 (도구 또는 기타 사용), 사용자 피드백, 인프라 모니터링 등을 통해 수행됩니다.

사건을 기록한다는 것은 단순히 다음 정보를 기록하는 것을 의미합니다.

  • 정확한 / 적절한 발생 날짜 및 시간.
  • 유형 및 간략한 설명과 함께 사건 제목
  • 사건을 기록한 사람의 이름 및 자세한 설명
    해당되는 경우 오류 코드 포함
  • 후속 조치를 위해 사건에 배정 된 사람의 세부 정보
  • 사건 현황
  • 기술 토론, 결정 및 승인을 포함한 첨부 파일

# 2. 분류 및 우선 순위 :

사고 분류는 유형 (소프트웨어, 하드웨어, 서비스 요청 등)에 따라 사고를 분할하는 데 도움이되므로보고 및 분석이 더 쉬워집니다. 우선 순위 지정은 처리 할 사고의 순서 / 우선 순위를 식별하는 데 도움이됩니다. 영향, 심각도 및 가장 중요한 위험 요소에 따라 다릅니다.

#삼. 조사 및 분석 : 이 단계는 문제를 더 잘 이해하기위한 것이므로 지금 바로 문제를 해결할뿐만 아니라 재발 방지를위한 정보를 수집합니다.

# 4. 해결 및 복구 : 사고를 제거하고 시스템을 이전 작업 상태로 되돌리기위한 조치가 취해집니다.

# 5. 사고 종결 : 해결 방법을 다시 테스트하고 시스템이 의도 한대로 작동하는 경우 사고가 종결됩니다.

사고 관리 시스템

인시던트 관리는 스프레드 시트를 사용하여 수동 또는 정적으로 수행 할 수 있지만 도구를 통해 수행하면 훨씬 더 효과적이고 동적이고 체계적입니다.

사고 관리 시스템은 많은 고객 지원 콜센터에서 업데이트를 생성하고 사고를 해결하는 데 사용됩니다.

인기있는 사고 관리 도구 :

버그 또는 결함 외에도 사고를 추적하는 데 사용할 수있는 인기있는 사고 관리 도구는 다음과 같습니다.

#1. 앉다! (인시던트 추적 지원) :

사고 추적 도구 1

  • 사건 추적기 지원 (SiT)는 모든 플랫폼에 PHP와 MySQL을 사용하고 지원하는 무료 오픈 소스 및 웹 기반 애플리케이션입니다. 일반적으로 '헬프 데스크'또는 '지원 티켓 시스템'이라고도합니다.
  • SiT에서 직접 이메일을 보내고, 파일을 첨부하고, 사건 로그에 모든 통신을 기록하는 데 유용합니다. SiT는 서비스 수준 계약을 알고 있으며 사고가 외부에있는 경우 신고됩니다.

# 2. JIRA :

사고 추적 도구 2
지라 또한 버그, 결함 또는 사고 추적에 사용되는 Atlassian에서 개발 한 인기있는 독점 사고 관리 도구입니다. 소프트웨어 및 모바일 앱에 사용되는 Java 기반 도구입니다. JIRA 체계는 워크 플로, 권한, 구성, 문제 유형 등을 포함합니다. JIRA는 또한 민첩한 테스트를 지원합니다.

자세한 정보 및 튜토리얼은 다음을 확인하십시오. JIRA 튜토리얼 시리즈.

#삼. 사고 추적 시스템 :
사고 추적 시스템 사건 추적에 사용되는 소프트웨어입니다. 적절한 솔루션과 함께 사고의 근본 원인을 파악하고 분석하는 데 도움이됩니다. 사고 추적 시스템은 사용하기 쉽고 사고 추적 및 기록을위한 데이터베이스 지원을 제공합니다.

테스트 사건 보고서 :

  1. 테스트 인시던트 보고서는 발생한 각 인시던트에 대한 고유 ID를 사용하여 결함 저장소에 생성 된 항목입니다. 테스트 사고 보고서는 다양한 테스트 단계에서 발견 된 모든 문제를 문서화합니다.
  2. IEEE 829-1998은 테스트 중에 발생하는 각 사고를 문서화하는 데 사용되는 테스트 사고 보고서의 표준 형식입니다.

IEEE 829-1998 템플릿의 개요는 다음과 같습니다.

=> 여기에서 IEEE 사고 추적 템플릿을 다운로드하십시오.

다음은 필드에 대한 간략한 설명입니다.

#1. 식별 : 사고를 식별하고 찾기 위해 고유 한 ID와 회사가 생성 한 번호를 지정합니다.

# 2. 요약 : 사건을 간결하게 요약합니다. 관련 사실을 이해하기에 충분한 세부 정보가 포함되어 있습니다. 참조, 관련 테스트 절차, 소프트웨어 버전, 테스트 사례 등

#삼. 사건 설명 : 다음과 같은 세부 사항으로 사건을 설명합니다.

C ++ 용 이클립스 설정
  • 예상 결과
  • 실제 결과
  • 반복 시도
  • 이상
  • 날짜와 시간
  • 절차 단계
  • 테스터 이름

사고 추적 보고서 형식은 산업 표준 및 비즈니스 요구 사항에 따라 변경할 수 있습니다.

회사에서 사용되는 예는 다음과 같습니다.

=> 여기에서 수정 된 사고 보고서 템플릿을 다운로드하십시오.

결론:

이 기사에서는 사고 관리가 버그 추적과 크게 다르지 않다는 것을 보여 주므로 ISO 표준과 실제 실제 템플릿이 첨부 된 프로세스의 멋진 요약이 될 것입니다.

이 기사를 끝내기 전에 여러분 모두에게 남기고 싶은 또 다른주의 사항은 대부분의 회사가 한 용어를 다른 용어와 구별하지 않기 때문에 버그 / 결함 / 사건 등의 정의에 너무 집착하지 않도록하는 것입니다. 따라서 이들 모두는 대부분의 시간 동안 동의어로 사용됩니다. 또한 문서 불일치를 사건으로, 기타 통화 환경 문제를 사건으로 부르는 회사가 있습니다. 지역에 따라 방언이 변함에 따라 기술 QA도 마찬가지입니다. 술어. 우리가 여러분에게 가져 오는 것은 대부분의 것입니다. 예외는 항상 존재하는 것이 아닙니다.

즐거운 시간 되세요!

추천 도서

^