<div id="readability-page-1" class="page"><div><div><h2 id="0ae6" data-testid="storyTitle">애자일 조직에서 QA팀의 역할 (The role of the QA team in the Agile software development)</h2><div><a rel="noopener follow" href="/@goddesstop?source=post_page-----be9c459cc86e--------------------------------"><div aria-hidden="false"><img alt="HyunJun Park" src="https://miro.medium.com/v2/resize:fill:88:88/1*ykn8Jdr9or1H6BSQC3HawA.jpeg" width="44" height="44" loading="lazy" data-testid="authorPhoto"></div></a><a href="https://medium.com/29cm?source=post_page-----be9c459cc86e--------------------------------" rel="noopener follow"><div aria-hidden="false"><img alt="29CM TEAM" src="https://miro.medium.com/v2/resize:fill:48:48/1*TP1aY6ZJaPSPs3fKA6sYKA.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></div></a></div></div><figure></figure>채용 시장을 보면 많은 조직들이 애자일 문화를 경험한 것을 우대하거나 필수 조건으로 내세우는 것을 볼 수 있습니다.이제는 그만큼 IT업계 전반에 깊숙이 자리 잡은 개발 문화라고 볼 수 있겠는데요 이러한 애자일 조직에서의 QA는 어떤 모습을 가지고 있어야 할까요?먼저 애자일이란 무엇인지 이야기를 해야 할 것 같습니다.애자일에 대한 내용은 쉽게 접할 수 있습니다.간단하게 검색만 해봐도 “민첩한 소프트웨어 개발” 이라고는 되어있는데과거에는 이것이 정확히 무엇을 말하는지 잘 알지 못했습니다. 단순히 빨리, 자주 개발하면 되는 것인가?그렇다면 폭포수와 어떤 차이가 있는것인지, 단순히 폭포수보다 기능 범위를 작게 해서 자주 빠르게 릴리즈 하면 되는것인지 혼동스러웠죠.제가 혼동스러웠던 이유는 이것을 프로세스로 이해했기 때문이었습니다.아이디어를 도출하는 것부터 릴리즈까지의 개발 라이프사이클에 무언가 변화가 있는 것이라고 생각했기 때문이었습니다.하지만 이것은 프로세스가 아니었습니다.<blockquote>조직이 가지고 있어야 할 원칙이었습니다.</blockquote>민첩하고 유동적인 개발을 하기 위해서 원칙을 가지고 있어야 하는데 그 원칙이 바로 애자일 이었던 것입니다.과거의 폭포수 개발은 개인전의 면모가 강했습니다. 기획팀이 기획을 끝내면 개발팀이 개발을 시작하고 끝내고 QA팀이검증을 시작하고 끝내는, 어떻게 보면 계주 달리기 같은 모습이었습니다.애자일은 이것을 개인전이 아니라 팀전으로 바꾸는 것입니다.2명이 계주로 총 200m를 달리던 것이라면 애자일은 2인3각으로 100m를 달리는 것이라고 볼 수 있습니다.한 사람이 달리는 양은 같을 수 있지만 개인 위주냐, 팀워크 위주냐의 차이가 발생하는 것이죠.그래서 애자일이 세상에 나올 때 개발 원칙도 같이 공개가 되었습니다.그중에 기존의 폭포수 개발때와는 매우 상반된 원칙이라고 느낀 것이 있습니다.<pre>개발 후반에도 요구 사항 변경을 환영합니다.</pre>폭포수 때에는 개발 후반에 요구사항이 변경되는 것을 환영하지 않았습니다. 오히려 극도로 꺼려했습니다.하지만 애자일은 이것을 환영하고 있습니다. 바로 또 다른 원칙 때문입니다.<pre>가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객 만족을 실현합니다.</pre>애자일의 원칙의 가장 핵심 원칙이라고도 할 수 있을 것 같습니다.고객 만족을 실현하기 위해 애자일 조직이 있으며 그것을 기준으로 움직인다는 것이죠.그렇기 때문에 개발 후반에 요구 사항이 변경되어도 그것이 고객 만족을 위한 것이라면 환영한다는 것입니다.</div><div>이제 QA팀이 이런 애자일 조직에서 어떠한 역할을 해야 하는지 이야기할 수 있을 것 같습니다.개발 주기를 본다면 QA팀은 독립적인 활동이 불가능한 조직에 가깝습니다.QA활동을 하기 위해서는 누군가 선행해서 기획서를 만들어 놓았거나, 누군가 소프트웨어를 만들어놓은 상태여야 하기 때문이죠.어떻게 보면 개발 프로세스 앞부분부터 참여는 할 수 있으나 각 단계를 세밀히 살펴보면 주로 뒷부분에 참여하게 되는 모습입니다.이러한 특성상 QA팀은 애자일 개발 원칙 중에 하나인 “개발 후반에 요구 사항 변경”에 굉장히 민감할 수밖에 없습니다.그렇다고 해서 이러한 변화를 거부해서는 안됩니다.QA조직도 이러한 상황을 인지하고 애자일 조직이 목표로 하는 것을 실현하기 위해 변해야 합니다.<blockquote>요구사항이 항상 있을 수 있음을 인정해야 합니다.</blockquote>QA 진행 중에도 요구사항은 변경될 수 있습니다. 그럴 때 QA만이 할 수 있는 리스크 매니징으로 무엇이 더 유저에게 좋은 영향을 줄지 판단해야 합니다.이 변경사항이 적용되어 더 큰 유저 임팩트가 생길 수 있다면 현시점 기준으로 가장 리스크를 최소화할 수 있는 QA활동에 대한 계획과 전략을 수립해서 진행해야 하고, 이것이 적용되었을 때 제품의 안정성에 문제가 생길 수 있다면 해당 내용을 소속 애자일 조직에 공유하여 리스크를 인지하고 옳은 판단을 할 수 있도록 정보를 제공해줘야 합니다.단순히 리소스가 안되니 이건 할 수 없다.라고 말하는 것은 애자일 원칙에 어긋난다고 생각합니다.무엇이 더 좋은 방향인지 확인하는 과정이 꼭 필요하고 결정되었으면 그것이 이뤄질 수 있도록 모두 노력해야 하는 것이 애자일 조직이라고 생각합니다.QA조직은 현재 주어진 시간 안에서 리소스를 어떻게 사용하여 가장 큰 효과를 낼 수 있을지에 대한 고민을 끊임없이 해야 한다고 생각합니다.8시간 정도 테스트가 필요한 기능이라고 했을 때 나에게 실질적으로 주어진 시간이 2시간뿐이라면 그 2시간에 가장 효과적으로 테스트를 할 수 있는 전략을 세워야 합니다.가장 높은 우선순위를 가진 테스트 케이스를 우선적으로 실행하고, 이슈가 발생했을 때 유저에게 피해가 크게 갈 수 있는 기능위주로 테스트를 해야 하고, 기능 Flow 상에서 이슈가 발생하여 해당 기능을 사용하지 못하는 경우가 없도록 확인하는 것 등이 해당될 수 있습니다.애자일에서는 이렇듯 폭포수 때보다는 전략과 계획을 세워야 하는 상황이 더 빈번하게 발생하기 때문에 이러한 전략과 계획을 세우는 능력이 더 중요하다고도 볼 수 있습니다.</div><div>폭포수에 어느 정도 적응했던 저도 요구 사항이 자주 바뀌어서 올 때는 매우 힘들었습니다.오히려 다들 왜 이렇게 일하는지 이해를 못 했던 순간도 있었습니다.그런데 그렇게 다들 최선의 방향을 찾아가면서 개발과 배포를 이어 나갈 때 유저 지표가 의도한 대로 상승하는 것을 경험해 보니 왜 사람들이 이렇게 긴밀하게 움직이며 협업해 나가는지 이해하게 되었습니다.개인전을 했던 제가 이제는 팀전을 할 수 있게 된 것이죠.애자일 조직에 속한 QA라면 이렇게 애자일 조직과 전체를 아우르는 팀전을 할 수 있어야 합니다.무엇이 더 긍정적인 효과를 가져올 것인지를 계속해서 고민하고 그것을 도울 수 있는 방법을 찾아가야 합니다.변화를 두려워하지 말고 변화와 함께 해야 합니다.이럴 때 QA조직도 비로소 애자일 조직이라고 할 수 있을 것이라고 생각합니다.Linkedin: https://www.linkedin.com/in/maxparkblog: https://goddessbest-qa.tistory.com</div></div>

29CM 기술블로그 - Medium

채용 시장을 보면 많은 조직들이 애자일 문화를 경험한 것을 우대하거나 필수 조건으로 내세우는 것을 볼 수 있습니다.
이제는 그만큼 IT업계 전반에 깊숙이 자리 잡은 개발 문화라고 볼 수 있겠는데요 이러한 애자일 조직에서의 QA는 어떤 모습을 가지고 있어야 할까요?
먼저 애자일이란 무엇인지 이야기를 해야 할 것 같습니다.
애자일에 대한 내용은 쉽게 접할 수 있습니다.
간단하게 검색만 해봐도 “민첩한 소프트웨어 개발” 이라고는 되어있는데
과거에는 이것이 정확히 무엇을 말하는지 잘 알지 못했습니다. 단순히 빨리, 자주 개발하면 되는 것인가?
그렇다면 폭포수와 어떤 차이가 있는것인지, 단순히 폭포수보다 기능 범위를 작게 해서 자주 빠르게 릴리즈 하면 되는것인지 혼동스러웠죠.
제가 혼동스러웠던 이유는 이것을 프로세스로 이해했기 때문이었습니다.
아이디어를 도출하는 것부터 릴리즈까지의 개발 라이프사이클에 무언가 변화가 있는 것이라고 생각했기 때문이었습니다.
하지만 이것은 프로세스가 아니었습니다.
조직이 가지고 있어야 할 원칙이었습니다.
민첩하고 유동적인 개발을 하기 위해서 원칙을 가지고 있어야 하는데 그 원칙이 바로 애자일 이었던 것입니다.
과거의 폭포수 개발은 개인전의 면모가 강했습니다. 기획팀이 기획을 끝내면 개발팀이 개발을 시작하고 끝내고 QA팀이검증을 시작하고 끝내는, 어떻게 보면 계주 달리기 같은 모습이었습니다.
애자일은 이것을 개인전이 아니라 팀전으로 바꾸는 것입니다.
2명이 계주로 총 200m를 달리던 것이라면 애자일은 2인3각으로 100m를 달리는 것이라고 볼 수 있습니다.
한 사람이 달리는 양은 같을 수 있지만 개인 위주냐, 팀워크 위주냐의 차이가 발생하는 것이죠.
그래서 애자일이 세상에 나올 때 개발 원칙도 같이 공개가 되었습니다.
그중에 기존의 폭포수 개발때와는 매우 상반된 원칙이라고 느낀 것이 있습니다.
개발 후반에도 요구 사항 변경을 환영합니다.
폭포수 때에는 개발 후반에 요구사항이 변경되는 것을 환영하지 않았습니다. 오히려 극도로 꺼려했습니다.
하지만 애자일은 이것을 환영하고 있습니다. 바로 또 다른 원칙 때문입니다.
가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객 만족을 실현합니다.
애자일의 원칙의 가장 핵심 원칙이라고도 할 수 있을 것 같습니다.
고객 만족을 실현하기 위해 애자일 조직이 있으며 그것을 기준으로 움직인다는 것이죠.
그렇기 때문에 개발 후반에 요구 사항이 변경되어도 그것이 고객 만족을 위한 것이라면 환영한다는 것입니다.
이제 QA팀이 이런 애자일 조직에서 어떠한 역할을 해야 하는지 이야기할 수 있을 것 같습니다.
개발 주기를 본다면 QA팀은 독립적인 활동이 불가능한 조직에 가깝습니다.
QA활동을 하기 위해서는 누군가 선행해서 기획서를 만들어 놓았거나, 누군가 소프트웨어를 만들어놓은 상태여야 하기 때문이죠.
어떻게 보면 개발 프로세스 앞부분부터 참여는 할 수 있으나 각 단계를 세밀히 살펴보면 주로 뒷부분에 참여하게 되는 모습입니다.
이러한 특성상 QA팀은 애자일 개발 원칙 중에 하나인 “개발 후반에 요구 사항 변경”에 굉장히 민감할 수밖에 없습니다.
그렇다고 해서 이러한 변화를 거부해서는 안됩니다.
QA조직도 이러한 상황을 인지하고 애자일 조직이 목표로 하는 것을 실현하기 위해 변해야 합니다.
요구사항이 항상 있을 수 있음을 인정해야 합니다.
QA 진행 중에도 요구사항은 변경될 수 있습니다. 그럴 때 QA만이 할 수 있는 리스크 매니징으로 무엇이 더 유저에게 좋은 영향을 줄지 판단해야 합니다.
이 변경사항이 적용되어 더 큰 유저 임팩트가 생길 수 있다면 현시점 기준으로 가장 리스크를 최소화할 수 있는 QA활동에 대한 계획과 전략을 수립해서 진행해야 하고, 이것이 적용되었을 때 제품의 안정성에 문제가 생길 수 있다면 해당 내용을 소속 애자일 조직에 공유하여 리스크를 인지하고 옳은 판단을 할 수 있도록 정보를 제공해줘야 합니다.
단순히 리소스가 안되니 이건 할 수 없다.라고 말하는 것은 애자일 원칙에 어긋난다고 생각합니다.
무엇이 더 좋은 방향인지 확인하는 과정이 꼭 필요하고 결정되었으면 그것이 이뤄질 수 있도록 모두 노력해야 하는 것이 애자일 조직이라고 생각합니다.
QA조직은 현재 주어진 시간 안에서 리소스를 어떻게 사용하여 가장 큰 효과를 낼 수 있을지에 대한 고민을 끊임없이 해야 한다고 생각합니다.
8시간 정도 테스트가 필요한 기능이라고 했을 때 나에게 실질적으로 주어진 시간이 2시간뿐이라면 그 2시간에 가장 효과적으로 테스트를 할 수 있는 전략을 세워야 합니다.
가장 높은 우선순위를 가진 테스트 케이스를 우선적으로 실행하고, 이슈가 발생했을 때 유저에게 피해가 크게 갈 수 있는 기능위주로 테스트를 해야 하고,
기능 Flow 상에서 이슈가 발생하여 해당 기능을 사용하지 못하는 경우가 없도록 확인하는 것 등이 해당될 수 있습니다.
애자일에서는 이렇듯 폭포수 때보다는 전략과 계획을 세워야 하는 상황이 더 빈번하게 발생하기 때문에 이러한 전략과 계획을 세우는 능력이 더 중요하다고도 볼 수 있습니다.
폭포수에 어느 정도 적응했던 저도 요구 사항이 자주 바뀌어서 올 때는 매우 힘들었습니다.
오히려 다들 왜 이렇게 일하는지 이해를 못 했던 순간도 있었습니다.
그런데 그렇게 다들 최선의 방향을 찾아가면서 개발과 배포를 이어 나갈 때 유저 지표가 의도한 대로 상승하는 것을 경험해 보니 왜 사람들이 이렇게 긴밀하게 움직이며 협업해 나가는지 이해하게 되었습니다.
개인전을 했던 제가 이제는 팀전을 할 수 있게 된 것이죠.
애자일 조직에 속한 QA라면 이렇게 애자일 조직과 전체를 아우르는 팀전을 할 수 있어야 합니다.
무엇이 더 긍정적인 효과를 가져올 것인지를 계속해서 고민하고 그것을 도울 수 있는 방법을 찾아가야 합니다.
변화를 두려워하지 말고 변화와 함께 해야 합니다.
이럴 때 QA조직도 비로소 애자일 조직이라고 할 수 있을 것이라고 생각합니다.
Linkedin: https://www.linkedin.com/in/maxpark
blog: https://goddessbest-qa.tistory.com
애자일 조직에서 QA팀의 역할 (The role of the QA team in the Agile software development) was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

애자일 조직에서 QA팀의 역할 (The role of the QA team in the Agile software development)

댓글