테스트의 하나의 방법론인 시프트레프트 테스트와 전도결함율에 대해 기재해봅니다.
버그의 수정 코스트
일단 우리는 버그가 어느단계에 많이 생성되고, 어느 단계에서 많이 발견되는지를 확인해야합니다.
Capers Jones 의 연구결과에 따르면, 버그가 많이 생성되는 단계는 아래와 같이 코딩하는 단계에서 많이 생성됩니다.
버그의 85%가 코딩단계에서 생성됩니다.
이후 보통의 테스트의 형태라면, 버그들을 대부분 통합테스트나 시스템 테스트 단계에서 발견합니다.
왜냐하면, 대부분 통합테스트나 시스템 테스트 단계에서 테스터들이 테스트를 수행하기 때문입니다.
버그를 찾아내는 단계는 버그를 심는 것과 정확히 반대의 형태를 가집니다.
그러나 버그를 수정하는 데에 소요되는 시간적, 물질적 코스트를 생각해보자면, 이것은 바람직한 것은 아닙니다.
시스템테스트 단계는 코딩단계에서 고치는거보다 최대 40배, 릴리즈 후는 최대 640배나 코스트가 더 들어갑니다.
이것은 왜그럴까요? 당연하게도 아래와 같은 이유로 설명할 수 있을 것 같습니다.
- 버그를 찾아내고, 재현하는 데에 오래걸립니다.
- 하위공정으로 가면 갈수록 외부 라이브러리나 환경 등에 의존적인 경우가 많이 있어 재현시키기도 어렵고 수정하기도 어려울 수 있습니다.
- 하나의 단순한 버그라면 문제없을 수 있지만, 이 버그로 인하여 다른 기능에도 사이드 이펙트가 있는 경우라면, 영향범위를 확인하고 수정범위를 파악하는데도 시간이 걸립니다.
게다가 당연하게도, 버그를 수정하면 수정이 되었고 다른 기존의 시스템에 문제가 없는지도 다시 테스트를 해야합니다.
하위 공정일수록 모듈 간의 결합도가 상승하므로 문제의 원인을 식별하기도, 수정하기도 어려운 것입니다.
Shift-left
Shift-left
V 모델에서, Shift-left란 Unit test단계에서 테스트를 많이해야한다는 것을 의미합니다.
Shift-left testing is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e. moved left on the project timeline). It is the first half of the maxim "test early and often". It was coined by Larry Smith in 2001.
개발자가 할 수 있는 Shift-left
Shift-left는, 테스트를 SDLC의 초기부터, 자주 진행해야한다는 내용입니다.
때문에 아래처럼, Shift-left를 하여 가능한 빠른 단계에서 버그를 식별하고 수정할 수 있어야합니다.
이것은 테스트 피라미드와도 연관관계가 있습니다.
유닛테스트 단계에서 버그를 찾아내면, 테스트 속도도 빠르고 수정도 손쉽게 가능하지만, 통합테스트를 거쳐 시스템테스트 (E2E 테스트)의 단계가 되면 테스트하는데에도 시간이 걸릴 뿐더러, 버그를 찾아내 수정을 하더라도 그 시간이 오래걸립니다.
그렇기 때문에 Shift-left를 실천해서 빠른단계에서 버그를 찾아낸다는 것입니다.
QA, Test담당자가 할 수 있는 Shift-left
개발자들은 유닛테스트에서 좀 더 테스트를 꼼꼼히 해서 버그를 찾아낸다고하면, QA/Test담당자들은 어떻게해서 Shift-left를 실천할 수 있을까요?
코드 정적리뷰
코드 정적분석 툴을 이용해 개발자가 컨벤션을 준수하고 있는지, 도달불가한 코드를 작성한 것은 아닌지를 체크해줄 수 있습니다. 다만, 이것은 온전히 QA, Test담당자만 할 수 있는 것은 아닙니다.
게다가 CI 파이프라인을 이용하여 매 커밋/푸시마다 자동적으로 정적분석을 실행할 수도 있기 때문에, 과거와는 다르게 굳이 QA/Test 담당자가 필요한 업무도 아니게 되었습니다.
API Test
UI만을 가지고 수행하는 시스템테스트, 인수테스트보다 더 빠른 단계인 API가 완성될 즈음의 타이밍부터 테스트하는 것도 효과적입니다. 간단하게는 파라미터의 유효성 체크부터 파라미터들간의 조합, 헤더값들의 설정 등을 확인할 수 있을 것입니다.
기획 리뷰와 W 모델
기획 리뷰야 말로 QA, Test담당자가 적극적으로 개입할 수 있는 Shift-left 방법일 것입니다. 그러나 여기서 말하는 기획 리뷰란, 제품이 개발중, 혹은 개발 완료된 상태에서 기획자 혹은 설계자로부터 전달받는 리뷰가 아니라, 제품/프로젝트의 Kick-off단계부터 참여하여 요구사항 정의단계부터 진행되는 논의에 적극적으로 참여하고, 생성되는 산출물들에 대해서 연속적으로 테스트를 진행하는 것을 의미합니다. 이를 통해 실제 테스트를 진행하기 위한 테스트 플랜과 테스트 설계 또한 조기에 진행할 수 있습니다.
이 방법은 개발이 다 완료되고 테스트를 진행하기 전에 제품의 기획 의도에 대해 리뷰받던 종래의 방법과는 다릅니다. 기획 초기부터 프로젝트에 같이 참여한다면 기존의 기능과의 모순되는 부분을 지적할 수 있을 뿐더러, 제품의 품질 향상에 우려가 되는 점을 빠르게 이해관계자들에게 전달할 수 있고, 버그가 될만한 요소들이, 직접적으로 코딩되지 않도록 막을 수 있습니다.
기획리뷰는 거창한 것이 아닙니다. 단순히 최소값과 최대값이 정의되지 않은 입력란을 만든다고 하였을 때, 아래에 대해 질문해볼 수 있을 것입니다.
- 최소값과 최대값은 어떻게 되는지.
- 한자와 특수문자, 이모지 등은 입력할 수 있는지
- 일반 문자는 입력할 수 있는지
- 숫자와 문자를 혼합해서 입력해도 되는지
등, 버그를 일으킬 수 있는, 정의되지 않은 점에 대해 이해관계자들에게 질문을 던지고 구체화하도록 유도하는 것부터 시작할 수 있습니다.
이러한 단순한 질문부터, 기존의 다른 시스템들과의 충돌유무, 이전버전과의 호환여부 등을, 개발이 이미 진행되는 시점이 아니라 개발이 진행되기 전부터 확인이 된다면, 버그를 없앨 수 있는 것입니다.
이와 같은 행동은 W모델로도 설명할 수 있습니다.
W Model
Paul Herzlich introduced W-Model in 1993.W-model is the most recent software development model where we start real testing activity simultaneously software development process starts. Where as software development process is a method in which a software or product is made through various stages of planning, development and testing before the final software or product is delivered. testing is such a stage that is extremely crucial to ensure the delivery of an optimum quality product.
- V-model and W-model are two of the most important models that are used in software testing.
- W-Model covers those activities which are skipped by V-Model and also, it deals with problems which couldn’t be catch by V-Model.
- W-Model approach attempts to address and tackle the shortcomings W-Model approach attempts to address and tackle the shortcomings of V-Model.
- W-model can be done only once the development of the product is complete with no modifications required to be done in between. This type of testing is most suitable for short projects.
- With the help of W-Model, we ensure that the testing of the product starts from the very first day of the inception of product and each phase of the product development is verified and validated.
https://www.geeksforgeeks.org/software-engineering-w-model/
https://shiftasia.com/column/difference-between-v-model-and-w-model-in-software-testing/
모든 공정에서 테스트 활동을 수행함으로써 Shift-left Testing을 QA/Test 담당자도 수행할 수 있습니다.
그러나, Shift-left 활동을 한다고 해서 과연 버그가 생기는 것을 얼마나 방지할 수 있을까요? 방지했다고 한다면 어떻게하면 이것을 정량적으로 나타낼 수 있을까요?
Ref
