Shift Left라는 접근 방식은 2001년 래리 스미스(Larry Smith)에 의해 최초로 등장한 테스트 접근 방식 중 하나입니다.
Shift Left는 QA를 릴리즈 프로세스에만 사용하는 것이 아닌, 개발 프로세스의 일부로 포함하여 개발 초기부터 QA 활동을 해야 한다는 테스트 방식입니다.
릴리즈 프로세스라면 이런 모습을 하고 있겠지만
Shift Left를 할 경우 이렇게 좌측으로(Left) QA의 활동시점과 영역이 이동되는 것을 뜻하게 됩니다.
(해당 단계는 조직마다 조금씩 다를 수 있으며 Shift Left는 1단계만 이동되는 것 또한 아닙니다. 필요한 만큼 Shift 될 수 있습니다.)
릴리즈 프로세스는 제품의 출시를 앞두고 진행되는 프로세스이기 때문에 개발의 후반부에 진행되는 프로세스입니다.
후반부인 만큼 결함의 발견이나 수정이 주로 뒤에 이루어지게 되는데 이럴경우 수정비용이 매우 높아지기 때문에 조직 전체에 큰 부담이 될 수밖에 없습니다.
하지만 Shift Left를 통해 이러한 결함의 발견과 수정의 시점을 전반부로 당겨오게 되면 수정비용의 감소와 제품의 안정성확보가 모두 용이해지기 때문에 현재까지도 자주 거론되는 중요한 테스트 방식입니다.
Shift-Left Testing
By combining development and quality assurance earlier and more deeply in your project plan, you can expand your testing program and reduce manpower and equipment needs.
www.drdobbs.com:443
Shift Left 방식은 현재 많은 QA조직에서 사용 중이시며 저도 잘 사용하고 있는 방법이기도 합니다.
우리는 이러한 Shift Left 테스트를 왜 하게 되었을까요? 가장 잘 알려진 이점은 '조기 투입으로 인한 수정 비용 감소'가 있을 것입니다.
저는 여기에 앞서 한가지의 이점이 더 있다고 생각합니다.
그것은 바로 QA 전략과 Test Plan을 미리 세울 수 있다는 것입니다.
QA 시작에 앞서 미리 테스트에 대한 방향성과 진행에 대한 전략을 수립하고 현재의 리소스로 최적화된 테스트를
진행하기 위한 준비기간이 필요한데 Shift Left를 사용한다면 이러한 시간을 확보할 수 있게 되는 것이죠.
사전 준비기간을 확보한다는 것은 Shift Left만의 이점은 아닙니다. 협업 부서와 스케쥴링 진행 시 해당 기능의 크기와 복잡성을 고려해서 충분한 기간을 확보하는 것도 가능합니다.
하지만 QA 요청을 주실때 가끔씩 사전 준비기간에 대한 내용이 간과되는 부분이 있습니다.
기획 문서와 제품만 있으면 바로 QA를 진행할 수 있을 것이라는 생각을 가지고 바로 QA요청을 하시는 경우입니다.
테스트는 사전 준비가 매우 중요한 활동 중에 하나입니다.
사전에 준비를 얼마나 잘 했느냐가 성공적인 테스트 진행을 결정한다 해도 과언이 아닙니다. 그래서 테스트 진행과 테스트 준비는 각각 별도의 업무로 인식해 주시는 것이 필요합니다. 프로그래밍도 바로 구현하는 것이 아니라 구조를 먼저 설계한 뒤 구현하는 것과 비슷한 이치입니다.
QA팀은 하나의 기능을 입사때부터 퇴사 때까지 줄곧 담당하지 않습니다.
매주 혹은 매일 내가 테스트 해야 하는 대상이 변경되며 변경될 때마다 해당 기능에 대한 지식을 필요로 합니다. QA입장에서는 테스트 대상이 변경됨으로써 해당 보유 정보까지 스위칭해야 한다는 것이 부담으로 다가올 수도 있습니다. 그만큼 각 기능들에 대한 이해도를 높이고 유지하기 위해 많은 노력 또한 필요하기 때문입니다.
이러한 점 때문에 별도의 준비 없이 바로 현장에 투입되어 테스트를 해야 한다면 대부분의 QA 분들은 원활한 테스트를 진행하실 수 없을 것입니다. 일반적으로 QA요청을 주실 때에도 사전 준비기간이 필요하다는 것을 인식하시고 요청을 주실 경우 더 원활한 테스트가 진행될 수 있으니 참고해 주시면 좋을 것 같습니다 :)
이러한 부분에 있어서는 Shift Left가 많은 도움이 됩니다. 조기 투입으로 인한 충분한 시간이 주어지기 때문이죠.
Shift Left를 사용하면 이슈 조기 검출, 사전 시간 확보등의 효과가 있는 것은 알 수 있었습니다. Shift Left는 어떠한 것을 얻기만 하기 위해 실행하는 것은 아니라고 생각합니다. Shift Left를 시행함으로써 문제를 방지하거나 비효율적인 부분을 개선할 수 도 있습니다.
Shift Left가 도입되지 않고 QA가 개발 후반부에 참여하는 것이 지속된다면 QA의 역할은 리그레이션과 통합테스트만으로고착화 될 가능성이 높습니다. 이럴 경우 QA가 다양한 경험을 할 수 없어져 QA 조직의 성장을 방해할 수 있습니다.
QA에게는 '경험 기반 테스트' 라는 설계기법이 있을 정도로 경험이 중요합니다. 하지만 특정 업무가 고착화되고 거기서 벗어날 수 없게 된다면 또 다른 경험을 할 수 있는 창구가 막혀 다양한 시선으로 제품을 판단할 수 없게 되어 QA의 성장 또한 어려울 수 있게 된다는 것입니다. 이를 방지하기 위해 다양한 경험을 위한 프로세스가 필요하며 Shift Left도 그 일환으로 QA에게 도움을 줄 수 있을 것입니다.
Shift Left가 도입되지 않은 상태라면 초기 개발부터 변경되어 온 기획과 정책의 히스토리를 알기란 쉽지 않을 것입니다. 해당 내용을 알기 위해서는 별도의 시간을 투입해야 하는 상황까지 발생할 것입니다. 이 시간은 QA만 소모하게 되는 시간이 아니며 해당 내용을 공유해 주는 인원의 리소스까지 별도로 소모를 해야 하게 됩니다.
물론 그 동안의 시간을 압축하여 중요한 내용만을 공유할 수 있는 장점은 있을 수 있으나 별도의 정책, 기획리뷰가 진행되지 못하거나 짧게 진행할 수밖에 없다는 단점도 양면으로 존재하게 됩니다.
Shift Left를 사용할 경우 이러한 히스토리 파악이 매우 용이하며 QA와 협업부서의 리소스를 모두 절약할 수 있게 됩니다.
또한 조기에 투입하여 모든 내용을 공유받았을 경우 협업 부서와 원활한 커뮤니케이션이 가능해집니다. 하지만 Shift Left를 진행하지 않았다면 해당 내용을 내가 온전히 공유받기 전까지는 유관부서와 원활한 커뮤니케이션도 어려워집니다.
이 과정에서 문의와 답변들이 커뮤니케이션 비용을 증가시킬 가능성도 충분히 존재하기 때문에 Shift Left를 통한 커뮤니케이션 비용절감 효과도 노릴 수 있습니다.
이렇게 이야기를 해보면 Shift Left는 단점이 없는 테스트 방식처럼 보이게 됩니다.
하지만 그렇지 않습니다. 제가 생각하는 이것의 최대 단점은 QA조직에 협업 요청을 언제 해야 Shift Left가 가능한지 협업부서가 알지 못하는 것이라고 생각합니다.
Shift Left는 소프트웨어 개발주기 초기에 QA가 투입되는 것이지만 실제 QA의 업무는 항상 '대상'이 있어야 가능합니다. 명세서가 있거나, 소프트웨어가 있어야 하는 것처럼 말이죠. 그렇기 때문에 아무런 실체가 없는 소프트웨어 개발주기 초기에는 할 수 있는 업무가 한정되어 있습니다.
이러한 이유로 협업 부서분들이 Shift Left 요청 시기를 잘 파악하지 못하시는 경우가 있습니다.
"지금 QA팀이 와도 딱히 할게 없는데...", "지금은 제품 기획 중인데..."라고 하며 QA 협업요청을 드려도 당장 우리가 무엇을 해달라고 할 게 없다 라며 난색을 표하시는 경우를 종종 보았습니다.
이러한 고민을 가진 동료분께 제가 이렇게 이야기한 적도 있습니다.
"이렇게 빨리 요청해도 되나?" 싶을때 요청하셔도 된다일단 QA인원 투입이 결정되어 프로젝트에 참가하면 담당 QA인원이 자연스레 현재 상황에서 할 수 있는 것들을 진행하게 될 것입니다. 그 과정에서 사전준비기간을 가지거나 기획, 정책리뷰를 진행할 것이고 이것들이 충분히 진행되었다고 판단되면 지금까지 얻게 된 정보를 토대로 해당 기능 개발에 더 긴밀히 접근하여 다양한 의견을 낼 수도 있을 것입니다.
협업부서에서 조기 투입 요청을 한 뒤 굳이 어떤것을 해달라고 하지 않아도 QA는 소프트웨어 개발주기 타임 테이블 별 할 수 있는 업무들을 정리해서 순차적으로 진행하고 있을 것입니다. 그렇기 때문에 협업 요청을 언제 해야 할지 고민하고 계신 개발 부서가 있으시다면 주저하지 마시고 요청 주셔도 좋을 것입니다.
물론 모든 QA조직이 Shift Left를 할 수 있는 것은 아닙니다. 규모나 인원이 적은 QA조직일 경우 소프트웨어 개발주기 후반부의 개발 QA에 모든 리소스가 매몰되서 도저히 Shift Left를 시도조차 할 수 없는 경우도 있습니다. 이럴 경우 조금 더 여유로운 일정관리를 통해 QA업무의 고착화를 피하고 Shift Left를 할 수 있게 하는 것이 좋습니다. 장기적으로 QA업무의 고착화는 살충제 패러독스(Pesticide Paradox: 동일한 테스트의 반복으로는 새로운 버그를 발견할 수 없다)를 불러일으킬 수 있고 제품이나 조직에 있어 좋지 않습니다.
지금까지 여러 방면으로 Shift Left에 대해서 이야기해 보았습니다.
모든 면에서 좋은 최선의 방법은 항상 하나가 아닐 것입니다. Shift Left도 모든 환경과 상황에 최선은 아닐 수 있지만 장점이 확실한 좋은 테스트 방식인 것은 맞다고 생각합니다. 앞으로도 Shift Left를 통해 QA분들이 더 많은 곳에서 활약하고 다양한 경험을 쌓을 수 있기를 바라겠습니다.
'QA' 카테고리의 다른 글
| QA 처우가 불 만족스럽다면 지금 해야 하는 것은 무엇일까 (69) | 2024.01.10 |
|---|---|
| 2023년 나의 QA Engineer 커리어 회고 (59) | 2024.01.02 |
| 애자일 조직에서 QA팀의 역할 (The role of the QA team in the Agile software development) (4) | 2023.11.29 |
| 변하지 않는 것은 없습니다. QA도 그렇게 되어야 합니다. (0) | 2023.06.07 |
| 제 2회 QA Korea Conference (QA 코리아 컨퍼런스) 개최 (0) | 2023.05.30 |
댓글