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

     

 

질문

"시스템이나 문서에 대한 엄격한 테스팅은 운영 중에서 발생할 수 있는 문제를 감소시킬 수 있고(리스크 감소), 소프트웨어 시스템의 품질을 높이는데 기여할 수 있다(테스팅을 통해 발견되는 결함이 사용자가 시스템을 실제적으로 운용하기 전에 수정된다는 것을 전제함)." 이라고 되어 있는데, 문서를 테스트하는 건 어떤 의미인가요? 테스트는 프로그램을 대상으로 하는 게 아닌가요?

 

그리고, 문서를 테스트하는데 왜 소프트웨어 시스템의 품질이 향상되나요?

 

ISTQB 버전

ISTQB Syllabus 2018

 

답변

1. 리뷰란?

리뷰는 테스트의 일종입니다. 소프트웨어 테스팅과 관련된 지식들을 공부하다보면 정적 분석(Static Analysis), 혹은 정적 테스팅(Static Testing)이라고 부르는 활동이 있는데 이때 말하는 '정적(Static) 활동' 중 하나가 리뷰(Review)입니다. 

 

리뷰 활동에서는 설계/기획 문서에만 수행하는 게 아니라, 코드나 테스트 케이스 등 여러 프로젝트 산출물들을 포함하여 포괄적으로 검토하게 됩니다. (IEEE 1028 - Generic process for formal review 참조.)

EduCBA - Static Testing

 

2. 리뷰의 목적

도서 "리뷰의 기술(모리사키 슈지 저)"에서 말하는 문서 리뷰 활동의 궁극적인 목적은 '수정 공수 줄이기'입니다. 즉, '리뷰'는 사업을 잘 하기 위해 '투자 대비 수익을 늘린다'에 관점을 둔 행위입니다. 흔히 말하는 ROI(Return on investment)에 대한 이야기입니다. 개발 공정의 마지막에 찾은 오류는 개발 공정 초기에 찾은 오류에 비해 수정 비용이 비싸다는 점에서 착안한 것입니다. '리뷰'는 분석/설계 단에서 이루어져야 효율이 높습니다. 

 

문서를 리뷰하는 목적은 바로 개발하고자 하는 시스템의 잠재적인 문제를 미리 발견하는 데에 있다고 할 수 있습니다. 이는 우리의 테스트 실무 활동에서도 같습니다. 리뷰를 해야 하는 이유는 아래와 같은 이유가 있습니다.

 

  • 오류가 있는 지 확인
  • 작업이 완료되었는 지 확인
  • 표준 및 지침을 준수하는지 확인

 

Payloadz - Software Review

여기에서 오류란 단순히 '틀린' 것을 포함하여 전체 설계/기획 중 모순되는 부분이 있는 지를 확인하고, 제품/서비스 출시 후 사용자 단에서 발생할 잠재적인 위험이 있는 지를 확인하는 행위를 말합니다.

 

리뷰를 모두 설명하려면 너무 길고 복잡하기 때문에 이 정도로 '리뷰 활동'에 대한 목적 설명을 마치려 합니다.

 

 

3. 테스팅 시 리뷰 진행 방법

ISTQB에서 소개하는 소프트웨어 테스팅 시 리뷰 활동을 진행하는 방법은 아래와 같습니다.

 

Software Testing Genius - Stages of Formal Reviews

 

ISTQB에서 소개하는 공식 리뷰(Formal Review) 단계에 대한 설명은 향후 리뷰(Reviwe)에 대한 전문적인 소개가 필요할 시에 다시 진행하겠습니다.

 

조금은 더 한국 사람의 실무-Friendly하게 소개를 하자면, 아래의 내용과 같습니다. 물론, 꼭 아래와 같은 순서로 진행해야 한다는 의미는 아니며, 아래의 순서는 일종의 가이드라인 정도로 생각해주시면 됩니다.

 

  1. 기준을 정의: 체크리스트 여부 확인
  2. 산출물을 확인
  3. 체크리스트 대비 산출물과의 비교 결과 기록
  4. 변경사항을 공유, 토론
  5. 협의된 사안들을 구현
  6. 관련된 문서의 버전 관리
  7. 최종 문서를 산출물로 제공

 

다시 한 번 강조하지만, 프로젝트의 성격과 프로젝트 조직의 구성에 따라 프로세스는 바뀔 수 있습니다. 그러므로 위의 내용은 "리뷰를 위해서 해야 하는 일들에는 대략적으로 이런 일들이 있다" 정도로 이해하시면 좋습니다.

 

4. 리뷰의 장점

소프트웨어 개발 시 리뷰를 진행하면 다음과 같은 장점을 기대할 수 있습니다.

 

  • 소프트웨어 결함은 개발 초기 단계(특히 공식 검토)에서 식별될 수 있습니다. 모든 결함은 조기에 찾을 수록 수정 비용이 감소하며, 늦게 찾을 수록 수정 비용이 높아집니다.

  • 그러므로, 소프트웨어 문서 및 제품/서비스의 조기 검사를 통해 소프트웨어 유지 관리 비용을 절감 할 수 있습니다. 오류가 발생하여 대응하는 비용보다, 미리 사전에 검사하고 대응하는 비용이 더 저렴합니다.

  • 기술 문서 작성자의 생각을 정리하는데 사용될 수 있습니다. 또한, 작성자가 미쳐 생각지 못한 관점을 다른 사람의 관점으로 채울 수 있습니다.

  • 결함을 유발하는 프로세스 부족을 제거하는 데 사용할 수 있습니다. 인간의 인지능력은 완벽하지 않습니다. 아무리 훌륭한 프로세스를 사용할 지라도 이를 활용하는 인간은 완벽히 활동할 수 없습니다. 그러므로 그룹의 집단지성(Collective Intelligence)를 이용하여 인지부족으로 발생하는 결함을 상호보완하도록 할 수 있습니다.

 

이와 관련한 또 다른 내용은 본 블로그의 다른 필자들이 작성하신 테스팅의 원리[3] - “개발 초기에 테스팅을 시작하라.” 라고하는데, 테스트는 개발이 완료된 후에 하는거 아닌가요? 의 내용을 참고하세요.

 

5. 리뷰의 종류

ISTQB의 용어집에서 정의하는 대표적인 리뷰는 크게 3가지가 있습니다.

 

  • Peer review : A review performed by others with the same abilities to create the work product.
  • 동료 검토 : 작업 산출물을 만들기 위해 동일한 수행 능력을 가진 다른 이들과 함께 수행 되는 검토.

 

  • Inspection : A type of formal review to identify issues in a work product, which provides measurement to improve the review process and the software development process.
  • 인스펙션작업 산출물 내에서 이슈들을 식별 하기 위한 정형적인 검토 방법중 하나. 검토 프로세스와  SW개발 프로세스의 개선을 위해 측정을 제공함.

 

  • Walk through : A type of review in which an author leads members of the review through a work product and the members ask questions and make comments about possible issues.
  • 워크 스루 : 작성자가 본인이 작성한 산출물에 대하여, 멤버들을 이끌고, 질문 하고 코멘트를 주고 받는 리뷰 방법 중 하나.
Tutorials Point - Code Review

 

실제로,  코드리뷰의 경우는 peer reivew를 통해 하고, inspection은 산출물을 검토 하는 방법에 정해진 프로세스가 있는 반면, walk through는 조금 스무스하게 특정 체크리스트에 의한 산출물을 리뷰 한다고 말씀 드릴 수 있습니다.

 

이상 리뷰에 대한 개요 정도로 이 글을 마무리하려 하며, 세부적인 내용이 궁금하시면 추가 질문 주시기 바랍니다.

 

참여자 정보

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

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

 

STEEG 개인 의견

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

본 글과 관련한 전문가 의견이 아직 없습니다.

 

관련 참고 자료

ISTQB Glossary - walkthrough (미리보기 생성 실패)

ISTQB Glossary - inspection (미리보기 생성 실패)

ISTQB Glossary - peer-review-2 (미리보기 생성 실패)

 

Review - Tutorialspoint

Review What do you meant by review? A review is a systematic examination of a document by one or more people with the main aim of finding and removing errors early in the software development life cycle. Reviews are used to verify documents such as require

www.tutorialspoint.com

 

What is Static Testing? What is a Testing Review?

What is Interoperability Testing? INTEROPERABILITY TESTING is a software testing type, that checks...

www.guru99.com

 

리뷰의 기술

리뷰 연구 전문가인 저자는 탄탄한 설계문서 구축을 위해 자신의 경험을 토대로 확립한 설계 리뷰 노하우를 이 책에 현실감 있게 소개한다. 리뷰 순서와 방법부터 왜 중요한 문제를 놓치는지, ��

www.aladin.co.kr

 

Software review - Wikipedia

A software review is "A process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".[1] In this context, the term "software pr

en.wikipedia.org

 

Top 5 Reason Why Usability Testing Can Save You Money

America's Best Software Engineers On-Demand at an Affordable Price

www.surgeforward.com

 

Return on Investment (ROI)

Return on Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or compare the efficiency of a number of different investments.

www.investopedia.com

 

ISTQB Foundation Level Exam Crash Course Part-6 - Software Testing Genius

 

www.softwaretestinggenius.com

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band

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

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

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