서비스 운영/개발팀의 가장 효율적인 QA 테스트 프로세스를 찾아서

서비스 운영/개발팀의 가장 효율적인 QA 테스트 프로세스를 찾아서

개발 후 QA 테스트를 통한 검증은 필수인 것 같다.

 

 

서비스 운영/개발팀의 QA 프로세스를 정립하는 것이 꽤 어렵고 과정이 있어 이렇게 기록하고자 합니다. 

 

 

 

QA 란?

---

Quality Assurance의 약자로 품질 보증을 말합니다. 제품 출시 이전에 각종 테스트(Test)및 검수 작업을 하는 업무 일정 수준의 품질(Quality)을 가질 수 있도록 제품 출시 이전에 각종 테스트(Test) 및 검수 작업입니다.

It 업계에서 또한 기능 개발 후 QA을 통하여 제대로 기능이 작동하는지 검증하는 시간을 필수적으로 갖게 됩니다.

 

 

 

 

개발자에게 QA 란?

---

개발자가 QA 테스트 결과를 지켜보는 것은 정말 쉽지 않다

SI/SM/솔루션/서비스 업계 상관없이 QA 테스트는 마지막 완성을 위해서 꼭 필요한 프로세스이며 정말 중요한 과정입니다. 이 과정이 없다면 불안정한 제품을 내놓을 수밖에 없지요.

 

사실 개발자에게 QA 테스트는 스트레스 중 하나인 것 같습니다. 열심히 만들어서 제출한 것들이 QA 테스트 후 쏟아지는 테스트 결과 이슈 리스트들은 마음의 상처를 피할 수 없는 것 같습니다. 분명 내부적으로 테스트를 해도 꼭 타인으로 인한 QA 테스트를 해보면 미처 발견하지 못한 혹은 예상하지 못한 이슈가 등장하게 됩니다.

 

그래도 많은 QA 테스트들을 겪다 보면 조금 익숙해진다고 생각합니다. 개발자도 인간이므로 분명 완벽하게 만들어내지는 못하다고 생각하기도 합니다. 그래서 QA 테스트 과정을 통한 프로세스는 개발 완료를 위한 피할 수 없는 필수 과정이라고 생각합니다.

 

오히려 QA 테스트를 통해 개발자가 미처 발견하지 못한 치명적인 실수를 발견하는 것이 지금 생각해 보면 훨씬 좋다고 생각합니다. 치명적인 실수를 그대로 프로덕션에 배포하게 된다면 끔찍한 일이 벌어지기 때문이죠.

 

 

 

 

 

서비스 운영/개발 프로덕트 팀의 QA 프로세스 정립 과정

---

현재 저희 프로덕트 팀은 QA 프로세스를 여러 과정들을 통해 팀에게 가장 알맞고 효율적인 프로세스를 찾아 적용시켜 더욱 기능 제품 개발에 시너지를 주었습니다.

 

과거에 항상 QA 테스트의 번거로움과 시간 낭비, 정확하지 못한 테스트로 인한 치명적인 이슈 발생 등등 여러 서비스 운영을 하는데 많은 피해를 보고 느꼈던 것 같았습니다.

 

저희 팀의 QA 테스트 프로세스 발전 연대기는

엑셀 표 -> Notion 표 -> Jira 자체 QA 기능 -> Jira 보드 +  Notion 표

 

위와 같은 과정을 겪고 마지막으로 결정한 프로세스는 <Jira 보드 + Notion 표>로 확정 짓고 매우 좋은 효과를 보게 되었습니다.

 

 

엑셀 표

처음에는 단순하게 엑셀 표로 정리하여 구글 엑셀 시트로 공유하여 개발자와 QA팀과 정보를 공유하는 프로세스였습니다.

 

초반에 고생하여 템플릿을 구축하면 명확하게 정리되는 엑셀이 좋긴 하지만 너무 가독성이 떨어지고 여러 명이 동시에 직접 포커스하고 입력 및 수정해야 하는 행위들은 실수를 유발하게 되었고 결국 중요한 테스트 결과를 지우는 등 예상치 못한 누락이 많아지게 되어 효과적이지 못하다고 생각하게 되었습니다.

 

 

Notion 표

Notion의 표는 가독성이 확실히 올라가게 되었습니다. 친근한 UI가 도움이 되었지만 엑셀과 별다를 것 없이 여러명이 직접 수정 / 반영으로 인한 실수는 많이 막을 수 없다고 생각하게 되었습니다.

 

 

 

Jira의 QAlity

결국 QA 시스템을 집중적으로 따로 지원하는 서비스 서칭하다가 현재도 사용하고 있는 Jira에 QA기능을 따로 지원하고 있다는 것을 발견하고 도입해 보았습니다.

 

QAlity라는 서비스였습니다. 확실히 명확하고 실수를 해도 기록이 잘 남아 있어 더 정확한 QA 테스트를 진행할 수 있었지만 Jira  QA 기능 자체가 너무 러닝커브도 높고 사용하기 너무 번거로웠습니다.

 

QA 테스트 하나를 생성하는데도 너무 많은 설정과 시간이 사용되어 쓰다 보면 익숙해지겠다는 한계를 넘어섰다고 생각하게 되었습니다. 웹의 기능 속도 성능 또한 체감상 많이 느렸던 것 같았습니다.

 

 

 

 

Jira 보드 +  Notion 표 -> (최종 확정)

결국 뚜렷한 프로세스를 찾지 못하여 진지하게 팀 내 전체를 회의를 통해 Jira 보드 +  Notion 표라는 조합의 QA 프로세스를 구축하게 되었습니다.

 

Jira의 QAlity가 아닌 현재도 계속 잘 사용 중인 업무 task을 쪼개서 각각의 업무 티켓을 올리고 업무 마우스 드래그 기능 하나로만 상태를 손쉽게 바꾸는 용도인 Jira 보드를 사용하였습니다.

 

 

 

각각 아래와 같은 용도로 사용했습니다.

 

Notion 표: 미리 컨벤션을 구축해 둔 QA용 노션 표에 테스트 결과 내용 입력 (구체적인 테스트 환경도 입력)
Jira 보드: QA팀은 QA 테스트 결과 이슈 task 등록 -> 개발자 task 확인 후 바로 디버깅 개발 진행 및 task 상태 변경 -> QA 팀은 계속 테스트를 진행하며 보드에 task 등록

 

위와 같은 역할을 각각 주어 Notion 표는 기록용(상태 수정 X) Jira 보드는 이슈 사항 기록용 (상태 수정 O)으로 서로의 단점을 상쇄시키는 효율적인 QA 테스트 프로세스를 정립하였습니다.

 

 

Notion 표는 수정하기에 까다로워 Notion 표 하나로만 수정하는 것은 누락과 같은 실수가 발생할 수 있으니 한 사람 혹은 특정 인물들이 한번 테스트 결과를 기록하고 나면 내용을 수정하지 못하도록 규칙을 세우면서 이러한 역할만을 Notion 표에게 부여해주었습니다.

 

Jira 보드는 Notion 표의 테스트 상태 수정 반복에 대한 실수가 발생하는 것에 대한 약점을 보안한 해결책이었습니다. 한번 Jira 보드에 등록해 둔 task는 쉽게 수정되지 않고 모듈화 되어있으며 보드에 등록한 task 티켓을 이슈 디버깅 개발 완료 후 개발자가 직접 마우스 드래그로 원하는 상태 보드 칼럼에 놓으면 끝이어서 매우 직관적이고 실수를 방지할 수 있었습니다.

 

 

두 업무 서비스를 이용하여 서로의 단점을 상쇄시키는 시너지를 발생하게 되었다.

 

 

 

 

 

마무리하며...

---

분명히 저희 팀이 구축해 둔 프로세스 말고 더 좋은 프로세스가 존재하다고 생각합니다. 더 나아가 어느 정도 규모가 있는 회사들은 QA 팀이 따로 있으니 더 확실하고 철저한 프로세스가 있을 겁니다.

 

하지만 이 작은 팀에서 효율적인 QA 테스트 프로세스를 구축해 보는 경험은 다른 문제를 직시하였을 때 많은 도움을 줄 것이라는 확신을 가지게 되었습니다.

 

특히 위 과정들의 접근 방식과 해결 도출 방법들은 미래 처음 서비스 창업하고 나서 작은 규모의 업무 프로세스를 정립할 때 많은 도움이 되지 않을까 싶습니다.

 

 

감사합니다.