애자일 테스팅을 위한 전체 팀 접근 방식

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

 

Shift your mindset

오래된 테스팅 사고방식이 틀렸다는 얘기가 아닙니다. 하지만 애자일 팀에서 일하려면 다른 사고방식이 필요합니다. 많은 갈래길 중 단 하나의 옳은 길이란 없듯이, 품질을 높이기 위해 진행 상황을 평가하고 개선해 나가는 애자일 사고 방식(Agile mindset)이 필요합니다. 지속적으로 회고하고, 목표를 설정하고, 실험하고 개선해야 합니다.

테스터들이 그들의 업무를 단순히 결함을 찾는 다거나, 요구사항이 충족되었는지 살펴 본다거나, 혹은 소프트웨어를 파괴하는 것으로 여기는 경우, 서로 손가락질하게 되는 경우가 많이 발생하고, 협력하는 대신 적대적인 관계를 맺기 때문에 애자일에 적합하지 않은 태도입니다. 대신에 어떻게 도움을 줄 수 있는지 생각해야 합니다. 그 외 다른 요소들이 있지만, 이것이 팀의 협업에 큰 차이를 만드는 중요한 요소입니다. 강조하고자 하는 것은 팀의 다른 구성원들이 상대 팀이 아니라는 점입니다.

테스터뿐만 아니라 프로그래머를 포함한 다른 팀원들의 마음가짐도 바뀌어야 합니다. 프로그래머는 개발한 코드를 테스트할 다른 사람에게 단순히 넘겨준다는 생각 대신에, 다른 마음가짐을 가질 필요가 있습니다. 많은 경우 프로그래머는 자신의 코드를 정말 잘 테스트하지만, 때로는 일부 리스크를 인지하지 못하거나, 큰 그림을 보지 못하고 작은 덩어리에 집중하게 되는 인지 편향이 있을 수 있습니다. 만약, 프로그래머, 나아가 전체 팀이 항상 테스트에 대해 생각하기 시작한다면, 훨씬 더 협력적인 팀이 될 수 있습니다.

Build your skill set

T자형 스킬은 애자일 개발에서 애자일 팀원의 능력을 설명하는 훌륭한 비유입니다.

우리는 역할보다 기술과 역량을 중시합니다. 우리는 팀에서 다양한 활동을 할 수 있으므로 수평 막대(다양한 역량)를 통해 여러 분야에서 협업하고 다른 영역에 지식을 적용할 수 있습니다.

예를 들어, 내가 가진 코딩 경험은 개발자와 함께 자동화 테스트를 하는데 도움이 됩니다. 테이더베이스에 대한 지식은 데이터베이스 관리자와 협업하는데 도움이 되고, 보안테스팅에 대한 충분한 지식은, 그것을 할 수 있도록 돕습니다. 이것이 다양한 것들에 대해 조금씩 알고 있는 나의 기술영역이고, 많은 애자일 팀 구성원들 또한 이렇게 다양한 영역에 대한 지식을 가지고 있습니다.

그런 다음 우리는 수직 기술, 우리가 가장 열정을 가지고 있는 심층 기술을 가지고 있습니다. 예를 들어 나의 깊은 기술은 비즈니스 영역을 빠르게 학습하는 것입니다. 저는 비즈니스 운영 방식, 사람들이 업무를 수행하는 방법, 비즈니스를 성공적으로 만드는 요소를 배우는 것을 좋아합니다. 그렇게 함으로써 팀에 가장 큰 가치를 더할 수 있습니다.

Adam Knight는 T-자형 비유를 좀 더 확장하여, 다양한 T-자형 기술을 가진 사람들로 구성된 Square-Shaped 팀에 대한 얘기를 했습니다. 팀원은 모두 사고력을 지니고 있으며여기서 정말 중요한 핵심 요소는 다양성입니다. 인지적 편견을 극복하기 위해서는 이러한 다양한 관점이 필요합니다. 팀은 항상 학습할 준비가 되어 있고, 실패 또한 학습이기에 실패를 두려워하지 않습니다.

테스트를 성공적으로 수행하는 데 필요한 몇 가지 특정 기술을 살펴보겠습니다.

사고력

'사고력', 대부분의 사람들은 이것을 소프트 스킬이라고 부르거나, 좀 더 쉽게 'people 스킬' 이라고 부른니다. 우리는 '사고력'을 선호합니다. 왜냐하면 당신은 이러한 기술을 배우기 위해 약간의 노력을 기울여야 하기 때문입니다.

Communication, 테스터는 훌륭한 정보 제공자이지만 때때로 나쁜 소식을 얘기해야 하기 때문에 모든 사람이 듣고 싶어 하는 것은 아닙니다. 사고력은 다른 팀원들과 이런 경우에 어떻게 협력할지 도움을 줍니다.

Collaboration, 우리는 비즈니스 언어와 기술 팀의 언어를 배우고 시스템이 어떻게 작동해야 하는지 이해해야 할 때 이 모든 사람들을 모아 대화를 나눌 수 있습니다.

Listening Skills, 듣기 기술은 제가 항상 활용하는 핵심 요소입니다. 숨겨진 가정을 주시하십시오. 비즈니스 팀은 개발 팀이 특정 기능이 어떻게 작동해야 하는지 정확히 알고 있을거라 생각하지만, 실제로 다른 생각을 가지고 있을 수 있습니다.

사고하는 테스터가 되고, 여러분들의 사고력을 키워보세요.

기술적 인식

경험상, 우리는 프로그래머 만큼의 개발능력을 필요로하진 않습니다. 그러나 일부 기술적인 스킬들을 이해하면 팀 내 technical 구성원들과 협업하는데 도움이 됩니다.

예를 들어 높은 수준의 시스템 아키텍처를 알고 있으면 해당 아키텍처의 어떤 영역이 잠재적으로 위험하거나 취약한지, 어디에서 문제가 발생할 수 있는지에 대해 나머지 팀원들과 논의할 수 있습니다. 기본 프로그래밍 개념과 디자인 패턴 같은 경우에는 팀이 사용하는 IDE를 사용하는 방법을 알고 소스 제어 시스템을 사용하는 방법을 아는 것이 개발자 및 팀의 다른 구성원과 협업하는데 도움이 됩니다. 데이터베이스를 아는 것은 데이터 측면의 위험을 식별하는 데 도움이 되고 테스트 데이터를 설정하는 데 도움이 됩니다. CI 정책에 대해 이해하고, 자동화 테스트가 어떻게 돌아가는지, 빌드가 어떻게 이루어지는지, 언제 어디에 빌드가 배포되는지를 알면 어떤 환경에서 어떤 부분을 정확히 테스팅해야 하는지 알 수 있습니다.

이런 것들이 모두 우리가 기술적인 인식을 구축하는 데 정말로 도움이 된 기술적인 스킬들 입니다.

도메인 지식

기술적인 인식의 또 다른 영역에 도메인 지식이 있습니다. 물론 다른 팀원들 또한 잘할 수 있지만, 특별히 테스터가 강점을 가지고 많은 가치를 추가하는 영역 중 하나라고 생각합니다. 비즈니스 목표를 달성하고 비즈니스를 성공적으로 만들고 고객과 최종 사용자에게 가치를 가져다 줄 비즈니스에 대한 테스트에 중점을 둡니다.

실제 유저가 어떻게 서비스를 이용할지 공부해 보세요 비즈니스 문제를 더 잘 해결하는데 큰 도움이 될 것입니다. 비즈니스 분석가, PO, PM는 비즈니스 영역에서 탁월한 경향이 있습니다. 그들과 협업이 많은 도움이 될 것입니다. 고객 지원팀에게 찾아가 어플리케이션의 어떤 영역에서 문제가 많이 발생하는지 확인하는 것도 좋은 방법입니다.

Engage the whole team

우리는 테스트 및 품질에 대한 책임을 지고, 전체 팀을 참여시키는 것에 대해 이야기했습니다.

어떻게 하면 그렇게 할 수 있을까요? 어떻게 하면 테스터뿐만 아니라 팀의 모든 사람이 애자일 테스팅 사고방식으로 전환하도록 할까요? 어떻게 하면 필요한 테스트 활동이 적시에 완료되도록 할까요?

엘리자베스 헨드릭슨(Elizabeth Hendrickson)은 테스팅은 단계가 아니라 활동이라고 말한 적이 있습니다.

폭포수 개발 모델에서 일 해온 사람들은, 개발의 마지막 단계에서 수행하는 테스트의 경험해왔고 테스트가 수행되어야하는 시점을 정확히 알고 있습니다. 하지만 애자일 개발에서는 테스트는 항시 수행됩니다. 이전에 해오던 테스팅 방법이 더 이상 필요하지 않은 것은 아니고, 다르게 적용해야 합니다.

팀은 새로운 기능에 대해 논의하기 시작하자마자 테스트 및 테스트 가능성에 대해 생각하기 시작합니다. 테스트 주도 개발, Acceptance Test 주도 개발과 같은 몇 가지 사례를 통해 더 나은 코드 디자인을 얻을 수 있습니다. 이터레이션 계획 회의에서 종종 우리가 어떻게 그 유저스토리를 테스트할 것인지 묻고 모든 사람들이 테스트 가능한 디자인에 대해 생각하게 합니다. 우리는 테스트를 작성하고, 테스트가 실패했을 때 어떻게 처리할 지에 대해 논의합니다. 반복되는 작은 이터레이션에서 지속적으로 테스트하고 코딩합니다.

Elizabeth Henderson이 말한 애자일의 정의에 따르면, 애자일 팀은 지속 가능한 속도로 비즈니스에 가치를 자주 제공하며, 테스트 활동은 지속 가능한 속도의 핵심입니다.

경험상 우리가 목표를 달성하는 방법은 전체 개발 팀이 테스트 품질에 대한 책임을 지는 것입니다. 개발 팀이라고 하면 개발자, 테스터, 데이터베이스 전문가, Ops, 디자이너 등 소프트웨어를 개발하는데 도움을 주는 모든 사람을 의미합니다. 소프트웨어 제품에서 원하는 품질 수준을 팀 전체가 함께 의논하십시오. 원하는 품질 수준을 방해하는 장애물에 부딪히게 되므로, 그런 장애물을 피하기 위해 시도방안을 생각해야 할 것입니다. 예를 들어 제가 일한 팀에서 API를 통해 승인 테스트 주도 개발을 하고 싶었지만 시스템 아키텍처가 이를 허용하지 않았습니다. 그래서 우리는 사용자 인터페이스를 통해 이를 대신해야 했습니다. 따라서 장애물에 부딪히게 될 것이라는 점을 인식하고 이에처할 준비를 하십시오.

이제 기능적 팀과 애자일 팀에 대해 이야기해 보겠습니다. 폭포수 프로젝트에서 우리는 개별적으로 작업하고 다음 사일로에 작업을 넘겨주는 기능적인 팀을 가졌습니다. 애자일 팀에는 소프트웨어를 제공하는 데 필요한 모든 기능을 제공하는 사람이 함께 작업합니다. 우리는 역할을 채우기보다 우리가 필요로 하는 기술과 역량에 중점을 둡니다. 모두가 테스트를 하고, 다양한 사람들이 디자인과 코딩에 참여하는 것 처럼 애자일 팀에서 역할이란 정말 흐릿합니다. 어떤 것이든 우리는 협력하고 짝을 지어 다양한 활동을 수행하고 지식을 전달합니다.

Focus on quality, not speed

우리는 모두 마감 시간과 마감 시간의 압박을 경험했습니다. 더 열심히 일하지만, 반드시 더 좋아지는 것은 아닙니다. 먼저 품질에 중점을 두는 것이 더 나은 이유를 알아보겠습니다.

많은 기업이 애자일은 피쳐를 빨리 만들어내는 것이라고 생각하지만, 애자일은 단순히 빠르기를 뜻하지 않습니다.

맞는 말이기도 하지만, 실제로 의미하는 바는 지속 가능한 속도로 더 자주 유저에게 가치를 제공하는 것입니다. 사용자가 작은 단위의 기능들을 더 빨리 얻기 때문에 빨라 보이는 것입니다. 때때로 마감일을 맞추기 위해 일부 요구사항을 제외 하기도 하지만, 어쨌든 그것들은 여전히 해야하는 일로 남아있습니다. 마치 이자를 지불해야하는 대출과 같은 것이지요. 빨리 갚을 수록 이자가 줄어듭니다.

너무 많은 지름길을 선택한다면 피드백 루프가 길어지고 어떤 것도 변경하기가 두려워집니다. 기반이 약하면 기술적인 부채가 발목을 잡고, 제품의 반응성이 떨어집니다. 목표가 배포 속도 대신 가능한 최고의 품질을 제공하는 것일 때, 우리는 견고한 기초를 구축할 수 있습니다.

TDD와 같은 핵심 프랙티스를 익히는데 시간을 많이 써야 합니다. 짧은 피드백 루프는 더 빠른 변경을 가능하게 하므로 지속적인 통합, 자동화 테스트와 같은 방식을 사용합니다. 뿐만 아니라 비즈니스를 배우고 비즈니스 전문가와 관계를 형성하여 협업하고, 가장 중요한 기능을 식별합니다.

이 견고한 토대를 바탕으로 제공하고자하는 가장 가치 있는 기능은 지속적으로 제공함으로써, 비로소 빠르게 작업하게 되는 것입니다.

폭포수 프로젝트에서 테스트는 일반적으로 Code Freeze 라고 하는 코드 작업이 끝날 때까지 시작되지 않습니다. 동일한 코드를 반복적으로 테스트하는 것은 낭비이기 때문이지요. 애자일에는 개발의 작은 증분이 완료되자 마자 즉시 테스트합니다. 페어링, 'Show me' 또는 'desk check'라 불리는 방법들을 사용하여, 프로그래머가 코딩을 마치면 테스터가 빠르게 살펴보고 해당 결함을 찾아 즉각 수정될 수 있도록 합니다. 이터레이션을 통해 발생한 버그를 모두 해결함으로써, 나중에 Bug Triage, Bug Database와 같은 버그 분류작업으로 시간을 낭비하지 않을 수 있습니다.

FAQ

만약 모든 사람에게 책임이 있다면, 아무의 책임도 아닌게 됩니다. 모든 사람이 품질을 소유한다는 것이 정말 효과가 있을까요?

사람들이 책임을 진다면 효과가 있다고 생각합니다. 만약 그들이 자제력을 가지고, 품질을 위해 내가 무엇을 할 수 있는지 책임있게 말할 때, 바로 그런 경우입니다.

어쨌든 품질은 괜찮아질 것이라고 단순히 생각한다면, 그런 경우는 정말 아무도 하지 않는 상황인 되는 것입니다.

그래서 저는 그것이 모든 개인에게 달려있고, 각자가 그런 식으로 훈련이 잘 되어있어야 한다 생각합니다.

 

만약 모든 팀원이 테스트를 한다면 왜 테스터가 필요 할까요?

사실 테스팅의 유형은 다양하고, 모든 유형의 테스트를 잘하기는 어렵습니다. 테스터는 전문적인 테스트 기술을 제공합니다. 예를 들어, 대부분의 팀에서 테스터가 아닌 팀원들은 탐색적 테스트에 대해 잘 알지 못합니다. 그들은 시작하는 방법조차 모를 때, 테스터가 시작하는 데 도움을 줄 수 있습니다. 보안 테스트 또는 성능 테스트와 같은 전문화된 테스트를 위해서는, 전문 테스터가 필요하고 해당 지식을 팀 전체에 전파할 수 있습니다.

 

애자일 팀에서 테스터와 프로그래머의 적절한 비율은 무엇인가요?

마법의 비율같은 것은 없습니다. 2대1, 혹은 3대1의 비율이 우리에겐 효과적일 수 있지만, 다른 팀에겐 그렇지 않을 수 있습니다. 저의 경우 10명 남짓 개발자가 있는 팀에서 유일한 테스터로 일 했었습니다. 그런 경우, 저는 거의 테스트 자문에 더 가까운 역할을 하였습니다.

프로그래머가 어떤 테스트가 누락되었을 수 있는지, 그리고 일부 부하 테스트 결과를 어떻게 해석하는지 이해할 수 있도록 도왔습니다. 반면에 매우 넓은 비즈니스 지식을 기반으로하고 있는 경우, 제품의 전체를 아는 것이 매우 어렵기 때문에 보다 높은 테스터의 비율을 가지고 있습니다. 일부 이런 경우에는 거의 1대1의 비율에 가깝죠.

만약 여러분의 팀에 어떤 문제가 있다면 문제가 무엇인지 확인하세요. 추가적인 테스터 필요없이 아마 개발자가 도울 수 있는 영역일 수도 있어요.

결론적으로 여러분들의 팀에 맞는 방법은 무엇인지 생각해야합니다.