워터폴 프로젝트 관리는 개발과 테스트를 서로 다른 두 단계로 구분합니다. 개발자가 기능을 만든 다음, 테스트 작업을 위해 QA(품질 보증) 팀에 "던져 놓는" 것입니다. QA 팀은 자세한 테스트 계획을 작성하고 실행합니다. 또한 새 작업으로 인해 발생했을 수 있는 기존 기능의 회귀를 힘들게 확인하며 결함이 있으면 이를 제출합니다.
이러한 워터폴 또는 기타 기존 테스트 모델을 사용하는 많은 팀에서는 제품이 성장함에 따라 테스트 작업의 양이 기하급수적으로 증가하고 QA 팀은 이를 따라가는 데 항상 어려움을 겪고 있습니다. 프로젝트 소유자는 릴리스를 연기하거나 테스트를 생략하는 것 중 하나를 골라야 하는 원치 않는 선택의 상황에 놓이게 됩니다. (99%의 경우에서 어떤 것을 선택했는지 맞춰 보세요.) 그동안 개발 팀은 다른 작업으로 넘어갔습니다. 따라서 기술적 부채가 증가할 뿐만 아니라 각 결함을 해결하려면 코드 베이스의 두 부분 간에 비용이 많이 드는 컨텍스트 전환이 필요합니다. 이미 안 좋은 상황이 더욱 나빠지는 것입니다.
설상가상으로, 일반적으로 QA 팀은 발견한 버그의 개수에 따라 보상을 받으므로 개발자는 방어적인 태도를 취하게 될 수 있습니다. 개발자와 QA 팀 모두가 코드의 버그 개수를 줄이는 동시에, 프로젝트 소유자가 둘 중 하나만 선택해야 하는 고통스러운 상황을 없애줄 더 좋은 방법이 있다고 생각해 보세요. 더 뛰어난 만능 소프트웨어를 만들 수 있게 될 것입니다.
애자일 및 DevOps 테스트를 만나보세요.
기존 테스트 방법에서 애자일 테스트 방법으로 전환
애자일 및 DevOps 팀의 목표는 높은 품질의 새로운 기능을 지속적으로 제공하는 것입니다. 그러나 기존의 테스트 방법론은 애자일 또는 DevOps 프레임워크에 적합하지 않습니다. 높은 개발 속도로 인해, 각 빌드의 품질을 보장하기 위해서는 새로운 접근 방식이 필요합니다. Atlassian에서는 애자일 방식으로 테스트를 진행합니다. Jira Software의 선임 QA 팀 리더인 Penny Wyatt와 함께 Atlassian의 테스트 접근 방식을 자세히 살펴보세요.
신용 카드 부채가 늘어나는 것과 마찬가지로, 기술적 부채 역시 시작할 때는 어려움이 적지만 금세 눈덩이처럼 빠르게 불어나고 팀의 중요한 애질리티를 떨어뜨립니다. 빠르게 늘어나는 기술적 부채에 맞서기 위해, Atlassian에서는 개발자들이 품질 면에서 뛰어난 챔피언이 되도록 권한을 부여합니다. Atlassian은 개발자들이 다음과 같은 주요 기술을 통해 제품의 품질을 높인다고 믿습니다.
- 개발자는 코드를 통해 문제를 잘 해결합니다.
- 테스트를 직접 작성하는 개발자는 문제가 있을 때 코드를 수정하는 데 더 많은 권한을 부여받습니다.
- 기능 요구 사항과 테스트에 미치는 영향을 이해하는 개발자는 일반적으로 더 나은 코드를 작성합니다.
Atlassian은 백로그의 각 사용자 스토리에는 기능 코드와 자동화된 테스트 코드가 모두 필요하다고 생각합니다. 테스트 팀이 자동화된 테스트를 수행하는 동안 기능 코드를 개발자에게 할당하는 팀도 있지만, Atlassian에서는 한 명의 엔지니어가 이 모든 것을 완전히 제공하는 것이 더 효과적이었습니다.
새 기능의 버그와 기존 기능의 회귀를 다르게 처리하세요. 개발 중에 버그가 발견되면 시간을 내어 실수한 부분을 파악하고, 수정하고, 다음으로 넘어가세요. 회귀는 한 번 나타나면(즉, 이전에 작동했지만 더 이상 작동하지 않는 경우) 다시 발생할 가능성이 높습니다. 향후에 이러한 회귀로부터 보호할 수 있는 자동화된 테스트를 만드세요.
이 모델은 개발자가 혼자 일한다는 뜻은 아닙니다. 팀에는 QA 엔지니어도 있어야 합니다. QA 팀은 기능의 개발에 중요한 관점을 제시하며, 훌륭한 QA 엔지니어는 버그가 일반적으로 어디에 숨어 있는지 알고 있으며 개발자에게 발생할 수 있는 의외의 문제에 대해 조언할 수 있습니다.
예비 테스트를 통한 인간적 감성
개발 팀에서 QA 팀원은 개발자와 협업하여 예비 테스트를 진행하며, 이는 개발 중에 더 심각한 버그를 막기 위한 중요한 관행입니다. 코드 검토와 마찬가지로, 이 단계 덕분에 테스트와 관련된 지식이 개발 팀 전반에서 전달되었습니다. 개발자가 더 효과적으로 테스트를 수행하면 처음부터 더 나은 코드가 제공되는 결과로 이어집니다.
예비 테스트가 수동 테스트라고 생각하시는 분들도 있을 것입니다. 아니요. 적어도 수동 회귀 테스트와 같은 의미로 사용되는 것은 아닙니다. 예비 테스트는 위험을 기반으로 한 비판적인 사고 접근 방식으로, 테스터가 위험, 구현의 세부 정보 및 고객 요구 사항에 대한 지식을 활용할 수 있도록 합니다. 테스트 프로세스 초기에 이러한 사항을 파악하면 개발자 또는 QA 엔지니어는 스크립트가 있는 테스트 사례, 자세한 테스트 계획 또는 요구 사항 없이도 이슈를 빠르고 포괄적으로 찾을 수 있습니다. 예비 테스트 세션에서 얻은 인사이트를 원래의 코드 및 자동화된 테스트에 다시 적용할 수 있기 때문에, 기존의 수동 테스트보다 훨씬 효과적이라고 생각합니다. 예비 테스트는 기능을 사용하는 경험에 대해서도 스크립트가 있는 테스트를 통해서는 알 수 없는 방식으로 가르쳐 줍니다.
품질 유지를 위해서는 예비 테스트와 자동화된 테스트를 함께 이용해야 합니다. 새로운 기능이 개발됨에 따라, 예비 테스트를 사용하면 자동화된 테스트만 사용하는 경우보다 더 넓은 의미에서 새로운 코드가 품질 표준을 충족하는지 확인할 수 있습니다. 여기에는 자동화된 테스트가 제공하는 회귀에 대한 강력한 보호 기능 외에도 사용 편의성, 만족스러운 시각적 디자인 및 기능의 전반적인 유용성이 포함됩니다.
변화하기란 아주 어려울 수 있습니다
애자일 테스트에 대한 제 여정이 잘 요약되어 있는 개인적인 일화를 알려 드리겠습니다. 저는 경력 초기에 한 엔지니어링 팀을 관리했는데, 이 팀은 자동화 테스트 작성이 "QA 팀의 일"이라고 생각하여 큰 거부감을 가지고 있었습니다. 버그가 많은 코드를 여러 차례 반복하고 자동화된 테스트로 인해 팀 속도가 느려지는 이유를 모두 들은 후, 저는 반대에도 불구하고 모든 새로운 코드는 자동화된 테스트를 통해 입증되어야 한다는 결정을 내렸습니다.
단 한 번의 반복 후에 코드가 개선되기 시작했습니다. 그리고 테스트 작성에 가장 단호하게 반대하던 개발자는 테스트가 실패했을 때 행동을 취하는 팀원인 것으로 드러났습니다. 다음 몇 차례의 반복을 통해 자동화된 테스트가 성장하고 브라우저 전반에서 확장되었으며 개발 문화가 개선되었습니다. 물론 기능을 제공하는 데는 더 오래 걸렸습니다. 하지만 버그와 반복 작업이 크게 감소하여 결국 엄청난 시간을 절약할 수 있었습니다.
변화는 쉬운 경우가 드뭅니다. 하지만 대부분의 가치 있는 것들과 마찬가지로, 본격적으로 시작하여 새로운 패턴을 만들 수 있다면 왜 더 빨리 시작하지 않았는지 스스로에게 묻게 될 것입니다.
