QA를 보다 효과적으로?

QA를 보다 효율적으로?

들어가는 말

QA란 서비스가 배포되기 전 사용자가 느낄 수 있는 불편함 혹은 서비스 자체에 기능적 결함등을 확인 할 수 있는 마지막 관문과 같은 역할을 합니다. 이는 서비스의 품질을 보장하고, 사용자가 안정적이고 만족스러운 경험을 할 수 있도록 하는 중요한 단계입니다. 만약 QA가 온전히 진행되지 않고 사용자가 서비스를 마주하게 된다면, 서비스에 대한 신뢰가 무너지는 최악을 맞이할지도 모릅니다. 그렇기 때문에 QA는 꼼꼼하게, 그리고 체계적으로 진행되어야 합니다. 이에 대한 고민의 결과로, QA 프로세스를 개선하기 위한 몇 가지 방안을 생각하게 되었습니다.

현재 BCSD의 QA 방식은?

각 팀(User, Campus, Business)별 QA 방식이 조금씩은 모두 다르지만 그 결은 같다고 느껴졌습니다.

각 팀원들이 특정 혹은 여러 기능에 대한 모든 경우의 수를 체크하고 실행시켜 보는 방식으로 진행하고 있습니다. 이렇게 발견한 이슈들은 모두 문서화를 통해 공유하고 핫픽스로 즉각적으로 해결하거나, 필요에 따라 후속 작업으로 처리하게 됩니다.

이러한 방식은 개별 기능에 대한 집중적인 테스트를 가능하게 한다는 점에서 이점이 있을 수 있습니다. 그러나 동시에 아쉬운 점도 존재합니다.

• 의도와 실수의 경계가 모호해 질 수 있다.
• 불필요한 리소스 소모
• 경우의 수 파악 및 문서화 과정의 실수 발생

위 문장을 조금 풀어서 예시와 함께 이야기해보려고 합니다.

1. 의도된 기능인지 개발 과정에서의 실수인지 파악하기 어렵습니다.

   기능의 동작이 상상 혹은 기획(기능 명세)과 다른 경우, 이것이 추후에 수정이 된 부분인지 오류인지를 파악하기 위해 불필요한 시간이 들어갈 것입니다. QA에 개발에 참여한 모든 인원과 함께 진행해야하지만 그러지 못할 때를 생각한다면, 해당 기능의 Issue, PR, 관련 소통 기록 등을 보며 실수인지 수정된 기획인지를 파악해야 할 것입니다.

2. 불필요한 리소스 소모

   1번에서 말한 문제점이 발생했을 경우 이를 해결하기 위해 담당자를 찾고 커뮤니케이션하는 비용이 발생할 것입니다. 이는 전체적인 서비스의 배포 기간을 딜레이 시킬수도 있으며, 불필요한 수정등을 야기할 수 있습니다.

3. 경우의 수 파악 및 문서화 과정의 실수 발생

   모든 경우의 수를 파악한다는 것은 생각보다 매우 어려운 일일 것입니다. 빼먹는 경우도 있을 것이며, 문서화 과정에서 누락되는 부분도 있을 것입니다. 여러명에서 모든 사항을 문서화 한다 하더라도 이것을 검토하고 관리하는 어떤 추가적인 리소스가 필요할 것입니다.

위와 같은 문제점을 살펴보면, 현재의 QA 방식이 완전히 효과적이지만은 않다는 것을 느낄 수 있습니다. 들어가는 말에서 이야기 했던 것 처럼 QA는 서비스가 배포 되기 전 마지막 단계로 작은 빈틈이 서비스의 신뢰도와 직결되어 있습니다. 그렇기에 모두가 더 신경을 곤두세우고 진행될 것입니다. 이런 스트레스 강도가 높은 작업을 다른 방향으로 접근하여 위와 같은 문제점을 해결할 수 있는 방식을 모색할 필요가 있다고 느꼈습니다.

인수 테스트란?

앞선 문제를 개선하기 위해 저는 “인수 테스트”라는 접근 방식을 생각해보았습니다.

인수 테스트

: 사용자가 실제 서비스를 사용하는 것 처럼 실제 사용 시나리오를 기반으로 기능을 테스트하는 방법

단순히 개별 기능의 동작을 확인하는 것을 넘어, 서비스가 전체적으로 예상대로 동작 하는지 검증하는데 중점을 둡니다. 인수테스트는 나아가 서비스 유저 저니맵을 그릴 수 있는 기회도로 작용합니다. 이를 통해 사용자의 흐름을 예측하고 그 흐름에 이상이 없는지 확인할 수 있습니다.

예를 들어

1. 유저가 회원가입을 합니다.

   1. 아이디 입력

   2. 비밀번호입력

   3. 비밀번호 재 입력

      …

2. 유저가 로그인을 합니다.

3. 메인 페이지에 도착합니다.

4. 복더방에 들어갑니다.

   …

이렇게 시나리오를 기반으로 하면, 1차적인 기능 테스트가 보다 체계적이고 순조롭게 진행 될 것입니다.

(마치 참교 교재처럼 보고 따라갈 요소가 생긴다!)

단순히 코드의 오류를 찾는 것에서 나아가, 시스템이 실제 사용자에게 제공되는 순간들을 점검할 수 있는 것이 인수 테스트의 강점입니다. 또한, 여기서 약간의 바리에이션을 준다면, 사용자가 갑작스럽게 행하는 개발자가 예상하지 못한 동작을 시나리오 초기 단계에서 큰 부담 없이 예측하고 테스트할 수 있습니다. 이로써 다양한 상황에 대한 대비도 가능해지며, 보다 안정적인 서비스 제공이 가능해질 것입니다.

인수 테스트를 BCSD에 녹인다면?

한편으로는 "이미 기획이 짜여 있는데 시나리오가 왜 필요하지? 시나리오가 현재 기획과 무엇이 다른 거지?"라는 생각이 들 수도 있습니다.

그러나 시나리오란 초기 기획이 수정되거나, 개발을 진행하면서 "이건 다음 PR에서 해야지~"하면서 놓치는 부분들을 보완할 수 있는 중요한 도구입니다. 이러한 요소들을 따로 아카이빙하고, 기획 문서에 즉시 반영할 수 있다면, 그 기획 문서 차제가 시나리오로서 완성될 수 있을 것입니다. 그러나 우리의 개발 상황 속에서 이를 체계적으로 관리하는 것은 쉽지 않을 것입니다.

그렇다면, 계속 언급하고 있는 시나리오는 “누가 어느 시점에 써야하는 것이냐!”라고 생각이 들 것입니다.

제가 생각하는 최적의 시점을 PR을 작성할 때라고 생각합니다. 실제로 개발한 내용을 가장 생생하게 기억하는 시점이기 때문입니다.(문서화에서 가장 중요한 것은 미루지 않기…)

기획된 부분에서 어디를 어떻게 개발했는지, 특이사항이 있다면 그것을 시나리오 문서에 바로 기록합니다. 이렇게 다양한 기능들의 개발 과정이 시나리오 문서에 추가되면, 실제 작업 내용을 반영한 실질적인 문서가 완성됩니다. 이 문서에는 바뀐 기획 및 특이사항이 모두 녹아들어 있을 것입니다. 결과적으로, 이 문서는 실제적인 유저 저니맵이 될 것이고, 이는 기획과 개발의 무결성을 유지시킬 수 있는 요소일 것입니다.

(이후 마케팅 용 혹은 다양한 로깅을 찍을 때나 DA 파트에서도 활용 가능 예상)

QA를 진행할 때는 이 시나리오 문서를 활용하여 스토리라인을 따라가며, 사용자가 의도된 흐름대로 서비스를 이용하는 데 문제가 없는지 확인할 수 있을 것입니다. 이후에는 다양한 사용자의 행동을 통해 엣지 케이스를 확인하고, 서비스의 견고함을 확보하는 작업을 진행할 수 있을 것입니다.

성공적인 테스트를 위해서 노력해야 하는 점?

경우의 수를 파악하고 시나리오를 작성하는 과정이 개발 기간을 지연시킨다면, 이는 오히려 테스트를 하지 않는 것만 못할 수 있습니다. 또한, 개발자가 고려하는 경우의 수가 너무 단조로워서 테스트가 충분히 효과적이지 않을 수도 있습니다.

그러나 조금 더 깊이 생각해보면, PR에 변경 사항을 걸어 코드 리뷰 시 내가 중점적으로 확인해야 할 것들을 적는 것이 중요합니다. 개발자는 기능 명세를 기반으로 작업을 진행하므로, 이 명세를 바탕으로 실제로 개발한 내용과 개발 중 발생한 변경 사항을 기록하면 됩니다. 이를 통해 시나리오에 대한 부담을 줄이며 실제 개발 내용만을 정제해 나갈 수 있을 것입니다.

하지만 모든 프로젝트에서 이러한 접근 방식이 적합하지는 않을 수 있습니다.

예를 들어:

• 수정이 잦지 않은 어드민: 어드민 페이지는 일반적으로 안정된 기능을 제공하며, 사용자 인터페이스와 상호작용이 복잡하지 않습니다. 이러한 경우, E2E(End-to-End) 테스트가 적합합니다. E2E 테스트는 사용자가 실제로 시스템을 사용하는 것처럼 전체 흐름을 시뮬레이션하여, 시스템이 처음부터 끝까지 예상대로 동작하는지 확인합니다. 어드민 페이지와 같이 큰 변화가 자주 일어나지 않는 경우, E2E 테스트를 통해 주요 기능들이 예상대로 작동하는지 검증하면 효율적입니다.
• 수정이 많은 공용 패키지나 유틸: 공용 패키지나 유틸리티는 자주 수정되며, 여러 프로젝트에서 재사용되기 때문에 안정성이 매우 중요합니다. 이러한 경우, 인수 테스트를 통해 각 기능이 명세대로 동작하는지 꼼꼼히 확인해야 합니다. 인수 테스트는 기능의 세부적인 동작을 검증하는 데 중점을 두므로, 자주 변경되면서도 신뢰성이 필요한 코드에 적합합니다.
• 유저의 흐름과 서비스의 동작 과정이 중요한 경우: 사용자가 서비스를 이용하는 전체적인 흐름이 중요한 애플리케이션에서는, E2E 테스트와 인수 테스트를 적절히 병행하여 사용합니다. E2E 테스트로 큰 그림을 검증하면서, 인수 테스트로 세부적인 기능을 확인하여 서비스의 견고함을 확보할 수 있습니다.

각 프로젝트마다 특성이 조금씩은 다릅니다. 따라서 적절한 QA및 테스트 방법을 고민하고 도입해보는 것이 보다 안정적인 서비스를 제공하기 위해서 중요할 것입니다.

마무리 말

현재 부트캠프에서 프로젝트를 진행하며, QA를 진행해야하는 순간이 있었습니다. 그러나 BCSD 개발보다 훨씬 빠르게 진행되는 일정 속에서 프로젝트 멘토님께 적절한 QA 기간에 대해 질문한 적이 있었습니다. 그때 멘토님은 QA를 특정 기간에 몰아서 하는 것이 아니라, 기능마다 QA를 진행한다고 진행해야 한다고 조언하셨습니다. 그리고 이와 관련하여 "인수 테스트"라는 개념을 언급하셨습니다.

기능마다 시나리오를 작성해 아카이빙해두고, 마지막 QA 때에는 해당 시나리오를 활용하여 미리 준비된대로 테스트를 진행하는 방향을 추천하셨습니다. 처음에는 “시나리오가 기획이랑 무엇이 다르지?“라는 생각이었지만, 해당 문장을 곱씹으며 실제 개발 상황이랑 비교해 보니 시나리오의 필요성을 느끼게 되었습니다.

기획대로 이루어지는 개발은 존재하지 않을 것입니다. (다양한 원인으로 기획이 다이어트를 하기도 살이 찌기도 하죠..^^)

다양한 개발 환경에서 적절한 문서화와 특성에 알맞는 테스트 방법이 이후 QA의 부담을 줄여줄 수 있는 한줄기의 빛일 수도 있겠다!라는 생각이 되어 글을 작성해보았습니다.

이번 기회로 지금 하고 있는 프로젝트에는 어떤 방식이 더 어울리고 효율적일지 고민해보면 좋겠습니다!