[팀블로그] 소프트웨어 테스팅 참고서

     

 

질문

Defect와 Bug와 Error, Failure는 모두 같은 말인가요?

 

ISTQB 버전

ISTQB Syllabus 2018

 

답변

소프트웨어에서의 문제점들을 칭하는 다양한 용어들이 존재합니다. 실무에서도 "버그, 이슈, 문제, 굳었다, 뻗었다, 죽었다" 등 다양한 표현으로 소프트웨어 상의 문제를 표현하곤 합니다. 사실 실무와 합쳐져 발생한 콩글리시를 제외한다 해도, 국제 표준에서 사용되고 전 세계적으로 통용되는 공식적인 용어들이 많이 있습니다.

 

해당 용어들의 차이는 Software Development Life Cycle의 어느 단계에서 발견 되었는가 전체적으로 차이가 있습니다.

 

Causes of Software Defects

 

Defect

결함은 크게 두 가지 설명으로 통용됩니다.

(1) 실제 결과와 예상 결과 간의 차이를 결함이라고합니다.

(2) 개발자가 문제를 찾아 개발 단계에서 스스로 해결하면 이를 결함이라고합니다.

 

ISTQB와 같은 자격증을 공부하실 때, 혹은 국제 표준을 공부하실 때에는 '소프트웨어의 결함'에는 특정 속성이 있음을 이해하셔야 합니다.

 

  • 심각도 기준
    심각도(Severity)는 결함 발생 시 미치는 영향의 정도를 정의합니다. 아주 사소한 버그라도 치명적일 수 있습니다. 국제표준에서는 '사회에 영향을 미치는' 정도의 해석으로 '심각도'를 바라보지만, 실무에서는 '회사의 이익'에 영향을 주는 결함을 의미한다고 생각하시면 됩니다.

    예를 들어, 사용자 로그인이 특정 도메인에서만 작동하고, 서브 도메인(Sub-Domain)에서는 정상적이지 않다고 생각해 봅니다. 카카오나 네이버 같은 서비스들에서는 여러 서브 도메인들이 엮여 하나의 서비스를 구성하는데, SSO(Single Sign On)이 작동하지 않는 경우 서브 도메인을 따라 이동하면서 계속 로그인을 해야 하는 상황이 발생할 것이고, 이는 곳 매출 저하로 결과가 나올 것입니다. 아주 작은 실수 하나로 인해 회사의 매출이 저하되고, 순이익이 감소하는 사태가 발생할 수 있는 것이지요.

    따라서 결함의 심각도는 특정 결함의 정도나 강도가 소프트웨어 제품 또는 그 작동에 악영향을 미치는 정도를 반영한다고 생각하시면 됩니다. 결함에 대한 심각도 메트릭은 다음 범주를 참고하세요.

 

치명적임 "치명적"인 결함은 즉각적인 수정이 필요합니다. 중대한 결함은 소프트웨어 제품 또는 대규모 기능에 영향을 줄 수있는 필수 기능에 직접 영향을줍니다. 예를 들어, 기능 / 기능 장애 또는 전체 시스템의 붕괴 등
주요함 소프트웨어 제품의 주요 기능에 영향을 미치는 결함은 주요 결함입니다. 그러나 이러한 결함으로 인해 시스템이 완전히 고장 나지는 않지만 소프트웨어의 몇 가지 주요 기능이 정지 될 수 있습니다.
경미함 이러한 결함은 영향이 적고 소프트웨어 제품에 큰 영향을 미치지 않습니다. 이러한 결함의 결과는 제품 작동에서 볼 수 있습니다. 그러나 사용자가 작업을 실행하는 것을 방해하지는 않습니다. 다른 대안을 사용하여 작업을 수행 할 수 있습니다.
사소함 이러한 유형의 결함은 제품 작동에 영향을 미치지 않습니다. 따라서 때로는 무시하고 생략하기도 합니다. 예를 들어 철자나 문법 오류가 있습니다.

 

  • 확률 기준
    소프트웨어에서 결함을 바라보는 또 다른 관점은 소프트웨어를 실행하는 중 문제점이 발생할 가능성과 이를 사용자가 인지할 가능성, 그 확률에 대한 이야기입니다.

    소프트웨어 제품/서비스의 결함 가능성을 고려하여 다음과 같은 방식으로 확률을 분류합니다.

 

높음 거의 모든 응용 프로그램 사용자가 결함의 존재를 추적 할 수 있습니다. 이것은 높은 확률을 나타냅니다.
중간 사용자의 절반이 소프트웨어 제품에 결함이 있는지 추적 할 수 있습니다.
낮음 일반적으로 사용자가 감지하지 않거나 소수의 사용자만 감지 할 수 있습니다.

 

  • 우선 순위 기준
    소프트웨어 결함을 바라보는 관점에는 비즈니스/개발 관점 우선순위(Priority) 비교도 있습니다.

    프로젝트 관리 관점에서 혹은 고객의 비즈니스 관점에서 '먼저 개발되어야 하는, 우선 순위가 높은' 내용들이 존재할 수 있습니다. 또한 개발 관점에서는 모든 소프트웨어 내부 모듈에는 의존성(Dependency)가 존재하며, 이로 인해 특정 부분에서 발생하는 일부 결함의 수정을 먼저 해결해야만 다른 의존성을 가진 부분들이 해결됩니다. 이런 우선순위 선정은 결함 발생 시 반드시 결정해야 하는 내용입니다.

    우선 순위 분류도 다음과 같은 방식으로 구분됩니다.

 

높음 우선 순위가 높으면 결함을 수정하기 위해 가능한 빨리 진행해야 합니다.
중간 다음 버전 또는 제품 릴리스에는 이를 해결하는 것이 포함됩니다.
낮음 이 유형의 결함은 개별적으로 수정할 필요가 없습니다. 다른 유형의 결함과 함께 이러한 유형의 결함을 수정합니다.

 

Bug

버그는 프로그램의 코딩 오류 또는 오류로 인해 프로그램이 의도하지 않거나 예상치 못한 방식으로 작동함을 의미할 때 사용하는 용어입니다. 

"버그가 있다"라는 의미는 프로그램에 결함이 있다는 의미입니다. 버그는 프로그램의 소스 코드나 디자인에서 사람이 만든 실수와 오류로 인해 발생합니다. 일반적으로 모든 유용한 컴퓨터 프로그램에는 버그가 있지만 잘 작성된 프로그램에는 비교적 적은 버그가 포함되어 있으며 이러한 버그는 일반적으로 프로그램이 작업을 수행하는 것을 방해하지 않습니다.

 

소프트웨어에서 버그가 발생하는 요인은 굉장히 여러 군데가 있으며, 이를 해결하기 위한 인류의 노력, 실무 가이드가 바로 소프트웨어 공학이라는 학문입니다. 소프트웨어 공학의 내용이 전체적으로 이해하기 어렵고, 다소 생경한 표현들이 등장하다보니 소프트웨어 공학을 단순히 '이론'으로 치부하고 학습하기를 꺼리는게 흔한 현상입니다. 하지만 지금 이 글을 읽고 계시는 독자분들도 그러셨다면, 오늘 이 블로그의 내용을 읽고 이해하려 노력하시는 부분에서부터 시작하시면 됩니다.

 

Error

프로그래머가 프로그램을 성공적으로 컴파일하거나 실행할 수 없는 경우 이를 오류라고합니다.

 

사용자 인터페이스
오류
시스템과 사용자가 상호 작용하는 동안 일반적으로 나타나는 오류입니다. 시스템의 누락 또는 잘못된 기능, 백업 기능이 없거나 사용 가능한 역기능 등
오류 처리
오류
사용자가 소프트웨어와 상호 작용하는 동안 발생하는 모든 오류는 정확하고 의미 있는 처리가 필요합니다. 그렇지 않으면 혼동됩니다.
구문 오류 소프트웨어 GUI를 테스트 할 때 철자가 틀린 단어나 문법적으로 잘못된 문장
계산 오류 이 오류는 잘못된 논리, 잘못된 수식, 일치하지 않는 데이터 형식 등으로 인해 발생합니다.
흐름 제어
오류
소프트웨어 프로그램이 예기치 않게 동작하는 잘못된 방향으로 프로그램 제어를 전달하는 것과 관련된 오류는 흐름 제어 오류입니다. 무한 루프의 존재, 런타임시 구문 오류보고 등
테스트 오류 테스트 프로세스를 구현하고 실행할 때 발생한 오류를 의미합니다. 예를 들어, 버그 스캔 실패, 오류 또는 결함 보고의 비효율성.
하드웨어 오류 이러한 오류는 하드웨어 장치와 관련이 있습니다. 가용성 및 장치 호환성

 

Failure

소프트웨어 제품이 사용자들에게 배포되고 고객이 문제를 발견하면 제품을 '제품의 실패' 라고 합니다. 릴리스 후 최종 사용자가 문제를 발견하면 해당 특정 문제를 실패 라고합니다.

 

소프트웨어의 실패는 아래와 같은 성격을 가지고 있습니다. 힘 빠질 수 있는 내용이지만 실무에서의 우리는 잦은 실패를 경험하게 되어 익숙해지기도 합니다. 하지만 ISTQB를 공부하시는 입장에서는 아래의 내용을 명확히 이해하셔야 합니다.

 

  • 모든 예기치 않은 테스트 결과가 실패한 것은 아닙니다. 또한 실패는 할 수 있습니다
  • 입력 값을 잘못 입력하거나 출력을 잘못 해석하는 것과 같이 소프트웨어와의 상호 작용에서 사람의 실수로 인해 발생합니다.
  • 누군가 고의로 시스템 오류를 일으키거나 악의적인 피해를 입히려고 할 때 발생합니다.
  • 테스트 데이터, 테스트 환경 등의 잘못된 처리로 인해 발생합니다. 이러한 조건을 결함이라고 하지만 실제로는 결함이 아닙니다.
  • 때로는 결함이 발견되지 않은 테스트도 실패를 일으킬 수 있습니다.

 

결론

버그는 코딩 오류의 결과이고 결함은 요구사항에서 벗어나 발생하는 문제입니다. 결함이 반드시 코드에 버그가 있음을 의미하는 것은 아니며 구현되지 않았지만 소프트웨어 요구 사항에 정의된 기능 일 수 있습니다. 하지만, 위의 내용은 이론적인 내용이며, 실무에서는 보통 "버그" 혹은 "이슈"라는 용어로 사용하고 있습니다.

 

그 외, 여러 소프트웨어의 문제점들을 칭하는 여러 용어들에 대한 설명은 difference-between-defect-error-bug-failure-and-fault 를 참고하여 주세요.

 

참여자 정보

• 글쓴이 : 아이티마니, 천년나무

• 검토한이 : 품생품사, 현의노래, Bykj

 

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다.
   개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.
 

[STEEG - 실무 적용편] "결함 우선 순위"와 "심각도" 활용 : 품질 지표 정량화 하기

목차 Defect와 Bug와 Error, Failure는 모두 같은 말인가요? - 원글 링크 : softwaretestingreference.tistory.com/145 주요 차이점 결함 우선순위는 개발자가 결함을 해결해야 하는 순서이고, 심각도는..

qa-testing.tistory.com

관련 참고 자료

 ※ 아래는 필자들이 선정한 관련 외부 자료입니다. 
     아래 자료들은 필자들이 작성한 본문 의견과 다를 수 있으며, 필자들과 관련되지 않았을 수 있습니다.

참고 사이트

 

Difference between Defect, Error, Bug, Failure and Fault! - The Official 360logica Blog

Testing is the process of identifying defects, where a defect is any variance between actual and expected results. “A mistake in coding is called Error, error found by tester is called Defect, defect accepted by development team then it is called Bug, bu

www.360logica.com

 

Software Defect, Bug, Failure, Fault & Error : What is the difference ? | Testing Journals

Software Defect, Bug, Failure, Fault & Error : These words play a very critical role in Software testing life cycle. Although they are used interchangeably by developers and sometimes by QA person, but they surely have precise meaning after-all.

www.testingjournals.com

 

Severity & Priority in Testing: Differences & Example

As a tester, you may think that ‘Designing Test cases is challenging enough, then why bother about...

www.guru99.com

 

Bug Severity vs Priority In Testing With Examples

This article will cover major differences between bug severity and priority with real-time examples, basic terminologies, key takeaways, and more.

www.lambdatest.com

 

Software engineering - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search Computing discipline Software engineering is the systematic application of engineering approaches to the development of software.[1][2][3] Software engineering is a computing disciplin

en.wikipedia.org

 

소프트웨어 공학 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 에어버스 A-380은 상당한 양의 소프트웨어를 사용하여 "종이 없는" 조종석을 창조하였다. 소프트웨어 공학으로 항공기 소프트웨어를 이루는 수백만행의 소스코

ko.wikipedia.org

 

관련 동영상

 

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band

※ 알림 : 본 블로그는 소프트웨어 테스트&품질 카페 (https://cafe.naver.com/swtester)의 '앞마당멀티' 사이트이며, 본 블로그 자체에서 댓글, 방명록 등 커뮤니티 기능을 지원하지 않습니다.

일반적으로 공개 커뮤니티에서는 다양한 사람들의 의견이 모이기 때문에 많은 논의가 다양한 관점에서 이루어지기 적합하지만, 또 다양한 사람들이 모이는 커뮤니티의 특성상 객관성과 주관성이 모호하게 표현되기도 합니다. 그렇기 때문에 전문적인 지식을 정리하기에 적합하지 않다고 생각하여 전문 지식 컨텐츠 게시를 목적으로 할 공간을 확보할 필요가 있었습니다. 그런 이유로 본 블로그에서는 전문 지식의 내용이 희석되거나, 변질될 가능성이 높은 커뮤니티 기능을 분리하기로 결정하였습니다.

본 블로그 내용에 대해 논의하고 싶으신 내용이 있으시거나, 반론 게재, 수정 요청, 개인 의견 추가, 혹은 추가로 궁금하신 점들 등은 소프트웨어 테스터&품질 카페의 '질문과 답' 게시판에서 언급하여 진행해 주십시오. 필진들이 진중하게 논의하여 반영이 필요하다고 생각되는 내용은 참고하여 반영하겠습니다.