개요
중요한 QA 조치가 누락된 소프트웨어 프로젝트에 참여한 적이 있으신가요? 그것은 여러분만의 경험은 아닙니다. 놀라울 정도로 많은 기업과 프로젝트에서 이런 일이 발생합니다. 모두가 QA라는 것이 존재하고 이를 수행해야 한다는 것을 알고 있지만, 모든 노력은 보통 출시 직전 큰 QA 스프린트로 귀결됩니다. 이런 부하가 큰 작업으로 인해 소프트웨어를 간신히 작동하게 만듭니다. 물론 이런 혼란은 다음 릴리즈 주기에서도 반복됩니다. 개선은 없죠.
대학에서 가르치는 것
문제는 컴퓨터 공학을 공부한다고 해서 소프트웨어 품질 기준을 보장하는 방법을 배우지 못한다는 점입니다. 대부분의 시간은 알고리즘, 컴퓨터 작동 방식, 일부 언어의 개념과 역사 등을 배우는 데 소비됩니다. 또한, 적어도 제가 공부할 때는 프로젝트 관리 접근 방식과 스크럼에 관한 한 학기가 있었습니다. 이 모든 것은 훌륭했지만, QA는 완전히 빠져 있었습니다. QA를 소홀히 한다는 점은 매우 아쉬운 일입니다. 왜냐하면, 전체 학생의 90% 이상이 졸업 후에 회사에서 일하기 때문입니다. 졸업자들은 버그 없는 소프트웨어를 제때 전달해야 하는 능력이 필요합니다.
회사가 어떻게 간신히 시간에 맞춰 서비스를 제공하는지에 대해
예산상의 이유로 프로젝트에서 가장 먼저 사라지는 것이 바로 QA 기준과 조치입니다. 이런 경우는 수없이 많이 보셨을 겁니다. 프로젝트 막바지에 계획하는 경우가 많지만, 개발이 더 오래 걸리거나(실제로 자주 발생하고) 범위가 늘어나면(이는 항상 발생하죠) 더 이상 QA를 할 시간이 부족해집니다. 결국 최소한의 비정형(unstructured) 테스트만 수행하고 금방이라도 바람 불면 무너질 것 같은 집과 같은 서비스를 출시합니다.
일부 회사나 팀에는 특정 QA 표준이 마련되어 있습니다. 일반적으로 팀의 선임 멤버가 나머지 팀원들에게 이런 기준을 적용하는 경우가 많습니다. 아마도 그들은 QA가 없으면 모든 것이 훨씬 더 어려워진다는 사실을 뼈저리게 깨달았기 때문일 것입니다. 안타깝게도 표준을 마련하는 것만으로는 충분하지 않습니다. 팀에서 단순히 프로젝트 관리 지표를 충족하기 위해 테스트를 작성하는 경우가 종종 있기 때문이죠.
어떻게 이 쳇바퀴에서 빠져나올까요?
프로젝트에서 누락된 QA 조치에 대해 말할 수 있는 경험과 자신감을 쌓는데 수년이 걸렸습니다. 관리자와 논쟁하고 릴리즈에 쫓기며, 프로덕션 시스템 장애를 처리하고, 모니터링이 누락된 부분을 찾아야 했죠. 네, 이는 재밌는 일은 아닙니다. 예를 들어 리팩터링과 같이 관리자가 직접 볼 수 없는 코드 베이스나 프로젝트의 다른 개선 사항도 상황은 비슷합니다. 하지만, QA는 특히 어려웠습니다. 왜냐하면 아무런 조치를 취하지 않으면 제대로 하는 방법조차 배우지 못하기 때문입니다.
“유닛 테스트는 통과했지만, 통합 테스트는 하지 않았을 때”
목소리를 내고 토론을 반복해서 제기하는 것 만이 이 쳇바퀴를 벗어나는 첫걸음을 찾는 데 도움이 될 것입니다.
돈에 대해 이야기하세요
어느 순간 저도 올바른 기준을 사용하지 않고 있다는 것을 깨달았습니다. 소프트웨어가 ‘더 안정적’이거나 ‘유지보수가 훨씬 쉬워질 것’이라고 설명하는 것은 코드베이스에 대해 작업하지 않는 사람에게는 별로 와닿지 않습니다. 우리는 돈에 대해 이야기해야 합니다. 개발자로서 우리는 QA를 수행하지 않았을 때의 비용에 대해 이야기해야 합니다. 이것이 일반적으로 비즈니스와 관리자의 언어입니다. 저는 항상 이런 예시를 들어 QA 조치를 설명하려고 노력합니다. ‘지금 하지 않으면 4개월 안에 개발 노력과 비용이 15% 증가할 것입니다.’ 또는 ‘모든 기능에 대해 단위 테스트를 구현하지 않으면 릴리즈 안정화 단계가 매번 더 오래 걸릴 것입니다. 매번 모든 사이드 이펙트를 수동으로 테스트해야 하므로 우리가 구축하는 모든 부분에 대해 직접적으로 검증해야 합니다. 이렇게 하면 릴리즈 할 때마다 더 오래 걸리게 될 것입니다.’ 라고요.
제 경험상, 이런 전환은 포인트를 효과적으로 전달하는데 도움이 될 것입니다. 결국, 이런 노력이 모든 사람의 삶을 더 좋게 만들어 줄 겁니다. 아직 모든 사람이 이것에 대해 알지 못하지만요.
최소 유효 용량
현실적으로 보면, 초기 투자 비용이 큰 QA 조치를 과도하게 설계해서도 안 됩니다. 전체 프로젝트 진행을 저해해서는 안되고 이런 접근 방식으로는 이해관계자들의 동의를 얻을 수도 없습니다. 저는 항상 앱의 가장 중요한 부분만 확인하는 것이 좋다고 생각합니다. 일반적으로 전체 앱이 기반이 되는 특정 사용 사례, 기능 또는 무언가가 있습니다. 소프트웨어가 고객에게 가치를 제공하기 위해 반드시 정확하게 작동해야 하는 핵심 기능이 그에 해당합니다. 이 부분을 테스트하고 항상 예상대로 작동하도록 하는 방법과 조치를 생각해 내세요.
저는 ‘최소 유효 용량(Minimal Effective Dose, MED)’이라는 용어를 좋아합니다. 원하는 결과를 만들어내는 가장 작은 용량입니다. QA에서 이것은 파이프라인에서 수동 테스트 계획, 파이프라인에서의 자동화된 테스트 또는 다른 것일 수 있습니다. 이 부분이 시작하기에 적합한 지점입니다. 핵심 기능이 확보되면 점차 안정성을 확장할 수 있습니다. 예를 들어, 새로운 기능을 추가할 때마다 단위 테스트를 추가합니다. 또한, 외부 API 또는 사용자 입력과 같은 제어할 수 없는 정보 출처에 대해서도 생각해 보세요. 이런 것들이 오용으로 인해 소프트웨어가 충돌할 수 있는 더 명백한 상황에 해당하므로 이런 것들을 검증하는 방법도 찾아보세요. 반복하고 점점 더 하세요. QA에서도 마찬가지 입니다.
주의 깊게 보는 것들
새로운 프로젝트를 시작하거나 참여할 때마다 저는 QA 컨셉을 살펴봅니다. 아무리 서비스가 작아도 팀은 이에 대해 고민해야 합니다.
- 무엇을 출시하나요?
- 그것이 제대로 작동하는지 확인해야 하나요?
- 어떻게 그 작업을 할까요?
- 의도적으로 제외하는 조치와 그 이유는 무엇인가요?
이런 점에 대한 문서화, 특히 테스트 계획 작성은 소프트웨어 개발의 훌륭한 기반을 마련해줍니다. 팀이 어떻게 프로젝트를 진행할지 생각했다는 점도 보여주죠. 이것도 역시 MED 관점에서 생각하는 것입니다. 또한, 이런 접근 방식을 분기에 한번처럼 정기적으로 검토하는 것이 좋습니다.
새 코드를 작성할 때 TDD를 사용하지는 않지만, 소프트웨어를 작성할 때 테스트를 작성하는 것은 강력히 권장합니다. 지금이 바로 테스트를 작성하기 적절한 시기입니다. 기능을 구현하면서 테스트를 작성하면 코드가 실제로 테스트할 수 있는 방식으로 구조화되어야 한다는 이점이 있습니다. 기존 소프트웨어에 대한 테스트를 작성하면 종종 주어진 코드가 너무 상호 의존적이거나 단일 책임 원칙을 위반했음을 알 수 있습니다. 테스트를 통해 원하는 동작을 이해하고 모든 것이 예상대로 작동하는지 확인할 수 있습니다. 코드 자체의 문서라고 볼 수 있습니다.
프로젝트 이점
팀 내에서 목소리를 내면 주변 사람들은 당신이 프로젝트를 중요하게 생각한다는 것을 깨닫게 될 것입니다. 품질에 대한 토론을 시작하고 가능한 해결책을 제안하는 것은 개발자로서 영향력을 넓혀줄 수 있습니다. 이는 프로젝트뿐만 아니라 개인적으로도 이익을 가져올 수 있습니다. 개발자와 관리자 모두 삶의 질이 향상되며, 이런 부분은 확실히 주목받을 것입니다.
건강한 속도로 프로젝트를 성장시키기 위해서는 QA 조치가 필수적입니다.
더 나은 프로젝트를 위한 변화
프로젝트에서 이미 QA 조치를 사용하시나요? 아니면 모든 것이 매우 취약한 상태인가요? 개발자 기술을 확장하고 고품질 소프트웨어를 작성하는 것으로 인정받고 싶은가요?
작게 시작하세요. 프로젝트의 MED에 대해 생각해 보세요. 주인의식을 갖고 팀에서 더 나은 방향으로 변화시킬 수 있는 목소리를 내세요. 모든 사람이 QA 홍보대사가 될 필요는 없지만, 솔선수범하여 주변 사람들에게 필요한 접근 방식을 알려줄 수 있습니다. 토론을 촉발하세요.
Just do it.
Flo 올림.
