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

     

 

질문

소프트웨어 테스팅이란 무엇이며, 테스팅의 목표와 임무"는 무엇인가요?

 

ISTQB 버전

ISTQB Syllabus 2018

 

답변

소프트웨어 테스트란?

소프트웨어 테스트의 정의를 한 마디로 표현하면 "주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공"하는 조사 과정입니다.

테스팅 활동을 수행하면서 도출되는 여러 데이터들로 현재 개발 중인 제품/서비스에 대한 판단 기준을 제공할 수 있다는 의미입니다. 이를 통해 소프트웨어 테스트는 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하기도 하며, 사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 해줄 수 있습니다. 시험 기술에는 프로그램이나 응용 프로그램을 실행하여 소프트웨어 버그를 찾는 절차를 포함되나 이에 국한되지는 않습니다.

 

소프트웨어 결함은 어떻게 일어나는가

ISTQB에서는 소프트웨어 결함이 다음의 과정을 통해 일어난다고 언급하고 있습니다.

 

인간은 코드, 소프트웨어, 시스템, 또는 문서 안에 결함을 만들어내는 오류(실수)를 범할 수 있으며, 결함 코드가 실행되면 시스템은 바라던 결과에 대해 실패하거나, 바라지 않던 결과로 인해 실패할 수 있습니다.

 

소프트웨어, 시스템, 문서 안의 결함은 실패로 이어질 수 있지만 모든 결함이 그러한 것은 아닙니다. 특정 환경에서 정상적으로 작동하던 소프트웨어가 다른 환경으로 이동하여 작동 환경이 바뀌면 실패가 발생할 수도 있습니다. 환경 변화의 실제 예는 새로운 하드웨어 플랫폼에서 실행되거나, 소스 데이터가 바뀌거나, 프레임워크가 변경되었을 때, 혹은 다른 종류의 소프트웨어와 상호 작용함 등을 들 수 있습니다.

 

테스팅의 목적

1979년에 발간된 소프트웨어 테스팅의 기술(Art of software testing)에서는 소프트웨어 테스팅의 목적으로 "오류를 찾기 위한 활동"이라 칭하였습니다. 이 한 문장이 소프트웨어 테스팅의 목적을 설명하는 기반이 될 수 있으나, 자세한 설명은 아래의 내용을 참고해 주세요.

 

1. 일반적인 테스팅의 목적

  • 남아 있는 결함을 발견하기 위함입니다.

  • 명세를 충족하였는지 확인하기 위함입니다.

  • 사용자 및 비즈니스 요구를 충족하였는지 확인하기 위함입니다.

  • 결함을 예방하기 위함입니다.

 

2. 부가적인 테스팅의 목적

  • 품질 수준에 대한 자신감 획득과 정보를 제공합니다.

  • 비즈니스 리스크를 감소시키는 정보를 바탕으로 의사결정 가능한 정보를 제공합니다.

  • 개발 프로세스 점검하고, 개발 프로세스 내의 이슈를 제기합니다.

  • 논리적 설계의 구현을 검증합니다.

  • 시스템과 소프트웨어가 적절히 동작하는지에 대해 확인합니다.

The Purpose of Testing

 

3. 관점에 따라 다른 테스팅의 목적

  • 고객의 요구사항 분석 단계 : 실제 개발 리소스를 투입하기 전, 솔루션의 방향이 올바른 지 확인하고 고객의 필요가 실제로 해결 가능한 지 확인하기 위함입니다.

  • 개발 진행 중 : 고객에게 배포하기 전, 제품의 외부 실패 비용으로 돌아올 수 있는 소프트웨어의 결함들을 찾아내고, 수정하기 위해 가능한 많은 장애 상황을 만들어 내기 위함입니다.

  • 제품 서비스/인수 시점 : 초기 분석한 고객의 요구사항 및 기대 결과대로 시스템이 동작하는지를 확인하고, 요구사항에 맞게 개발되었는지 확신을 얻기 위한 과정입니다.
  • 유지보수 단계 : 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하기 위함입니다. 운영 : 시스템 특성(신뢰성, 사용성 등)을 평가합니다.

  • 품질 평가 단계 : 특정 시간에 응용 프로그램 및 시스템을 출시하는 것의 리스크를 개발 프로젝트에 관련된 이해관계자에게 전달하기 위함입니다.

 

소프트웨어 테스팅은 이런 것이다.

「소프트웨어 테스팅이란?」을 한 마디로 요약하기는 결코 쉬운 일은 아닐 것입니다. 그래도 한 마디로 요약해야 한다면 『응용 프로그램 및 시스템의 동작, 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘(원인-결과에 대한 역학적 인과관계』 정도로 표현 가능합니다. 

 

결함을 발견하는 메커니즘 즉, 테스팅 방식으로 정적 분석과 동적 분석이 있습니다.


이것은 프로그램 실행 여부 기반이라고 할 수 있습니다.

 

정적 테스트는 프로그램을 실행 전 소스코드 파싱 기반 문법, 코드 등 잠재적 취약점을 발견하는 기법이며, 동적 테스트는 프로그램 실행 후 실제 발생 오류 발견 및 문제 해결 분석 기법을 말합니다.

 

1. 정적 분석의 유형에는 대표적으로 인스펙션, 피어 리뷰, 워크쓰루가 있습니다.

 

대표적인 정적 분석 유형 관계도

 

구분 인스펙션 피어 리뷰 워크쓰루
공식성 Formal Mid Formal Informal
개념 산출물 대상 공식 검토 개발단계별 산출물 대상 동료 검토 소팀 내 결함 해결방안 상호 검토
목적 요구사항 확인 계획의 적합성 평가 결함 발견
기법 이해관계자 산출물 검사 검토 회의 집중 검토 기법
규모 3 ~ 6명 3명 이상 2 ~ 7명
참석자 이해관계자 경영자, 개발 관리자 개발자
리더십 훈련된 중재자 선임 관리자 개발자 본인
결함 기록 공식 기록 공식 기록 개인별 기록

 

1) 인스펙션
 • 공식적 검사입니다.
 • 프로그램을 실행하지 않고 산출물을 대상으로 공식적 검토, 결함 발견 과정입니다.
 • 구성: 이해 관계자, 중재자, 검토자, 기록자

 

2) 피어 리뷰

 • 동료 검토를 의미합니다.
 • 프로젝트 수행과정에서 각 단계 별 산출물, 제품에 대해 동료들이 상호 교차하여 검토 수행하는 활동입니다. 
 • 구성: 프로젝트 팀원, 체크리스트

 

3) 워크쓰루

 • 비공식 검토입니다.
 • 프로젝트 개발 초기에 팀 내에서 수행하는 검토 과정을 말합니다.
 • 구성: 프로젝트 팀원

 

2. 동적 분석의 소프트웨어를 직접 실행하는 과정에 존재하는 결함을 검출해 내는 테스트 방식입니다.

 

그리고 형태에 따라 화이트박스 테스트와 블랙박스 테스트로 나눌 수 있습니다.

 • 화이트박스 테스트는 응용 프로그램의 내부 구조, 동작을 디테일하게 거사하는 테스트 방식입니다.

동적 분석 예시

 

 • 블랙박스 테스트는 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식입니다.

화이트박스 테스트와 블랙 박스 테스트

 

블랙박스 테스트와 화이트박스 테스트의 차이점은 아래의 표와 같습니다.

 

블랙 박스 테스트 화이트 박스 테스트
내부 구조 나 프로그램 또는 코드가 숨겨져 있고 그것에 대해 알려진 것이없는 소프트웨어 테스트 방법입니다. 테스터가 소프트웨어의 내부 구조 나 코드 또는 프로그램에 대해 알고있는 소프트웨어를 테스트하는 방법입니다.
대부분 소프트웨어 테스터가 수행합니다. 대부분 소프트웨어 개발자가 수행합니다.
구현에 대한 지식이 필요하지 않습니다. 구현에 대한 지식이 필요합니다.
외부 또는 외부 소프트웨어 테스트라고 할 수 있습니다. 내부 또는 내부 소프트웨어 테스트입니다.
소프트웨어의 기능 테스트입니다. 소프트웨어의 구조 테스트입니다.
이 테스트는 요구 사항 사양 문서를 기반으로 시작할 수 있습니다. 이러한 유형의 소프트웨어 테스트는 상세 설계 문서 이후에 시작됩니다.
프로그래밍에 대한 지식이 필요하지 않습니다. 프로그래밍에 대한 지식은 필수입니다.
소프트웨어의 동작 테스트입니다. 소프트웨어의 논리 테스트입니다.
더 높은 수준의 소프트웨어 테스트에 적용 할 수 있습니다. 일반적으로 낮은 수준의 소프트웨어 테스트에 적용됩니다.
비공개 테스트라고도합니다. 클리어 박스 테스트라고도합니다.
시간이 가장 적게 소요됩니다. 대부분의 시간이 소요됩니다.
알고리즘 테스트에는 적합하지 않거나 선호되지 않습니다. 알고리즘 테스트에 적합합니다.
시행 착오 방법과 방법으로 할 수 있습니다. 내부 또는 내부 경계와 함께 데이터 도메인을 더 잘 테스트 할 수 있습니다.
예 :키워드를 사용하여 Google에서 무언가 검색 예 :루프를 확인하고 확인하기위한 입력

블랙박스 테스트 유형 : 
A. 기능 테스트
B. 비 기능 테스트
C. 회귀 테스트

화이트 박스 테스트 유형 : 
A. 경로 테스트
B. 루프 테스트
C. 상태 테스트

 

테스팅의 목표와 임무

1. 과거의 테스팅의 임무

  • 소프트웨어 제품 내에서 오류를 찾을 목적으로 수행하는 활동이었습니다.
  • 응용 프로그램 및 시스템 정상 작동 여부를 확인하기 위함이었습니다.

 

2. 현재의 테스팅의 임무

  • 사용자의 기대 수준과 요구 사항에 맞게 구현되고, 동작하는지를 확인합니다.
  • 결함 데이터를 바탕으로 개발 프로젝트의 리스크 정보를 정량적 수치로 의사 결정권자에게 전달합니다.
  • 개발 프로젝트 초기 단계에 개발 산출물을 테스트 관점에서 리뷰하고, 테스트 케이스 작성 과정에서 결함을 사전 발견합니다.(결함 예방 활동)
What is the Main Aim of Software Tester?

 

테스팅의 목표와 임무를 완수하기 위한 필수 조건 : 커뮤니케이션

이 단락은 ISTQB를 공부하시는 분들이 꼭 이해하고 계셔야 하는 부분은 아닙니다. 하지만 실무를 하시는 분이시라면 마음속 깊이 새겨 매일의 업무에 임하셔야 하는 내용입니다.

 

테스터가 수행하는 일에서 큰 비중을 차지하는 것 중의 하나가 바로 커뮤니케이션입니다. 테스터는 소프트웨어 제품의 품질에 관한 정보를 제고하는 일을 하는 사람들입니다. 따라서 올바른 의사결정이 이루어질 수 있도록 이런 정보를 정확하게 전달하는 일이 매우 중요합니다.

 

어떤 사람들은 단순히 몇 가지 테크니컬 한 스킬만을 가지고 테스터로 일을 시작하겠지만, 실무에서 다른 사람들과 원활하게 커뮤니케이션하는 능력과 전달하고자 하는 바를 명확하게 전달하는 능력은 그 어느 스킬보다도 중요합니다.

 

테스터들은 애매모호한 부분이 없도록 정확한 단어를 적재적소에 사용해 매끄러운 말과 문장을 만들고, 이를 통해 오해가 원인이 되어 발생하는 리스크를 미연에 방지할 수 있어야 합니다. 항상 말하려는 의도와 말이 일치하는 것이 아니기 때문에 종종 그럴 것이라는 가정 하에 커뮤니케이션이 수행되며 이런 불충분하고, 어설픈 커뮤니케이션으로 인해 부적절한 행동이 취해지게 되는 것입니다.

 

Who series :: QA Team

 

서로 다른 지위에서 서로 다른 역할을 수행하고, 서로 다른 지식을 가진 사람들과 정기적으로 커뮤니케이션할 필요가 있습니다.

 

  • 개발자 - 그들이 만든 소프트웨어 제품에 대해 질문을 던지고 그에 대한 지식을 습득해야 합니다. 기술적인 면을 이해하기 위해 우리가 발견한 버그와 해당 버그들을 어떻게 재현할 수 있는지에 대해 설명해 줄 필요가 있습니다.

  • 제품 리더 - 요구사항을 정확하게 이해하기 위해, 유즈 케이스에 대해 질문하고 유저 시나리오와 관련된 정보를 제공합니다. 이들에게 필요한 정보를 제공함으로써 제품 배포에 관한 적절한 의사 결정을 하도록 만들 수 있습니다.

  • 테스터 - 팀 단위로 일하는 테스터라면 동료들과 이슈에 관해 논의하고, 이를 통해 의사 결정을 진행하는 것이 매우 중요합니다. 신규 입사자나 주니어 테스터를 훈련시키거나 이들이 난관에 부딪혀 도움이 필요하다면 그들이 어떤 일을 수행해야 하는지 명확하게 설명해줄 필요가 있습니다.

  • 사용자/고객 - 이들이 원하는 바가 무엇인지, 그리고 이들이 겪고 있는 이슈들은 어떤 것인지 정확하게 인지하고 있어야 합니다. 만약 고객 지원 업무까지 함께 수행하고 있다면, 사용자와 고객들이 이해할 수 있는 방식으로 트러블슈팅 또는 문제를 해결하는 방법을 설명할 수 있어야 합니다.

  • 매니저 - 어떤 일이 완료되었고, 어떤 일이 아직 완료되지 않았는지를 적절하게 보고해야 합니다. 관련된 리스크와 결과, 기간도 함께 보고되어야 하며, 어떤 제안을 하고 싶다면 그 아이디어와 이로 인해 어떤 영향이 발생할 것인지를 명확하게 설명할 수 있어야 합니다.

 

서면으로 커뮤니케이션하는 것 역시 구두로 커뮤니케이션하는 것만큼이나 중요합니다. 휘황찬란한 표현을 사용해 문서를 만드는 것이 어려운 일은 아니만, 결국은 아무도 읽지 않는 불필요한 문서로 판명되는 일도 빈번하게 발생합니다.

How to Land One

 

커뮤니케이션의 상대방에게 프로세스와 프로젝트 전체에 가장 효율적이고 적합한 커뮤니케이션을 수행할 수 있도록 노력해야 합니다.

 

참여자 정보

 글쓴이 : 품생품사, 천년나무

• 검토한이 : Bykj, Byungjoo, 아이티마니,  현의노래

 

STEEG 개인 의견

※ STEEG 전문가들의 개인 의견은 각 전문가 개인이 경험한 경력에 따른 주관적 견해입니다.
이런 개인 의견들의 경우는 그룹 전체의 의견을 대표하지 않음을 알립니다.

(본 글에 대한 전문가의 별도 포스팅이 존재하지 않습니다.)

 

관련 참고 자료

 

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

위키백과, 우리 모두의 백과사전. 소프트웨어 테스트(영어: software test)는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스트

ko.wikipedia.org

 

So, What Is Software Testing?

If you had to answer the question ‘What is software testing?’ what would you say? It’s something that is pretty difficult to compress into a couple of short...

www.ministryoftesting.com

 

What is Software Testing? Definition, Basics & Types

What is Black Box testing? In Black-box testing, a tester doesn't have any information about the...

www.guru99.com

 

The Purpose of Testing

An Agile Team who doesn’t care about Quality isn’t Agile at all.

labs.bawi.io

 

Differences between Black Box Testing vs White Box Testing - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

Pair testing - Wikipedia

Pair testing is a software development technique in which two team members work together at one keyboard to test the software application. One does the testing and the other analyzes or reviews the testing. This can be done between one tester and developer or business analyst or between two testers with both participants taking turns at driving the keyboard

en.wikipedia.org

 

What is Risk Management and Why is it Important?

This definition explains what risk management is, why it is important and how it can be used to mitigate threats and decrease loss within an organization. The limitations and standards of risk management are also described and examples of risk management a

searchcompliance.techtarget.com

 

Risk Management Professional - RMP - Ritaj Managerial Solutions

Projects by their nature always carry uncertainty (risk). Effective risk management is a key contributor to project success. This training highlights your ability in the specialized area of assessing and identifying project risks while mitigating threats a

ritajms.com

 

DevelopSense: Testers Know That Things Can Be Different

Rapid Software Testing developed by James Bach and Michael Bolton A mind-set, and a skill set, and classes on how to do excellent software testing in a way that is very fast, inexpensive, credible, and accountable. Hello and welcome to the DevelopSense Web

www.developsense.com

 

The Testing Planet Archive

Got a few spare minutes? Come and read the best of The Testing Planet archive from Ministry of Testing

www.ministryoftesting.com

 

Risk-based testing - Wikipedia

Risk-based testing (RBT) is a type of software testing that functions as an organizational principle used to prioritize the tests of features and functions in software, based on the risk of failure, the function of their importance and likelihood or impact

en.wikipedia.org

 

The Art of Software Testing (Second Edition) 한국어판

소프트웨어 테스팅 분야에서 한 획을 그은 진정한 명서이며 고전이다. 테스팅에 대한 일반적인 내용을 개발과 연계해 최근 출간된 그 어떤 책보다 오히려 더 체계적이고 설득력 있게 소개한다.

www.aladin.co.kr

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band

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

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

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