동민이집

갑자기 회사에서 2023년도 1분기/상반기 KPI를 적어서 제출하라고 하네,, 다른 부서들은 수치상으로 보여줄만한 것들이 많을텐데 QA는 이슈 줄이는 것 말고는 마땅히 적을게 없어서 자격증 취득과 파이썬 개발 공부하기로 적어냈다. 아무튼 그래서 앞으로 한달은 공부해야 되는 이 개발조무사의 운명ㅠ.. ISTQB 모바일에 대해서 따로 출판되는 문제집은 없고, 기존 ISTQB에 모바일 도메인 특성을 결합한 형태의 문제를 자주 낸다고 하더라. 아무튼 나 상반기에 ISTQB-MAT 자격증 취득해야하는 상당한 부담감 느끼고 있는 중,, 회사 생활 쉽지않다. 정말 ㅎ..

사실상 말이 소프트웨어 테스팅의 기초지, 은근 헷갈리는 문제 많고 까다로운 섹터 같음. 아래부터는 혼잣말에 가까울 수 있다주의.. 그,, 메모하면서 해야 (그나마) 기억 잘하는 친구들 있잖아,, 그게 나라는 말쑴..

아래 문제는 그냥 문배(문제로 배우는 소프트웨어 테스팅II) 풀면서 혼자 메모한거..

1) 소프트웨어 품질 >

품질 뭐,, 실생활에서는 별 생각 안하고 쓰는 뜻이긴 하나 QA 입장에서 엣헴,, 품질이라 함은,, 명시된 요구사항을 충족 시키는 정도가 되겠다. 요건 실무에서도 많이 느끼긴 하는데 아무튼 명세, 즉 기획서에 대한 커버리지 충족이 주 타겟이 되는 느낌으로다가 접근한달까..? 기획서 상으로는 뭔가 이상하다 싶어서 문의 정도는 해 볼 수 있겠지만, (e.g. 1+1 =3으로 나와있는데요?) 그걸 내가 오류 또는 결함이라고 단정지을 수 없다는거다. 왜냐면 QA에서 명시하는 품질 자체가 명세 기반이기 때문(e.g. 그거 기획의도인데요?하면 할 말 없다이거야..) + 사용자 또는 고객의 필요와 기대를 충족시키는 것도 품질의 범주에 포함된다.

2) 오류, 결함, 장애 >

이것도 진짜 지독히 나오는 단어 중 하나 같은데, 보통 사람들은 그냥 별 생각없이 부르는 말을 여기서는 확실하게 정리하고 가야한다.

오류는 일단 실수랑 같은 말이고, 굳이 해석하자면 잘못된 결과를 낳는 인간의 행위가 되겠다. 뭐,, 개발자가 코딩을 하던 중, 원래 한 번 입력해야 할 p를 두 번 입력하였다. 정도?

결함은,, 친구가 많다. 흔히들 얘기하는 버그, 결함, 결점 모두 같은 말이다. 요건 오류로부터 시작되고 그로 인해 요구된 기능을 적절히 처리하지 못하는 것? 정도가 된다. p를 두 번 입력하여 pp로 코딩되었을 때 실행문이 실행되지 않는 것. 정도가 결함의 범주에 포함된다.

마지막 끝판왕은 역시 결함이다: 결함은 장애라고도 불리는데 아무튼 모시깽이 저렇게해서 결국 최종적으로 발생하는 현상을 일컫는다. 실행문이 실행되지 않아 크래시(crash)가 발생, 또는 버튼을 눌러도 실행되지 않음. 정도가 된다. 진짜 헷갈리는데 자주 나오니 꼭 기억할 것. (물론 나 자신에게 하는 말)

3) 테스팅 종료 조건 > 

테스팅 종료 조건 요건 실무랑 동일한 것 같다. 근데 약간 말장난 때문에 헷갈리긴 하는데 배포(또는 릴리즈) 준비가 완료될 시점이 종료 시점이 된다. 대고객 서비스 오픈했을 때 문제가 되는 부분이 있는지 확인하는 절차. 흠,, '고객들이에게 오픈할 때 문제되는 부분이 있는지' << 이 부분 실무자로써 약간 말,, 할 말이 많긴 한데 참아야지,, 읍읍..

4) QA가 소스코드를 볼 수 있다고? >

개발자들의 소스코드(Source Code)도 QA가 산출물 리뷰를 해줄 수 있다고 하네,, 졸 충격적;; 이건 월요일에 출근해서 개발자들한테 물어봐야겠다.. "멈뭄미 개발자님,, 제가 소스코드를 보고 산출물 리뷰 해줄 수 있는 부분이 있나요? QA책에서는 가능하다던데요..?" ㅎ.. 결코 내가 틀린 문제라 웅엥거리는게 아니야..

5. 효과성과 효율성 >

QA에서 말하는 효과성과 효율성에 대해 늘 헷갈린다. 그래서 효과는 커버리지 개념으로 접근했고 효율은 시간적인 개념으로 접근했다. 이게 맞나? 싶은데,, 혹시 잘못 알고 있다면 천재 QA님들께서는 과감히 댓글 달아주심 고마울 것 같아요.. 그러니까 효과성은 시간이나 가용 리소스보다는 실제 얼마 많은 양을 커버하고 오류를 줄이는데 목적을 둔 테스팅이고, 효율성은 시간이나 인력 등의 리소스에 조금 더 치중한 테스트 방법론이라고 이해하고 있음.

- 효과 > 계획했던 것을 얼마나 목적대로 창출하는지? 

- 효율 > 우웅,, 계획도 중요하긴 한데,, 상황에 맞춰 리소스 배치도 중요해;

7. 테스팅의 목적 > 

테스팅의 목적은 뭐 이런저런 이유 다 가져다가 붙일 수 있는 것 같음. 근데 헷갈리게 '~의 원인 식별' 과 같은 것들이 붙기도 하는데, 대부분 원인들은 우리 QA들이 찾는다기보다는 개발자분들이 찾아주시는 경우가 많다. 물론 재현스탭이야 우리가 찾아 개발자에게 전달해주는건 맞지만, 원론적으로는 어떤 이유나 요인(factor)을 찾는게 '원인을 찾는' 행위에 포함되기 때문에 원인은 개발자들이 찾아줘야 함 ㅎ.. 

10. 확인 테스팅과 리그레션 테스팅 > 

우선 리그레션 테스트는 실무에서 정-말 많이 쓰이는 테스트 중 하나다. 말 그대로 a라는 이슈를 수정하면서 다른 영역에 사이드 이펙트가 발생하지 않았는지를 체크하는 일종의 요약테스트? 정도다. 실제 일하면서 어 여길 수정했는데 왜 저기서 이슈가 발생하지? 라는 생각을 참 많이 하고 또 겪는데, 그래서 리그레션 테스트는 QA들에게는 선택이 아닌 필수로 진행하는 테스트 중 하나다.

확인 테스트는 얼핏 들으면 느낌은 리그레션 테스트와 비슷한데,, 전체적으로 테스트하는게 아닌, 수정된 영역을 다시 재확인하는 테스트라고 보면 된다. 위 예시에 비유하자면 '수정된 a이슈를 재확인하는 절차' 정도로 해석할 수 있을 것 같다. 이거 매일하는건데 말이지,,

11. 테스팅의 일곱가지 원리 > 

이거 무슨 일곱가지 죄악도 아니고 잊을만 하면 등장하는 내용인데, 사실 십계명마냥 줄줄이김밥 외울 필요는 없다. STEN이 주관하는 ISTQB 시험은 객관식으로 출제되는 문제인만큼 '~ 케이스는 요거에 속한다.' 정도만 알고 있음 될듯. 헷갈릴 것도 없고,,

1. 테스팅은 결함이 존재함을 밝히는 활동

2. 완벽한 테스팅은 불가능

3. 개발 초기에 테스팅

4. 결함은 집중 

5. 살충제 패러독스

6. 테스트는 정황에 의존적

7. 오류-부재의 궤변

2345는 한 번에 이해가 되는데, 1,6,7은 뭔소린가 싶기도 하다. 6번 정황에 의존적은 코난도 아니고 뭔데 정황에 의존한다는거지,, ㅎ.. 1번은 결함이 발견되지 않았더라도 해당 소프트웨어에 결함이 없다고는 할 수 없다.라는 의미로 해석하면 되고,, (사실상 2번과 비슷한 느낌) 6번은 테스트 방법은 테스트 주체에 따라 다른 방법론으로 접근할 수 있다는 말이다. 뭐 은행 소프트웨어와 게임 소프트웨어를 같은 테스트 방법론으로 접근할 필요는 없지. 마지막 7번은 개발된 프로그램이나 소프트웨어를 사용자가 찾지 않는다면 결함을 찾는 행위 또한 필요하지 않다. 라는 말. 생각해보면 내가 만든 앱이든 뭐든 쓰는 사람 아무도 없으면 뭐하러 QA를 하겠너,,

16. 완벽한 테스팅이 불가능한 이유 > 

무한경로, 무한타이밍(순서), 무한입력값 때문. 대충 비슷한 말 같은데 특히 타이밍은 실무에서 진짜 많이 체감한다. 아무튼 무한도전도 아니고 요 3가지 때문에 완벽한 테스팅이 불가능하다고 함

17. 살충제 패러독스

살충제 패러독스. 살충제의 역설 정도일려나. 그러니까 bug를 잡기위해 testcase라는 살충제를 도입했는데, 같은 살충제를 계속 사용하다보니 bug들이 면역이 생겨 더 이상 잡히지 않는다. 정도로 해석할 수 있을듯. 그래서 testcase는 가급적 재사용하지 않아야하고(확인 범위가 과거와 동일하다면 사용해도 됨) 추가 테스트 및 확장된 영역의 테스트 시에는 수정하여 사용해야 한다는 의미다. 하지만 현실에서 강한 살충제 뿌리면 벌레들도 내성 강해져서 잘 안죽던데,, 자강두천 같은 뭐 그런 느낌이야뭐야,,

18. 테스트 프로세스(짱짱 중요...)

이 부분 정말 헷갈려 죽어ㅠ.. 하지만 제대로 안외우면 시험 때마다 항상 나와서 당연히 먹고 들어가줘야 할 점수 다 놓치게 됨. 일단 순서 외우는 것부터 ...

1. 계획과 제어

2. 분석 및 설계

3. 구현 및 실행

4. 완료 조건 평가 및 리포팅

5. 테스트 마감 활동

사실 계획과 제어는 순서도 상으로 1번에 위치하지만 테스트 마감 활동까지 전반에 걸쳐 수행되는 친구들이다. 그래서 계획과 제어아래 2>3>4>5 순으로 테스트가 진행된다고 보면 될듯. 어휴 이 내용 다시 생각만 해도 너무 숨막히는 부분.. 요건 다음 편에 적어야지..

목표없이 한 해를 보내곤 했었는데, 이번년도에는 그래도 목표를 세워보려고 한다. 개인적인 목표부터 업무 관련 목표까지 나름 세워봤는데 여기 쓸 수 있는거라곤 업무적인 목표밖에 없는 듯? 그.래.서 상반기엔 모바일 앱 테스팅 자격증 취득을 목표로 도전해보기로 했다.

사실 작년에 한 번 준비했었는데, 야근을 밥 먹듯 하는 나로써는 업무와 같이 병행하기가 너무 힘들었다. 응 핑계 ISTQB처럼 1주일만 공부하고도 쉽게 취득할 수 있을 줄 알았는데, 역시 ISTQB 특유의 사람 헷갈리게 하는 문제 방식에 된통 당해버려 고작 반타작했다는..

상반기라 2023-02-21, 2023-05-23, 총 두번 시험을 볼 수 있을 것 같은데 제발 한 번에 붙었으면 좋겠다. 내가 지금껏 취득한 금융자격증은 afpk를 제외하고 커트라인이 60점이었는데, STEN에서 주관하는 ISTQB는 커트라인이 65점이라 은근 까다로웠다. 실제로 처음 ISTQB시험 봤을 때 25점 받아, 1점 차이로 불합격한 기억이 있지...

다수의 금융관련 자격증을 취득해본 내가 STEN의 자격증 시험을 더 어렵게 느끼는 이유는, 무엇보다 시험 관련 교재가 명확하게 정해져있지 않다는 점이 가장 큰 것 같다. 기껏해봤자 '문제로 배우는 소프트웨어 테스팅'(이하 문배)와 STEN에서 제공하는 실라버스 몇 장이 전부니까. 다른 시험의 경우, 과거 기출되었던 문제들을 모아 문제은행식으로 제공하기도 하는데 ISTQB 관련 문제 유출을 엄격히 금지하고 있어 문제의 풀(pool) 또한 매우 적어 무작정 많은 문제를 풀어볼 수도 없다.

- 공부 방법

<계획은 ISTQB 취득 때와 동일하게 진행할 예정>

1. 개발자도 알아야할 소프트웨어 테스팅 실무 정독

ISTQB 시험을 두 번 본 결과, 기본에 대한 이해와 개념을 묻는 질문이 생각보다 많이 나왔다. 다른 분들은 문제로 배우는 소프트웨어 테스팅(이하 문배)를 먼저 풀면서 개념을 잡는 분들도 계시던데, 나는 그것보다는 이론으로 먼저 개념을 이해하는게 더 잘 이해되는 것 같더라. 절반 정도는 간단하게 풀 수 있지만 65점 당락을 결정짓는 문제를 풀기 위해선 어느정도 개념에 대한 이해가 반드시 필요한 것 같다. 개알을 먼저 보든, 문배를 먼저 보든 그건 응시자 마음이겠지만, 뭐가 됐든 간에 단순 암기 외에 문제에 대한 개념 이해도 반드시 필요하다는 것.

2. 문제로 배우는 소프트웨어 테스팅 정독 및 풀이

개념에 대한 이해가 어느 정도 완료되었으면 이제 문제를 풀면서 개념을 적용하여 답을 구하는 과정이다. 학창 시절 공부를 썩 잘하진 못해서 이런 글을 쓰는 것 자체가 굉장히 어색하지만,, ISTQB 공부는 아무튼 이런 식으로 했다. 이 시험은 기출문제가 없기 때문에, 문배로라도 문제를 많이 접하면서 익숙해지는 과정이 필요한듯.. 오답 시에는 왜 틀렸는지에 대한 이해도 반드시 필요

3. 실라버스 풀이 및 이해

마지막은 STEN에서 공식적으로 제공하는 실라버스 문제 풀이다. 문배와 비슷하나 포맷이 실제 시험 포맷과 비슷하고, 시험에 출제된 적이 있는 문제로 구성되어있다는 것이 그 차이점이다. 개인적으로 실라버스 문제를 많이 올려주었음 하는데 무슨 이유에서인지 그렇게 많이 업로드해주지 않는다. ISTQB는 그나마 실라버스라도 많은데 MAT는 실라버스도 몇 개 없어서 공부하기가 여간 힘든게 아니다.

책 구매는 완료했고, 시험까지는 한 달 정도 남았다. 한 달 정도 제대로 공부하면 취득하기 어려울 것 같진 않은데, 중요한건 회사 일을 하면서 동시에 공부도 할 시간을 확보할 수 있을지 고민이다. 뭐든지 적어가면서 해야 머리 속에 잘 남는다고, 공부하면서 배운 것 중 QA가 알아두면 좋을 내용, 혹은 팁 같은건 요 카테고리에 추가해두어야지. 그럼 2023년도 진짜 화이팅이야ㅠ

참고. STEN에서 주관하는 모든 시험은 아래 공식 홈페이지에서 모두 조회할 수 있다.

+ 책 구매 완료.. 시험 비용은 143,000원인데 이번 달도 빡세게 돈 모아야겠구나,,

새회사로 이직도 하고 어느덧 1년이 지났다. 전 회사는 중소기업이었어서 혼자 근무했기 때문에,, 비교할 사람도 없고 나 하나만 잘 했으면 됐는데, 대기업으로 이직하고 나니, 팀원도 북적북적해지고 나와 비교할 수 있는 주체들도 생기고 혼자서도 참 생각이 많아졌다. 그 내용에 대해 짤막(?)하게 적어보려고 한다. 최근 근무하면서 느낀 점도 더불어서 말이다. 몇 명이나 이 비루한 글 을 볼지 모르겠지만,, 준비하시는 분이 참고할 수 있으면 좋겠고, 현직에 계시는 분이면 많이들 공감해주셨으면 하는 바람.

1. 가장 중요한 연봉

연봉에 대해서는 이전 포스팅에서도 몇 번 고민해봤는데, 연봉은 확실히 다른 직군에 대해 적은 것 같다. 아니 '적은 것 같다' 가 아니고 적다. 이 부분은 QA 현직자로 근무하시는 분들이면 크게 공감하실듯한데, 정말 눈물이 날 따름이다ㅠ 정말 바쁜 것으로 치면 둘째가라면 서러운 부서인데,,  가끔 잘 모르시는 분들이 QA를 IT 및 개발직군으로 오해하셔서 연봉을 엄청 많이 받을 것이라고 예상하시던데,, IT는 맞지만, 당연히 비개발 직군으로 분류되고 처우도 마찬가지다. 

* QA직군 아예 모르시는 분들은 Q&A 묻고 답해주는 상담원인줄 알고 계시는 분들도 간혹 있음ㅋㅋ 우리 부모님이 실제로 그랬지..

생산직에서도 마찬가지로 QA와 비슷한 QC가 있긴 한데, 생산직에서의 QC와 연봉이 비슷하지 않을까? 라는 생각이 든다. 이건 내가 지레짐작으로 넘겨짚는건 아니고, 내가 실제로 과거 충북 음성 소재의 한 화장품 회사에서 지류 구매 직무로 3개월간 근무했기 때문에 잘 안다.

* 물론 QA, QC 통틀어 가장 높은 연봉은 의약계 QC가 아닐까라는 생각이,,

이야기가 조금 샜는데, 아무튼 QA로써 연봉은 기대하지 않는게 좋을 것 같다. 개인적인 생각으로는 본인이 향후 중소기업에 QA직군으로 입사할 예정이라면,, 나는 입사를 권유하지 않을 것 같다. 어느정도 깜냥이 된다면 조금 더 노력해서 대기업으로의 시작을 추천,,

현재QA 연봉 테이블이 얼마일지는 잘 모르겠지만, 업계평균을 어느정도 아는 나로써는,, 중소기업부터 신입으로 시작하기엔 원천 올리기 너무 힘들 것을 잘 안다. 중소기업 게임QA 3년으로 시작해봐서 잘 안다. 2016년 기준 QA연봉 초봉이 2,200만원이었으니 말 다 했지.  경력이 중요하다고 생각해서 입사하더라도, 최소 경력년수만 채우고 이직을 추천한다. 별 생각 없을지 몰라도 나중에 몇 년 지나 시간이 흘러서 보면 중견/대기업으로 시작한 다른 동년배들보다 연봉이 훨씬 낮을 것이다. 보통 연봉 앞자리부터 다르니까 말이다.  

2. 워라벨, 야근 등등

이건 정말 회사마다 다르다고 보는게 맞을 것 같다. 나는 중소기업에서 근무한 적도 있고, 현재는 대기업에서 근무하고 있어서 좀 더 많은 경험을 해본 토대로 써보자면, 다른 직군 대비 많은 편인 것 같다. 중소기업이었을 때와 현재 대기업에서의 야근하는 이유가 조금씩 다르긴한데, 아무튼 많은 편임. 물론 현재 회사는 최대한 야근을 지양하고 있지만, 그게 말처럼 쉬운게 아니다.

중소기업에 다녔을 때는 QA가 혼자였어서 그냥 절대적인 일 자체가 많았다. 개발자는 5명인데, QA는 나 혼자밖에 없다보니 절대적으로 들어오는 QA요청 자체가 많았던 편. 그러다보니 업무시간 내내 일해도, 할 일이 많이 남아있어서 자체적으로 남아 야근을 했었다. (야근수당은 물론 없었고..) 정해진 기일 내에 QA 확인 끝내서 배포할 수 있었으니까. 지금 생각해보면 혼자서 그렇게 많은 일을 어떻게 했나 싶기도 하고. 약간 이렇게 빡세게 일했던게 나에게 긍정적으로 작용했던걸까..

대기업은 조금 환경이 달랐다. 우선 팀원이 여러 명이기 때문에 혼자서 해내야 할 절대적인 양이 엄청 많은건 아니었다.(최근 그렇게 되어가고 있긴 하지만..) 다만 스프린트 단위로 진행이 되기 때문에 짧은 시간 내에 QA를 끝내야 하는 상황이 잦다. 또 개발 > 개발완료 > QA요청 > QA완료 등 체계도 더 복잡해졌기 때문에 그에 대한 처리 공수도 드는 편이고. (그리고 이슈가 워낙 많다보니 통계/관리으로도 리소스가 필요..)

그러다보니 개발과정을 기다리면서 대기하는 시간이 이전에 비해 다소 증가했다. 중소기업에는 개발완료된 QA요청은 항상 수북히 쌓여있었기 때문에 이런 고민은 없었는데, 아무튼 이래저래 야근은 많은 편인 것 같다. 근데 또 주변 다른 QA분들 보면 정말 야근이 아예 없으신 분들도 계시더라,, 물론 거의 멸종상태.. 야근은 회사 특성이나 회사 분위기에 따라 다를 것 같지만, QA는 상대적으로 야근이 많은 직무라고 생각함.

3.  자기계발 & 자동화 QA에 대한 고민

업계에서 가장 내로라하는 QA분들과 같이 일하고 있는데, 이렇게 좋은 팀원들과 함께 일하다보니 한 편으로는 나 자신에 대한 채찍질도 하게 되는 장점(?)이 있다. 게임QA(3년) > 증권QA(3년) > 핀테크QA(1년~) 회사로 이직하면서 나름대로 S/W적으로도 공부를 많이 했다고 생각했는데, 이 곳에 와보니 정말 나는 비교도 안될 정도로 domain 지식으로 가득차신 분들로 넘쳐나는걸 느꼈다. 솔직히 같이 일하기 죄송스럽다는 생각이 들 때도 있을 정도였으니까.

개발 영역도 새로운 개발언어가 나오고 발전이 있듯이 QA 영역도 마찬가지다. 새로운 QA 방법은 계속해서 발전하고, 그 중 하나가 지금 내가 관심 갖고 공부하고 싶은 자동화 영역이다. 요즘 새로 지원하는 사람들은 보통 열에 아홉은 자동화 QA를 할 줄 아는 것 같았다. 내가 그들보다 좋은 아웃풋을 내기 위해선 적어도 내가 그들이 할 줄 아는 것만큼은 할 수 있어야 된다는 생각이 들더라. 그래서 안드로이등 스튜디오 설치 및 환경 갖추고, 셀레니움으로 하나둘씩 독학하고 있는데 정말 쉽지 않더라. (앱피움도 있는 것 같던데, 나와는 안맞더라..) 그나마 가장 허들이 낮다는 파이썬으로 시작 중인데, 아무래도 문과 경제학과 나와서 업무병행하며 다시 옹알이 수준으로 시작하려니 이래저래 수월치 않다. 열심히 노력해서 큐발자가 되는게 소박한 내 꿈,,

하지만 끊임없이 노력해서 현재 회사까지 올라온만큼, 나는 할 수 있을 것이라는 자신감 또한 있다. 우습지만 지금까지 목적으로 두었던 것들 대부분 성취했고, 앞으로도 그럴 생각이니까. 혹자는 회사의 노예가 되려고 안달이구나. 라고 말하며 폄하하지만, 회사와 별개로 그냥 내 목적을 이루고 싶다는 생각이 가장 크다. 나도 그렇고 QA쪽에서 롱런하고 발전하고 싶으면 자동화에 대한 자기계발은 필수일 것 같음.  

4. 향후 QA에 대한 미래?

이건 뭐 비단 QA영역에 한정된 고민은 아닐 것 같다. 인간이 했던 많은 일들을 기계가 대신하고 있다. 가장 크게 영향을 받은 업종은 서비스업종인데, 대부분의 가게에만 봐도 과거 일했던 종업원 수를 줄이고 키오스크를 설치하여 그 자리를 대체하고 있다. 한 때는 인간 일자리를 기계가 뺐는다고 질타를 받기도 했지만, 최저임금이 시간당 9천원을 넘어가면서, 이젠 그 누구도 그런 소리를 하지 않는다.

QA는 조금 다를까? 사람들마다 견해가 조금씩 다를 수 있다고 본다. 일단 QA의 전망이 밝다고 말하는 사람들은 결국 모든 서비스는 고품질화를 목표로 하기 때문에, 상품 안정성을 높일 수 있는 QA의 수요는 늘어날 것이고, 그에 따라 처우도 좋아질 것이다. 라는게 그들의 주요 논지다. 맞는 말이기도 하다. 지금 업계에서 잘 나가는 몇몇 앱이나 사이트만 봐도 그저그런 웹/앱에 비해 오류도 확연히 적고 뭔가 잘 다듬어진 느낌을 받는다. 결국 서비스의 안정성과 고품질화를 목표인 회사에서는 그만큼의 처우를 주고서라도 고급QA를 채용할거고, 그에 따라 연봉 테이블은 높아질 수 있을 것이다.

반면, 어둡게 전망하는 사람들도 있다. 몇몇 회사는 실제 지금 QA자동화를 통해 기존 QA 혹은 테스터들이 하던 단순 업무들을 대신 처리하고 있다. 무형의 소프트웨어는 처우를 개선해달라고 요청하지도 않고 지치지도 않는다. 결국 위 서비스업의 일부처럼 자동화된 컴퓨터가 일부 QA의 일자리를 뺏을 수도 있다고 보는 견해다. 얼마나 걸릴지는 모르겠지만,, 난 이 의견 또한 동의한다. 다만 이런 경우 자동화QA를 통제하고 컨트롤 하는 QA관리 직군이 대유행할듯 싶지만. 향후 전망이 좋을지, 나쁠지 확실치 않지만 당신이 생각하는 미래는 어떨지 궁금함.

5. 이 길을 시작하려는 사람들에게 하고 싶은 말

QA를 시작하려는 분들 중에는 관련 전공자도 있을 것이며, 나처럼 전혀 관련도 없는 전공자들이신 분들도 있을 것 같다. 또 QA라는 직종을 이미 알고 관심있게 지켜본 분도 계실 것이고, 그냥 채용 공고에 뽑는다고 해서 찾아보고 알아가는 과정이신 분들도 있을 것이다. 뭐 물론 다른 직종에서 이직하려고 하시는 분들도 계실 것 같고.

하고 싶은 말은 정말 많지만, 하고 싶은 말을 줄여 말하자면,, 대충 한 번 해볼까? 하고 시작하려면 시작하지 말아주세요. 정도다. 솔직히 내가 처음 QA에 발을 들였던 2010년대 중반만 해도 잘 알려지지 않은 업종이여서 전문 인력도 많이 없었던 시기라 소위 말하는 '이 정도' 만 해도 일 잘한다. 라는 소리를 들을 수 있었지만, 이젠 아니다. 계속해서 노력하지 않으면 언젠가 더 나은 지식을 가진 새로운 사람들에게 의해 추월 당할 것이기 때문. (일 자체도 반복되는 일이 많고 드라마틱하게 시각적으로 보이는게 없는 일이라 아주 지겹게 느껴질 수도..)

시작하겠다면 단단히 맘 먹고 시작하길 추천한다. 위에 써놓은대로 야근은 야근대로 많을 수 있고 처우 자체도 굉장히 좋은 편도 아니며, 사회적으로 QA가 무슨 일 하는지도 모르는 사람들이 대부분이다. 미래도 밝다고 장담할 수 없는 부분이고. 하지만 본인이 단단히 맘 먹고 시작한다면, 이 분야에서 손 꼽히는 사람이 될 수 있다고 생각한다. 나도 현재 그 목표를 이루지 못한 상태에서 이런 글을 적고 있는게 우습긴 하지만, 나는 나름대로 칼을 갈며 계속 공 들이고 있다. 언젠간 그 꿈을 반드시 이룰 수 있을 것이라고 생각하면서.

찾다찾다 정말 안나와서 속 시원하게 내가 올림 ㅠ

아이폰 개발자 모드 켜는 방법은 정말정말 쉽다 ㅋㅋ...

- 설정 >  개인정보 보호 및 보안 > 보안 > 개발자 모드 ON

근데 쉬우면 뭐하나..?  대부분 이 개발자 모드 옵션 자체가 보이지 않을 것이다.

왜냐하면 이 기능은 Apple Developer에 등록된 디바이스에서만 사용할 수 있기 때문. 나같은 경우는 개발자는 아니지만,, QA로써 구글 파이어베이스나, 테스트플라이트를 사용하는 회사차원의 등록된 테스트 디바이스를 사용하기 때문에 요 기능을 이용할 수 있다. 아마 대부분의 일반인들이 사용하는 아이폰에서는 이 기능을 이용할 수 없다..!! 구글 같은 경우는 개발자 모드 들어가기 참 쉬운데,, 애플은 애초에 이 기능을 아무나 이용할 수 없게 해둔 것 같다. 아무래도 내 생각엔 보안 때문인 것 같음.. 뭐 아이폰의 장점일 수도 있겠군..

이직 후 슬슬 적응도 됐고,, 주말도 됐고,, 간만에 티스토리 포스팅을 해보려고 한다. 뭐 그래봣자 별 내용은 아니고, 이번 회사로 이직하면서 가장 많이 느낀 부분 중 하나를 풀어보려고 하는데, 머리 한 켠에 늘 생각만 해두고, 고민해보지 않았던 영역 중 하나인 '과연 QA도 코딩을 할 수 있어야 할까?'에 대한 부분(그리고 나머지 하나는 자동화에 대한 부분이다..)

올해 6월, 3년간 근무했던 개발회사에서 이름 들으면 거의 다 알만한 핀테크 업계의 중견급 회사로 이직했다. 이직 성공이라는 기쁨도 잠시, 큰 시련이 들이닥쳤다. 이전에는 회사 내 QA가 나혼자였기 때문에 내가 방식대로 근무할 수 있었지만 이직한 회사는 규모도 크고 팀원도 있기 때문에 내가 하고 싶은대로 할 수 없었고, 무엇보다 COVID-19로 인해 제한적인 출근, 새로운 프로세스를 익혀야하는 이직자들에게는 너무나 끔찍한 환경이었다. 이제와 돌이켜 생각해보면 입사 후, 새 환경에 익숙해지기 참 힘들었는데, (아무튼 잘 적응한 나에게 칭찬 한 번,, 물론 많이 깨지기도 깨졌..)

다시 본론으로 돌아와서, 물음에 대한 해답을 내놓자면 '코딩을 꼭 할 줄 알아야하는건 아니지만, 할 줄 알면 좋다.' 정도인 것 같다. 물론 현재 일하는 회사의 프로세스와 구조에 따라겠지만, 결국 상위 티어의 회사로 이직할 수록 어느 정도의 개발언어를 배워두는게 좋은 것 같다. 물론 개인적인 생각.

처음 입사한 게임사의 QA는 개발언어 공부 및 코딩 필요성을 전혀 느끼지 못했다. 애초에 QA라는 직무를 수행하기 위해서 관련 학과를 전공해야하는 것도 아니기 때문이다. 이후 두 세번의 이직을 하여 지금 회사까지 왔는데, 이 곳의 QA는 디버깅은 물론, 스크립트 테스트 자동화에 대한 것들도 준비하고 있기 때문에 간단한 스크립트 구조 하나 작성하지 못하는 나에게는 너무 힘든 환경. 물론 이직한 회사도 QA에게 있어 코딩이 필수는 아니지만, 거의 다 할 줄 알더라..라는 내용. istqb 자격증 하나 있어서 그것 하나 믿었는데, 그건 기본이고 정보처리기사 자격증에 it자격증 취득하신 분들도 수두룩,, (난,,? 침울..)

특히 테스팅의 끝판왕인 자동화 영역으로 들어서는 순간 코딩은 정말 필수 소양이 되는 것 같다. 늦은 시기이긴 하지만, 그래도 파이썬 코딩 배워보기 위해 인터넷강의도 바쁜 시간 쪼개 청강중이다. 비전공자라 그런지, 아니면 내가 감이 없는지 인터넷 강의 보면서 그대로 받아적기만 하면되는데도 실수하고 진도가 잘 안나간다.. 그래도 천천히 배워봐야지.

TE의 주요 직무가 테스팅이기 때문에 실제로 코딩이나 개발을 실무 자체에 많이 할 일은 없다. 따라서 굳이 배울 필요는 없지만, 본인이 큰 물에서 놀고 싶다면 배워두면 좋고, 배워두면 새로운 콘텐츠에 일원으로 참여하기 용이한건 사실이다. 나만 보더라도 자동화에 정말 많은 관심이 있는데, 코딩 하나 할 줄 모르니 뭐 하나도 할 수가 없다. 

점점 큰 물로 갈 수록 사람들의 능력이 고스펙화되는걸 느끼는데 이런 현실에 난,, 뭘 했는지 ㅎㅎ.. 참 많이 와닿는다.

세줄 합격 후기

이미 ISTQB 합격 후기가 워낙 많다보니, 이 포스팅이 무슨 소용이 있나 싶은데, 일단 그래도 정말 공부할 시간이 없었던 것에 비해 합격한만큼 시험 팁이나 공부 방법에 대해 귀띔해주려고 한다. 비전공(본인은 경제학과 출신임)출신도 일주일 정도 빡세게 공부하면 충분히 취득할 수 있는 자격증이니만큼 시험 기간 일주일 전이라고 포기하지 않도록 하자. 

ISTQB CTFL 시험 준비 기간

공부기간은 정확히 일주일 정도인듯. 회사 다니면서 쉬는시간에 틈틈이 공부하고, 출퇴근 시간에 아이패드로 모의고사 문제 풀고, 저녁에 매장 끝나고 밤 10시부터 12시까지 약 2시간 독서실에서 공부하고, 좀 짬을 많이 냈던 것 같다. 하루에 4시간 정도씩 6일 정도 공부했으니 순수 공부시간은 약 25시간 내외다. 솔직히 일주일 공부한게 자랑은 아니지만, 그래도 공부에 투입한 시간 대비 합격 통보를 받았으니, 나로써는 만족이다. 불합격이었다면 세상 끔찍했을듯.

ISTQB CTFL 시험 비용

시험비용은 16만원 + 부가세 16,000원하여 총 176,000원이다. 아무래도 국가공인자격증이다 보니, 시험 비용이 진짜 저세상급인데, 뭐 대체할 수 있는 QA 자격증이 많은 것도 아니고 해서 그냥 결제했다. ISTQB 한국버전인 KSTQB도 있는데 KSTQB의 경우 시험 응시료가 훨씬 저렴한 것으로 알고 있다. 돈 아까우면 해당 KSTQB 자격증 취득도 괜찮아보임.

*본인의 경우도 역시 KSTQB를 시험을 보고 싶었지만, 아직까지 대외자격증으로 알려져있는 것은 ISTQB가 훨씬 더 유명하기 때문에 눈물을 머금고 몇 만원이나 더 비싼 ISTQB 자격시험을 치뤘다. (시험 문제와 난이도는 거의 비슷하다고 한다.)

ISTQB CTFL 준비물

준비물은 신분증과 펜(유성펜 or 컴퓨터용 사인펜)만 있으면 된다. 시계는 일반 시계만 가능하다. 애플워치나 갤럭시 워치같은 디지털 시계는 불가능하다. 나도 갤럭시워치 차고 시험 보려고했는데, 제거해달라고 하더라. 대신 40분전, 20분전, 10분전에 감독관이 남는 시간을 알려주기 때문에 시험시간에 그렇게 신경쓰지 않아도 된다. 신분증은 주민등록증과 운전면허증, 여권만 사용할 수 있으며 스마트폰을 통한 본인인증 및 등록증 조회는 어렵다고 하니 참고 바람.

ISTQB CTFL 공부 참고물

ISTQB 시험 공부 하시는 분들 모두 마찬가지겠지만, 총 3건의 참고서로 공부한다고 한다. ①개발자도 알아야할 소프트웨어 테스팅 실무. ②문제로 배우는 소프트웨어 테스팅. ③ STEN에서 제공하는 실라버스 ISTQB 기출 모의고사 문제집이다.

① 개발자도 알아야 할 소프트웨어 테스팅 실무, 줄여서 개알은 책을 구매해서 공부했다. 이 책에 있는 내용이 그대로 시험에서 나온다고 보면 될 정도로 책의 내용도 방대하고 비전공자의 경우 이해하기 어려운 내용도 꽤 많다. 단어도 비슷비슷한 것들이 많아 무작정 암기하기도 어렵다. 때문에 나처럼 시간이 많지 않다면 핵심 요점만 정리하고 이해하고 암기할 수 있도록 한다. 100점 만점 중 65점만 득점(26개/40개)하면 합격하는 시험이기 때문에 굳이 모든 문제를 다 맞추고 이해해야 할 필요가 없다. 배점도 없는터라 전략적으로 확실히 이해할 수 있는 부분만 명쾌하게 이해하고 넘기자.

② 문제로 배우는 소프트웨어 테스팅, 줄여서 문배의 경우 개알보다 더 도움이 되었다. 직접 문제로 시험과 관련된 내용을 풀어보면서 이해되지 않는 부분에 대해 명확하게 인지할 수 있었고, 무엇보다 해답에 대한 설명이 아주 자세히 나와있어서 오답노트 작성에도 정말 크게 도움이 됐다. 각 챕터별 문항수가 배치되어있어서 챕터 문제를 읽어보고 답을 맞춰봤는데, 그 과정에서 더 암기하는데 큰 도움이 되었던 것 같다. 오답노트 작성은 필수인듯. 

③ 마지막으로 STEN 공식 홈페이지에 게재되어있는 실라버스 문제풀이다. 이 실라버스 문제풀이는 꼭 풀어봐야한다! 꼭! 시험에 기출되었던 문제를 그대로 다시 풀어보는 것이기 때문에 실라버스 문제를 풀어본다는건 매우 중요한 것 같다. 본인의 경우 약 3회에 해당하는 기출문제를 3번~4번 정도 되풀어봤는데, 실제 시험에서 매우 비슷한 유형의 문제가 출제되어 쉽게 문제를 풀어 나갔던 기억이 난다. 개인적으로 1, 2번 보다도 마지막 3번인 실라버스가 진짜 중요한듯.

ISTQB CTFL 공부 팁

위에 간단하게 언급했지만, 이 문제는 100점에 가깝게 문제를 맞춰야하는 시험이 아니다. 100점 만점 중 65점, 문항수로 26개 이상만 득점하면 합격하는 시험이다. 한 마디로 모든 문제를 다 맞춰야 할 필요가 없다는 소리다. 본인의 경우 챕터 5, 6, 7에 있는 테스트 방법론에 대한 문제는 정말 잘 이해했으나, 앞 부분에 있는 테스트의 이론적인 부분을 묻는 문제는 정말 너무 어려웠다. 아마도 비전공 + 제대로 자리잡지 못한 개념 등의 총체적 난국 때문인 것 같은데 아무튼 그 때문에 앞(1,2,3챕터)부분에서 어려운 부분은 과감히 포기해버리는 배제 방법을 택했다. (물론 기초를 묻는 아주 쉬운 문제의 경우에는 맞춰주어야 함...)  

문항 수도 오지선다형이 아닌 사지선다형이기 때문에 찍기만 해도 정답일 확률이 무려 25%나 된다. 그래서 커트라인이 60점이 아닌 65점일 수도 있지만,  아무튼 본인이 공부할 시간이 부족하다면 이 점만 기억해두자. 이해되지 않는 것은 과감히 넘길 줄 알되, 이해하기 쉽거나, 본인에게 잘 맞는 파트는 빡세게 암기하여 높은 점수를 취득해야 한다는 것. 본인의 경우 뒷부분 문항 (30번부터 40번)은 거의 막힘없이 술술 풀렸던 기억이 난다. 물론 앞장은 별표 천지였지만.

ISTQB CTFL 난이도

난이도 자체는 크게 어렵지 않는 것 같다. 몇몇 문제는 거져 주는 문제도 있다. 가령 '도덕적인 행위'와 관련있는 것처럼, 한 눈에 보기에도 답이 아닌 것 같은 문제들 말이다. 반면 어려운 문제는 정말 어렵다. 60분에 40문제면 한 문제당 1분 30초 정도만에 풀어야한다는 결론이 나오는데 문제를 읽고 이해하는데만 그 이상 걸릴 것 같았다. 본인의 경우 그런 문제는 과감히 포기하거나 나중에 읽기로 하고 뒤로 넘겨버렸다. 

한 마디로 정리하자면 쉬운 문제는 아주 쉽고, 어려운 문제는 아주 어려운 문제다. 물론 내가 어렵다고 생각한 문제도 기초가 튼튼하거나 개념이 잘 잡혀있다면 아주 쉬운 문제겠지만, ISTQB 시험 성격상 정답이 애매모호한 문제가 정말 많다. 이런 애매모호한 문제는 주로 문제의 물음에 답이 있으므로, 애매한 경우 문제의 지문을 다시 읽어보는 것도 좋다. 금융자격증과 굳이 비교해보면 아마도 펀드투자상담사(펀드투자권유대행인)과 비슷한 것 같다.

ISTQB CTFL 실용성

많은 사람들이 ISTQB 자격증은 실용성이 없다고 한다. 몇몇 유투버는 있으나마나한 자격증이라고 소개하기도 하던데, QA업계에 5년간 몸 담아본 나로써는 대충 어떤 의미인지는 알 것 같다. 실무적인 내용보다는 주로 이론적인 내용이 담겨있고, 이런 이론적인 내용이 주로 실무를 해야하는 QA 엔지니어와 어느정도 괴리감이 느껴지긴 했다.

당장 모듈 받아서 테스트케이스 작성하고 이런 일련의 테스트 활동이 주로 현실의 내가 회사에서 해야할 일이라면, 이 자격증은 이론, 방법론, 구조에 대해 설명하고 있기 때문에 실무적인 부분에서 퀄리티업을 기대했다면 그 기대에 조금 못미칠 것 같다는 생각. 그래도 내가 정말 테스트 리더(팀장 급)로 성장하고 큰 판을 짜야하는 위치에 올라가게 된다면 그때쯤 되면 필수 자격증이 될 것 같다. 언제까지 숲이 아닌 좁은 나무들만을 바라볼 위치는 아니니까. 

또 QA 자격증 자체가 금융자격증처럼 많지 않기 때문에 ISTQB 자격증을 가지고 있다는건 꽤나 취직/이직 시 좋은 자격요건이 된다. 자격증이 막 어렵고 취득하기 까다롭다기보다 QA에 대한 관심이 있다/없다 정도를 구별할 수 있는 하나의 잣대가 될 수 있기 때문인 것 같다. 나같아도 스펙 다 똑같다고 치면, 그나마 ISTQB 있는 친구를 고르고 싶을듯 함

ISTQB CTFL 시험 총평

ISTQB 자격증 공부는 인터넷 강의고 뭐고 없다. 내가 경험한 바에 따르면 닥치는대로 문제 풀어보고, 틀린 문제에 대해 이해하고, 시간이 난다면 오답노트를 작성하고, 수시로 눈에 익혀주는 수밖에 없는 것 같다. 26점 턱걸이로 통과해놓고 이렇게 후기 쓰는 것도 우습지만, 통과했으니 이런 말도 할 수 있는 듯하다. 시험 참 쉬우면서도 한 편으로는 너무 애매하고 어렵다. 

솔직히 나는 일주일동안 공부해서 턱걸이로 통과했지만, 작성하고 보니 일주일은 너무 타이트한 것 같다. 그래도 최소 2주는 되어야 그나마 안전한 라인에서 통과할 수 있을듯. ISTQB 자격증 참 좋다. 그래도 하나 따놓는게 좋지 않을까? 

혹 ISTQB CTFL레벨과 CTAL레벨 시험 보는 사람이 있을수도 있어서 일정도 업로드한다. 시험에 참고하시길..