2022.04.30 QA에 대한 생각

곧 2년차가 되어가는 파견 QA이다. 졸업하고 나서 조기 취업으로 QA로 일을 시작하게 되었다. 파견 QA라고는 하지만 의외로 좋은 곳들에서 일을 했다. 이름만 들으면 알만한 곳들에서 QA 경험을 쌓았다. 하지만 이젠 슬슬 놓아주려고 한다..

 

해당 글은 파견 2년차 QA가 자신의 생각만을 글로 적은 것으로 자사서비스 QA나 경력이 많은 사람들이 보기엔 부적합하다고 판단한다. 자신의 한탄글일 뿐이니 별 생각 없이 소설 한편 읽는다고 생각하며 읽어주시길.

 

1. QA로 얻은 것들

QA란, 개발이 완료된 시스템이 사용자에게 가기 바로 직전 단계에서 그 시스템이 원하는 동작을 하는지, 망가지지는 않는지 확인하는 작업이다. 아무리 개발을 잘한다고 한들 실제 사용자들은 이리 뛰고, 저리 뛴다. 시스템에 무슨 짓을 가할지 아무도 모른다. 그런 일을 사전에 예방하는 마치 의사 옆에는 간호사가 있듯. 개발자 옆에는 QA가 있다.

 

개발자들이 흔히 놓치는 이슈는 무엇이 있는지 확인할 수 있다. 시스템을 누구보다 먼저 사용해보기 때문에 접할 수 있다. 후에 개발자가 된다면 이 부분은 깊게 생각하고 설계해야겠다고 결심하게 만들어준다.

 

지금까지 많이 본 이슈는 아래와 같다.

1. 문구 => '저장하기' 문구로 나와야 하는데 'SAVE' 로 나온다거나?

2. 버튼 => 버튼이 동작하지 않는 이슈, 동작하지 않아야 하는데 동작하는 이슈 등등

3. UI => 팝업을 넘어서서 문구가 노출되는 이슈

4. 달력 => 이후~이전 날짜가 검색되는 이슈

4. 와이파이 미사용 오류 => 하얀색 화면이 계속 보여지고 있는 이슈, 꽤나 딥하고 생각할 수 있지만 조심해야한다.

 

지금 생각나는 것은 이것뿐이다. 이외에도 여러가지 이슈들이 많이 있다. 이슈들을 발견해서 개발자에게 전달하고 수정된 것을 확인하면 원하던대로 바뀐 것을 보고는 행복해했다.

 

기획서와 UI 설계서를 볼 수 있다. IT 직군이 아니라면 볼 수 없는 귀중한 자료이다. 기획서를 보면 추후 혼자 프로젝트를 설계할 때에도 기획서를 참고하면서 이런 프로젝트를 설계해보면 어떨지 생각해볼 수 있으며, 기본적인 생각을 통한 유추로 어떻게 하면 설계를 할 수 있을지 혼자 고민할 수 있어서 좋은 경험을 할 수 있다고 생각한다. 물론, 기획자들이 만든 기획서의 발 밑도 개발자들이 만드는 시스템의 발 밑도 미치지 못하겠지만.. 어디까지나 도전하는데에 귀중한 자료가 되는 점에서는 충분히 도움이 된다고 생각한다.

 

개발자와 기획자, UI 설계자와 대화를 나눌 수 있다. 실제로 일하는 사람들과 대화를 하면서 어떤 것은 개발 자체가 불가능하다는 것을 배우고 기획자를 통해 사용자가 어떤 기능을 더 선호할지 고민해보게 되며 UI 로서는 사용자에게 친근한 UI가 어떤 것인지 배울 수 있다. 또한 대화를 나누기도 하지만 서로에 대한 의견을 굽히면 안되는 일도 있어서 서로 조율하는 방법도 터득할 수 있는 시간을 가진다. 예를 들면, 어떤 기능을 쓰면 앱이 크러쉬를 일으켜 자동으로 꺼지는 현상이 발생하여 개발자는 이 기능을 만들 수 없다고 이야기하는데 기획자는 그 기능이 꼭 필요하다며 설득을 한다. 그런 이야기가 몇번 오가다 적당한 타협점을 찾아 문제를 해결한다.

 

2. QA에 대한 고찰

분명 QA는 필요한 직업이다. 사용자들이 컴플레인을 하기 전 막아줄 수 있는 역할이기 때문이다. 하지만, 정말 QA 가 필요할까? QA가 아닌 QA가 하는 일만 다른 사람한테 넘겨도 되는 일이 아닌가? 라고 QA를 하다보면 의문이 든다.

 

아무나 할 수 있는 간단한 업무, QA를 직접 구할 수 있을 대기업들도 QA는 외주 인력을 쓰며 내부 인력이라고 해봤자 QA 매니저, QA들을 관리하는 사람을 구할 뿐이니까. 이상하다고도 생각할 수 있다. 의사의 옆에 간호사가 있듯 있어야 하는 거라면서? 그치만 잘 한번 생각해보자. 의사가 간호사가 없다고 해서 자신의 일을 못할까? 아니다. 아주 작은 병원을 가면 의사만 있는 곳도 있다. 그곳에서는 의사가 간호사가 하는 일까지 하게 된다. 그렇다고 해서 간호사만큼의 지식이 없는가? 나는 의사가 간호사보다 더 지식이 풍부하다고 생각한다. 의사는 기본 6년 공부, 간호사는 짧게는 2년에서 4년 공부한다는 점에서 말이다. 간호사들이 부족하다는 이야기를 하고싶은 것은 전혀 아니다. 그럼 개발자의 옆에 QA가 없어도 되지 않을까? 아주 작은 IT 기업에서는 개발자만 존재한다. 그들은 테스트 코드와 기능 테스트를 통해 더 손쉽게 테스트를 진행한다. 시스템의 결함만 찾으면 되는 직업이라 아무나 시작할 수 있으며 경험이 많으면 더 많은 연봉을 줘야한다 생각해 기업에서는 주로 2~3년차를 더 선호한다.

 

개발자들마다 성향이 다르다. 이슈를 찾아줘서 고맙다는 사람, 이슈가 많다고 고객사에게 따지는 것이 아닌 QA에게 따지는 개발자 무리들. 이슈를 찾는 일이 QA가 하는 일인데 너무 많다고 투덜거리는 사람 한명은 반드시 있다. 시스템을 구축하는 곳에서는 더 많은 이슈를 찾아 고쳐야 추후 도움이 되니 찾아달라, 개발자는 찾지 말아달라 라 하는 곳에서는 내가 한없이 작아져 있는 모습을 보았다. 내가 하는 일을 부정 당하는 느낌이랄까?

 

늦은 퇴근 시간, 이건 일하는 곳마다, 회사 바이 회사에 대한 문제이다. 하지만 난 지금까지 일하면서 QA보다 늦게 들어가는 개발자보다 QA보다 일찍 들어가는 개발자를 더 많이 만났다. QA가 올린 이슈 해결도 안하고 집에 간다며 신기해하는 사람들도 있겠지만.. 늦은 배포, 늦은 배포에서 달라진 것은 없는지 확인하는데까지 걸리는 시간이 길다. 보통 늦은 배포를 하고나면 개발자들은 일찍이 집에 간다. 아침에 확인하고 확인된 것을 바탕으로 다시 이슈를 찾고 이슈가 해결되면 저녁에 확인해달라고 요청이 들어온다.

 

여러가지 이유를 통해 QA가 더 싫어졌다. 가능하면 빨리 벗어나고 싶을정도로. 하지만 이런 소중한 경험이 있기 때문에 개발자로 가기 위해서는 개발 코드만 잘 짜면 되는 것이 아닌 언제나 이슈를 생각하면서 개발을 해야한다는 교훈점을 얻게 되었다. 이렇게 힘들고 싫어하는 듯한 일을 계속하는 이유를 묻는다면 한가지 뿐이다. 현재 가진 것이라고는 QA에 대한 경험과 QA 자격증 뿐이라는 것. 그리고 퇴사한다고 바로 어떤 회사가 나를 데려가는 것도 아니다. 그렇다면 신중하게 무엇인가 떠날 수 있을 능력 하나를 만들어 이곳저곳에 서류를 넣어보고 깨지고 다쳐봐야겠다고 생각하였다. 취준 기간 동안 아무것도 안하는 것보단 무엇인가 일하면서 취준 기간을 보내는 것이 합리적이라고 생각했다.

 

현재 노력하는 건 아무것도 없냐고 물어보면 서운하다.

 

- 업무 : 프로젝트 리더를 종종 맡는다

- 방통대 : 4년제 학위를 위함

- 프로젝트 진행 중 : 해외대리구매 프로젝트

- 프로젝트 기약 : 건축물 구매/판매

- 코딩테스트 : 백준

- CS 지식 : 깃헙, 정리문

 

앞으로 일주일씩 일주일 안에 무엇을 했는지 일기 형식으로 적어 내려갈 생각이다. 그러지 않으면 앞으로도 한탄만 하고 노력은 안할 것 같아서.. 긴 한탄 글을 읽어주었다면 정말 고맙다고 인사드리고 싶다.