점점 빨라지는 서비스 제공 주기
최근에는 많은 서비스들이 어떤 기능에 대해 완벽하게 개발한 후 출시를 하기 보다, 몇 번의 스프린트/이터레이션으로 나누어 점진적으로 출시를 진행하고 있습니다. 고객에게 릴리즈할 기능의 크기를 잘게 쪼갠 다음에 (MVP, Minumum Valuable Product) 고객의 피드백을 보고 서비스/기능의 다음 방향성을 빠르게 결정/변경하는 방식입니다.
https://kruschecompany.com/agile-software-development/
이러다보니, 종래에 한 달 혹은 유저의 요구에 따라 그때그때 애플리케이션/프로그램의 배포를 하는(한 달 이상) 서비스와 같은, 전형적인 Water-fall 프로세스를 거치던 곳에서 위와 같은 점진적 프로세스에 따라 잦은 배포를 하는 서비스로 이동하시는 분들께서는 이직 초기에 컬쳐핏에 대해 적응하기 많이들 어려워하시는 것 같습니다.
하루에만 해도 수십회의 비정기배포와 핫픽스, 잦은 테스트 의뢰가 발생하기도하고, 특정기능을 개발하는 프로젝트에서는 잦은 요구사항의 변경이 발생합니다. 배포 후에는 로그 등을 확인하고 다음 기능의 일정을 준비하는데, 이 이터레이션 간의 기간이 짧아 테스트 준비활동에 대해 타이트하게 느끼시는 분들도 계십니다. 혼자서 안건 하나만 담당하면 양반이고, 여러 안건을 동시에 준비해야할 경우도 있습니다.
이러한 경우에서, QA엔지니어를 포함한 테스트 담당자들은 어떻게 대응해야할까요?
테스트 방법의 전략적 접근
테스트를 해야하긴 하지만, 무조건적으로 모든 요구사항에 대해 충족하고, 버그가 정말 0인지아닌지를 식별하기위해 대량의 테스트케이스를 작성하고 많은 테스트 수행 기간을 할당받을 수는 없습니다. 리소스는 제한되어있고 모든 케이스들을 확인할 수 없기 때문에, 테스트 수행 시에 좀 더 전략적으로 접근해야할 필요가 있습니다.
1. 요구사항 검사 (Inspect requirement)
Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money.
일단 기능의 요구사항을 검사 합니다. 품질관점에서 품질에 영향을 끼칠만한 요소는 없는지 확인합니다.
- 개발자가 개발할 때에 모호한 표현은 없는지
- 기존 기능과 신규 기능에 대해 상호모순적인 요구사항은 없는지
- 명확하지 않은 기댓값이 있는지
등, 개발자가 개발을 진행할 때 버그가 생길만한 요소가 없을지를 체크해야만 합니다.
안건은 작은 MVP로 자주 반복될 것이므로, 제일 이상적인 것은 안건의 시작 (Kick-off) 타이밍에서부터 테스트담당자가 안건에 같이 합류하여 요구사항이 빌드업되는 과정에 같이 참여하며 체크하는 것입니다.
이 때, 정해진 기간 내에 완성할 수 있는 요구사항의 크기인지도 같이 체크가 되어야합니다. 반복적으로 제공될 기능이긴 하지만, 그 때 그 때의 요구사항의 크기가 정해진 일정 내에서 일정 수준의 품질을 제공하기는 어려운 수준의 많은 요구사항을 담고 있을 수 있습니다.
해당 스프린트에 고객에게 제공될 기능의 크기가 커지는 것을 경계해야만 합니다.
기능이 커지면 커질수록 테스트하기도 어려워집니다.
2. 요구사항에 대한 인식 조정 (Align understanding of requirement)
다음으로, 요구사항에 대해, 이해관계자들 간에 동일한 인식을 가지고 있는지 끊임없이 확인해야합니다. 어떠한 A라는 기능에 대해, 이해관계자들 간 서로의 이해가 다르면 제대로 된 서비스가 만들어질리가 없고, 이것은 버그를 야기하는 원인이 되기도합니다.
(버그가 많으면 많을수록 버그를 수정하거나, 어떻게해야할지 논의하는 과정에서 불필요한 리소스가 소모됨)
테스트 담당자의 입장에서 이해관계자들의 인식을 확인하고, 통일하는 방법으로는 몇가지가 있습니다.
질문하기
테스트 담당자는 테스트를 설계하고, 테스트케이스를 작성해야합니다. 이 때, 필요한 정보에 대해 프로덕트 디자이너, 기획자 등에게 질문을 하고, 이에 대한 답변을 개발자를 포함한 이해관계자들에게 공유함으로써 인식을 맞추도록 유도할 수 있습니다.
테스트케이스에 대해 공유하고 피드백 받기
요구사항에 대해 궁금한 점 없이, 빠르게 테스트케이스를 설계하고 작성을 다 할 수도 있을 것 입니다. 이 때, 작성한 테스트케이스에 대해 이해관계자들에게 공유하고 피드백을 받음으로써 상호 잘못 이해하고 있는 요구사항에 대해 찾아낼 수 있을 것입니다.
이 방법은 특히 개발자와 테스트 담당자에게 유용한 방법인데, 개발자는 테스트케이스를 확인하고 본인이 개발하고 있는 방향이 맞는지 체크해볼 수 있고, 개발자 본인이 느끼기에 잘못된 케이스가 있다면 이것을 테스트 담당자에게 묻고, 테스트 담당자가 다시 이해관계자들에게 확인하는 방향으로 인식을 맞추어볼 수 있습니다.
테스트 담당자도 본인이 작성한 테스트케이스에 대해 피드백을 받음으로써, 본인이 잘못 인식하고 있던 요구사항에 대해 인지하게 되고, 테스트케이스를 수정할 수 있게 됩니다.
3. 테스트케이스를 좀 더 적게 설계하고 작성하기 (Design and create less testcase)
당연하게도, 짧은 간격으로 반복적인 배포를 하는 서비스라면 테스트를 수행할 기간도 그만큼 타이트할 것입니다. 테스트케이스의 갯수를 줄일 수 있어야합니다. 일부러 적게 만들어라 이것이 아니라, 좀 더 효율적인 테스트케이스 설계방법 을 통해, 테스트케이스의 양을 적절한 양이 되도록 조정해야합니다.
이 때 여러 테스트케이스 설계기법(명세기반, 구조기반, 경험기반 설계기법) 들을 통해, 서비스에서 크리티컬한 이슈를 발생시킬만한 부분을 도출해낼 수 있도록 케이스를 작성해야합니다.
또한 앞서 말씀드렸듯 모든 테스트케이스를 작성하고 수행할 수는 없으므로, 기능의 핵심 요구사항(MVP)에 대해서 우선순위와 중요도에 따라 테스트가 설계되어야하며 수행하지 않는 케이스들에서 이슈가 발생할 수 있다는 점을 인지하고, 이해관계자들과도 어느정도 인식이 맞추어저야합니다.
테스트케이스뿐만이 아닙니다. 서비스를 제공하는 환경(OS, 단말기 등)도 가능하면 통계에 기반하여 유저가 제일 많이 사용하는 환경으로만 한정하는 것도 하나의 방법일 것 입니다. 예를들어 500개의 테스트케이스가 있는데, 2개버전의 OS를 커버해야한다면 단순하게 계산해도 1000개의 테스트케이스를 수행해야하는 것입니다.
iOS는 16만 확인하고, 안드로이드OS는 13만 확인하고.. 하위 OS에서 발생하는 이슈는 다음 버전에서 대응한다던지.. 이런식으로 확인해야하는 환경도 적절히 조정합니다.
4. 이슈에 대해 대화하기 (Communicate about issue)
테스트 수행 중에 확인되는 이슈들에 대해 이해관계자들과 계속해서 커뮤니케이션을 진행합니다. 정해진 일정 내에 모든 이슈들가 수정이 되지 않았으므로 테스트 기간을 무조건 연장해야할 필요는 없고, 모든 이슈를 전부 수정해야할 필요도 없습니다. 이슈의 중요도에 따라 수정 우선순위를 설정하고, 마이너한 이슈 혹은 유저에게 큰 영향이 없는 이슈라면 다음 이터레이션에서의 대응을 결정해야합니다. (점진적 대응)
이러한 결정에 대해 테스트 담당자가 결정할 수도 있겠으나, 이슈의 내용에 따라서는 이해관계자들간의 합의로 결정되어야합니다.
5. 다 같이 테스트하기 (Test together)
테스트 담당자가 테스트케이스에 대해 수행을 완료했더라도, 버그가 없다는 것을 보장할 수 없습니다. 이 때 제한된 테스트 담당자의 리소스 이상으로 테스트를 수행해야한다면, 프로젝트의 이해관계자 전체가 모두 테스트를 해볼 수도 있을 것입니다.
방법은 여러가지가 있을 것 입니다. 간단하게 개밥먹기(Dog-fooding) 형식으로 조작해볼 수 있고, 시간을 정해놓고 ad-hoc테스트, 더 나아가 테스트 차터를 작성하여 테스트 참가자들에게 목적을 할당하고 수행하는 탐색적 테스팅을 수행해볼 수 있을 것입니다.
이러한 경우라면 정해진 테스트케이스 이외에도 엣지케이스에서밖에 확인할 수 없는 이슈라던지, 더 나아가 사용성에 대해서도 이슈는 없는지 검토해볼 수 있을 것입니다.
6. 작성한 테스트케이스들을 정제하여 회귀테스트케이스에 추가하기 (Refine regression testsuite)
이번 이터레이션에 작성한 테스트케이스들에 대해, 회귀테스트 스위트(테스트케이스 세트)에 추가합니다. 이터레이션은 어떠한 기능에 대해 점진적으로 개발해나갑니다. 따라서 다음 이터레이션에서 이전 이터레이션에 개발한 기능도 제대로 동작되어야합니다.
이 때, 이슈를 찾아낼 수 있었던 케이스들 위주로 추려내어 회귀테스트케이스에 추가합니다.
7. 회귀테스트를 자동화하기 (Automate regression test)
이터레이션이 쌓이고 쌓이면 자연스럽게 각 이터레이션마다 수행해야할 회귀 테스트케이스의 갯수가 늘어나게됩니다. 이렇게 되면 해당 이터레이션의 테스트케이스 수행 리소스보다, 기능 전체의 회귀 테스트케이스 수행 리소스가 더 커지는 경우도 생길 수 있습니다.
이럴때 수행 리소스를 줄이기 위해 회귀테스트를 자동화할 수 있습니다. 그러나 회귀테스트는 자동화하는 시점부터 막대한 리소스가 필요하므로,
- 어떤 케이스에 대해 자동화를 해야할지?
- 중요도 대비 자동화 코스트가 낮은 케이스는 어떤 것인지?
- 자동화를 했을 때의 절약할 수 있는 코스트가 가장 높은 케이스는 어떤 것인지?
를 면밀히 따지고 자동화를 진행해야합니다.
더욱 중요한건 조직의 분위기와 테스트 담당자의 Mindset
중요한 것은 조직에서 이슈를 바라보는 분위기일 것입니다. 잦고 빠른 배포주기를 가진 조직이라면, 그만큼 어느정도 이슈에 대해서는 관대한 분위기가 형성되어야합니다. 완벽한 프로덕트/기능을 제공하기보다, 좀 더 빠르게 기능을 제공하고 완성해나간다는 분위기라면, 이슈에 대해서도 어느정도 너그러운 조직일 것입니다.
많은 테스트담당자들이 프로덕션환경에서 이슈가 발생하면 스트레스를 많이 받고는 하는데요, 담당자들도 이러한 조직분위기에 맞추어 테스트에서 확인할 수 없었던 이슈들에 대해 좀 더 너그러운 마음가짐을 가져야할 것 입니다.
만일 배포 후 이슈가 발생했다면,
- 해당 이슈가 왜 발생했는지
- 해당 이슈를 테스트를 수행하면서 확인할 수 있는 방법은 없었는지
- 향후 재발방지를 위한 방법
등을 이해관계자들과의 회고를 통해 대화를 해야할 것 입니다.
ref.
정보에 감사드립니다.