애자일 테스팅 도전과제: 품질, 프로세스, 팀 이슈의 극복

digital.ai라는 기관에서는 매년 State of Agile Report를 통하여 설문조사에 기반한 애자일 동향 리포트를 발행하고 있습니다. 애자일을 도입한 목적, 채택한 애자일 어프로치, 도전과제, 사용 중인 툴 등 여러 내용이 포함되어 있는데요. 인상적인 부분은 높은 퍼센티지를 차지하는 고질적인 도전과제(문제)들은 해가 지나도 여전하다는 것입니다. Agile Manifesto(애자일 선언문)가 발표된 지 20년이 지난 지금, 깊이 생각해 볼 부분이 아닌가 생각이 듭니다. 그러면 애자일 테스팅은 어떨까요? 애자일 테스팅의 인플루언서 네 분이 모여 10년 전(2012년) 나누었던 얘기를 되짚어 보았습니다.  

 

[출처] https://www.youtube.com/watch?v=YI3h9fqrBQA

형식 : 온라인 공개 토론회

패널 : Lisa Crispin, Bob Galen, Matt Heusser, Steve Miller

안건 : Agile Testing Challenges

• Misconceptions
• Top Agile Testing Challenges
• Maintaining Quality and the Speed of Iterations
• Establishing the Whole Team View
• Best Ways to Use Testing Tools

Misconceptions

질문 - 애자일, 애자일 테스팅과 관련하여 당신이 생각하는 가장 흔한 오해는 무엇이라 생각하나요?

[스티브] - 많은 사람들이 애자일은 아주 가볍기 때문에 유저스토리나 요구사항 별로 테스트 상태를 추적할 필요가 없다고 생각하지만 그건 큰 오해입니다. 어떤 유형의 테스트를 수행하든 모든 요구사항과 유저스토리는 충분히 만족할만한 테스트가 수행되었는지 확인 가능해야 하기 때문입니다. 추적 가능성(Traceability)이 투명성(Transparency) 불러 일으키고, 그런 투명성이 애자일의 근간이 됩니다.

[리사] - 사람들이 애자일을 "더 빠른 것"으로 인식한다는 것입니다. 아마도 그것은 속도를 뜻하는 '스프린트'와 같은 단어를 쓰기 때문이라고 생각하는데요. 하지만 저는 Elizabeth hendricks가 말한 '지속 가능한 속도로 비즈니스 가치를 자주 제공한다'는 의미의 정의를 좋아합니다.

지속 가능한 속도로 이를 수행하고 기술적 부채를 통제하는 방법을 배우려면, 초반에 방법과 원칙을 배우는데 많은 시간 투자가 필요합니다. 그래야만 팀이 빈번한 이터레이션 안에서도 업무를 잘 수행할 수 있고 기술적 부채도 낮게 유지할 수 있습니다. 그러면 결과적으로 빨라지게 되는 것이죠.

속도에만 집중한다면 곤경에 빠질 것입니다. 시간이 많이 걸리긴 하지만 품질에 집중해야만 빠르게 진행할 수 있습니다.

[밥] - 애자일 테스팅이 너무 기술적인 면만 간주된다는 것입니다. 예를 들어 TDD, ATDD, BDD, UT와 같은 방법을 이용하여 모든 작업을 자동화하고 버튼만 누르면 마법처럼 모든 결과가 나타나게 되는 그런거죠.

자동화가 애자일 테스트에서 매우 중요한 부분이라고 생각하지만, 유일한 방법은 아니라 생각합니다. 성공적인 애자일 테스팅을 위해서는 테스팅 기술에 정말로 열정을 가진 테스트 전문가가 있어야 합니다.

[매트] - 첫 번째는, 애자일 테스트는 모든 테스트가 사전에 자동화되고 개발되어야 된다고 생각하는 것입니다.

두 번째로 회사가 마치 기성품과 같이 책에 나와있는 특정 방법론을 '그냥' 따라하면서 애자일하고 있다고 생각한다는 것입니다. 방법론에 따라 작업을 수행해 보지만 이전과 별로 다르지 않은 결과를 경험하곤 "애자일 해봤는데, 그거 잘 안되는 거야"라고 생각하는데 정말 안타까운 일입니다.

Top Agile Testing Challenges

질문 - 당신이 경험했던 최고의 애자일 테스트 도전과제는 무엇이고 어떻게 해결하셨나요?

[매트] - 애자일 개발을 처음 시도하게되면 어쩔수 없이 책을 따라 할 수 밖에 없게되는데, 보통 생각만큼 잘 안 돌아가는 경우가 생깁니다. 그럴 경우, 애자일을 반대했던 사람들이 "그것 봐 잘 안 되잖아~"라고 말하는 것(일종의 초를 치는)이 큰 도전과제 중 하나라고 생각합니다.

두 번째로는 충분히 변화하지 않는 것이라고 생각합니다. 전통적인 개발 프로세스와 비교하면 테스팅 기간이 상당히 짧습니다. (몇 주 → 몇 시간) 그 짧은 시간 안에 소프트웨어가 deliverable 한지를 확신하고 릴리즈하기 위해 테스트를 좀 더 빨리 수행할 수 있는 방법(예를 들어 자동화 테스트)들을 찾아내기 위해 투자해야 한다고 생각합니다.

[리사] - 점증적이고 연관성있게 작업하기 위해, 피쳐들을 작은 단위로 쪼개는 방법을 익히는데 큰 어려움이 있다고 생각합니다. 특정 부분의 새 기능을 구현/테스트/자동화/탐색하고, 그 위에 덧붙혀 작업을 점진적으로 진행하는 방식을 익히는데 수 개월 혹은 1~2년이 걸릴 수도 있습니다.

다른 하나는, 보다 큰 조직의 경우 성능테스트, 로드테스트, 보안테스트 등과 같은 특별한 목적의 테스트를 수행하는 전문 인력이 부족하고, 그런 인력들을 확충해나가는 것이 큰 도전과제라고 생각합니다.

[스티브] - Q&A 채널에 올라온 글을 잠깐 언급하면, 애자일은 "날아가는 비행기를 고치는 것과 같다"라고 합니다. 예를 들어, 작은 유저스토리들이 진행되면서 변경되고, 그러한 변경 사항들을 확인하기 위해 테스트 영역을 다시 정해야하기 때문에 테스트 수행에 많은 영향을 미칩니다. 밥 어떻게 생각하시나요?

[밥] - 타당하다 생각합니다. 조금은 큰 관점에서 말씀드리면, 애자일 테스팅의 가장 큰 도전과제 중 하나는, 그것이 애자일 테스팅에만 국한된 것이 아니란 것입니다.테스트 그룹이나 테스터들만의 문제가 아니란 거죠. 만약 조직이 애자일로 전환하기로 했다면, 조직 차원에서 애자일해져야 하고, 전체 팀이 다 함께 가야한다는 것이지요. 전체 팀의 관점에서, 모든 것을 테스터들에게만 떠맞기고 확인하도록 둘 수는 없습니다. 구성원 모두가 어떻게 작업하고 어떻게 하면 효과적으로 테스트할 수 있을지에 대해 고민하고 점진적으로 변화할 필요가 있습니다. 강조하고 싶은 부분은, 조직의 경영진의 역할이 중요한데요. 팀에게만 애자일 방법을 찾도록 내버려두지만 말고, 애자일은 속도전이 아니다란 걸 충분히 이해하고(결국 속도전이 될 수도 있지만, 그것이 목적은 아님), 팀을 지원하고 지도해야 합니다. 그리고 그것이 전사적으로 퍼져나갈 수 있도록 해야합니다.

Maintaining Quality and the Speed of Iterations

질문 - 이터레이션의 품질과 속도를 유지하는 데 가장 효과적인 애자일 테스트 프로세스 및 Practice는 무엇입니까?

[리사] - 애자일 테스팅 프로세스에 관한 것은 아닌데요. 새로운 애자일 팀의 경우 목표를 너무 과도하게 잡는 경향이 있습니다. 사업팀을 만족시키고 싶어하고, 1~2주 안에 많은 일을 끝낼 수 있다고 생각해서, 많은 유저스토리들을 작업범위로 산정합니다. 그리곤 이터레이션이 끝날 때면 테스트가 완료되지 않았다거나, 코딩이 완료되지 않은 상태를 직면하죠. 따라서 전체 스토리를 줄여야 합니다. 한 번에 하나의 스토리를 완료하는 것에 집중하고 진행 중인 작업(WIP)를 제한하는 것이 아주 중요합니다.

사람들이 특정한 애자일 방식에 능숙해지더라도 요구사항과 명세를 이해하는데 여전히 어려움을 가지고 있다는 것이 또 다른 큰 문제라고 생각합니다. 그래서 개발자, PO, 테스터가 함께 문제를 논의하는 Three Amigos 형식이 많이 필요하다 봅니다. 명세와 관련된 예시를 많이 확보하여 테스트 케이스화하고, 그것을 바탕으로 Acceptance 테스트 주도 방식의 개발방법을 시도해보는 것이 도움이 될 것으로 생각합니다.

[밥] 미성숙한 팀의 경우, 과도하게 목표를 두고 그것이 큰 문제가 된다는 것에 동의합니다. 또한 품질보다는 속도에 치중하는 것도 큰 문제라 생각하는데요. 올바른 전환을 위해서 목표치를 절반으로 줄여서 잘 마무리하는 것을 시도해보는 것을 추천합니다. 그 정도의 작업량을 처리하는데 충분한 경험과 성숙도가 쌓이면 조금씩 늘여나갈 수 있습니다.

[매트] 프랙티스는 상황에 따라 좋을 수도 있고 나쁠 수도 있다고 생각합니다. 하지만, 애자일 상황에서 일반적으로 좋고, 도움이되는 것들이 몇 있죠. 예를 들어 우리가 할 작업들에 대한 진정한 동의를 가지고 있는지? 코드작업을 하기 이전에 우리가 할 작업들에 대한 공동의 이해를 높이기 위한 킥오프 미팅을 하는지? 발생한 이슈들에 대해서 무분별하게 계속 유저스토리를 추가로 생성하지는 않는지? 와 같은 것들이죠.

이러한 소프트웨어 개발 방식에 새로운 팀들이 가지고 있는 속도를 최고로 생각하는 사고방식에 대해 한가지 더 말씀드리면, 속도를 높이기 위한 지름길은 없습니다. 아마도 한 번의 이터레이션 혹은 한 달 안에 실패의 고통을 맛보게 될 것입니다. 그런 사고방식을 바로잡고 올바른 문화를 세워가는데 비용이 들어갈 것입니다.

Establishing the Whole Team View

질문 - 애자일 팀 내에서 필요한 품질 및 테스트에 대한 "전체 팀" 관점을 어떻게 확립하나요?

[스티브] 애자일은 모두가 작은 기능의 세트들을 공동작업하는 매우 협력적인 이벤트라는 점에서 폭포수 모델과는 매우 다릅니다. 그래서 많은 질문 중에 하나가, 어떻게 전체 팀이 품질과 테스트에 관련하여 공동의 이해를 가지고 협력할 수 있냐는 것입니다. 심지어 테스트 스프린트와 개발 스프린트를 별도로 관리하여 모두가 자신의 속도와 완료항목에 따라 작업할 수 있도록 되어야 하지 않냐는 질문도 받습니다. 밥 이에 대해 어떻게 생각하시나요?

[밥] 절대 분리하지 마세요. 제발~ 애자일은 기능적으로 분리된 팀들이 서로 일거리를 넘겨주고 받으며 일하는 방식이 아닙니다. 여러분들의 팀 DNA에 그것을 각인 시킬 필요가 있다고 생각합니다. 전체 팀 혹은 분리된 팀으로 움직이는지 인지할 수 있는 징조들을 생각해보면, 만약에 "왜 테스트에서 그게 발견되지 않았죠?"라고 말한다면 애자일 팀의 테스터들이 전체 팀으로 일하는 것이 아니라 분리된 기능으로 일하는 것일 겁니다. 만약 스프린트 플래닝 미팅에서 테스터의 estimation 이 고려되어지지 않는다면, 서로의 목소리에 귀기울이지 않고, 스토리의 복잡성을 다 같이 풀어나가지 않는다면 전체 팀으로 동작하는 않는 것으로 볼 수 있습니다. 개발자가 테스트에 기꺼이 참여하지 않고, 그것이 당연시 여겨진다면 전체 팀으로 동작하지 않는 것으로 볼 수 있습니다.

이 부분에서 운영진들이 중요한 역할을 하는 것 같습니다. 매일 매일의 대화에서 테스팅, 개발, 프로젝트 관리의 이슈들을 팀 차원에서 이야기할 수 있는 기회를 가지고, 그런 다음 스프린트 리뷰를 통해서 확대해 나가는 것입니다.

[매트] 몇 가지 생각나는 것 중에 하나는 병목지점이 어디고 어떻게 더 빨리 작업을 처리할 수 있을까에 집중하는 것입니다. 가령, 여러분의 프로세스 상에 병목 지점이 있다면, 모든 작업들이 병목지점의 속도에 맞춰 늦어지게 됩니다. 이럴 경우 보통 병목 현상에 대해 불평하고 서로를 비난하는 경우가 많은데, 그것은 전체 팀 접근 방식에서는 절대 팀의 속도를 향상시키지 않습니다. 그들의 업무에 더 많은 항목을 추가하여 멀티태스킹을 요구하는 것 또한 속도를 높이지 않습니다. 병목지점을 분리하고 관찰하여 더 빠르게 할 수 있는 방법을 알아내야 합니다. 예를 들어 만약에 테스트가 늦어진다면 개발자가 업무를 조정하여 시스템 레벨의 자동화 테스트 스크립트를 작성할 수도 있겠죠. 그렇게 팀원들간의 업무 조정/협조를 통해서 처리량을 최대화 할 수 있습니다.

[리사] 밥과 매트가 얘기한 것 처럼 좋은 리더가 필요하고, 팀이 품질에 대한 책무가 무엇인지 다 함께 얘기해야합니다. 어떤 장애물 때문에 책무를 다하지 못한 것을 핑계삼지 않아야 합니다.

도메인 지식을 좀 더 깊이 이해하면 비지니스 스토리들을 간단하게 하는데 도움이 됩니다. 사업팀의 목적과 무엇을 원하고 어떤 문제를 해결하고자 하는지를 충분히 이해한다면, 그것을 해결할 수 있는 간단하면서도, 더 효율적인 방안을 제안할 수 있기 때문입니다.

Best Ways to Use Testing Tools

질문 - 애자일 팀에서 테스트 도구를 사용하는 가장 좋은 방법은 무엇입니까?

[밥] 현재 팀의 경우를 예로 들어보면, 다양한 오픈 소스툴들을 이용해서 테스트 자동화 작업을 진행 중입니다. 유저스토리 별로 자동화 스크립트를 작성하는데요, 유저스토리가 놀랍도록 불분명하고 acceptance test 조차도 없습니다. 자동화가 활기차고 고급적이고 저 또한 항상 그것에 투자하고 난처한 상황에서 저를 구해도 주지만, 자동화를 우선시 하는 것은 옳지 않다 생각합니다. 토론하고, 협력하고, 잘 정의된 유저스토리를 작성하는 것 부터 시작해야 합니다. 개인, 팀, 조직에서 그런 것들을 잘 할 수있도록 하는 것에 집중해야 하고 난 뒤, 잘 쓰여진 유저스토리와 팀의 협조를 기반으로 자동화 작업을 시작해야 합니다. .

[리사] 운좋게도 오늘날 우리는 어플리케이션의 모든 레벨에서 테스트할 수 있는 다양한 툴이 있고 훌륭한 드라이버와 프레임워크들이 있습니다. 먼저 테스트 도구에 대한 요구사항을 결정한 다음 전체 팀이 함께 조사한 후 도구를 선택하기 위한 작은 실험을 해야 합니다. 그리고 전체 팀이 자동화를 성공시키는 데 필요한 모든 기술을 익히도록 하는 것이 중요하다고 생각합니다.