QA의 포트폴리오는 과연 무엇일까?

안녕하세요. 다들 잘 지내시나요?

 

QA 컨퍼런스를 마치고 나서, 그동안 제가 품어왔던 QA에 대한 고민들을 하나씩 정리해보고 있습니다.

‘정리’라기보다는, 늘 마음속에 있던 생각들을 글로 꺼내어 보는 작은 시도에 가깝습니다.

 

오늘은 QA직군에서 많이 이야기하는 '포트폴리오'에 대한 고민을 이야기해보려 합니다.

이 글은 어디까지나 제 개인적인 생각과 경험을 바탕으로 정리한 내용이니 가볍게 참고해 주시면 감사하겠습니다!

 

# 왜 포트폴리오가 고민일까?

비둘기야 니 머선 고민 있나..

사실 저는 ‘포트폴리오’라는 단어를 들으면 가장 먼저 디자인 직군이 떠오릅니다.

명확한 산출물이 있고, 그 결과물 자체로 무엇을 그리고자 했는지 자연스럽게 드러나는 구조가 인상적이었기 때문입니다.

 

제품 개발자의 포트폴리오 역시 비슷한 맥락으로 이해해 왔습니다. 무엇을 만들었고 어떤 기능을 구현했는지가 눈에 보이니까요.

하지만 제가 생각한 QA는 조금 다르게 느껴졌습니다.

 

QA 직군의 대표적인 포트폴리오는 아마도 '테스트 케이스(Test Case, TC)'일 겁니다.

요즘은 자동화 테스트가 많아졌지만 제가 처음 이 고민을 시작했을 당시엔 TC가 중심이었어요

 

그런데 곰곰히 생각해 보니 이런 생각이 들었습니다. “테스트 케이스만으로 포트폴리오가 될 수 있을까?”

 

게다가 대부분의 회사에서는 TC가 회사 자산이기 때문에 외부에 가져갈 수조차 없습니다.

그리고 테스트 케이스라는 것이 본질적으로 ‘제품을 테스트하기 위한 문서’이다 보니

제3자 입장에서 이해하기 어려운 내용이 많을 수 있다는 점도 고민이었습니다.

 

예를 들어 우리 팀에서만 사용하는 언어나 용어가 TC 안에 들어가 있다면

다른 회사 사람들이 그 문서만 보고 전반적인 QA 역량을 파악하기는 어렵지 않을까? 하는 걱정이 있었던 것이죠

---

# 그럼 시중에 있는 제품들로 TC를 작성하면 되잖아

네 그것도 충분히 좋은 방법이라고 생각합니다. 하지만 저는 공개된 제품을 대상으로 테스트 케이스를 작성할 때도 고민이 참 많았어요

 

예를 들어 네이버라는 대중적인 서비스를 선택해서 포트폴리오용 TC를 작성한다고 한다면

결국에는 ‘로그인’, ‘검색’처럼 이미 많은 사람이 알고 있는 기초적인 기능을 중심으로 테스트를 구성하게 될 것 같은데

 

이때 고민이 생겼습니다. “이런 너무 익숙한 기능들을 테스트 케이스로 만들었을 때, 내가 보여주고 싶은 QA 역량이 잘 드러날까?”

 

단순히 TC를 만드는 행위만으로는 내 포트폴리오가 어떤 관점으로 만들어졌고, 어떤 가치를 전달하고 싶은지 설명하기 어렵겠다는 생각이 들었었습니다.

 

결국 이렇게 만든 포트폴리오가 “조금 평범하고, 경쟁력이 약한 건 아닐까?” 하는 의문이 생기더라고..

---

# 내가 보여주고 싶었던 것

그래서 저는 단순히 테스트 케이스를 작성하는 것이 아닌, “왜 이렇게 작성했는지”, “어떤 관점으로 바라봤는지” 함께 보여주고 싶었습니다.

 

그렇게 하기 위해서는 기획 문서와 같은 참고 자료가 있거나 상대방이 제가 테스트한 제품에 대한 이해가 어느 정도는 있어야

제 TC의 의도와 구조를 제대로 전달할 수 있다고 생각했습니다.

 

그러던 중 제가 기획 관련 도서인 《현업 기획자 도그냥이 알려주는 서비스 기획 스쿨》 을 읽게 되었고

그 안에서 소개된 ‘역기획’이라는 방법에 큰 영감을 받았습니다.

 

그래서 저는 이 ‘역기획’ 방법을 QA 포트폴리오에 적용해 보자는 생각으로

저만의 포트폴리오 계획을 시작하게 되었습니다.

 

도그냥의 ‘역기획’을 간략하게 설명하자면 이미 완성된 서비스를 문제 해결의 관점에서 거꾸로 분석해

비즈니스 전략과 UX 의도를 추론해보는 학습 방식입니다.

 

(이 개념이 흥미롭다면, ‘도그냥 역기획’으로 구글에 검색해 보시면 더 자세한 정보를 볼 수 있어요! 😊)

https://groschool.kr/category/business/post/reverse-planning

혼자 서비스 기획을 공부하는 방법

 

---

# 그래서 어떻게 할 것인가?

그래 해보자!

우선 저는 제가 평소에 자주 사용하던 제품들 중에서 눈에 띄거나 궁금했던 ‘작은 기능’ 하나를 선택하고 그 기능이 왜 만들어졌는지 어떤 문제를 해결하고자 했는지를 저만의 관점으로 분석해 보기로 했습니다.

 

단순히 눈에 보이는 기능 명세를 정리하는 것이 아닌 그 안에 담긴 제품의 의도 그리고 비즈니스 목적까지도

역으로 추측해 보는 방식입니다.

 

이렇게 해서 제가 분석한 내용을 바탕으로 기능 명세서, 그리고 그에 맞는 테스트 시나리오와 테스트 케이스 작성

더 나아가 자동화 테스트 코드까지도 작성해 보는 것입니다.

 

이 과정을 통해 “저는 이 기능을 이렇게 이해했고, 그래서 이런 테스트 전략을 세웠습니다.”

라는 메시지를 자연스럽게 담아내고 싶었어요.

 

단순한 TC의 나열이 아니라 내가 어떤 시선으로 제품을 해석하고 그 결과를 어떻게 테스트 전략으로 풀어냈는지까지 보여줄 수 있다면

비로소 나만의 색이 담긴 QA 포트폴리오가 되지 않을까 생각합니다.

 

# 그래서 하고 싶은 말은?

다들 힘냅시다!

저 역시 지금도 포트폴리오에 대한 고민과 어려움을 안고 있습니다. 그리고 지금 제가 떠올린 방식이 꼭 정답이라고 생각하지도 않습니다.

 

하지만 저는 '일단 해보자' 마인드와 함께 남들과는 다른 나만의 시선과 방식을 무기로 삼아 포트폴리오를 하나씩 만들어가고 싶다는 생각을 하게 되었습니다.

 

이런 과정을 통해 나만의 무기를 만들어 간다면 언젠가는 좋은 동료들과 함께 일할 수 있는 기회도 자연스럽게 찾아오지 않을까

그런 기대와 마음으로 오늘 이 글을 정리해 보았습니다.

 

피드백은 언제나 감사합니다! 🙇‍♂️