4. 결함 성능 - 29. 결함 관리
29. 결함 관리
1. 결함 분류
2. 결함 관리 프로세스
3. 결함 관리 도구
결함
소프트웨어의 에러(Error), 결함(Defect), 결점(Fault), 버그(Bug), 실패(Failure)와 같은 용어가 사용되며, 이러한 결함으로 인하여 설계와 다르게 동작하거나 다른 결과가 발생하는 것을 의미한다.
#에러(Error)
결함(Defect)의 원인이 되는 것으로, 소프트웨어 개발자, 분석가 등에 의해 유발된 실수
예) 이체
누군가한테 이체를 하려고 하는데 이체 대상을 지정했음에도 불구하고 다른 사람에게 이체가 된다면 이건 에러이다.
예 2) 메뉴
내가 원하는 메뉴를 눌렀는데, 그게 아니고 다른 페이지가 열리면 그것은 개발자나 분서가의 개발과정 중의 잘못으로 에러다.
심각도별 분류 5가지로 분류할 수 있다.
1. 치명적(Critical) 결함 - 뱅킹앱을 사용하는데 A친구한테 이체를 했는데 전혀 모르는 사람에게 이체가 되었다.
2. 주요(Major) 결함
3. 보통(Normal) 결함
4. 경미한(Minor) 결함
5. 단순(Simple) 결함
결함 우선순위
결정적, 높음, 보통, 낮음 또는 즉시 해결, 주의 요망, 대기, 개선 권고 순으로 표시하며 결함의 심각도가 높다고 해서 반드시 우선순위가 높은 것은 아니다.
결합 유입별 분류 4가지로 분류할 수 있다.
1. 기획시 유입되는 결함
2. 설계 시 유입되는 결함
3. 코딩 시 유입되는 결함
4. 테스트 부족으로 유입되는 결함
1. 결함 분류
1. 시스템 결함
주로 애플리케이션이나 데이터베이스 처리에서 발생된 결함이다.
2. 기능 결함
애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함이다.
결국은 기능 파악을 제대로 못해서 해당 기능을 제대로 수행하지 못하는 상황을 말한다.
3. GUI 결함
화면 설계에서 발생된 결함이다.
4. 문서 결함
기획자, 사용자, 개발자 간 의사소통 및 기록이 원활하지 않아 발생된 결함이다.
앞서 형상을 배웠는데, 만들어지는 모든 문서들에 문제가 발생한 것이다.
기록이 제대로 안되어 의사소통에 누락이 발생된 것이다.
예)
'나는 분명히 이것을 했는데, 보고서를 작성 안 했네 그래서 다른 팀에서 제대로 일을 못했다.' 이런 문제.
2. 결함 관리 프로세스
애플리케이션 테스트에서 발견된 결함을 처리하는 과정은 다음 그림과 같다.
1. 결함 관리 계획
결함 관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립
2. 결함 기록
테스터는 발견된 결함에 대한 정보를 결함 관리 DB에 기록
3. 결함 검토
등록된 결함에 있어서 주요 내용을 검토하고, 결함을 수정할 개발자에게 전달
4. 결함 수정
개발자는 할당된 결함 프로그램 수정
5. 결함 재확인
테스터는 개발자가 수정한 내용을 확인하고 다시 테스트 수행
6. 결함 상태 추적 및 모니터링
결함 관리 팀장은 결함 관리 DB를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공
7. 최종 결함 분석 및 보고서 작성
발견된 결함과 관련된 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함관리를 종료
결함 추적 순서
결함이 발견되고 해결될 때까지의 과정이며 다음과 같다.
1. 결함 등록
제일 먼저 결함을 등록한다.
'무슨 문제가 생겼어, 뭐 실행해야 되는데 제대로 뭐가 안된데' 그러면 그때 등록을 한다.
2. 결함 검토
'이 문제 어떻게 해결하면 좋을까?'
3. 결함 할당
해당하는 담당자(개발자)에게 할당한다.
4. 결함 수정
해당하는 담당자(개발자)가 수정한다.
5. 결함 조치. 보류
보류는 중간단계로써 만약 문제가 해결이 안 될 경우에 보류하는 것이다.
6. 결함 해제
결함을 해결했으면 결함 보류 및 조치를 해제한다.
3. 결함 관리 도구
1. Mantis
소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 및 이슈 관리, 추적을 지원하는 오픈소스 도구
2. Trac
결함 추적 및 통합 관리를 지원하는 오픈소스 도구
3. Bugzilla
결함을 지속적으로 관리하고 심각도와 우선순위를 지정할 수 있는 오픈소스 도구
4. Redmine
프로젝트 관리 및 결함 추적 도구
5. JIRA
아틀래시안에서 제작한 PHP로 개발된 결함 상태 관리 도구
7. Test Collab
테스트 케이스를 관리하기 위한 간단하고 쉬운 인터페이스를 제공하며 Jira, Redmine, Asana, Mantis등과 같은 버그 추적 도구와의 완벽한 통합 지원
결함 관련 용어
1. 에러 (Error)
개발 단계 중 소프트웨어 개발 또는 유지보수 수행에서 발생한 부정확한 결과로, 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등이 있다.
2. 오류 (Fault)
프로그램 코드상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생되며, 잘못된 연산자가 사용된 경우에 프로그램이 서브루틴으로부터의 에러 리턴을 점검하는 코드가 누락된 것을 말한다.
예)
정상적인 프로그램은 A라는 것을 출력하는데, 비정상적인 프로그램은 B라고 출력한다던지..
3. 실패 (Failure)
정상적인 프로그램과 비정상적인 프로그램의 실행 결과의 차이를 의미하며, 프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
4. 결함 (Defect)
버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선사항 등의 전체를 포괄하는 용어이다.
결함 내성 (Fault Tolerance)
고장 허용성이라고도 한다.
시스템을 구성하는 부품의 일부에서 결함(Fault) 또는 고장(failure)이 발생하여도 정상적 혹은 부분적으로 기능을 수행할 수 있는 내성을 의미한다.
문제 풀이
1. 소프트웨어의 에러(Error), 결점(Fault), 버그(Bug), 실패(Failure)와 같은 용어가 사용되며, 이러한 원인으로 인하여 설계와 다르게 동작하거나 다른 결과가 발생하는 것을 무엇이라고 하는가?
결함
2. 소프트웨어 개발 또는 유지보수 수행 중에 발생한 부정확한 결과로, 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등에 해당하는 결함 관리 용어는?
에러
3. 다음 중 소프트웨어 결함 관리의 심각도별 분류가 아닌 것은?
① Critical
② Major
③ Normal
④ Week
4번
4. 다음 중 소프트웨어 결함 유입별 분류에 해당하지 않는 것은?
① 기획 시 유입되는 결함
② 설계 시 유입되는 결함
③ 코딩 시 유입되는 결함
④ 모듈화 시 유입되는 결함
4번
5. 다음 중 결함의 분류에 해당하지 않는 것은?
① 시스템 결함
② 기능 결함
③ 테스트 결함
④ 문서 결함
3번