품생품사(品生品死)의 소프트웨어 품질 정보 창고

[개발] 소프트웨어 테스트 케이스(TC)를 의미 있게 작성하는 방법 공유!!

품생품사(品生品死) — Fri, 16 May 2025 20:00:44 +0900

오프닝: 일상의 테스트는 정말 쉽지만 체계적인 테스트는 매우 어렵다

테스트의 정의는 "결함을 발견하기 위한 활동"이라고 명시되어 있습니다. 하지만 이것은 명확한 목적을 가지고 테스트를 할 때의 정의라고 생각합니다. 사실 우리는 무의식적으로 일상의 생활에서 테스트를 수행하고 있습니다. 무언가를 이용할 때와 같은 모든 상황에서 테스트 활동을 하는 것인데요.

일상에서의 테스트와 체계적인 테스트는 차이가 크다.

예를 들면, 스마트폰에서 가장 많이 사용하는 앱을 실행해 보세요. 잘 실행되었나요? 방금 테스트를 수행한 것입니다. 테스트 케이스를 작성한다면 아래와 같이 작성할 수 있습니다.

Number	Step	Expected Result
1	OOO 앱을 실행한다.	스플레시가 표시된다. - 홈 or 로그인 페이지 확인

물론, 이런 상황에서 네트워크가 끊겼다던가 서비스를 해주는 회사에 서버가 다운되었다든가 한다면 앱이 실행되지 않는 상황이 발생할 것입니다. 그것의 테스트에 관한 결과로 결함(Defect)이라고 하고, QA나 테스트 엔지니어는 테스트 결함 리포트를 작성하여 문제를 해결할 수 있는 담당자에게 내용을 공유하게 됩니다.

우리는 앱을 이용하기 위해 특별한 목적 없이 앱을 실행합니다. 결함을 발견하기 위한 목적을 가지고 앱을 실행하지는 않습니다. 결국 QA나 테스트 엔지니어와 같이 특정 목적을 가지고 앱을 실행한다면 그것은 명확한 R & R(Roles And Responsibilities)을 가지고 있는 사람의 테스트 활동이라고 정의할 수 있을 것입니다.

이런 점에서 우리는 한가지 깨달을 수 있는 중요한 한 가지가 있습니다. 그것은 바로 "누구나 테스트를 할 수 있다."라는 전제입니다. 이것은 테스트 업계의 진입 장벽이 낮다는 것을 의미하기도 합니다. 그래서 회사에서 발생하는 오해는 '개발자가 테스트하면 되지.', '기획자가 테스트하면 되지.', '디자이너가 테스트하면 되지.'와 같이 아무나 테스트하면 되고, 만약 나중에 회사의 경영이 악화하기라도 한다면 'QA 인력 필요하나?'로 결론을 내기도 합니다.

누구나 테스트할 수 있지만 아무나할 수 없다.

또한, 반대로 이야기하면 테스트는 누구나 할 수 있고, 쉽다고 생각해서 테스트를 업으로 하기 위해 취업 전선에 뛰어드는 사람들이 있습니다. 진입 장벽이 낮은 것은 사실입니다. 다만, 테스트의 '빙산의 일각'만 보고 '어? 그냥 테스트하면 되는 거 아닌가?'라는 생각으로 시작하시면 후회만 남을 것입니다.

회사에서 바라는 체계적인 테스트가 어려운 이유는 제품이나 서비스를 제공하는 입장에서 품질이라는 명분을 어깨에 짊어지고 있기 때문이라 생각합니다. 우리는 다양한 테스트 활동을 통해 고객이 제품이나 서비스를 이용하는 데 문제가 없도록 증명해야 합니다. 이것은 단순히 앱을 실행하는 것으로 끝나는 것이 아니고, 회사 내에서는 우리가 원하는 대로 만들어졌는지를 확인하고, 예상하지 못한 부분에서 결함이 발생하지 않는지를 확인해야 합니다. 만약 결함이 있다고 하더라도 고객이 받아들이기에 얼마나 큰 위험이 있는지도 생각해야 합니다.

이런 모든 일련의 과정들은 회사에서 수행하는 체계적인 테스트라고 할 수 있습니다. 회사에서 수행하는 테스트는 단순히 결함을 찾기 위한 활동이 아닌 원하는 대로 잘 만들어졌는지를 검증하고, 발견된 결함들은 잘 해결되었는지를 확인하고, 다양한 테스트를 통해 예상되는 위험이 있다면 발생했을 때 어떻게 대처해야 할지도 미리 계획해 두어야 합니다.

결론은 일상적인 테스트만 보고 일을 시작하시려는 분들이 계신다면 회사에서 해야 하는 제품이나 서비스를 위한 테스트는 생각만큼 쉽지 않을 것은 명심하시기를 바랍니다. 일상적인 테스트를 통해 약간의 수익을 얻을 수 있는 방법은 제가 발간한 전자책에 자세히 작성해 두었으니 참고해 보시기 바랍니다.

실전 노하우 아주 쉽고 간단한 테스트로 투잡하기 - 크몽

품생품사 전문가의 전자책 서비스를 만나보세요. # 목표 설정 : 쉽고 간단하지만 적은 시간과 노력으로 현실적인 부수입...

kmong.com

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

의미 있는 테스트 케이스를 작성하려면?

저는 테스트 케이스를 작성할 때 누구나 쉽게 이해하고, 따라 수행할 수 있는 테스트 케이스를 작성하려고 노력합니다. 이것은 매우 중요한 목표입니다. 내가 아닌 제3자가 테스트 케이스를 보더라도 아무런 문제 없이 수행할 수 있어야 한다는 말과 같습니다. 간혹 QA가 나뿐이라서, 테스터는 나 혼자라서 내가 보기 쉽게 혹은 내가 수행하기 쉽게만 작성해 놓는 사람들이 있습니다. 이렇게 작성된 테스트 케이스는 의미 없는 테스트 케이스라고 저는 생각합니다.

테스트 케이스의 작성과 수행 목적을 다시 한번 리마인드하면 개발물이 요구사항대로 개발이 되었는지 확인하기 위함입니다. 혹은 예외 케이스에서 문제가 발생하지 않는지를 확인하기 위한 목적이 있기도 합니다. 다양한 목적을 가지고 작성되는 문서이기 때문에 자기 자신만 알아보는 문서는 아무런 의미를 가질 수 없다는 것입니다.

그러면 테스트 케이스가 의미 있게 작성되려면 어떻게 작성해야 할까요? 여기에는 제가 연재하던 맨 처음 글에 정답이 있습니다. 간단하게 말씀드리면 테스트 케이스 설계(Design)가 필요합니다. 테스트 케이스를 잘 설계하면 누구나 쉽게 따라서 테스트 케이스를 수행할 수 있게 됩니다. 누구나 요구사항대로 개발되었는지 테스트할 수 있게 됩니다. 누구나 예외적인 상황에서 문제가 발생하고 있지 않은지 확인할 수 있게 됩니다.

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

오프닝: 테스트를 분석한다고? 무엇을 설계한다는 거야? 잡썰제가 가장 잘하는 영역인 테스트에 대한 이야기를 해보려 합니다. 블로글 외에도 전자책도 준비하고 있습니다. 물론 블로그에 모

qa-testing.tistory.com

또한 테스트 케이스 작성에 대한 설계를 잘하려면 다양한 테스트 설계 기법을 적절히 이용하는 것이 좋습니다. ISTQB에서 정의하고 있는 명세 기반의 동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅이 있습니다. 구조 기반에는 결제 테스팅과 커버리지, 조건 테스팅과 커버리지, 조건/결정 커버리지, 변경 조건/결정 커버리지, 다중 조건 커버리지가 있습니다. 물론 위와 같은 설계 기법을 모두 활용해야 하는 것은 아닙니다. 요구 분석을 통해 품질 누수가 발생하지 않으려면 어떤 테스트 방법을 가지고 테스트해야 할지를 고민해야 합니다.

단순 텍스트, UI의 변경이라면 설계 기법을 활용하는 것이 비효율적인 방법이 될 수도 있습니다. 테스트 케이스가 의미를 가지고 효과적으로 테스트를 할 수 있으려면 테스트 케이스 설계가 잘 돼야 합니다.

테스트 케이스 설계는 나무의 비유하여 생각하면 이해하기가 쉽습니다. 나무의 뿌리는 분석에 해당합니다. 나무의 기둥으로 우리가 만들어야 할 제품 혹은 서비스입니다. 가지 하나하나를 우리가 흔히 활용하는 대분류라 생각하고, 잔가지는 중/소분류라 생각합니다. 열매는 우리가 확인해야 하는 포인트(요구사항 = 기대 결과)입니다.

테스트 케이스와 프로덕트의 이해

여기서 생각해 볼 수 있는 것은 나무의 기둥을 타고 가지를 타고, 잔가지를 타고 열매로 가는 길이 우리가 테스트 케이스에서 볼 수 있는 스텝입니다. 또 하나 생각해 볼 수 있는 것은 나무의 기둥은 1개(프로덕트 & 서비스)이기 때문에 이쪽저쪽 이동해서 확인하는 것은 매우 비효율적인 테스트라는 것을 어림짐작할 수 있습니다.

그래서 제가 생각하는 의미가 있고, 효율적인 테스트 케이스는 흐름이 명확하고, 그 흐름을 최대한 벗어나지 않으면서 테스트를 완료할 수 있도록 설계된 테스트 케이스가 정말 잘 작성된 테스트 케이스라고 생각합니다. 테스트 케이스 하나하나는 명확한 기대 결과를 가지고 있지만 흐름대로 테스트해서 최종 완료까지 할 수 있어야 합니다.

사실 흐름을 가지면서 테스트 케이스를 작성하는 것은 매우 어렵습니다. 해당 프로덕트의 도메인 지식이나 비즈니스 지식을 알고 있어야 흐름에서 벗어나지 않는 테스트 케이스를 작성할 수 있기 때문입니다. 다음 섹션에는 흐름을 벗어나지 않는 테스트 케이스 작성 방법에 대해서 자세히 다뤄보도록 하겠습니다.

[분석] 소프트웨어 테스트 케이스(TC) 작성 전 요구사항 문서 보는 방법 공유!!

품생품사(品生品死) — Fri, 25 Apr 2025 20:00:28 +0900

오프닝: QA나 테스트 엔지니어도 개발자다

우리가 알고 있는 소프트웨어 개발자라고 하면 보통 코더, 프로그래머라고 생각하고 있을 거로 생각합니다. 하지만 이것은 잘못된 의미입니다. 기획자도 QA도 PM도 PO도 모두 개발자라는 사실을 알고 계셨나요?

'소프트웨어 개발'의 정의를 구글 AI에게 물어봤습니다.

소프트웨어를 기획, 설계, 구현, 테스트, 배포, 유지보수하는 일련의 과정입니다. 
즉, 컴퓨터가 특정 작업을 수행하도록 지시하는 프로그램을 만들고, 관리하는 것을 의미합니다.

'소프트웨어 개발자'의 정의를 구글 AI에게 물어봤습니다.

소프트웨어 개발자는 소프트웨어를 설계, 개발, 테스트, 유지보수하는 일을 하는 사람을 말합니다. 
즉, 컴퓨터 프로그램이나 애플리케이션을 만드는 전문가를 의미합니다.

공통으로 의미하는 것은 소프트웨어 개발 작업에 종사하는 사람을 소프트웨어 개발자라고 하는 것입니다. 그래서 좁게는 설계와 코딩을 하는 프로그래머를 의미하고, 넓게는 프로젝트를 관리하고 관련 업무를 수행하는 사람을 포함한다고 할 수 있습니다.

프로젝트를 수행하기 위해서는 보통 PM(Project Manager), PO(Project Owner), 기획자(Planner), 백엔드(Back-end), 프론트엔드(Front-end), 큐에이(QA or Tester) 등의 조직으로 구성되어 있습니다. 인원수는 프로젝트의 크기에 따라 다르고요. 그래서 위에서 얘기하는 정의에 따르면 QA 업무를 수행하는 사람도 '소프트웨어 개발자'라고 할 수 있는 것입니다.

프로젝트에 참여하는 모든 사람이 개발자다

이 이야기를 하는 이유 중 가장 중요한 것은 소프트웨어를 출시한다는 것의 책임을 누구 하나에게 지정하기 어렵다는 것입니다. 프로젝트를 수행하는 모든 인원이 개발자이기 때문에 간혹 "개발을 어떻게 한 거야?", "개발자 누구야?" 등등의 어휘는 맞지 않는다는 것이죠. 하지만 우리는 무의식적으로 알고 있습니다. 개발을 어떻게 한 거냐고 물으신다면 특정, 백엔드나 프론트엔드 개발자를 찾을 것이고, 테스트라는 용어가 보인다면 바로 QA나 테스트 엔지니어를 찾게 될 것입니다.

모두가 개발자의 의미를 명확히 알고 얘기하면 아무런 문제가 되지 않겠지만, 용어를 꼭 맞춰야 하는 것은 아니기 때문에 우리는 무의식적 의미를 나름의 해석으로 프로젝트를 수행하고 있습니다. 여기서 문제는 소프트웨어 잘 만들기 위해서는 생각의 맞춤이 매우 중요하기 때문에 용어 하나로 파생될 수 있는 다른 의미들은 최소화하는 것이 매우 중요합니다.

매우 보편적인 '개발'과 '개발자'의 의미도 다른 것과 같이 의미를 명확히 알고 사용할 때 생각의 차이를 조금이나마 줄일 수 있다는 것을 잘 알고 있어야 합니다. 구두로 맞추기 어려울 때는 문서를 통해 맞추기도 하고, 미디어(이미지, 동영상 등)를 이용해 생각을 맞추기 위해 노력을 해야 합니다.

작은 커뮤니케이션의 오류가 큰 이슈로 다가올 수 있다

이것은 향후 소프트웨어의 품질과도 직결될 수 있습니다. 초기 품질에 대한 중요성을 궁금해하는 경우가 있는데 저는 개인적으로 요구사항 리뷰나 기획서 리뷰보다 구성원들이 사용하는 용어를 맞추는 것이 초기 품질을 높일 수 있는 가장 중요한 요소라고 생각합니다.

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

오프닝: QA의 역할과 책임에 대한 오해와 진실 풀어보기테스트를 다시 한번 정의하면 '테스트 활동은 결함을 발견하기 위한 활동'입니다. 품질 보증이라는 우리의 포지션 명인 QA는 다양한 테스

qa-testing.tistory.com

테스트를 위한 요구사항 문서를 보는 방법은?

QA와 테스트 엔지니어가 보게 되는 요구사항 문서를 기준으로 말씀드리겠습니다. 요구사항에 관심이 있으시다면 '요구사항 정의서'에 대해서 공부해보시길 바랍니다.

요구사항을 분석해서 최종적으로 만들어야 하는 산출물에 대한 정보를 담은 문서가 바로 기획서입니다. 명확한 정의는 '목표를 달성하기 위해서 구체적인 계획을 작성한 정제되지 않은 문서 혹은 자료'라고 할 수 있습니다. 그래서 기획서만을 봐서는 우리가 원하는 '테스트 케이스(Test Case)를 작성할 수 없습니다. 그러면 우리는 어떤 문서를 봐야 할까요?

요구사항을 포함한 문서를 잘 분석해서 TC 작성을 고민해야 한다

QA나 테스트 엔지니어가 봐야 하는 문서는 화면 설계서, 스토리보드가 대표적입니다. 이것은 폭포수와 애자일 방법론을 활용하는 조직에서 약간의 차이가 있습니다. 폭포수 방법론으로 프로젝트를 개발하는 조직은 최종 산출물에 화면 설계서나 스토리보드가 필수 산출물이기 때문에 무조건 작성해야 합니다. 고객이나 현업이 있다면 반드시 제출해야 하는 문서이기도 합니다. 제가 경험했던 회사에서는 화면 설계서나 스토리보드를 .ppt로 작성하는 것이 보통이었습니다. 조금 더 예전에는 .docx로 작성하기도 했었고, 공공기관에서는 아직도 .hwp 파일에 작성하기도 합니다.

애자일 방법론으로 프로젝트를 개발하는 스타트업 같은 경우, 조금 예전에는 엑슈어(Axure)라는 도구를 활용하기도 했고, 노션(Notion)을 활용하기도 했던 것 같습니다. 하지만 현재는 거의 피그마라는 디자인 도구를 통해 '디자인+화면 설계'를 포함하는 문서가 트랜드로 대부분 활용하고 있다고 보시면 됩니다.

[Sample] Figma를 활용한 디자인 + 화면 설계

기존 화면 설계서나 스토리보드를 작성하면 디자인적인 요소는 포함되지 않았으나 (3) 번과 같이 피그마를 활용한 화면 설계서에는 디자인적인 요소도 포함하게 됩니다. 여기서 중요한 것은 UI/UX 관련된 부분은 디자이너가 테스트(확인, Validation) 해야 하고, QA나 테스트 엔지니어는 문서에서 기능/성능적인 부분을 테스트 케이스화 해야 하는 것입니다.

이전 섹션에서 잠깐 언급했듯이 기능적인 부분에 문제가 발생하면 사용자는 매우 큰 불만족을 느끼기 때문에 최대한 기능적인 부분을 테스트 케이스화 해야 합니다. 이전 섹션을 읽어보지 않으신 분들은 아래 링크 참고해 주세요.

[준비] 쉽게 작성하고 빠르게 수행할 수 있는 테스트 케이스(TC) 작성하는 방법 공유!!

오프닝: 내가 하는 일이 세상에서 가장 힘든 이유는?세상에는 많은 일들이 있습니다. 일이라는 것이 누군가에게는 경제 활동이고, 누군가에게는 자아를 성찰하는 활동이고, 또 누군가에게는 그

qa-testing.tistory.com

필자의 경우 테스트 케이스 작성 시 첫 번째 케이스는 UI/UX 확인 케이스를 작성하곤 합니다. 다만, 디자인적인 상세 요소(1 pixel, layout, margin 등)는 아니며 화면 설계적으로 확인이 필요한 컴포넌트의 구성이나 팝업의 문구 등을 확인 포인트로 작성하는 것이죠. 혹은 해당 페이지에 접근했을 때 UI 깨짐 등이 발생하지 않는지에 대한 최소한의 확인 포인트를 작성합니다.

1번 케이스에는 UI/UX 적인 요소를 작성하고, 2번 케이스부터는 1번에서 작성한 UI 요소에 대해서 기능적으로 확인하는 케이스를 나열합니다. 간단하게 정리하면 아래와 같은 내용으로 테스트 케이스를 작성하고 있습니다.

No.	Division	Step	Expected Result
TC-001	UI/UX	로그인 페이지를 확인한다.	로그인 페이지가 표시된다. - Title: "Log In" - Input Fields: Email address \| Password - Placeholder Text: Email address \| Password - Button: Log In - Link Button: Forgot password? \| Sign up
TC-002	Function	Email address를 입력한다.	Email address가 입력된다. - 입력 조건: OOO(이메일 포맷 등)
TC-003	Function	Password를 입력한다.	Password가 입력된다. - 마스킹 처리 등 보안 관련 정책

테스트 케이스에 대한 상세 작성 방법은 다음 섹션에서 말씀드리도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다.

[준비] 쉽게 작성하고 빠르게 수행할 수 있는 테스트 케이스(TC) 작성하는 방법 공유!!

품생품사(品生品死) — Sat, 19 Apr 2025 20:00:45 +0900

오프닝: 내가 하는 일이 세상에서 가장 힘든 이유는?

세상에는 많은 일들이 있습니다. 일이라는 것이 누군가에게는 경제 활동이고, 누군가에게는 자아를 성찰하는 활동이고, 또 누군가에게는 그 무언가의 의미일 것으로 생각합니다. 저는 컴퓨터 정보학(입학할 때는 컴퓨터공학이었는데 졸업할 때 컴퓨터 정보학으로 개명됨)을 전공하고, 한 때, 소프트웨어 개발을 하려고 했던 사람입니다. 물론, 개발의 재미와 탐구. 가장 중요한 것은 성취감이었던 것 같습니다.

개발의 시작은 대학교 4학년 때, 교수님 추천으로 인턴으로 입사하여 시작하게 되었습니다. 회사도 그 흔한 가산디지털단지나 구로도 판교도 아닌 천안 아산이었습니다. 회사에 정말 10미터 떨어진 기숙사에서 회사와 기숙사를 오가며 회사 생활을 시작했던 것 같아요. 그전에는 안 해본 아르바이트가 없을 만큼 나름 해볼 것 많이 해봤으나 회사에 소속돼서 일하는 것은 처음이었는데 누군가는 꿈꾸었던 기숙사 생활이었습니다.

군대 같았습니다. 자고 일어나면 아침을 회사 사람들과 구내식당에서 밥을 먹고, 점심도 같은 식당이고, 밥 다 먹으면 탁구치고 다시 일하고, 저녁 먹고 또 일하고 그랬습니다. 금요일은 그나마 오후 4시에 퇴근하여 서울에 갈 수 있게 배려를 해주기도 했던 회사였습니다.

중요한 것은 조선 관련 회사다 보니 인턴 3개월 동안 1개월은 부산에 출장을 갔습니다. 바지선에서 직접 개발한 임베디드솔루션을 테스트해야 했습니다. 그래서 전기 관련 엔지니어와 함께 정말 난생처음 보는 배에 올라 테스트했던 기억이 있습니다. 배의 크기가 아파트 20층 정도 되는 크기였어요.

'테크로스'에서 테스트했던 유조선

그렇게 3개월이 지나고는 회사에서 정규직 전환 의사를 물었지만, 서울에서 일하고자 하는 마음에 퇴사를 결정했었습니다. 그리고 속으로는 '개발자는 다 이렇게 일하는 건가?'라는 생각도 하게 되었고, 앞으로의 삶이 걱정되기도 했던 것 같습니다. 정말 내가 하는 일이라서 나만 힘든 거냐고 생각도 하게 되었고요.

그리고 서울에 올라와 우연히 테스트라는 일을 하게 되었습니다. 이력서를 처음 작성하고 잡코리아와 사림인에 등록해서 회사로부터 연락이 와서 면접을 보고 입사하게 되었습니다. 그렇게 저의 일, 경제 활동이자 자아를 성찰하기 위한 일을 시작하게 되었습니다.

일을 시작한 것이 2010년 2월이었고, 첫 월급이 세후 130만 원이 좀 안 되었던 것으로 기억합니다. 집은 경기도 동두천인데 회사는 서울의 양재라서 출퇴근만 5시간이 걸렸지만 그래도 일한다는 마음에 4~5시간 잠을 자면서 1년을 좀 넘게 일했습니다. 이건 누가 봐도 힘든 것 같죠? 물론 저보다 더 힘든 상황에서 회사에 다니시는 분들도 계실 겁니다. 그리고 지금은 세상도 바뀌고 일하는 방식도 많이 바뀌었으니까요.

그렇지만 아무리 세상이 바뀌었다고 하더라도 결국은 "지금 내가 하는 일이 가장 힘든 일이다."라는 것입니다. 누군가는 내가 하는 일에 대해서 보상? 대가에 대한 개념으로 일의 가치를 측정하기도 하고, 성취감이나 보람으로 일의 가치를 측정하기도 합니다. 그래서 이런 피드백에 대한 것이 부족할 때 힘들다는 생각하게 되는 것 같습니다. 그래서 대기업에 다니면 '돈으로 위로받는 회사'라는 표현을 하기도 하는 것 같습니다.

내 삶의 가장 중요하게 생각하는 것은 무엇일까?

그래서 지금 제가 하는 일!! QA 혹은 테스트 엔지니어, 품질 관리자라는 직업이 어떠냐고 물으신다면...저는 현재 매우 만족합니다. 이 일을 하지 않았다면 무슨 일을 했을지 상상하기 어렵습니다. 지금의 저를 있게 해준 일이고, 주변에 일부 소중하고 고마운 사람들을 만날 수 있게 해준 것도 지금의 테스트라는 일이, 직업이 가져다준 선물 같은 것이라 생각합니다.

아주 작은 일이라도 누군가는 힘든 게 맞습니다. 맞아요. 이것은 부정하면 안 됩니다. 다만, 부정하기보다는 응원하고, 그 일로 인해 나는 무엇을 얻었고, 혹은 무엇을 깨달았는지를 생각하는 것이 나를 성장시킬 수 있는 '일'의 진정한 의미가 아닐까 하는 생각을 하게 되었습니다.

근데 제목은 테스트 케이스 작성하는 법이라고 하고 이게 무슨 뜬구름 잡는 얘기인가 하시겠죠? 일에 대한 만족도를 높이기 위해 제가 15년 동안 공부하고, 깨닫고 느낀 것을 앞으로 QA나 테스트 엔지니어들의 주 업무인 테스트 케이스를 가지고 자세히 설명해 드리려고 합니다.

15년 품질 관련 일을 하면서 경험한 삶에 대한 깨달음

이전 글도 참고해 주세요.

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

qa-testing.tistory.com

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

qa-testing.tistory.com

테스트 케이스를 작성하기 전 준비할 것 정리하기

우선 많이 갈리는 테스트 케이스, 체크리스트, 테스트 시나리오의 활용 목적을 명확히 해야 합니다. 표준에 나와 있는 이야기는 아니지만 업무를 통해 제가 생각하는 테스트 케이스의 목적은 '요구사항대로 개발이 되었는지 검증하는 목적'이라 생각합니다.

확인(Verification)과 검증(Validation)에 대한 차이점도 면접에서 많이 물어보는 질문 중의 하나이기도 한데요. 간단하게 설명하면 확인은 인풋에 1을 넣으면 0인지 1인지를 확인하는 것이고, 검증은 똑같이 1을 넣었을 때 왜 1을 넣었고 0일 나왔을 때는 왜 0이 나왔으며, 1이 나왔다면 왜 1이 나왔는지에 대한 차이가 있습니다. 그래서 단위 테스트라는 가장 작은 단위의 테스트를 할 때는 확인이라는 표현을 많이 사용하고, 통합 테스트 시점 이후에는 검증이라는 표현을 사용하는 것이 보편적입니다. (슬픈 사실이지만 모르는 사람이 더 많을 거에요. )

꼬꼬물로 설명하게 되는데 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트가 있습니다. 개발 생명주기에 따른 매칭되는 테스트 방법이라고 해야 할까요? 업계 표준에는 'V 모델'라는 것이 있습니다. 궁금하시면 구글링해 보시거나 챗GPT에게 물어보시는 것을 추천해 드립니다.

혹시나 제가 작성하는 용어 중에 궁금하신 것이 있으면 댓글에 남겨 주시면 제가 아는 한도 내에서 최대한 쉽게 설명해 드리도록 하겠습니다.

그리고 체크리스트 목적을 이야기하기 전에 테스트 케이스와 체크리스트의 차이가 무엇인지 많이 물어보시는데요. 명확하게 기대 결과의 유무라고 대답하면 됩니다. 체크리스트는 기대 결과가 없고, 테스트 케이스는 앞에서도 이야기했듯이 요구사항에 대해 검증하는 활동이기 때문에 기대 결과가 명확히 작성되어야 합니다.

체크리스트와 테스트 케이스의 차이점을 쉽게 설명하면요.

로그인 버튼을 클릭한다.
- 체크리스트: 로그인 버튼이 클릭 된다. (O | X의 개념)
- 테스트 케이스: 로그인 버튼 클릭 후 홈 화면으로 이동된다. (기대 결과대로 동작하는지의 개념)

그래서 체크리스트의 활용 목적은 개발 단위 테스트에서 활용하거나 간단하고 빠르게 확인이 필요할 때(배포 전 혹은 출시 후) 많이 활용하고 있습니다. 저는 현재 회사에서도 가끔 활용하고 있습니다. 체크리스트를 쉽게 작성하는 방법은 나중에 자세히 다뤄보도록 하겠습니다.

그리고 마지막으로 테스트 시나리오라는 것은 조금 어렵습니다. 품질 관련업을 하지 않으시는 분들이 가장 많이 혼용해서 사용하는 용어 중의 하나입니다. 보통은 테스트 케이스를 이야기하면서 테스트 시나리오라고 이야기하는 경우인데요. 이것 또한 품질 관련 일을 하는 사람이라면 명확하게 구분하는 것이 좋습니다. 테스트 시나리오는 간단하게 이야기하면 흐름을 포함하는 테스트 케이스입니다.

테스트 시나리오와 테스트 케이스의 차이점을 쉽게 설명하면요.

테스트 케이스:
- 사전 조건: ID/PW 입력
  - 로그인 버튼을 클릭한다.
- 기대 결과: 메인 홈 화면으로 이동된다.
테스트 시나리오:
1. ID와 PW를 입력한다.
2. 로그인 버튼을 클릭한다.
  - 기대 결과: 메인 홈 화면으로 이동된다.

테스트 케이스는 하나의 스텝에 하나의 기대 결과를 가지는 것이 가장 바람직합니다. 반면, 테스트 시나리오는 N개의 스텝을 통해 하나의 기대 결과를 가지게 됩니다. 이것 또한, 나중에 이슈(해결해야 하는 문제*)가 발생했을 때의 관리 방법이 다르기 때문에 이것도 다음 섹션에 자세히 다루겠습니다.

가장 중요한 것은 상황에 맞게 테스트 케이스가 필요한 것인지 체크리스트가 필요한 것인지 테스트 시나리오가 필요한 것인지를 판단해서 문서를 작성해야 하는 것입니다. 이것은 테스트의 효율이나 효과에 대해서 큰 차이가 있기 때문에 요구사항 문서를 보고 습관같이 테스트 케이스를 작성하기보다는 여러 가지 상황을 고려해서 어떤 방식으로 문서를 작성해야 할지를 먼저 고려해야 합니다.

소프트웨어는 생각을 맞추는 일이다.

이렇게 용어의 의미를 명확히 해서 활용해야 하는 이유는 동료들과의 커뮤니케이션을 명확히 하기 위함입니다. 소프트웨어의 성공과 실패는 커뮤니케이션을 잘했냐? 못했냐?의 작은 차이에서 시작된다고 생각합니다. 모두가 똑같이 '아버지가 방에 들어가신다'라고 이해했는데 누군가 한 명이 '아버지 가방에 들어가신다'라고 이해하게 되면 나중에 스노우볼 효과가 되어 큰 문제가 될 수 있기 때문입니다. 물론 중간에 잘 못 이해한 부분을 커뮤니케이션해서 바로 잡아야 하는 것도 매우 중요한 활동입니다.

테스트 케이스를 작성하는 것은 명세 기반 테스트 설계 기법이라 합니다. 말이 어렵죠? 요구사항 명세서는 요구사항을 포함하는 문서입니다. 명세하다는 의미는 '분명하고 자세하다'라는 의미로 요구사항 명세서는 '요구사항에 대해서 분명하고, 자세하게 작성된 문서이다'라고 이해하시면 됩니다.

예를 들면, 기획서가 대표적이고, 화면 설계서나 스토리보드, 최근 트랜드인 피그마 디자인 문서에 기능 정의를 포함해서 작성한 문서가 명세서라고 생각하시면 됩니다. 우리가 명세서에서 봐야 할 것은 기능 정의입니다. 아래 그래프는 품질 관련 일을 하는 사람들이 지켜나가야 하는 소프트웨어의 성질을 이야기해 주고 있는 그래프인데요. 사용자 관점에서 체감 불만이 가장 높은 것이 기능성이기 때문입니다.

ISO 9126, 29119에 명시된 고객 체감 불만 정도 그래프

예를 들면 로그인 버튼 클릭했는데 로그인 안 되는 경우라 생각하시면 가장 쉽게 이해되실 것 같습니다. 그렇기 때문에 우리는 명세서에 작성된 기능에 대한 정의를 테스트 케이스화 해서 문서를 작성해야 하는 것입니다. 기능 명세는 대부분 'OOO으로 동작된다.' 혹은 '로그인: 버튼' 등으로 작성이 되어 있을 겁니다. 우리는 이것을 보고 해당 기능의 위치 정보와 스텝과 기대 결과 등으로 테스트 케이스를 작성해야 하는 것입니다.

최근에는 글로만 작성된 명세서를 보고 테스트 케이스를 작성하는 것은 극히 드물 거에요. 기획자들이 작성한 화면 설계서, 스토리보드 혹은 피그마 디자인 문서로 테스트 케이스를 작성하게 됩니다.

글이 길어져서 다음 섹션에 테스트 케이스 작성에 대한 이야기를 본격적으로 시작해 보도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

품생품사(品生品死) — Thu, 3 Apr 2025 20:00:37 +0900

오프닝: QA의 역할과 책임에 대한 오해와 진실 풀어보기

테스트를 다시 한번 정의하면 '테스트 활동은 결함을 발견하기 위한 활동'입니다. 품질 보증이라는 우리의 포지션 명인 QA는 다양한 테스트 활동을 통해 품질을 보증할 수 있는 데이터를 상품의 출시나 서비스의 오픈을 판단할 수 있도록 데이터를 수집하고, 제공해야 하는 것이 QA라는 포지션의 사람들이 해야 하는 숙명이라 생각합니다. (숙명까지는 아니더라도??)

누군가는 QA가 출시의 판단 여부를 결정해도 되지 않느냐 물어보는 경우도 있었습니다. 개인적으로는 회사에는 제품과 서비스를 책임지는 포지션은 회사마다 조금은 차이가 있겠지만 일반적으로 명확히 R&R(Role and Responsibilities)에 명시되어 있을 겁니다.

QA 역할과 책임에 대해서 한번쯤 고민하기

프로덕트 단위에는 PM(Project Manager)이 있을 것이고, 기능 단위에서는 PO(Project Owner)라는 포지션을 가진 사람들 최종 책임이 있는 사람이라 생각합니다. 물론 소규모의 회사일수록 C레벨 분들의 판단하에 출시나 배포가 진행되는 경우가 있긴 합니다. 출시나 배포 후 문제가 발생했을 때 책임을 묻는 사람은 다름 아닌 PM이나 PO일 것입니다.

그렇다면 QA에게는 무엇을 물을까요? 어떤 책임을 지고 업무를 수행해야 할까요? 업계에 좀 오래 계신 분들은 "테스트 안 하고 뭐 했어?"라는 말을 지나가면서 누군가에게 들어 보셨을 거로 생각합니다. 명확하게 QA에게는 테스트 관련된 책임과 품질에 대한 책임을 묻는 것이 일반적입니다. 이것은 프로덕트나 프로젝트와 관련은 있지만 출시나 배포의 책임이라 볼 수는 없는 부분입니다.

이런 부분도 QA나 테스터의 포지션에 있는 사람들의 입지가 올라오지 않은 상황에서 최종적으로 인수 테스트 영역에서 테스트를 많이 했던 시절의 이야기라 생각합니다. 지난 일들을 생각해 보면 '마지막에 네가 테스트했으니까 네 책임이야'하는 매우 단순한 논리에서 발생한 오해이지 않을까 싶습니다.

지나간 OO 회사의 면접에서 있었던 일입니다. QA가 배포의 판단을 하면 안 된다고 작성한 과제의 한 부분에 관해서 토론 아닌 토론을 했던 경험이 있는데요. 물론 저의 자세는 위의 논리대로 말씀드렸지만, 그 회사는 배포의 판단을 QA의 권한이라고 생각하는 조직? 회사였던 것 같았습니다. (이런 식의 면접은 안 봐도 결과는 불합격이죠 ‍ ️)

면접은 항상 어려운 것

"출시나 배포의 판단을 QA가 한다?"가 잘못된 정의는 아닙니다. QA나 테스터 혹은 마지막으로 테스트했던 누군가의 책임을 회피하려는 것도 아닙니다. 여기서 중요한 것은 R&R이 명확히 해서 업무를 수행해야 한다는 것입니다. 그리고 출시나 배포 후 발생하는 문제는 개인적으로 프로젝트에 참여한 모든 사람이 책임을 나누어야 한다고 생각합니다. 또한, 책임을 운운하기보다는 발견된 문제를 빠르게 해결하려는 방법을 미리 계획해 두는 것이 바람직한 운영/유지 보수를 대비하는 자세가 아닐까 싶습니다.

프로젝트의 테스트를 잘 수행하기 위한 방법은 아래 블로그를 참고해 주세요

[준비] 프로젝트 종료까지 관리되는 테스트 계획서 작성하는 방법 공유!!

오프닝: 프로젝트를 준비하는 QA의 자세는?테스트 계획서는 SI에서는 필수 산출물로 꼭 작성되어야 하는 문서입니다. 그리고 또 포함되는 문서가 품질 관리 계획서입니다. 이번 섹션에서는 품질

qa-testing.tistory.com

테스트를 시작하기 위해서 꼭!! 준비해야 하는 항목들

테스트 분석을 통해 우리는 프로젝트에 어떤 테스트가 필요한지를 알게 되었을 겁니다. 이게 무슨 소리냐고요? 아래 블로그도 참고해 달라는 것이지요

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

qa-testing.tistory.com

테스트를 분석하고 설계하였다면 이제는 실제 테스트를 하기 위해 준비를 해야 합니다. 가장 중요한 것은 자신만의 기준을 만들어야 합니다. 물론 회사에서 해야만 하는 테스트 관련 기준이 있다면 매우 좋습니다. 하지만 대부분 테스트에 대한 기준 수립과 정립을 QA나 테스트 엔지니어에게 기대기 마련입니다. 저는 테스트에 대한 기준을 "QA나 테스트 엔지니어 자신의 테스트 만족도"라 생각합니다.

"내가 만족할 만큼 테스트했는가? 이정도 테스트했으면 문제없을 것 같다."라는 마음이 생길 때까지 테스트하려는 기준을 가슴속에 만드는 것입니다. 저는 개인적으로 '내가 테스트했으면 쪽 팔리면 안 된다.'라는 생각을 조금은 테스트가 익숙해지는 시점에 하기 시작했습니다. 이런 마음가짐은 자신을 좀 더 몰아치게 되고 스킬업 하는 동기부여가 되기도 합니다. 간혹 출시 후 이슈가 발생했다면 어디서 테스트가 부족해서 생긴 문제인지 다시금 생각하는 시간을 가질 수도 있습니다.

마음가짐이 생겼다면 이제 실제적인 테스트 준비를 해야 합니다.

제가 생각하는 테스트 수행 전 꼭 준비해야 하는 항목은 세 가지입니다.

테스트를 잘 하기 위해 중요한 것 세 가지

첫 번째, 테스트 환경을 준비해야 합니다. 테스트 케이스를 수행할 수 있는 환경이 잘 준비되어 있는지 최대한 명확하게 확인하는 것이 좋습니다. 확인을 최대한 하더라도 막상 테스트를 시작하게 되면 환경이 도와주지 않아 테스트 케이스 결과에 N/A(Not Available) 많아질겁니다. 테스트 환경은 인프라적 요소일 수도 있고, 임베디드 환경이나 테스트 기기가 없는 등의 환경을 이야기합니다. 예를 들면, 이번 안드로이드 최소 버전을 10으로 올렸다면 10 버전이 설치된 기기가 미리 준비되어 있어야 하는 것이 대표적인 사례일 것 같습니다.

크게 보면 개발 서버와 운영 서버만 분리되어 테스트하는 동안 코드 프리징되지 않고, 테스트를 수행하는 중에도 배포가 됩니다. 그러면 매우 불안정한 상황에서 테스트를 수행하게 되고 이런 부분도 환경적인 요소의 부재라 할 수 있습니다. 꼭! 코드 프리징된 상태에서 변경 점을 파악하면서 테스트를 수행해야 '이전 버전에서는 잘됐는데 이번 버전에서 왜 안되?' 상황을 줄일 수 있습니다. 저는 이런 상황을 '리그레이션이 무너졌다'라는 표현을 쓰기도 하는데요. 변경 관리가 안 되면 충분히 발생할 수 있는 부분이니 꼭 명심하시길 바랍니다.

제일 좋다고 생각하는 개발 환경 구성은 개발/스테이징/운영으로 환경이 분리된 상태에서 테스트를 수행하는 것이 가장 바람직한 환경 세팅이라 생각합니다. 스테이징 기준으로 테스트가 완료되면 변경 없이 바로 운영으로 배포될 수 있도록 환경이 구성되어 있어야 합니다.

테스트 환경의 중요성

N/A라는 용어가 나와서 좀 더 첨언을 하자면 N/A 항목도 하나의 테스트 Fail로 봐야 합니다. 테스트 케이스에 대한 이야기는 다음 섹션에 자세히 다루겠지만 요구사항에 대해 확인하지 못한 부분이기 때문에 N/A 항목을 Fail로 생각하고 테스트 결과 리포트에 별도의 목록으로 제공해야 합니다.

저도 미처 생각하지 못했던 부분이었는데 교원에 재직 당시 프로젝트를 수행하면서 품질률을 측정할 때 N/A 항목이 매우 중요하다는 깨달은 부분입니다. 가장 명확한 것은 N/A 항목도 이슈로 등록하는 것이 좋겠지만 한두 개가 아니라면 목록화해서 공유하는 것도 괜찮습니다. 다만 N/A 사유가 명확해야 합니다.

두 번째, 테스트 데이터를 준비해야 합니다. 테스트 데이터도 환경과 마찬가지로 테스트 수행 시점에 발견되는 경우가 많습니다. 이 부분은 환경과는 조금 다르게 테스트 케이스를 작성하면서 보완할 수 있고, 준비할 수 있는 부분입니다. 더미 데이터를 미리 생성해 둔다던가 테스트 케이스의 조건에 맞는 데이터를 생성해 둘 수 있습니다. 데이터가 없다면 백엔드 개발자에게 요청해서 미리 데이터를 준비할 수 있도록 해야 합니다. 이것도 데이터 부재로 테스트 케이스를 수행할 수 없다면 N/A로 결과를 입력하게 됩니다.

세 번째, 커뮤니케이션을 맞춰야 합니다. 이건 정말 조직마다 케바케일 수 있고, 도메인에 따라 사용하는 용어가 다르기 때문에 사소한 용어라도 서로 의미를 다르게 사용하고 있다면 최대한 커뮤니케이션에 문제가 없도록 사용하는 용어를 맞춰야 합니다. 예를 들면, 저는 N/A로 테스트 못 한 결과를 입력하지만, 어떤 분들은 N/T(Not Test)로 용어를 사용하기도 합니다. 프로젝트를 수행하는 데 있어서 혹은 더 넓게 소속되어 있는 회사에서 사용하는 용어는 꼭 맞춰서 커뮤니케이션할 수 있도록 준비하시기를 바랍니다.

커뮤니케이션이 일치하지 않으면 요구사항은 산으로 간다

위 세 가지만 미리 잘 확인하고 챙기신다면 테스트 수행하는 시점에 N/A 항목을 최소화할 수 있을 거로 생각합니다. N/A가 적다는 것은 요구사항에 대해서 최대한 검증을 해놓은 상태이기 때문에 기능적으로는 문제가 없다는 것을 자신 있게 얘기할 수 있는 상황일 것으로 믿어 의심치 않습니다.

"소프트웨어 테스트의 완료는 곧 나의 자신감이다."

긴 글 읽어 주셔서 감사합니다.

[준비] 프로젝트 종료까지 관리되는 테스트 계획서 작성하는 방법 공유!!

품생품사(品生品死) — Mon, 31 Mar 2025 20:00:16 +0900

오프닝: 프로젝트를 준비하는 QA의 자세는?

테스트 계획서는 SI에서는 필수 산출물로 꼭 작성되어야 하는 문서입니다. 그리고 또 포함되는 문서가 품질 관리 계획서입니다. 이번 섹션에서는 품질 관리 계획서가 아닌 테스트 계획서에 대해서 말씀드리겠습니다.

간단하게 설명하면 품질 관리 계획서에는 기획/개발/테스트/배포/운영 유지보수에 대해서 품질을 어떻게 관리할지에 대한 내용이 있어야 하며, 테스트 계획서는 품질 관리의 일부 '테스트' 목적과 목표. 그리고 어떻게 테스트하고 테스트 관련 정보를 담은 문서라고 생각해 주시면 쉽게 이해 되실 거로 생각합니다.

테스트를 바라보는 QA의 자세

프로젝트의 시작은 '킥오프'라는 활동으로 시작됩니다. 킥오프는 아시다시피 축구에서 공을 차는 것으로 경기를 시작한다는 의미로 새로운 프로젝트를 시작할 때 킥오프 회의 혹은 미팅함으로써 프로젝트를 시작하게 됩니다. 물론 킥오프의 주최는 PM(Project Manager)이 합니다. 참석자는 유관부서 장들과 고객이나 현업, 외주 개발을 하는 경우 외주 개발사 담당자가 참여합니다.

이때, QA나 테스트 엔지니어는 무엇을 해야 할까요? 저는 킥오프 미팅에 참석하면 이후 풀이에서 술 마셨던 기억밖에 없습니다. 회의 때는 아무런 말 하지 않고 있다가 "수고하셨습니다." 한마디 했던 것 같습니다.

이유 있는 '수고하셨습니다.'이긴 한데요. 왜냐하면 과업의 범위나 어떤 프로젝트인지 감도 없는 상황이기 때문에 품질이나 테스트에 관련된 정보를 말할 수 없는 상황이기 때문입니다. 결국 '의쌰의쌰'의 시간에 나도 힘내보고자 참여하는 회의라 생각하시면 될 것 같습니다.

킥오프는 한 잔하기 위한 명분인가?

물론, PM의 성향에 따라 품질에 대해서 의견을 물어보는 경우도 있을 테지만, '아직 특별한 계획은 세우지 못했고, 프로젝트 관련 문서를 보고 말씀드리겠다' 정도로 정리하더라도 특별히 문제가 되지 않습니다.

그렇다면, 프로젝트 관련 RFP(Request For Proposal) 문서가 작성되고, WBS(Work Breakdown Structure)라는 업무 분류 체계 문서가 작성될 때쯤, 그리고 요구사항이 명확해질 때 우리는 움직여야 합니다. RFP 문서를 보고 프로젝트(과업)의 범위를 확인하고, WBS 문서에서는 일정과 리소스를 확인해야 합니다. 가장 중요한 요구사항 문서를 보고 우리는 품질 관리 계획과 테스트 계획을 수립해야 합니다.

우린 RFP? WBS? 이런 거 없는데? 요구사항 문서 이것도 그냥 피그마 문서가 다인데? 하시겠죠? 위에 문서들은 SI 사업에서나 모두 볼 수 있는 문서이고, 애자일하게 개발하는 회사(스크럼, 칸반, 사일로, 스쿼드 방식 등)는 요구사항이 정리된 문서와 피그마 문서가 어느 정도 작성이 완료되었을 시점이라 말씀드릴 수 있습니다.

제가 말씀드리려는 부분은 SI에서 작성하는 테스트 계획서가 아니고, 빠르게 대응해야 하는 조직에서 테스트 계획서 꼭 작성해야 하는가에 의문을 풀고, 프로젝트가 종료될 때 테스트 계획서가 어떻게 활용되는지 말씀드리겠습니다.

오해가 풀리고 진실을 알게 되었을 때 테스트 계획서를 작성하는 방법

오해라고 할 것까지도 없었고, 진실이라고 하기에도 모호한? 그런 내용이었지만 테스트 분석과 설계에 대해 이해하셨다면 그것으로 되었다고 생각합니다. 혹시나 이전 글을 읽어보시지 않았다면 제가 무슨 얘기를 했는지 모르실 것이기 때문에 아랫글을 참고해 주세요.

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

qa-testing.tistory.com

테스트 계획서의 작성 목적은 계획해서 계획한 대로 업무를 수행하기 위한 단순한 의미가 아닙니다. 프로젝트 수행에 있어서 계획서는... 테스트 계획서뿐만 아니라 '계획서'라는 명명의 문서들은 모두 같은 목적을 가집니다. 계획 대비 얼마나 성과를 내었는지를 확인하기 위함입니다. 이것은 프로젝트 종료 시 회고의 참고 자료가 되기도 하고, 일부 회사에서는 평가의 기준 지표가 되기도 하고 협력사나 외주사와 함께 일하는 경우 SLA(Service Level Agreement) 기준이 되기도 합니다.

정리하면 테스트 계획 대비 얼마나 테스트를 했나? 만 확인하면 안 되죠. 테스트는 그렇습니다. 성과? 잘해야 본전인 것이 테스트 활동이라 성과로 표현하기는 매우 어려운 영역이라 생각합니다.

그렇다면 테스트에 있어서 계획서의 목적은 무엇일까요? 제가 생각하는 테스트 계획서를 작성하는 목적은 '요구 추적을 한 눈에 확인 할 수 있는 문서'라고 생각합니다. 그래서 계획서에 포함되어야 하는 내용은 일정, 리소스, 요구사항(기준), 테스트 분석/설계 내용, 이슈 관리 목록, 테스트 범위, 테스트 환경 정보, 테스트 결과, 그리고 결과에 따른 배포 현황 등이 포함되어야 합니다.

이렇게 많은 내용을 담으려면 문서 작성 시간만 하더라도 많은 시간이 소비되고, 이렇게까지 작성해야 하나? 싶을 정도의 내용이 많다고 생각하실 수 있겠지만 사실 문서를 작성하는 데 필요한 시간은 30분도 안 걸리는 것 같습니다.

개인적으로 테스팅 전략이라 쓰지만 결론은 테스트 계획서이다

제가 하는 방식을 그대로 공유해 드리겠습니다. 따라만 하셔도 테스트를 관리하는 데 매우 큰 도움이 되실 거라 자신합니다.

첫 번째, 테스트 요청을 받습니다. 슬랙(메신저)를 통해 일정 조율을 하고, 필요시 테스트 범위를 확인하기 위해 기획 리뷰? 설명을 듣고 테스트를 분석합니다. 물론 저는 머리로 합니다. 노하우가 쌓이면 충분히 하실 수 있습니다. 분석된 내용을 바탕으로 일정을 산정합니다. 어느 시점에 어느 정도 공수가 필요하고, 어떤 환경에서 어떻게 테스트하는 것이 좋겠다는 결론을 바로 결정합니다.

요청 받은 내용 및 조율된 내용 작성

두 번째, 요청받은 내용을 컨플루언스에 정리합니다. 현재 재직 중인 회사는 컨플루언스/지라 세트로 업무를 수행하고 있습니다. 대부분의 문서는 컨플루언스 문서로 작성하고 있으며, 저는 '테스팅 전략'이라는 제목으로 템플릿을 하나 만들어 두고 바로 작성을 합니다. 작성할 수 있는 내용은 별로 없습니다. 조율된 일정, 요구사항이 있는 피그마 문서 링크, 개발 담당자 정도입니다.

테스트 환경 및 개발 정보 정리

세 번째, 테스트케이스를 작성합니다. 계획서 내용에 요구사항 기준으로 작성된 테스트케이스를 첨부합니다. 저는 지라 애드온인 Xray라는 도구를 사용 중이어서 Xray의 링크를 첨부합니다. Xray라는 도구가 좀 재미있기는 한데요. 혹시나 기회가 된다면 활용해 보시길 추천해 드립니다. 가장 많이 활용하고 있는 기능은 Xray에서 제공하는 Test Plan이라는 이슈 유형(커버리지 측정)이 있고, Test Execution이라는 유형(테스트 케이스에 이슈 추적)으로 테스트 수행 관리가 가능합니다. 나중에 Xray 활용에 대해서도 한번 상세히 다뤄보도록 할께요.

테스트 분석/설계 후 작성된 테스트 케이스 정보

네 번째, 테스트 수행 결과를 작성합니다. 여기에는 테스트를 수행하는 동안 발견한 이슈 목록이 포함됩니다. 이슈 목록은 지라의 에픽으로 관리하고 있습니다. 예를 들면 에픽 제목은 '[이슈 목록 - {플랫폼}] {프로젝트명}'으로 일관화하여 프로젝트를 진행할 때마다 에픽을 생성해서 이슈를 관리하고 있습니다. 또한, 이 시점에 꼭 확인해야 할 것은 이슈로 생성된 개발 아이템이 모두 해결되었는지와 이슈 목록에 링크된 이슈들은 모두 해결되었는지. 그리고 테스트하지 못한 항목들에 대해서는 어떻게 협의했는지에 대한 정보를 작성합니다.

테스트 수행 결과 정리

다 섯째, 배포 여부에 대해서 작성하게 되면 테스트 계획을 포함하는 테스팅 전략 문서가 완료됩니다.

정리하면,

테스트 기간 및 범위
- 일정: 테스팅 전략 수립, 테스트 케이스 설계 및 작성, 테스트 수행 기간, 배포 예정일, 테스트 대상 플랫
- 요구사항 기준 문서: 기획서, 피그마, 화면설계서, 스토리보드 등
테스트 케이스 목록
테스트 수행 여부
- 테스트 환경 정보
- 개발 담당자 정보
이슈 관리 목록
테스트 결과
- 배포 여부 및 배포일
- 잔여 이슈
- 수행하지 못한 테스트케이스 목록

위의 모든 내용이 하나의 문서에 작성되어 있습니다. 테스트 계획서(필자는 테스팅 전략 문서라 쓰고 있음)에는 어떤 요구사항으로부터 어떤 변경 점을 테스트하였는지와 테스트 수행에서 발견된 이슈는 무엇이 있는지? 해결하지 못한 이슈나 확인하지 못한 케이스는 무엇인지를 확인할 수 있습니다.

요구사항 = 테스트 케이스 = 이슈

이것을 보통 요구 추적이라 이야기합니다. 예전에 엑셀을 많이 활용하던 시절에는 ID로 요구 추적을 하였고, 지라나 혹은 다른 도구를 통해 관리하는 경우에는 링크라는 기능을 이용해 요구 추적이 가능하게 되었습니다. SI에서는 요구 추적 문서를 별도로 사이트맵처럼 작성하기도 합니다. 일반적인 테스트 계획서에는 요구 추적에 관련된 내용을 포함하지 않습니다.

요구 추적이 중요한 것은 누구의 잘잘못을 추적하려는 게 아닙니다 88년도에는 그랬을지 몰라도 현재의 요구 추적은 배포 후 이슈가 발생했을 때 빠르게 대처하기 위함임을 알아야 합니다. 이슈를 해결하기 위해서 히스토리 정보가 필요하거나 어디 영향 범위에 내의 테스트가 부족해서 미처 발견하지 못한 이슈가 있었다던가 등등의 정보를 통해 운영/유지 보수를 원활히 하기 위함입니다.

테스트 계획서(전략 문서)를 위와 같이 작성한다면 테스트에 국한된 일부의 문서가 아닌 프로젝트 전체적으로 현황을 확인할 수 있는 문서로 활용될 수 있다고 확신합니다.

도움이 되셨길 바라고, 긴 글 읽어 주셔서 감사합니다.

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

품생품사(品生品死) — Thu, 27 Mar 2025 20:00:53 +0900

오프닝: 테스트를 분석한다고? 무엇을 설계한다는 거야?

잡썰

제가 가장 잘하는 영역인 테스트에 대한 이야기를 해보려 합니다. 블로글 외에도 전자책도 준비하고 있습니다. 물론 블로그에 모두 담지 못하는 내용들로 가득 채워서 작성하고 있습니다. 2024년부터 조금씩 준비하고 있었는데 올해는 어떻게든 완성을 해보려 합니다.

QA는 단순히 테스트만을 얘기하는 것은 아니다

본론의 시작

처음 시작은 가볍게 테스트에 대한 분석과 설계에 대한 이야기를 해보려 합니다. 테스트를 분석하고 설계 한다는 것은 앞으로 우리가 어떤 테스트 방법을 통해 어떻게 이슈를 발견할지를 결정하는 매우 중요한 부분입니다. 대부분의 QA나 테스트 엔지니어는 이 부분을 생략하고, 기획서나 화면 설계서, 스토리보드, 최근에는 피그마 문서 작성이 완료된 시점에 바로 테스트 케이스를 작성하고 있으실 겁니다.

잘못된 방법이라기보다는 좀 더 올바른 방법, 혹은 목적을 명확히 하는 테스트를 위해서는 반드시 테스트를 분석하고 설계 과정을 거치는 것을 추천합니다.

그래서 테스트 분석은 무엇이냐? 제가 생각하는 테스트 분석은 요구사항을 보고 어떤 테스트를 수행해야 커버 가능한... 그러니까 보통 QA가 말하는 커버리지인 그물망을 좀 더 촘촘히 할 수 있는 방법을 찾아내야 합니다. 이것과 동시에 이뤄지는 것이 바로 테스트 설계인 것입니다.

참고로 품질 보증과 테스트는 다릅니다. 캠패인과 같이 얘기하고 있는데 간단하게 설명하면 우리는 최종적으로 품질 보증을 위해 다양한 테스트 활동을 하는 것으로 정의할 수 있습니다. 여기서 테스트 활동은 ISTQB에서 정의하는 모든 테스트 설계 기법이 해당합니다.

ISTQB 실라버스의 테스트 설계 기법의 분류표

그렇다면 위의 모든 설계 기법을 알아야 실무에 적용할 수 있는가는 아닙니다. 우리는 무의식적에 테스트 설계 기법을 테스트케이스에 녹여서 작성하고 있기 때문인데요. 역으로 작성된 테스트케이스를 보면 동등 분할이나 경계값 분석 등 관련 케이스가 있다는 것을 알 수 있습니다.

다만, 여기서 중요한 것은 동등 분할이든 경계값 분석이 꼭 필요한 케이스에 활용할 수 있도록 분석 활동이 필요하다는 점입니다.

테스트 분석과 설계를 꼭 해야 하나?

테스트 분석을 하려면 두 가지 조건이 필요하다고 생각합니다.

첫 번째, 어느 정도의 테스트 설계 기법에 대해서 알고 있어야 합니다. 위에서도 잠깐 이야기했지만, 모든 방법을 다 알아야 하는 것은 아닙니다. 도메인이나 플랫폼 등 특성에 맞는 테스트 설계 기법이나 활용도가 높은 기법을 어느 정도는 알고 있어야 합니다. 혹은 내 노하우를 가장 잘 활용할 수 있는 테스트 설계 기법(필살기?)을 알고 있으면 좋습니다.

두 번째, 도메인 지식입니다. 도메인 지식이 없는 신입이나 이직 했는데 전혀 다른 분야라면 꼭 도메인 지식을 습득할 수 있도록 내부 교육을 받거나 관련 문서를 읽어야 합니다. 하지만 이것도 우리는 자연스럽게 너무도 익숙하게 알고 있습니다.

왜냐하면 신입은 신입이기 때문에 어느 정도 커리큘럼이 있거나 온보딩이 잘 되어 있을 것이기 때문인데요. 문제는 경력이 이직했을 때인데 이것도 이직하는 회사의 조사를 어느 정도 하고 면접을 봤을 것이기 때문에 큰 문제가 없습니다. 혹은 관련 도메인에 재잭 중인 지인 한 명쯤은 있을 거라 수습 기간 내에는 도메인 지식을 습득하는 데 큰 문제는 없을 거로 생각합니다.

그렇다면 테스트 설계를 어떻게 해야 할까요? 간단하면서도 쉽지는 않은 것 같습니다. 꼭 해야 하나? 라는 의문부터 생길 테니까요. 만약 지금 이 글을 읽고 있는 분이 사회 초년생이라면 요구사항을 읽어보고, 혹은 화면 설계서나 스토리보드를 보고 마인드맵이나 다이어그램을 그려보시길 추천해 드립니다. 특히 도메인 지식이나 플랫폼에 대한 특성 정보가 부족하다면 더더욱 해봐야 합니다.

처음에는 연습이 필요합니다. 나중에 테스트케이스를 작성하는 것도 마찬가지인데요. 익숙해질 때까지 도구를 통해 테스트를 분석과 설계하는 방법을 습득해야 하는 것입니다. 요구사항을 확인하기 위해서 어떤 테스트 방법이 커버리지를 최대한 끌어 올릴 수 있다고 분석이 되었다면 마인드맵 등을 이용해 설계를 해봅니다.

마이드맵 도구를 이용한 테스트 설계 예시

설계하면서 꼭 필요한 부분은 기능의 연관성입니다. 물론, 최근에 피그마를 통해 작성하는 디자인 문서에는 기능에 연관성을 한눈에 볼 수 있도록 작성하는 기획자나 디자이너가 있긴 합니다. 하지만, 우린 가장 좋은 상황은 배제하자고요. QA는 항상 최악의 상황에서 최고의 상황을 만들어야 본전을 하는 거니까요.

연관성을 찾다 보면 어떤 테스트가 필요할지 보이게 됩니다. 예를 들어 A 페이지에서 B 페이지가 넘어가는 순간 페이지 로딩이 필요한 부분이라면 성능 기준이 명시되어 있어야 하고, 성능 테스트는 어떻게 해야 할지를 고민해 보는 것입니다. 또 다른 경우로는 A라는 기능이 a, b, c 플랫폼에서 네이티브로 개발된 부분이라고 한다면 a, b, c에 대한 테스트케이스는 어디에 작성해야 테스트 흐름을 망치지 않고, 테스트를 수행할 수 있을지 고민하는 것입니다.

이러한 고민들을 할 수 있도록 테스트를 설계해야 합니다. 위 이미지에서도 볼 수 있듯이 노란색으로 되어 있는 부분은 테스트 환경 부재 혹은 테스트 데이터 부재로 인해 테스트할 수 없는 영역인 것을 설계 단계에서 미리 알 수 있었습니다. 그러면 해당 케이스가 작성되기 전에 테스트할 방법을 개발팀에 공유하고 최대한 배포 전 테스트가 될 수 있도록 상황을 만들어야 하는 것입니다.

물론 사회 초년생은 잠깐 언급했듯이 이러한 상황들이 익숙해질 때까지 연습해야 합니다. 그러면 경력이 꽉 찬 저와 같은 사람들은 어떻게 해야 하나요?라고 물어보실 수 있겠죠? 물론 필요하다면 문서를 정리해야 합니다. 다만, 선택이 될 뿐인 거죠.

익숙해질 때까지 해보는 거야

제가 생각하는 설계 단계의 스킵은... 우선 분석은 필수입니다. 분석해야 설계 단계를 스킵할 수 있을지 판단할 수 있기 때문입니다. 그래서 설계 단계의 스킵을 하는 조건은 도메인 지식이 많이 알고 있거나 해당 신규 개발이나 수정 개발되는 영역의 영향 범위를 명확하게 알고 있다면 생략이 가능합니다.

또 하나는 관리자로 계신 분들도 후배님들을 위해 분석과 설계에 대한 방법을 알려주고, 리뷰를 통해 좀 더 그물망이 촘촘해질 수 있는 테스트 설계가 될 수 있도록 가이드를 해주는 것도 하나의 역할이 되지 않을까 생각합니다. 나만 알면 자료이고 모두가 알면 지식이 되니까요.

간단하게 테스트를 분석과 설계하는 방법에 대해서 알아보았습니다. 상세 테스트 설계 기법은 개인적으로 공부해 보시길 바랍니다. 'ISTQB 테스트 설계 기법'으로 구글링만 해도 많이 나오고, GPT한테 물어봐도 잘 설명해 줍니다.

앞으로 조금씩 하나하나 5분 이내에 읽을 수 있는 테스트 지식에 대해서 제가 알고 있는 정보를 공유해 드리도록 하겠습니다. 읽어 주셔서 감사합니다.

[기회] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 11년에서 12년 차)

품생품사(品生品死) — Tue, 25 Mar 2025 20:00:25 +0900

오프닝: 기회라고 생각한다면 망설임은 사치일 뿐

인생을 살면서 나의 인생에 영향을 주는 기회가 몇 번이나 될까요?

기회는 모두에게 공평하지 않다는 말은 사실이다

물론 기회라는 것은 내 인생에 의미를 담고 살아가는 사람들에게 한정적이라 생각합니다. 예를 들면 1000억이 있고, 특별히 신경쓰는 부분도 없고, 걱정이 없는 상황이라고 생각을 해봅시다. 기회라는 것이 필요할까요? 7억 하는 롤스로이스가 1% 할인한다는 것이 이런 사람들에게 기회라고 생각이 될까요?

물론 경재적인 것에 대한 기회만 기회라고 할 수는 없습니다. 동네? 지역구에서 신임을 받고 유명인이라면 명예욕으로 출마를 생각할 수도 있고, 나의 경쟁 상대가 없는 시기라면 기회라고 생각할 수도 있을겁니다. 배우라면 유명 배우나 작가분의 대본을 받았을 때 기회라고 생각할 수도 있고요.

기회라는 것은 간절함이 있는 사람들에게 생기는 로또같은 게 아닐까요? 아무런 걱정과 생각이 없다면 기회라는 것은 무의미하다고 생각하기 때문인데요. 다만 기회에 잡느냐 혹은 그냥 흘려 보내냐는 차이가 있습니다. 진짜 로또는 로또를 사야지 기회가 생기는 것과 같이??(이게 비유가 맞나 )

다시 돌아와서 기회를 잡았다고 생각하는 일들을 좀 풀어보려 합니다. 사실 모든 상황이 종료되고 나서 아? 그 때 그게 기회였구나? 내가 기회를 잡은거였구나? 가 맞는 것 같습니다. 당시에는 간절함과 무엇이든지 해내고 싶은 마음이 더 커서 나에게 주어진 것들이 좋은 기회인지도 모르고 무작정 아무런 생각없이 "제가 하겠습니다!" 했던 것 같습니다.

저는 개인적인 성향이 남들이 하지 않는 것에 대해서 그냥 조건 없이 "제가 하겠습니다." 합니다. 이 자세는 제 삶을 바꿔놨다고도 생각하는 자세 중에 하나입니다. '고민할 시간에 그냥 해보자'라는 자세는 남자라면 군대에서 배웠자나요? 전 군대 다녀오고 남은 거라고는 마음가짐 하나라도 남아서 다행이다라고 생각합니다. (물론, 짬이 좀 찾을 땐 남들 잘 때 산업기사 공부하고, 그랬더라는... 추억이 있긴 합니다.

교원에서는 어떤 기회가 있었고, 결론이 어떻게 되었는지 말씀 드리겠습니다.

이전 글도 참고해주세요.

[난관] QA, 테스트 엔지니어의 연봉 정보 공개!!(ft. 9년의 시작)

오프닝: 관리의 결과 = 성과어느덧 10년 차에 왔습니다. 경력이 많다면 많고, 적다면 적은 그런 시기인 것 같습니다. 이 말은 10여 년 동안 정말 최선의 노력을 다해서 그래도 어디 가서 QA라고

qa-testing.tistory.com

나에게 왔던 '기회'라는 녀석은 노다지였다.

교원에 입사한 직후. 그러니까 1월에 입사해서 4월에 있었던 일입니다. 회사에서는 ISO/IEC 20000 ITSM(IT Sevice Management) 인증을 받으려고 TFT가 진행 중이었습니다. 당시 TFT에 활동할 사람을 뽑고 있었는데 팀에서는 지원하는 사람이 아무도 없었습니다. 그래서 저는(이전 글을 읽어보셨으면 예상하셨게지만...) "제가 해보겠습니다."하고 손을 들었습니다.

하지만, 당시 팀 내의 진급(저를 제치고 진급한 그 분) 대상자가 있었기 때문에 그분이 했으면 한다는 팀장이 반강제적인 의견이 있었습니다. 그분도 진급에 대한 생각이 없을 수는 없었기 때문에 TFT를 하기로 했습니다. 다만, 재미있는 것은 TFT 정원이 10명이었으나 QA라는 포지션도 필요할 것 같다는 TFT 팀장의 판단하에 정원을 11명으로 해서 저도 함께할 수 있게 되었습니다.

jungminlee - Certificate

제가 당시 손을 들지 않았다면 이런 기회를 잡을 수 있었을까요? ITSM은 프로젝트 관리를 위해 많은 정보와 지식을 습득할 수 있었고, 저는 정보시스템감리를 대학원에서 배웠기 때문에 연관도 있고 재미있게 TFT 활동을 했습니다. 차라리 많이 활동하지 못한 게 아쉬울 정도라고 할까요? QA 영역은 '서비스 수준 관리(SLA)' 정도가 다라서 크게 활동할 일은 없었습니다.

하지만, bsi라는 기관에서 교육도 받고, 시험도 봐서 자격증(ITSM 선임 심사원)도 취득할 좋은 기회가 되었습니다. 향후 내부 심사와 사후 심사 대응해 TFT를 참여하게 되었습니다. 이것은 대기업은 대부분 그럴 텐데 승진 포인트를 채우는 데 큰 도움이 되었습니다. 영국 기관 발급이라 매년 갱신(169유로)을 해야 하는 부담스러운 자격증이지만, 그래도 뭔가 뿌듯한 자격증을 취득할 수 있어서 매우 좋은 기회를 잡은 시간이었다고 생각합니다.

이후 2년 차에는 순조롭게 승진이 되었습니다. 물론 그사이에 품질률을 전사 프로젝트의 KPI로 정립하게 되었고, QA 파트로 분리되어 파트장도 되었습니다. 파트원은 5명이 되었고, 필요시 아르바이트를 채용해서 많게는 7명까지 파트를 운영하게 되었습니다.

KPI로 측정하여 개발팀의 평가 지표로 활용

그리고 만나게 된 프로젝트가 '아이캔두'라는 프로젝트를 만나게 되었습니다. 아이캔두 프로젝트는 교원에서 사활을 걸었다고 해야 할 만큼 큰 프로젝트였습니다. 당시 기억하기로는 개발비 약 80억, 사업비 400억 정도의 프로젝트로 얼핏 들은 기억이 있습니다. 하지만, 초기 QA의 투입은 없었습니다. 개발이 어느 정도 진척되고 외주 개발사의 상태를 명확하게 알 수 없는 순간 내부 QA를 해서 품질률을 측정해 보자는 니즈가 생기게 되었습니다.

그래서 부랴부랴 품질 계획을 수립하고, 기획서 분석을 통해 테스트케이스를 작성하였습니다. 2개월 동안 5명이 2,500여 건의 테스트케이스를 작성했던 것으로 기억합니다. 기획서는 50~100장 사이의 PPT 파일이 3~40개 있었고요. 분량이 어마어마했습니다. 테스트케이스 작성이 완료된 시점에는 거의 출시가 임박한 날짜였습니다. 7월 출시 예정이었는데 6월 말쯤 테스트를 하게 되었습니다. 테스트 결과는 처참했습니다. 품질률이 62~3% 정도 측정이 되었고, 이는 바로 팀장님을 통해 부문장님까지 보고 하게 되었습니다.

부문장님은 현업들과 협의하고, 외주 개발사들과 출시 여부를... 사실 여부를 따질 것도 없이 이건 출시 못 하는 상황이었습니다. 결과적으로 10월까지 추가로 개발할 시간이 주어지고, 저희는 10월 초에 다시 테스트하게 되었습니다. 기능은 어느 정도 제외하고도 75~80% 초반의 품질률이 측정되었던 것으로 기억합니다.

품질률을 관리해야 정량적으로 제품을 바라볼 수 있다

역시나 출시하기에는 턱 없이 부족한 품질률이었습니다. 재협의를 통해 12월에 다시 측정하자는 결론이 나왔습니다. 그냥 출시 지연이라 생각하실 수 있는데 30만 어린이들이 사용하는 프로덕트이고, 어린이들의 부모님과 약속된 프로젝트라서 지연하게 될 때마다 사업비는 점점 불어나고 있다고 생각하시면 됩니다. 회사로써는 큰 손해이지만 브랜드 이미지와 고객의 신뢰성을 잃지 않기 위해 출시 지연이라는 결정을 한 것입니다.

이것은 매우 중요합니다. 단순히 제가 측정한 품질률 숫자를 보고 이렇게 큰 결정을 할 수 있었으니까요. 물론 파트원들의 큰 노고는 저도 잘 알고 있습니다. 모두가 테스트를 잘 수행해 주었기 때문에 신뢰성 있는 품질률을 측정할 수 있었고, 저는 자신 있게 보고할 수 있었기 때문입니다.

12월은 더 이상 미룰 수 있는 상황이 아니었습니다. 교육이라는 도메인 특성상 학사 일정이 시작되는 1월에는 변경할 수 없다는 조건이 있기 때문인데요. 그래서 12월의 품질률 측정은 매우 중요한 지표라고 할 수 있습니다. 최종적으로 품질률을 측정했을 때 92% 정도 측정이 되었습니다. 여기서 중요한 것은 최대한 이슈를 알고 출시해야 합니다. 알고 있는 이슈에 대해서 언제까지 어떻게 해결할지 Workaround를 명확히 계획해서 공유해야 합니다.

결과적으로 만족하는 품질률은 아니었지만, 성공적으로 출시를 하게 되었습니다.

만족할 수 없지만 성공적으로 출시로 평가 받게됨

이후 매우 재미있는 상황들이 생겼습니다. 회사에서 중요하게 생각하는 프로젝트에서 QA가 어떤 활동을 하고, 어떤 영향력으로 일을 하고 있는지 증명하는 시간이 되었습니다. 그래서 창립 이례적으로 대표님께 품질 활동에 대한 보고할 기회도 생겼고, 평가도 최고점을 받을 수 있었습니다. 저 개인적으로도 자신 있게 얘기할 수 있는 경력이 생겨서 뿌듯했고, 파트원들 모두 좋은 평가를 받게 되어 힘들었지만, 행복한 시간을 보낼 수 있었습니다.

이렇게 3년이라는 시간 동안 많은 것을 경험하고, 경험은 진정한 경력이 되는 것을 느낄 수 있는 시간이었습니다. 교원이라는 회사는 많은 것을 큰 규모로 프로젝트를 진행할 수 있는 회사라 생각합니다. 하지만 전 이직을 선택하게 되었는데요. 이때가 딱 코로나가 확산하기 시작한 시점이었습니다.

많은 것들이 만족스러웠지만 트랜드라고 해야 할까요? 스타트업이라는 회사의 특성을 경험해 보고 싶은 생각이 들었습니다. 딱, 나이가 불혹이되던 시점이라~ 더 늦어지면 내 인생에 스타트업을 경험할 수 없을 것 같다는 생각이 들었습니다. 그래서 안정적으로 다닐 수 있고 앞으로 더 성장할 수 있었지만, 다양한 경험을 위해 이직을 결심하게 되었습니다.

이직 전 교원에서 최종적으로 수령했던 연봉은 영끌해서 6천만 원 초반 정도 되었습니다. 12년 차에 중견기업의 연봉이라 생각해 주시면 됩니다. 물론, 저는 사회생활이 조금 늦은 걸 생각하면 -500만 원 정도라고 생각해서 보통은 6천만 원 중반 정도 받지 않을까 생각합니다.

이후 직장은 2025년 현재 재직 중인 회사이기 때문에 나중에 이직을 하게 된다면 이후 글을 연재해 보도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

요약 : 포워딩 이직, 스타트업 이직, 경력직 이직, 경력 이직, 에듀윌 면접, 항해 99 취업, 에듀윌 대기업, 데이터 엔지니어 취업, 대기업 이직, 취업, 취준생, 멘토링

[난관] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 10년 차의 시작)

품생품사(品生品死) — Sun, 23 Mar 2025 20:00:24 +0900

오프닝: 관리의 결과 = 성과

어느덧 10년 차에 왔습니다. 경력이 많다면 많고, 적다면 적은 그런 시기인 것 같습니다.

이 말은 10여 년 동안 정말 최선의 노력을 다해서 그래도 어디 가서 QA라고 얘기할 수 있는 정도가 되었다면 정말 잘 걸어온 길이라 생각되고, 적다는 의미는 그냥저냥 누군가가 시키는 일만 하다가 지금도 누군가 일을 주지 않으면 아무것도 못 하는 상황이면 경력이 많다고 볼 수 없겠죠?

경력은 연차만 채운다고 경력이라 할 수 없는 것 같습니다. 그래서 누군가는 3년 차에 팀장의 경험을 해서 10년이 되었을 때는 눈 감고도 프로젝트를 관리할 수 있는 사람이 되기도 하고, 3년 차에 자동화 경험을 할 수 있게 된 사람은 10년이 되었을 때 기능뿐만 아니라 성능 테스트도 할 수 있는 그런 사람이 되어있기도 합니다.

경험은 기회가 왔을 때 혹은 기회를 만들었다면 그것을 인정받을 수 있을 정도로 해내지 않았다면 어디 가서 경력이 있다고 말하기는 어려울 것이라 생각합니다.

경력은 시간만 보낸다고 생기는 것이 아니다

저는 그래도 나름 경력을 잘 쌓아온 것 같습니다. 자신 있게 얘기할 수 있는 것은 그 누구보다도 경험이 많다라고 말할 수 있습니다. 물론 그냥 회사만 다녔다면 이직을 많이 한 사람보다 경험이 적어서 경력이라고 말하기 민망할 수 있을 것 같지만 저는 2018년 10월, 바로 딱 10년차 쯤 되었을 때부터 N잡을 시작했습니다. 코로나 1년 전에 먼저 시작을 했던 거죠.

기회?라고, 해야 할까요. 이전 직장이었던 메디트에서 RA 하시는 형님이 크몽에 번역일을 맡기는 것을 보고, 테스트도 충분히 N잡이 가능할 것이라는 생각을 했습니다. 그래서 바로 알아보고 실행에 옮겼었는데요. 처음에는 재능넷을 알아보는데, 카테고리에 QA나 테스트 관련 카테고리가 없었습니다.

크몽에는 QA, 테스트 카테고리가 있어서 서비스를 등록하고 시작을 했습니다. 사실 처음 1개월 동안은 아무런 작업 요청이 없었습니다. 당시 카테고리에 서비스가 5개인가 있었는데 아무도 이용하지 않았었어요. 1개월이 조금 지나고는 문의가 시작되고, 운이 좋게도 작업을 하게 되었습니다.

N잡을 말씀드리는 이유는 크몽이라는 플랫폼을 통해 1년에 적게는 30여개 많게는 3~50여 개의 프로젝트를 할 수 있게 되었습니다. 처음에는 앱/웹에 대한 테스트하고, 결과 리포트를 공유해주는 정도에서 점차 테스트케이스를 작성해서 품질률을 측정해 주는 정도의 서비스도 하게 되고, 투잡 전자책도 써보고, Jira 강의, 세팅도 하게 되었습니다.

프로젝트 경험했던 것을 그냥 포트폴리오로 정리를 하게 되었습니다. 많은 정보를 남기는 것은 고객사에 피해를 줄 수 있는 부분이기 때문에 그냥 '무슨 프로젝트 했었다' 정도로 정리를 하게 되었습니다.

[실전 취업/이직 준비] 서류 심사에 합격할 수 밖에 없는 경력 기술서 작성하는 방법!!

경력 기술서 잘 작성하는 방법은?신입이라면 사실 경력이라고 할게 별로 없습니다. 신입은 가장 중요한 게 이 전 글에도 말씀드렸듯이 포부가 가장 중요합니다. 포부는 자기소개서에 작성해야

qa-testing.tistory.com

품생품사의 SW 품질 이야기

크리에이터링크에서는 HTML을 몰라도 누구나 직접 반응형 홈페이지를 무료로 제작 할 수 있습니다. 홈페이지 제작, 홈페이지 만들기

swqa.creatorlink.net

그리고 중요한 것은 N잡의 마음가짐이라 생각합니다. 처음에는 제가 잘하는 테스트를 스타트업이나 작은 규모의 회사에서 테스트나 QA를 하지 못하고 출시했을 때의 걱정? 두려움을 최소화해 드리기 위해... 나는 경험을 의뢰인에게는 품질에 대한 자신감을 주는 목적으로 N잡을 시작하게 되었습니다.

7년이 지난 2025년에도 그 마음가짐은 동일합니다. 의뢰 비용도 7년 전과 동일합니다. 항상 의뢰인 분들께 최대한 제가 알고 있는 품질 지식을 전달해 드리기 위해 노력하고 있습니다. 제시간이 없어서 조금은 힘들기도 하지만 문제없이 출시했다는 피드백을 받을 땐 재직 중인 회사에서 출시 했을 때보다 기쁨이 2배 그 이상인 것 같습니다.

10년쯤 한 직업으로 계속 경력을 잘 쌓아왔다면 이러한 마음가짐. 나만? 이라는 생각보다 나의 역량이 누군가에게 도움을 줄 수 있는지가 매우 중요한 것 같습니다. 그만큼 나는 성장했다고 볼 수 있기 때문입니다.

그래서 다양한 경험을 통해 12년 차에는 엑셀 문서 하나로 품질을 정량적으로 측정할 수 있는 사람이 되었습니다. 이번에는 제가 가장 많이 성장했던 회사 경험에 대한 이야기입니다.

처음 이 글을 보신 분들은 이전 글도 참고해 주세요.

[도약] QA, 테스트 엔지니어의 연봉 정보 공개!!(ft. 8년 차)

오프닝: 품질, 테스트 관리 업무의 첫 시작7년 차까지의 경험을 바탕으로 테스트 관리부터 품질 관리의 업무를 본격적으로 시작하게 되었습니다. 물론, 아직까지 파트장이나 팀장이라는 타이틀

qa-testing.tistory.com

10년 차를 시작하면서 ~

오프닝이 조금 길었던 것 같습니다.

9년 차이자 8번째 회사는 '교원'이라는 회사입니다. 교직원 협회는 아니고, 구몬과 빨간펜으로 유명한 그 회사입니다. 취업에 대한 노하우? 팁을 잠깐 말씀드리면 ~ 경력이 좀 쌓이고, 적지 않은 나이가 되면 될수록 새로운 회사에 입사하기가 점점 어려워집니다. 대부분 이후, 여기서 이후는 관리자급 경력이 되면 추천이나 지인을 통해서 이직하는 경우가 더 많은 게 현실입니다.

교원이라는 회사에는 아는 사람이 한 명도 없고 정말 순수하게 추천도 아닌 절차를 밟아서 입사하게 되었습니다. 당시 2차 면접은 회장님 면접이었더라는 코로나 이후로는 회장님을 만나 뵐 수는 없다고 합니다.

2차 면접이 회장님과 전무님이 면접관이었다

제가 다녔던 회사 중에는 제일 규모가 있는 회사였고, 꼭 가고 싶은 회사 중의 하나였습니다. 그래서 입사했을 때 만족감이 높은 회사이기도 했습니다. 이전 직장인 메디트 입사 전에도 한번 지원을 했었고, 두 번째 도전에 합격하게 된 회사입니다. 게임 회사에 가고 싶었을 때는 스마일게이트에 계열사 3개 회사에 3번 면접을 봤지만 합격하지 못한 경험도 있습니다. 일반 소프트웨어?의 품질과 게임은 조금 다른 면이 있긴 합니다. 그래서 보이지 않는 취업의 문턱?이 있습니다.

이건 어디나 마찬가지일 수 있는데 도메인 경험이 있는 인재를 채용하는 것이 회사의 입장에서는 적응도 빠르고, 노하우가 있을 것이라는 기대감이 있기 때문에 소프트웨어라는 베이스는 같을 수 있지만 도메인이 다르면 남들보다 조금 더 노력해야 취업/이직이 가능하다는 것을 명심하시길 바랍니다.

다만, 전 지금까지 동일한 도메인에서 일한 경험은 없습니다. 모두 다 다른 도메인이었고 N잡을 하면서는 게임 테스트도 해보았습니다. N잡이 이런 매력은 있는 것 같습니다. 꼭 해보고 싶었던 경험을 간접적으로 경험해 볼 수 있는 매력??

GPT가 정말 내마음을 잘 아는 것 같네요

교원에 입사 당시에는 QA 포지션을 가진 동료가 1명뿐이었습니다. 제가 입사하고, 2명서 QA로 일을 해야 하는 상황이었습니다. 지금부터 드리는 얘기는 어쩌면 조직을 키워나가는 해답일 수 있습니다. 누군가는 운이 좋아서였다고 말할 수도 있을 것 같습니다. 사회생활에서 성장은 운과 역량이 잘 맞아떨어졌을 때 큰 시너지가 나는 것이라 생각합니다.

제일 먼저 한 것은 메디트에서와 마찬가지로 상황 파악을 먼저 했습니다. 교육 도메인은 처음이다 보니 정말 잘 작성된 기획서와 WBS라는 것을 처음 보게 되고 조금은 새로운 것들을 접하게 되었습니다. 이런 데이터들을 잘 활용해서 품질을 잘 관리 할 수 있는 방법은 무엇일까? 스스로에게 질문하였습니다.

그리고 또 하나 새로운 점은 내부 SI 방식의 업무를 하고 있다는 점이었는데요. 팀별로 예산과 M/M 내에서 발주처가 있고, 고객과 현업이 있고, 개발사가 외부에 있기도 하고 ~ 정말 지금까지 경험하지 못했던 업무 수행 방식의 회사였습니다. SI의 경험이 없는 것은 아니었지만 그때는 주는 대로 테스트만 하던 시절이었고, 지금은 관리를 해야 하는 상황이라 매우 다르게 느껴졌습니다.

교원은 1년에 10~20개의 새로운 프로덕트를 만드는 회사입니다. 보통 스타트업이나 중소기업을 비교하면 하나의 프로덕트를 개선하고 기능을 추가하거나 조금은 더 나아가 파생 프로덕트를 만드는 방식입니다. 정리를 하면 기능 단위 관리에서 프로덕트 단위의 관리를 해야 하는 것입니다.

일은 그냥 항상 많다. 누군가는 빠르게 누군가는 천천히 해결할 뿐

그래서 모수를 뽑아보니 2019년 기준 150개의 프로덕트, 250개의 앱(Android/iOS/교원 자체 스토어 포함)을 관리해야 했습니다. 또한, 기존에 있던 QA는 테스트케이스 없이 요청해 오는 대로 테스트만 수행하던 상황이었기 때문에 품질률에 대한 것은 상상할 수도 없던 상황이었습니다.

기존에 있었던 동료는 어떤 마음이었을지 상상이 되었습니다. '무엇을 할 수는 있었을까?' 재미있는 것은 이렇게 고민하고 있는 상황에서도 테스트 요청을 계속 들어오고 있었습니다. 새로운 프로덕트는 M/M를 넣어야 했고, 모든 것이 정말 빠르게 움직이고 있었습니다.

그리고 반대로 생각해 보니 좋은 상황이기도 했습니다. '관리해야 하는 프로덕트를 금방 다 만져 볼 수 있겠는데?'라는 생각을 했었던 것 같습니다. 그래서 프로덕트 리스트를 뽑고(약 150개) 테스트케이스를 작성하기로 계획을 세웠습니다. 공장같이 테스트케이스를 작성했던 것 같습니다. 그렇게 1년 정도 작업했을 때 대부분의 프로덕트의 테스트케이스를 작성했던 것 같습니다.

2명이 했던 프로덕트 배포 막대 그래프

중요한 건 2명이 이 모든 일을 가능하게 했다는 점입니다. 리소스의 트레이드 오프를 아십니까? 도는 아니예요 리소스가 많으면 많을수록 회사는 당연히 더 많은 퍼포먼스를 내기를 기대합니다. 그래서 보통은 많은 일을 주고 지칠 때까지 굴리다가 죽기 직전에 충원을 해줍니다. 그래야 숨통이 틔고 더 많은 일을 줄 수 있기 때문입니다.

하지만 현재 상황은 5명이 해도 힘든 일을 2명이 해내고 있다는 것을 당시 파트장님, 팀장님, 개발 팀장님들과 부문장님까지 알게 되었습니다. 아참? 참고로 입사 당시에는 저는 아무런 보직 없이 팀원으로 입사했습니다. 그래서 자연스럽게 팀장님이 먼저 '사람 필요하지?'라는 말이 먼저 나오는 상황을 만들게 되었습니다.

1년이 지난 후 2020년 1월에 신입 공채 인원 한 명이 충원되었고, 경력직(계약직) 직원도 충원되면서 4인 체계를 갖추게 되었습니다. 그리고 교원 창사 이례 처음으로 QA 파트장이 생기는 일도 생겼습니다.

팀원이 충원이 자연스럽게 되고, 파트장의 직책도 될 수 있었던 것은 단 하나 '성과'로써 얘기했다는 것입니다. 저는 성과를 관리자들이 좋아하는 숫자로 얘기를 했습니다. 기존에는 없었던 테스트케이스를 작성하고, 이슈를 체계적으로 관리하면서 프로덕트의 품질률을 보여드림으로써 팀의 KPI가 수립되고, 성과 달성을 통해 얘기했던 것이었습니다.

당시 관리했던 일부 내용(아래 300번까지 있습니다)

그러면 매일같이 야근했겠네? 주말마다 출근했겠네? 생각하실 수도 있을 것 같습니다. 기존에 있던 동료는 팀장님이 퇴근하기 전에 자리에서 못 일어나는 정말 보수적인 문화를 가진 조직이었습니다. 성과로써로 얘기하기까지에는 테스트 프로세스를 수립하고, 품질 프로세스를 정립했기 때문에 가능했으며 체계적인 품질 활동은 개발자는 물론 QA 인원들도 야근과 주말 출근을 자주 하지 않아도 되는 상황을 만들게 되었습니다. 도메인 특성상 야근이 필요할 때는 당연히 했습니다.

중요한 것은 기존보다 현저히 줄었다는 것은 사실이고, 5인 체계가 되었을 때는 거의 야근 없이 일하는 상황까지 만들게 되었습니다.

9년 차에 가장 큰 성장은 '아무도 할 수 없다고 생각한 일은 해냈다.' 입니다. 위와 같은 일을 어떻게 성장시키고, 발전시켰는지는 다음 글에 작성하도록 하겠습니다.

아참? 교육 입사 당시 연봉은 4,700만 원이었습니다. 메디트에서 받았던 4,400만 원에서 300만 원 올리고 이직했었는데요. 사실 입사 당시 조건이 1년의 성과를 보고 진급의 조건이 있었는데 좋은 성과를 냈음에도 다른 사람의 진급에 밀려서 진급하지 못했었습니다. 입사 전 회사와의 약속은 믿지 마세요. 절대! Never!!. 일은 재미있고 좋았고... 파트도 성장하고 있고 해서 다 좋았는데 연봉이 저를 막기도 했습니다. 이때 힘이 되었던 사람이 한 명 있었는데요. 입사 동기 형이 있었는데 큰 힘이 되었습니다.

제가 항상 얘기하는 인연의 힘은 내가 힘들 때 가장 큰 힘이 되어줍니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[도약] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 9년 차 날아올라)

품생품사(品生品死) — Sat, 22 Mar 2025 20:00:19 +0900

오프닝: 품질, 테스트 관리 업무의 첫 시작

8년 차까지의 경험을 바탕으로 테스트 관리부터 품질 관리의 업무를 본격적으로 시작하게 되었습니다. 물론, 아직까지 파트장이나 팀장이라는 타이틀을 달지는 못했습니다. 팀장의 서포터로서의 관리 업무를 하게 되었는데요.

3년 차(나모인터랙티브 재직 당시)에 팀장님의 부재로 잠시나마 팀장의 역할을 했던 적은 있었습니다. 기억에는 너무도 부담되었던 기억이 있습니다. 퇴사했던 팀장님이 너무도 좋은 사람이었고, 일도 잘하고, 배울 게 많았던 사람이어서 제가 그 자리를 대신할 수 없을 것 같다는 부담이었던 것 같습니다.

지금? 그러니까 나모를 퇴사한 지 10여 년이 지난 지금은 그 팀장님과 호형호제하면서 가끔 만나서 술 한잔하는 사이가 되었지만요.

하여튼 8년 차쯤 되었을 때는 주도적으로 업무를 할 수 있어야 하는 것 같습니다. 위에서 시키는 일만 해서는 안 되는 시기라 생각합니다. 주도적으로 했던 업무의 성과가 앞으로 내가 관리자로서의 역량을 평가할 수 있는 좋은 밑거름이 될 거예요.

본격적인 관리 업무의 시작

그럼, 바로 시작하기 전에 이전 글도 참고하세요.

[성취] QA, 테스트 엔지니어의 연봉 정보 공개!!(ft. 5년에서 7년 차)

오프닝: 품질, 테스트 관리를 선택한 나이전 글에서 잠깐 언급했듯이 저는 관리라는 업무를 선택하였습니다. 개발은 좋아하지만 관리가 재미있다고 생각했습니다. 사람을 워낙에 좋아하는 성격

qa-testing.tistory.com

9년 차 경력 사항

9년 차에 직장은 의료를 도메인으로 하는 회사였습니다. 회사명은 '메디트'이고, 구강 3D 스캐너를 주력으로 판매하는 제조업입니다. 이 회사는 나름 업계에서는 유명한 회사이기도 하고, 동계 올림픽의 스켈레톤 메달리스트인 '윤석민'의 아이언맨 헬멧을 만들어 준 회사이기도 합니다. 기사도 있어요.

메디트에 입사하여 가장 먼저 했던 것은 상황 파악이었습니다. 테스트는 어떻게 하고 있는지? 품질 관리는 어떻게 하고 있는지? 팀원들은 어떤 업무를 어떻게 하고 있는지? 등등 어떤 부분을 잘하고, 부족한 부분은 어딘지를 분석했습니다. 이것은 관리자로서의 첫 업무?라고 생각합니다.

관리자로서 일을 하려면 현재 상황을 파악하는 것이 매우 중요합니다. 제가 생각하는 관리자는 팀원들을 잘 이끌어서 최대한의 성과를 낼 수 있도록 하는 사람이라고 생각합니다. 가장 안 좋다고 생각하는 리더는 업무에 1도 기여 안 하고 팀원들의 성과를 자기 혼자만의 성과로 보고하는 사람이라 생각합니다. 막말로 그냥 리더의 자질이 없는 사람이라고 생각해요. 그런 리더하고 일하고 있다고 한다면 바로 이직하시길 바랍니다.

그렇다고 지금 메디트의 리더가 그렇다는 것은 아닙니다. 2025년 현재 이 글을 쓰는 순간에도 그 당시 2018년도에 함께 일했던 동생도 아직 잘 다니고 있기 때문에 명확히 말씀드릴 수 있습니다. 만약, TO가 있다면 추천하고 싶은 회사이기도 합니다. 똑똑한 분들이 많은 회사이고 매출도 안정적인 회사이기 때문에 추천할 수 있는 회사이기도 합니다. 찾아보니 실시간으로 좋은 기사들이 많네요. QA 채용(계약직) 공고도 있네요. 모집 요강은 읽고 있는 지금 마감될 수 있으니 모집 요강만 참고해 주세요.

[실전 이력서 예시] '메디트(Medit)' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 구강 3D 스캐너 - 메디트(Medit)이력서의 자기소개서는 전략입니다.- 자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.- 분석 후 결론부터 작성하고, 설명

qa-testing.tistory.com

그리고 수행한 업무는 테스트케이스를 작성했습니다. 기존에는 테스트 요청이 오더라도 테스트케이스 작성 없이 주먹구구식으로 테스트하고 있었고... 이러한 방법은 품질을 챙기는 데 1도 도움이 되지 않기 때문에 체계를 잡아가는 것이 최우선이었습니다.

간혹 1인 QA인데 무엇을 먼저 해야 할지 모른다는 분들이 있습니다. 그럼 전 명확하게 "테스트케이스를 작성하세요."라고 말씀드립니다. 조건은 테스트케이스가 없다면 프로덕트 전체 테스트케이스를 작성하라고 말씀드리고, 기존에 작성된 테스트케이스가 있다면 현행화하라고 말씀드립니다. 이 테스트케이스는 프로덕트의 현재의 스펙이 되고, 향후 테스트 수행 시 리그레이션(회귀) 테스트할 때 유용하게 활용됩니다.

관리자는 프로젝트나 서비스의 현재 상태를 파악하는 것이 매우 중요합니다. 테스트케이스를 작성하면서 도메인 정보를 습득할 수도 있고, 미처 발견되지 못한 이슈를 발견할 수도 있습니다. 이러한 과정은 회사에 적응하는 데도 큰 도움이 되기도 합니다. 물론, 함께 일하는 사람들과 친해지는 게 1순위입니다.

그리고 처음 주도적으로 업무를 해야 하는 미션이 떨어졌습니다. 그것은 바로 'e2e 테스트 자동화를 구축하라' 였습니다. 매우 좋은 기회였습니다. 비스텔 재직 당시에 제가 했던 업무는 자동화 시나리오를 작성했었는데요. 자동화 테스트에 활용되는 시나리오는 요구사항을 검증하기 위한 테스트케이스와는 다릅니다. (이건 제가 나중에 기술 블로그로 상세히 다룰 예정)

그래서 가장 먼저 했던 일은 회사에서 원하는 자동화가 어떤 것인지 파악하고, 몇몇 자동화 도구(솔루션)를 판매하는 회사를 벤치마킹하여 컨설팅을 받았습니다. 비용과 확장성을 고려해서 당시 선택했던 도구는 TestComplete라는 자동화 도구였습니다.

자동화 도구 도입 전에 해야 하는 일은 테스트 자동화 영역에 대한 시나리오를 먼저 설계하고 작성하는 것이었습니다. 설계라는 표현을 쓴 것도 매우 매우 중요하고, 내용이 많기 때문에 지금 작성할 내용은 아닌 것 같아서 나중에 상세히 다뤄보도록 하고, 지금은 테스트 자동화 구축을 위한 시나리오를 별도로 작성했구나! 정도로 알아주시면 좋을 것 같습니다.

이후 파일럿으로 일정 범위를 선택하여 시나리오대로 테스트 자동화를 개발하고, 테스트 수행에 대한 결과. 그리고 ROI(투자 대비 성과)를 대표님께 보고해서 좋은 평가를 받았던 기억이 있습니다. 사실 당시 최소 인력으로 제가 공부하고 커리어를 쌓는다는 마음으로 열씨미 했던 것 같습니다. 참고로 e2e 테스트 자동화는 변경에 매우 민감하기 때문에 유지보수 비용이 매우 큽니다. 이것은 나중 일이니까요?

e2e 테스트는 ROI가 매우 좋지 않습니다

하지만, 이것은 매우 중요한 경험이자 역량 강화가 되었습니다. 특히, 회사의 니즈에 의해서 시작할 수 있는 기회는 많지 않을 것이라 생각합니다. 요즘은 자동화 개발 못 하면 안 된다는 인식이 있다고 생각합니다. 이건 오해가 있는 부분입니다. 자동화는 테스트의 일부이지 프로덕트나 서비스 전체 품질을 보증할 수 있는 방법이라 생각하지 않기 때문입니다. 테스트 자동화는 선택 사항이지 필수 조건은 아니라는 것을 알고 있으신 게 좋습니다.

근거가 되는 논문의 이미지 일부입니다. 테스트의 목적은 결함을 발견하기 위한 활동인데 자동화 테스트로 이슈를 발견할 수 있는 확률은 9.3%밖에 되지 않습니다.

자동화 테스트에서 발견할 수 있는 이슈의 확률

이 개념을 알고 자동화에 접근해 보시는 걸 추천해 드립니다. 특히, 채용 시장에는 테스트 자동화를 필수로 뽑는 회사보다 매뉴얼 테스트(저는 이것을 요구 검증이라 함)를 할 수 있는 인재의 채용이 더욱 많다는 것을 알아주셔야 합니다.

다시 제 얘기로 돌아와서 테스트 자동화도 구축해서 좋은 평가를 받았고, 개발팀의 요청으로부터 테스트를 시작하고 결과를 공유할 수 있도록 테스트 프로세스도 확립하였습니다. 너무도 좋은 경험이었고, 경력을 쌓을 수 있는 회사였습니다. 물론, 모든 일은 제가 팀장의 직책이 아닌 상태에서 수행하게 된 업무였습니다.

단, 성공적인 업무 성과는 좋은 평가를 받게 되었고, 회사로부터 인정받는 사람이 되는 계기가 되었습니다.

회사의 인정은 곧 나의 커리어가 된다

하지만, 메디트라는 회사에서 1년의 재직 기간만 가지게 되었습니다.

가장 큰 이직의 이유는 제조업, 하드웨어를 함께하는 소프트웨어 회사는 제조가 우선순위가 높았습니다. 이해는 됩니다. 하드웨어는 금영이라는 것으로 찍고, 출고되면 반품? 상황이 발생하게 되면 그 비용이 만만치 않기 때문인데요. 이런 문제들을 최대한 소프트웨어에서 해결하려고 했습니다.

하드웨어에도 펌웨어라고 하는 것이 있지만 일부 기능의 제어할 수 있는 부분이기 때문에 하드웨어를 크게 변경해야 하는 상황에서는 최대한 소프트웨어로 커버하려는 부분이 있었습니다. 그래서 생각과는 다르게 업무를 하는 경우도 많이 생겼고, 제가 생각하는 커리어와는 방향성이 맞지 않다고 생각하게 되어 좋은 회사임에도 이직을 결정할 수밖에 없었습니다. 회사 위치도 가깝고 좋았는데 말이죠.

아쉽지만 이별해야 할 때

그렇게 메디트에서는 1년의 시간을 보내고 이직하게 됩니다.

이전 비스텔 퇴사 시 마지막 연봉은 3,950만 원이었고, 메디트 이직 당시 제안 받은 연봉은 4,400만 원이었습니다. 항상 말씀드리지만, 회사의 규모에 따라 연봉은 천차만별이고, 특히, 경력 이직의 경우 이전 직장의 연봉이 가장 중요합니다.

전 중간에 연봉 깎아서 이직했던 경험도 있기 때문에 그런 것이고, 여기까지 읽어 주신 분들은 더 많이 받으실 수 있을 거라 생각합니다.

다음 글은 9 ~ 12년 차로 일한 교원? 교직원 연합 아니고요. 구몬학습, 빨간펜으로 익숙한 교원에서의 경험을 가지고 찾아뵙겠습니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[성취] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 6년에서 8년 차)

품생품사(品生品死) — Fri, 21 Mar 2025 20:00:58 +0900

오프닝: 품질, 테스트 관리를 선택한 나

이전 글에서 잠깐 언급했듯이 저는 관리라는 업무를 선택하였습니다. 개발은 좋아하지만 관리가 재미있다고 생각했습니다. 사람을 워낙에 좋아하는 성격이기도 하고, 제 인생은 사람의 인연을 빼놓을 수 없기 때문에 선한 영향력의 힘을 알고 있기 때문에 저도 관리라는 업무를 통해서 후배님들의 성장을 돕는 것이 저도 성장할 수 있는 길이라 생각했던 것 같아요.

우연인지 필연인지 회사에서 리더? 관리의 일을 할 수 있는 기회들이 생기기 시작했던 시기였습니다.

관리자로 자리 잡기

멘토링을 할 때 어떤 후배님은 1인 QA, 리더로 일해야 하는 데 무엇을 어떻게 해야 할지 모른다고 해서 입사하는 게 맞는지를 물어보시는 경우가 있었는데... 제 개인적인 생각으로는 부딪혀 봤으면 좋겠다고 조언을 드렸었습니다. 사실 리더의 기회는 회사 생활을 하면서 경험하기 힘든 부분일 수 있습니다. 혹은 경력이 많이 쌓이고, 역량을 인정받았을 때 주어지는 사명? 책임감으로 얻게 되는 직책이기도 합니다.

그래서 기회가 생겼다면 경험해보는 것이 좋다고 말씀드리지만, 백지상태에서 시도해 보는 것이 멘티의 입장에서는 쉽지 않은 결정일 거라는 생각도 하게 됩니다. 용기가 필요합니다. 나의 대한 자신감도 필요하고요.

그럼, 바로 시작하기 전에 이전 글을 참고하세요.

[성장] QA, 테스트 엔지니어의 연봉 정보 공개!!(ft. 3년에서 4년 차)

오프닝: 나의 길을 정해야 할 때교육이나 강의를 할 때 항상 하는 얘기가 있습니다. 3 ~ 4년 차. 늦어도 5년 차 쯤에는 내가 좋아하거나 잘 하는 것을 정하고 경력을 쌓아야 한다고 얘기합니다. QA

qa-testing.tistory.com

6 ~ 8년 차? 경력 사항

지난 글까지 5번째 직장까지 회사를 소개하면서 제가 배운 것들을 말씀드린 것 같습니다. 그중에서도 가장 중요한 것은 일도 중요하지만 사람이 가장 중요하다는 것을 말씀드렸는데요. 중간쯤 왔으니 한번 간단하게 정리를 해볼까 합니다.

연차	회사	스킬업
1년차	테크로스(인턴) (도메인 : 조선)	1. 소프트웨어개발 2. C언어 3. MFC(C++) 4. 스터디, 과제 - Tool : 비주얼 스튜디오
2년차	와이즈와이어즈 (도메인 : 아웃소싱)	1. 모바일 웹 브라우져 HTML/XHTML 기능 테스트 2. 테스트 케이스 작성 3. 모바일 테스트 단말기 관리 4. 이슈 관리 및 보고서 작성 - Tool : QC
3년차	인투데이타시스템 (도메인 : SI)	1. TC 작성 및 테스트 2. 이슈 관리 및 보고서 작성 3. 전자/공공 부문의 프로젝트 통합/인수/제3자 테스트 - Tool : QC, RTC, OpenPMS
4년차	나모인터랙티브 (도메인 : 전자책 솔루션)	1. 테스트 계획 및 품질관리 계획 작성 2. TC 설계 및 작성 3. 이슈 관리 및 보고서 작성 4. 테스트 자동화 관리 - Tool : Mentis, CodeWorks, eggPlant
5년차	유와이즈원 (도메인 : 그룹웨어 솔루션)	1. TC 작성 및 테스트 2. 이슈 추적 관리 매트릭 구축 3. 테스트 주니어/시니어 교육 자료 작성 4. 이슈 관리 및 보고서 작성 5. 크로스 브라우저 테스트 6. 모바일 웹앱 테스트 - Tool : JIRA, Confluence

5년 차가 될 때까지 많은 것을 경험하면서 또 많은 것을 배울 수 있는 시간이었습니다. 많은 사람들을 만나면서 좋은 사람도 있었고, 정말 사람 때문에 이 회사 못 다니겠다고 느낀 회사도 있었습니다.

그 회사가 바로 4개월 만에 퇴사를 결정하게 된 유와이즈원이라는 회사입니다. 지금 와서 생각해보면 나름 재미있었으니 상세히 썰을 풀어보도록 하겠습니다. 당시 QA는 두 명뿐이었는데 사수?라는 사람은 관리만 하려 하고 테스트 케이스도 없으면서 탐색적 테스트? 당시에는 그냥 에드 훅 테스트 정도 했던 것 같아요. 그러면서 "야 너 이거 왜 찾지도 못하고 머 하는 거냐? 테스트한 것 맞아?" 이런 식의 모욕감을 주는 말을 많이 들었습니다. 지금까지 어디 가서 일 못한다는 말은 들은 적이 없던 저는 많이 충격을 받았던 것 같습니다.

그래도 복지도 좋고, 저 사람 빼고는 개발자들도 좋고 해서 최대한 그들이 원하는 것을 만들어 보려고, 처음으로 매트릭을 작성해 보았고, 반응도 좋았습니다. 데일리로 이슈에 대한 측정이 가능해졌기 때문인데요. 지금 생각해보면 JIRA 리포트를 통해서도 잘만 하면 뽑아서 Confluence에 리포트를 만들었으면 하는 생각이 들지만 그 당시에는 JIRA 초보여서 그런 생각은 못했던 것 같습니다. 그리고 연구소이기 때문에 스터디도 하고 있었는데 전 교육 자료를 좀 만들어 보라라는 지시가 떨어져서 처음 주니어/시니어 용 교육 자료도. ppt로 작성을 하게 되었습니다. 나름 카카오톡이 대중화? 되는 시점이었고, 그래서 좀 재미있게 만들어 보려고 노력했던 기억이 납니다.

하지만 막상 발표할 때는 내용이 너무 졸려서 다들 주무셨던 기억도 있습니다. 발표 스킬이 부족했던 것이었겠죠? 이렇게 저렇게 그래도 버티고 있는데 그분의 갈굼을 끊이지 않았고, 매번 반복됨에 지쳐가기만 했습니다. 그래서 첫 직장에서 친해지게 된 형에게 현 상황을 얘기하게 되었고, 자신의 회사에 TO가 있으니 지원해보라는 말에 바로 이직을 하게 되었습니다.

넘어가기 전에 연봉 정보를 잠깜 말씀드리면 유와이즈원 입사 당시 계약 연봉은 3800이었습니다. 복지 포인트가 연 100 정도 나오고, 대웅 그룹이다 보니 제휴 약국에서는 약을 포인트로 차감하는 식으로 50% 된 가격으로 구매할 수 있는 복지 혜택이 있었고, 복지몰도 자유롭게 복지 포인트를 사용할 수 있었습니다. 또한, 점심은 구내식당으로 쿠폰이 나오는 회사였으며, 정말 용돈 15만 원도 남는 회사였습니다. 복지 하나는 정말 괜찮았던 회사로 기억합니다.

[실전 취업/이직 준비] 서류 심사에 합격할 수 밖에 없는 경력 기술서 작성하는 방법!!

qa-testing.tistory.com

이후 입사하게 된 회사는 바로 비스텔이라는 회사입니다.

오호 기사를 찾아보니 시높시스에서 비스텔을 인수하였네요. 6월 22일 정말 얼마 되지 않은 따끈한 기사네요. 기존에 다니시던 분들은 어떻게 되었는지 궁금해지네요. 근무 환경이 좋아서 장기적으로 일하시는 분들이 많은 회사이기도 합니다.

비스텔이라는 회사는 반도체 엔지니어링 자동화 SW 서비스 분야에서 국내 최고 기술력을 인정받은 회사로 2000년 창립 이후 국내 반도체 제조회사 및 일본, 오스트리아, 미국 등 글로벌하게 사업을 했던 회사입니다. 사실 반도체라는 도메인으로 인해 정말 너무 어렵고, 생소해서 일하는 것에 대해서 고생을 많이 한 회사이기도 합니다. 하지만 고생한 만큼 얻은 것도 많은 회사인 것은 사실입니다.

비스텔에서는 정말 배운게 많은 회사입니다. 제 QA 인생을 바꿔놓은 회사도 비스텔이라고 할 수 있습니다. 우선 조직적으로 QA 인원이 15명 정도 되었습니다. 모두 정규직이며 제품별 QA가 2~3명이 배정되어 있는 구성으로 되어 있었으며, 애자일 방법론으로 개발을 하고 있어서 스크럼팀 내에 QA가 있다고 생각하시면 됩니다. 또한, JIRA의 활용도가 굉장히 높은 회사였으며, 2015년도 당시 주 40시간 근무제를 도입하여 하루 야근을 하게 되면 금요일은 일찍 퇴근하는 유연 근무제를 선도한 회사이기도 합니다. 필수 근무 시간은 11시에서 4시로 정하고, 앞 뒤 시간은 자유롭게 활용하여 주 40시간 근무를 원칙으로 하는 방식이었습니다. 연봉이 좀 낮더라도 사람들은 이 복지 하나로도 오래 다닐 수 있는 이유가 되기도 하였습니다.

워낙에 많은 것을 배우고 업무를 진행했던 회사이기 때문에 아주 오래전에 작성했던 경력 기술서를 가져와 보겠습니다.

직장명	부서	직위	담당 업무	기간
비스텔	PCS팀	책임 연구원	QC	2015.01 ~ 2017.01
업무 내용	1.eDCP(Data Collection Plan) Application 검증 담당. - 반도체 공정 시 발생하는 Data에 대해서 원하는 Data를 Monitoring 할 수 있도록 Plan을 작성하는 Application 검증. DCP라는 제품은 타 제품의 base가 되는 제품으로 back-end 부터 front-end까지 or 장비에서 발생하는 data 부터 User가 data를 Monitoring 할 수 있는 Client 설치를 위한 Web Server를 구축. (1) Agile Process로 개발 및 테스트 업무 진행 (2) QA 환경 구축 : Linux Server 구축 및 Web Server(IIS)를 이용하여 Client 설치 (3) Alpha 기간: 개발 범위를 분석하여 기존 작성된 TestCase를 수정 및 보완하여 Manual Test 진행. (4) Beta 기간: Risk를 분석하여 경험 기반으로 Test 진행 (5) RC 기간 : Regression Test를 통해 재발방지. Alpha 및 Beta 기간에 발견된 bug를 중심으로 Side Effect Test 수행 (6) RTM 기간 : Test Report 작성 – Release 기준에 맞도록 Test가 진행 되었는지 결재 첨부용. - 테스트 환경(DB, Server, Client) - 개발 Item 및 요구사항으로 인한 개선항목 List. - Manual Test 결과 - Affect Item List(발견된 Bug list) (7) Go-live 회의를 통해 Release 여부 결정(제품별 담당자 및 Manager를 포함하여 회의 진행) 2. eDCP(Data Collection Plan) Application HotFix-Test 진행 - 운영성 업무로써 고객사에서 접수된 요구사항 및 개선 사항이 개발 완료 되면, Build Manager를 통해 Build된 Setupkit으로 해당 Item을 Test하고, Test Report를 작성하여 RM(Release Manager) 결재를 통해 바로 배포될 수 있도록 업무를 진행함. EES라는 제품 안에 일부인 eDCP라는 Application 담당자로 정식 Release를 2회 진행하였고, 현재 3번째 Release를 준비 중입니다(분기별 정식 Release). Agile Process를 통해 전체적인 업무 흐름을 습득하였고, 가장 큰 역량 상승은 Linux로 server 환경을 구축하고, DB Data 정합성 검증을 할 수 있었다는 점입니다. 또한 Web Server 구축을 통해 Server/Client 환경에 대해서 더욱 자세히 알 수 있었습니다.

간단하게 얘기하면 백엔드부터 프런트엔드까지 테스트를 수행했고, 마지막에는 데이터 정합성까지 확인하는 역할을 수행하였습니다. 그래서 QC라는 포지션명을 썼던 것 같습니다.

테스트를 하기위해서는 환경 구축을 하는데 DB 스크립트(개발자가 제공해 줌)를 돌리고, 서버 환경 파일을 설정에 맞게 세팅하고, 데이터 확보를 위해 시뮬레이터를 돌리고, 변경점에 대한 테스트 진행 후 영향 범위를 분석하여 리그레이션 테스트를 수행하고, 서버 로그 확인과 DB 데이터 저장까지 테스트를 수행하였습니다. 지금 이렇게 간단하게 설명하면 어떻게 다 수행하나 싶을 정도로 어렵게 느껴질지 모르지만 제가 입사하기 전 많은 부분들이 개선되고, 고민한 흔적들이 있었으며, 테스트를 더 잘하기 위한 노력이 있었습니다. 또한, 제가 담당했던 제품은 다른 제품들이 데이터를 정제하기 전 데이터를 수집하는 제품이었기 때문에 더욱 중요한 제품이었고, 테스트를 더욱 견고히 해야 하는 제품이었습니다.

그리고 당시 QA 팀장은 도구 도입을 통해 문제를 해결하려는 의지가 강해서 다양한 도구를 사용할 기회가 있었습니다. 그래서 UI 자동화도 도입하게 되었고, 아틀라시안에서 지향하는 방법론대로 프로세스를 구축하여 개발할 수 있는 환경을 만들기도 했습니다. Zephyr라는 테스트 케이스 관리 도구가 있는데 당시 첫 도입 시 주도적으로 기존 테스트 케이스를 이관하고, 사이클 사용 등 수행하면서 사용법을 전파하기도 했는데 현재 재직 중인 회사에서도 활용도 높게 사용할 수 있는 경험이 되기도 하였습니다.

[실무 - Chap.1] 지라(JIRA)를 활용하여 효율적인 프로세스를 구축하기 위한 방법!!

Jira를 추천하는 이유?IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. 개발자던 QA이던 구인 공고 단골 Job Description이기도 합니다. 보통 기업 혹은 개인이 JIRA를 사용한다고 하

qa-testing.tistory.com

[실무 - Chap.2] 지라(JIRA) 프로세스를 체계적으로 구축하기 위한 방법!!

시스템 활용을 위한 최소한의 공통 기능 정의이전 글에서는 JIRA를 도입하기 전에 무엇을 준비해야 하는지 알아보았습니다. 앞으로의 글은 JIRA의 기능 설명이 아닌 정말 프로젝트를 만들고 어떻

qa-testing.tistory.com

사실 도구라는 것은 활용하기 나름이기 때문에 불편해하다고 하시는 분들도 있고, 전 나름 방법론? 프로세스를 명확히 알고 어떻게 활용했을 때 퍼포먼스가 좋았다는 것을 경험해봤기 때문에 사용하는데 큰 문제는 없었습니다. JIRA와의 호환성도 좋았으며, 테스트 관리를 하기에는 가장 적합한 시스템이라 생각합니다.

또한, 비스텔에 있으면서 테스트 중 테스트 미스로 인해 고객사에 큰 사고가 난 적이 있습니다. 데이터 하나가 잘 못 계산되면 반도체 공정에 문제가 발생할 수 있기 때문에 아주 예민한 제품이라 할 수 있는데 제가 테스트 케이스를 잘 못 이해하여 테스트 케이스를 수행했어야 했는데 범위 외로 생각하고 수행하지 않았던 것이 큰 문제로 발생을 하게 되었습니다. 테스트 케이스를 수행만 했다면 릴리즈 전에 버그를 발견할 수 있었는데 그렇지 못했던 게 문제였던 것인데요. 테스트 케이스의 중요성을 더욱 알 수 있는 중요한 시간이라 생각합니다.

저의 이런 사고? 때문에 결국 테스트 프로세스 내에 온 사이트 테스트가 들어가게 되었습니다. 제가 담당하는 제품의 주력 고객사는 일본 도시바였는데 릴리즈(분기별 정규 릴리즈 함) 때마다 일본에 가서 온 사이트 테스트를 해야 하는 상황이 발생한 것입니다. 첫 프로세스 도입 시에는 제 실수도 만회할 겸해서 처음 해외 출장이라는 것을 경험하게 되었고, 사이트에서는 테스트를 이렇게 하는구나라는 것을 몸으로 배울 수 있는 시간이었습니다. 하지만 이것은 처음이자 마지막 해외출장이자 온 사이트 테스트가 되었습니다.

2년이 조금 지나고, 와이프가 임신을 하게 되었는데 조산과 나중에는 유산기로 인해 제가 해외 출장을 가기가 어렵다고 판단을 하게 되어 릴리즈 때마다 같이 일하시는 분이 항상 일본으로 출장을 가게 되는 상황이 발생하게 되었습니다. 한두 번은 어쩔 수 없는 상황이라 생각했지만 이게 점점 쌓이다 보니 내가 테스트한 것에 대한 보증을 내가 못한다 생각하니 그것도 자존심이 상했고, 결국 전 보직 변경을 회사에 신청하게 됩니다. 바로 자동화 테스트 팀으로 가고 싶다고 했는데요. 자동화 테스트에 대한 관심도 많았고, 평소 많이 하고 싶다는 의지도 있었기 때문에 전배 신청을 했지만 TO가 없어서 받아들여지지 않게 되었습니다.

SW 테스트 자동화

그래서 전 다시 이직을 생각하게 되었고, 이 당시에는 급한 것도 없다는 생각에 1년 정도 분기별로 해서 게임회사 쪽으로 지원을 많이 했습니다. 스마일게이트(RPG, 메가포트, 스토브) / 넷마블 / 넷 게임즈 등 다양한 게임회사에 면접을 보았는데 잘 되지 않았습니다.

당시 전 게임 QA는 기획적인 요소를 알고 있어야 한다는 생각에 면접 때 기획적인 요소를 강조하면서 얘기했었는데 나중에 게임 QA를 좀 공부하다 보니 제가 잘못된 방향성을 가지고 면접을 봤다는 것을 알게 되었습니다. 안 뽑힌 게 당연할 정도라 생각합니다.

[실전 이력서 예시] 게임 QA 혹은 테스트 엔지니어에 지원했던 자기소개서 공유!!

게임 QA 지원 시 사용했던 자기소개서 공유제 QA 경력은 모바일 ➡ SI ➡ 솔루션 ➡ 제조&솔루션 ➡ 모바일/웹 이렇게 변했습니다.저도 한때 게임 QA를 목표로 지원을 했던적이 있습니다. SI에서 넘

qa-testing.tistory.com

[실전 이직/취업 준비] 게임 회사에 QA 혹은 테스터로 지원할 때 꼭!! 필요한 이력은?

게임 플레이 이력 준비하기한 때 게임 회사에 입사하고 싶다는 꿈을 꾸었던 적이 있었습니다.- 우선 가고자 하는 회사의 목표를 세우시길 바랍니다.- 입사 희망을 하는 회사에서 가장 히트가 되

qa-testing.tistory.com

그래도 나름 게임 회사 입사의 희망을 가지고 노력한 흔적은 있습니다. 사실 게임 공모전에도 참여하기도 했었습니다.

그렇게 비스텔에서 3년의 시간을 보내고 이직을 하게 됩니다. 비스텔 입사 당시 연봉은 3600이었고, 기존 유와이즈원에서 받던 금액보다 300만 원 정도 마이너스를 하고, 이직을 하게 되었습니다. 정말 경력직 이직을 하실 때 아무리 급하게 이직을 하더라도 연봉을 깎고 이직은 하지 말라고 말씀드리고 싶습니다. 이게 정말 회복하는데 시간이 엄청 오래 걸립니다. 나중에 연봉 협상을 통해 퇴직 당시 연봉은 4000만 원이었습니다. 7년 차에 4000만 원인데 중소기업은 보편적으로 이 정도는 되는 것 같습니다.

비스텔이라는 회사는 제 자신을 정말 한층 더 발전시켜준 회사였으며, 앞으로 이직하는 회사는 비스텔에서 배운 것을 풀어내는 정도로 일을 하게 됩니다. 그 정도로 배운 것이 많은 회사라고 생각됩니다. 주변에도 QA를 하시는 분들 커뮤니티를 통해서도 보면 백엔드를 테스트하고, DB 환경 구축해서 서버를 테스트하는 QA or 테스터는 극히 드뭅니다.

하지만 이러한 지식은 프런트엔드 테스트를 할 때 이해를 돕고, 리스크를 분석하는 눈을 가지게 됩니다. DB나 서버적으로 접근이 가능하게 되는 것인데요. 만약에 QA로 성장을 꿈꾼다면 꼭 서버와 DB를 공부하시길 추천드리고, 테스트 자동화를 하겠다고 어설픈 개발을 배우는 것보다 현실에 훨씬 도움이 많이 됩니다. 앱만 개발하더라도 서버와 연동되지 않는 앱은 없기 때문입니다.

다음 글은 8 ~ 9년 차로 일한 메디트라는 회사의 경험을 가지고 찾아뵙겠습니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[성장] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 3년에서 5년 차)

품생품사(品生品死) — Thu, 20 Mar 2025 20:00:25 +0900

오프닝: 나의 길을 정해야 할 때

교육이나 강의를 할 때 항상 하는 얘기가 있습니다. 3 ~ 4년 차. 늦어도 5년 차 쯤에는 내가 좋아하거나 잘 하는 것을 정하고 경력을 쌓아야 한다고 얘기합니다.

QA 업계는 크게 2가지 길이 있습니다. 관리와 엔지니어라고 할 수 있는데요.

내가 프로젝트, 일정, 사람(리소스) 등 관리의 업무가 잘 맞거나 혹은 e2e 자동화, 성능 테스트 등 개발의 영역이 잘 맞는 것을 고민하고 어느 분야를 성장해 나갈 것인지를 선택해야 합니다.

이 시점에는 앞으로 나의 10년을 책임져 줄 스킬업의 시간이라고 생각하시면 됩니다. 좋아하는 건 관리고 잘하는 건 개발이라고 하는 후배님이 가끔 있는데 이건 마지막에 선택의 팁을 드리도록 할게요.

이제는 선택의 시간

그럼 시작하기 전에 이전 글을 참고하세요.

[적응] QA, 테스트 엔지니어의 연봉 정보 공개!!(ft. 2년 차)

오프닝: 신입같은 중고 신입어떻게 생각하면 2년 차는 기업에서 가장 선호하는 인재의 상태일 거라 생각됩니다. 코로나19가 끝나가는 시점부터는 공채라는 개념이 사라지고(이건 '핵 개인의 시

qa-testing.tistory.com

3에서 5년 차의 경력은?

두 번째 직장에서 쓰디쓴 권고사직의 아픔을 딛고 이직하게 된 곳은 바로 나모인터랙티브라는 나모 웹에디터를 만든 나름 중소기업에서도 네임 벨류가 있는 회사였습니다. 디아블로 2를 열심히 하던 19살 시절 나모 웹에디터 크랙판을 구해서 웹 사이트를 만들던 게 생각이 나네요.

우선 현재의 나모인터랙티브는 영업 종료가 되어서 정보를 찾아볼 수 없는 회사가 되었습니다. 지란지교란 회사에 펍트리 에디터만 살아있는 상황이 되었는데요. 이 이야기는 나중에 좀 더 자세히 말씀드리겠습니다.

현재 회사의 정보를 확인할 수 있는 것은 이 정도인 것 같습니다. 두 번째 직장인 인투데이타시스템에서 우선 권고사직을 받은 상황이라 2개월 정도 시간이 주어졌습니다. 회사에서 제안한 방법은 개발자로 전향하겠느냐? 혹은 퇴사를 하겠느냐? 였고, 당시 친해진 인사 과장 형에게 회사가 바라는 방향성을 물었을 때 퇴사를 하는 것을 바라고 있다고 얘기를 해주었습니다. 그래서 전 출근해서 이직을 알아보고 있었죠. 대학원도 재학 중이고, 결혼식도 한 달 여 남은 상황이라 마음이 급했습니다.

당시 Sten이라는 QA나 테스터라면 알만한 이 사이트에 구인 공고를 보고 지원하게 되었으며, 이때 아주 재미있는 상황이 발생합니다. 첫 직장에서 잠깐 인사만 하고 지내던 분이 나모인터랙티브에 QA 팀장으로 있었던 것이죠. 첫 직장에서 같이 여행을 갔던 형이 그 분과 친해서 역으로 연락이 온 상황이었고, 절 적극 추천했다고 했습니다. 그래서 전 별 무리 없이 나모인터랙티브에 입사하게 되었습니다.

QA 쪽으로 직업을 생각하고 계신다면 Sten의 구인 구직 게시판을 참고하시는 것도 좋습니다.

입사 후 바로(3월 20일경 입사하여 4월 초에 결혼식 ) 일보다도 의도치 않게 결혼식을 공지하게 되었고, 8월에는 대학원 졸업도 하게 되는 저에게는 정말 많은 것을 이룬 회사가 바로 나모인터랙티브입니다.

처음으로 ePub이라는 것을 알게 되었는데 나모가 웹에서 전자책 저작툴을 개발하고 있었던 시점이었습니다. 이게 과연 사업 아이템으로 좋은 선택일까라는 의구심도 들긴 했으나 회사가 선택했기에 전 열심히 테스트해서 품질을 높이기 위한 방법을 찾고, 고민했습니다.

나모에서 QA 팀의 구성은 5명으로 품질관리팀으로 되어 있었으며, 테스트가 주 업무인 품질팀이었습니다. 웹에서 ePub을 제작할 수 있는 분야와 PC 설치용으로 ePub을 제작할 수 있는 분야로 나뉘어 있었으며, 전 PC 설치용을 담당하게 되었습니다. 그리고 번들 서비스 앱으로 구글 플레이 스토어와 애플 앱 스토어의 앱을 테스트할 수 있었습니다. 스토어에 등록하는 앱은 ePub을 볼 수 있는 뷰어였고, 이 뷰어 또한 ePub 3.0 표준을 준수하여 전자책을 볼 수 있도록 개발되어야 해서 단순 뷰어였지만 간단하지는 않았습니다.

기존 전자책은 ePub 2.0으로 제작되어 텍스트 위주의 전자책이었지만 나모에서 만든 저작툴로는 ePub 3.0을 표준으로 해서 영상이나 이미지를 이용해서 전자책을 만들 수 있는 도구였습니다. 당시에는 획기적이었고, 일본의 소프트뱅크와 공급계약도 맺는 등 잘 풀리는 것 같았습니다. 하지만 간과한 것이었을 까요? 우리나라는 책을 잘 안 보기도 하고, 2013년도에는 전자책이라는 것이 많이 보급되지 않은 현실의 벽에 부딪히게 됩니다. 회사는 점점 어려워지기 시작했고, 1년 6개월 뒤 저는 두 번째 권고사직을 맞게 됩니다.

나의 의지가 아닌 이직

이때는 호형호제하는 팀장의 말이 아직도 생각납니다. "사장님이 QA팀 2명을 줄이래. 우선 난 나갈 거고 넌 어떻게 할 거냐?" 전 1초의 망설임 없이 "머야 밑에 애들 어떻게 얘기해. 아오 형이랑 나랑 나가라는 거구만." 이야기를 주고받았던 게 아직도 생생합니다. 그래서 팀 장형은 5월에 퇴사하고, 전 6월에 퇴사를 하게 됩니다.

나모에서 배운 것을 정리하자면 ePub이라는 도메인에 대한 지식을 배울 수 있었고, 솔루션에 번들이라는 앱도 함께 출시할 수 있다는 개념을 알게 되었습니다. 또한, 솔루션을 아주 성공적으로 출시하더라도 영업이나 마케팅이 받쳐주지 못하면 QA가 아무리 잘하더라도 회사는 어려워질 수 있구나라는 것을 다시 한번 느낄 수 있는 시간이었습니다. 기술적으로는 Codeworks와 Mantis라는 BTS(Bug Tracking System)을 사용하여 결함을 관리하였으며, EggPlant라는 자동화 도구도 잠깐 살펴볼 수 있는 기회도 있었습니다.

그리고 퇴사 전에는 메뉴 트리를 이용해서 테스트 케이스도 설계하여 유작을 남겨 놓고 퇴사를 했습니다. 솔루션을 1년 가까이 보다 보니 내 머릿속이 스펙이기 때문에 솔루션을 열어놓고, 메뉴 트리를 작성하면서 테스트 케이스를 작성 가능한 수준까지 올라온 것을 느낄 수 있었습니다.

가장 중요한 것은 이전 글에서도 말씀드렸듯이 남는 건 사람이었습니다. 나모에서 같이 일한 사람 중 팀장과 한 동생은 지금도 가끔 만나고 한잔 하면서 지내고 있으니까요.

연봉 정보를 말씀드리면 우연치 않게도 나모에 입사하면서 대리를 달게 되었습니다. 인투데이타시스템에서 2600만 원으로 사원으로 퇴사하여 나모인터랙티브 입사 시에는 3400만 원으로 입사하게 되었습니다. 800만 원을 올려서 입사하게 되어 이직할만한데?라는 생각을 하게 되었는데요. 하지만 나중에 회사가 어려워져서 따로 연봉 협상은 할 수 없는 상황이었고, 5월부터 이직을 준비하게 되었습니다. 결국 경영악화로 인한 권고사직이라는 퇴사 사유를 쓸 수밖에 없는 상황이 되었습니다.

경영악화로 인한 권고 사직

하지만 이번 이직 시에는 아주 재미있는 상황이 발생했습니다. 첫 번째 직장에서 두 번째 직장을 이직할 때는 4개월 동안 10번 정도의 면접을 보았고, 한 군데만 합격할 정도의 확률이었다면 전 5~6월 사이 한 달 동안 10번의 면접을 보았고, 4군데 합격을 해서 조건을 보고 회사를 골라서 가게 되었습니다. 변한 건 딱 하나였습니다. 대학원 졸업의 이력이 생긴 것이었는데요. 당시 합격한 회사는 시스트란인터내셔널, 11번가, 유와이즈원(대웅그룹 계열사), 스탠다드네트웍스 4군데였습니다.

[실전 취업/이직 준비] 서류 심사에 합격할 수 밖에 없는 경력 기술서 작성하는 방법!!

qa-testing.tistory.com

이것도 좀 풀자면 스탠다드네트웍스 합격으로 나모에 퇴사 통보를 했는데 갑자기 입사 유보가 되는 상황이 발생했습니다. 결혼도 했는데 실직자 되면 정말 PC방으로 출근해야 하나라는 생각에 좀 더 공격적으로 이력서를 내기 시작했습니다. 그리고 정말 바로 세 군데가 합격해서 제가 선택한 회사는 유와이즈원으로 입사를 하게 되었습니다.

정말 사회생활 3~4년 차에는 다사다난했던 것 같습니다. 이것이 끝인 줄 알았는데 유와이즈원은 나한테 또 왜 이러는 거니 정말 ~ 다음 글에서 상세히 다뤄보도록 하겠습니다.

아 ? 좋아하는 일을 해야 하나? 잘하는 일을 해야 하나? 선택의 팁 은

삶의 질을 중요하게 생각(예: 워라벨 없으면 회사 못 다니는 분들)하면 좋아하는 일을 ~

성장을 중요하게 생각(예: 일하면서 공부도 하고 교육, 강의도 하는 분들)하면 잘하는 일을 ~

하는 게 맞을 것 같습니다.

물론 정답은 아니지만 최소한 위와 같이 선택해야 나중에 후회의 갭을 줄일 수 있을거라 생각합니다.

도움이 되시길 바랍니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[적응] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 2년 차는 거둘 뿐)

품생품사(品生品死) — Wed, 19 Mar 2025 20:00:54 +0900

오프닝: 신입같은 중고 신입

어떻게 생각하면 2년 차는 기업에서 가장 선호하는 인재의 상태일 거라 생각됩니다. 코로나19가 끝나가는 시점부터는 공채라는 개념이 사라지고(이건 '핵 개인의 시대' 책을 통해 깨달음) 상시 채용이 대체되었기 때문에 기업들은 '중고 신입' 즉, 해당 분야의 경험 있는 신입의 채용을 좋아하게 된 것 같습니다.

물론 말이 좋아 중고 신입이지 소희 말하는 경력 후려치기?? (옛날에는 많았답니다.)의 방식이 달라진 것 같다는 생각입니다. 백번 양보해서 회사는 경험 있는 인재를 채용해서 바로 실무에 투입하고자 하는 마음은 알겠으나 구직자의 입장에서 해당 업무의 경험을 하기는 쉽지 않은데 말이죠.

하여튼 저의 2년 차 경험을 시작해 보도록 하겠습니다.

아직은 신입

시작하기 전에 이전 글도 참고하세요.

[취업] QA, 테스트 엔지니어의 연봉 정보 공개 (ft. 신입, 경력의 시작)

오프닝: 경력의 시작제가 사회생활을 시작한 지 15년이 넘었습니다. 그래서 앞으로 글을 나누어서 제가 QA로 살기 위해 어떤 커리어를 쌓았고, 쌓으려 했는지 나름대로 정리를 해보려 합니다. 생

qa-testing.tistory.com

2년 차 경력은?

2년 차에 첫 이직을 하게 됩니다. 이직하는 회사는 인투데이타시스템이라는 회사였고, 삼성 SDS의 협력사로 전자 공공부문 SI 프로젝트에 파견되는 포지션이었습니다. 이때 이직의 기간은 5월에 퇴사하여 8월에 입사 확정되어 9월 1일부터 출근을 하게 되었고, 오픈 이력서를 통해 인사 담당자로부터 연락받아서 면접 제안을 받게 되었습니다. 약 4개월의 시간 동안 면접 10번 정도를 보았으며, 합격한 곳은 이곳뿐이었습니다.

사실 SI라는 것이 무엇인지도 모르고, 회사의 인사 담당자분이 너무너무 친절해서 낚였다? 라는 표현이 맞을지도 모르지만, 이 회사에서 전 정말 중요한 것을 배우게 되었습니다. 우선 업무적인 설명을 잠깐 하고, 무엇을 배우게 되었는지 말씀드리겠습니다.

SI(System Integration)

SI는 시스템 통합이라는 뜻으로 기업에서 요구하는 정보시스템을 기획 설계하고, 하드웨어 선택, 발주 조달, 사용자에 맞춘 프로그램 개발, 시스템 유지 보수 등을 전문적으로 대행하는 것이라고 쓰여있네요. 구글링해 보시면 많이 나옵니다. 당시 테스트 업계의 붐이 있었습니다. 모바일 시장이 피쳐폰에서 스마트폰으로 넘어가는 시기였고, 국가적으로도 많은 사업이 고도화되는 시기였습니다. 저도 NICE라는 대국민 서비스에 결함으로 인해 테스트팀이 필요하게 되어 인투데이타 회사를 통해 삼성 SDS의 NICE 프로젝트에 투입이 되게 되었던 것이었죠.

당시 이슈는 고3 학생들의 성적이 잘 못 계산되는 치명적이 오류였고, 국가가 삼성 SDS의 손해배상 청구가 되었던 이슈였습니다. 일반적인 이슈는 아니었고, 1년간의 데이터가 쌓여 있어야만 계산할 수 있는 로직이었고, 오픈 후 1년간의 데이터가 쌓이고, 계산이 돌았을 때 문제가 발생한 것이었습니다.

이런 사건을 통해 테스트의 중요성을 알게 되었고, 내가 하는 일이 누구나 할 수 있는 일이라 생각되지만 정말 중요한 일이구나라는 것을 알게 된 계기가 되었습니다. 그래서 내가 테스트를 잘못하면 누군가는 피해를 볼 수도 있고, 회사가 피해를 볼 수도 있다는 생각에 정말 다른 생각 안 하고, 테스트에 집중해서 일을 했었던 기억이 납니다. 조금이나마 테스트의 눈의 뜨는 시기라고 생각합니다.

특히, 프로젝트에 파견하다 보니 일하는 곳을 옮겨 다녀야 하는 어려움은 있었지만 다양한 경험을 할 수 있다는 것은 정말 큰 메리트였습니다. NICE 프로젝트를 시작으로 특허청의 특허넷 차세대, 삼성전자의 GMES 시스템, 국민은행 OOO 프로젝트(사실 프로젝트명이 기억이 안 나네요 ) 그리고 가장 기억에 남는 가족관계 증명서 인터넷 발급까지 다양한 프로젝트의 경험을 통해 데이터의 중요성과 테스트의 목적, 범위를 명확히 알 수 있는 시간이었습니다.

구조조정으로 인한 권고사직이라니...

그렇게 1년 좀 넘게 시간이 지나고는 알 수 없는 이유로 삼성 SDS의 구조 조정을 통해 협력사의 인원 감축의 통보가 왔고, 그 통보 대상에 제가 들어가 있어서 권고사직할 수밖에 없는 상황이 되었습니다. 결혼을 얼마 안 남기고 권고사직의 통보라 정말 앞이 캄캄했던 기억이 있는데요. 이후에 이직한 회사는 큰 회사는 아니었지만 네임벨류가 조금 더 있는 회사여서 안심하고 이직할 수 있었습니다.

2년 차에 배운 것은 앞에서도 잠깐 말씀드렸듯이 테스트 진정한 목적을 알 수 있는 시간이었고, 시스템 규모에 따라 테스트 범위는 어느 정도 가져가야 하는지를 알 수 있었고, 범위에 따라 어떤 테스트가 중요한지 테스트의 우선순위에 대해서 알 수 있는 시간이었습니다. 탄탄한 기본기를 잡을 수 있는 회사였습니다.

그리고 가장 중요한 것은 사람이었습니다. 처음에 말씀드렸듯이 인사담당자한테 낚였다는 표현을 했지만 10년이 지난 지금도 호형호재 하는 사이로 발전을 하게 되었습니다. 서로에게 큰 도움을 주는 사이는 아니지만 만나면 반가운 사이가 되었고, 함께 프로젝트에 투입되는 사람들이 있다 보니 같이 고생을 했다는 생각에 사람들과 많이 친해지고, 돈독해질 수 있었던 것 같습니다. 첫 직장에서도 같이 여행 가는 형이 생기고, 다음 이직하는 회사의 팀장이었지만 첫 직장에서 알게 되고, 두 번째 직장에서는 사회생활의 담소를 나눌 수 있는 사람들이 생긴 것이 저에게는 정말 큰 재산이 되었다고 생각합니다.

인연의 중요성

아? 그리고 중요한 정보를 알려드리지 않았네요. 연봉 정보를 말씀드리겠습니다. 10년 전 중소기업의 연봉이라 지금과는 조금 차이(좀 알아보니 그때나 지금이나 많이 차이 나지 않음)가 있음을 감안하시고, 첫 번째 직장에서 1800만 원으로 시작하여 두 번째 직장에서는 2300만 원으로 입사하였고, 한 차례 연봉 협상을 통해 2600으로 이직을 하게 되었습니다. 그리고 아직 대학원 졸업하지 않았습니다.

대학원의 복선을 꼭 따라와 주세요. 두 번째 직장 입사 시에 9월 1일이었기 때문에 한창 대학원 2학기를 달리고 있는 상황이었으며, 면접 시에도 대학원 재학 중이라는 것을 밝혔고, 학업에 지장 없는 것을 말씀드리고 입사를 했습니다. 파견되는 것을 모르고 말이죠 하지만 목표한 바는 꼭 이루겠다는 생각으로 정말 학업과 일, 연애?, 게임! 은 소홀히 하지 않았습니다. 절대로요. 2년 6개월이 정말 죽도록 힘든 시기였지만 지금은 최고의 시기라 말씀드릴 수 있습니다. 대학원의 선택은 절대 후회하지 않습니다.

다음 3년 차 글에서 이어서 말씀드리도록 하겠습니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[취업] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 신입, 경력의 시작)

품생품사(品生品死) — Tue, 18 Mar 2025 20:00:19 +0900

오프닝: 경력의 시작

제가 사회생활을 시작한 지 15년이 넘었습니다. 그래서 앞으로 글을 나누어서 제가 QA로 살기 위해 어떤 경력을 쌓았고, 쌓으려 했는지 나름대로 정리를 해보려 합니다.

생각 정리의 시간이고, 15년이라는 시간 동안의 사회생활을 돌아보기도 하는 글을 쓰는 뜻깊은 시간이 될 것 같습니다. 마지막에는 연봉에 대한 변화?? 사회생활 15년 정도 하면 얼마나 벌 수 있을까에 대한 궁금증도 이 글을 읽으시는 분들께 조금이나마 미래에 대한 막연함을 해소하는 데 도움 되시도록 공유해 드리도록 하겠습니다.

그럼, 바로 시작해 보도록 하겠습니다.

0년 차 경력은? 그런게 있을리가? 아니다. 있었다!

첫 시작은 26살 때입니다.

사회생활의 시작

이전 글에서도 잠깐 언급한 적이 있긴 한데 전 대학교를 26살에 들어가게 되었습니다. 아주 짧게 사연을 정리하면 26살 늦은 나이에 대학교를 가게 된 이유는 고3 때 집안 사정이 안 좋아서 제 때 대학교를 가지 못하였고, 군대에서 대한민국 사회를 느끼고, 살아남으려면 대학교를 가야겠구나라고 느낀 순간. 동네? 에 대학교가 신설되어 가봐야겠다 해서 수능을 보려 했지만 수시로 합격하여 대학교를 가게 된 거죠.

그렇게 저의 늦은 대학 생활은 시작되었습니다. 고학생이다 보니 20살 친구들과는 어울리기 어려웠고, 교직원들과 친해졌으며, 신입생들은 저를 교직원으로 알기도 했다는 슬픈 설화 아? 제 전공은 컴퓨터공학과입니다. 나중에 과명이 변경되어 컴퓨터정보학으로 졸업을 하게 되었습니다.

0년 차 사회생활이라고 이야기하는 이유는 4학년 2학기 때 인턴 생활로 소프트웨어 개발을 하기 시작했기 때문입니다. 역시나 고학생이다 보니 학업에 소홀할 수 없었죠. 나이도 많은데 성적도 안 나오면 그냥 창피했으니까요. 그래서 수업 시간에는 거의 교수님 보조를 많이 하게 되었습니다. 그리고 4학년 때는 교수님 추천으로 인턴을 할 수 있게 되었죠. 거리는 좀 멀었습니다. 천안 아산에 위치한 테크로스라는 회사였고, 전 소프트웨어 개발 3팀에 배치를 받게 되었습니다.

오호 ~ 검색해 보니 계열사도 생겼네요?

영화 인턴

회사는 조선업 관련 회사였으며, 배에 균형을 맞추기 위한 밸러스트 탱크라는 것이 있는데 이것을 배가 정박하게 되거나 혹은 낮은 수면을 운항하게 될 때 배의 높이를 조절해주고, 균형을 맞춰주는 역할을 하는 탱크입니다. 배의 높이를 맞출 때 해수를 이용하는데 여기서 문제가 발생합니다. 부산 앞바다의 해수를 가지고 균형을 맞추다가 인천 앞바다 가서 부산 앞바다의 물을 버려야 하는 상황이 발생하는 것인데요. 이것이 비즈니스 아이템으로 회사가 설립되었습니다. 전기 분해를 통해 해수를 깨끗이 하여 버리고 담고를 할 수 있게 되는 것이죠.

전 이러한 탱크를 조절할 수 있는 당시 임베디드의 들어가는 소프트웨어를 운영 유지 보수하는 개발을 하는 게 저의 롤이었습니다. 학교 다닐 때는 그래도 교수님이 내주시는 과제는 정말 잘했으나 역시 현장의 개발은 달랐습니다. 무엇을 어떻게 해야 할지 아무것도 모르겠더군요. 회사에서는 기숙사 생활을 했고, 테스트를 위해서 바지선이 있는 부산에도 자주 갔습니다. 부산에서도 숙소 생활을 하면서 낮에는 쫓아다니면서 일 배우고, 밤에는 과제를 하면서 밤을 새기도 했습니다. 이때, 연봉은 2300만 원이었고, 인턴이어서 80%의 월급만 받았었습니다.

이렇게 인턴 생활이 끝나갈 무렵 정규직 전환의 기회가 왔지만 전 승낙하지 않고, 학교로 복귀를 하였습니다. 이때, 배운 것은 현장에서의 개발이 어떻게 되는지를 배울 수 있었고, 개발자 정말 힘든 직업이라는 것을 몸으로 느끼고 올 수 있었습니다. 졸업 작품으로는 메신저를 개발해서 제출하였고, 인턴 생활이 조금이나마 도움이 되었던 것 같습니다.

그리고 졸업 전 처음 이력서를 작성하게 되었습니다. 사람인/잡코리아에 동일한 이력서를 작성하고, 오픈해 두었습니다. 그리고 얼마 지나지 않아 제 첫 직장인 "와이즈와이어즈"라는 회사에서 입사를 제안받아 면접을 보고, 입사를 하게 되었습니다. 입사 시 연봉은 1800만원 이었습니다.

1년 차의 경력은?

와이즈와이어즈라는 회사에 입사해서 처음 테스트라는 활동을 하게 되었습니다. 우선 그전에 학교 다닐 때 전 아르바이트와 교내 근로장학생을 했었는데요. 정말 쉬는 시간 없이 제 몸을 혹사? 했었습니다. 그러면서도 지켰던 것은 바로 "게임"입니다. 게임을 통해 커뮤니티를 알게 되었고, 정말 대한민국에서 출시하는 거의 모든 게임을 다 해보자는 마음으로 게임을 좋아하고 플레이했습니다. 그 이력은 아래 링크를 참고하세요.

[실전 이직/취업 준비] 게임 회사에 QA 혹은 테스터로 지원할 때 꼭!! 필요한 이력은?

qa-testing.tistory.com

그리고 저도 모르게 알파/베타 테스트 등을 하면서 자연스럽게 테스트라는 활동을 하고 있었던 것인데요. 그래서 그런지 소프트웨어를 개발하는 것보다 테스트를 하는 것이 더욱 재미를 느끼게 되었던 것 같습니다.

처음 테스트를 한 것은 공장 같은 느낌이었습니다. 제가 담당한 소프트웨어는 피쳐폰?(아시려나)의 웹 브라우저가 있는데 웹 브라우저를 구동시키기 위한 속성들에 대해서 테스트를 하는 것이었어요. LG의 일본향 모바일 단말기였고, 일본에서 제공한 테스트 케이스를 가지고 테스트를 수행하는 것이었습니다. 보통 스케줄은 2~30일 정도 수행하고, 테스트 케이스의 분량은 대락 2~3000건 정도 되었던 걸로 기억합니다.

그래서 제가 경험할 수 있었던 것은 HTML/XHTML 다른 말로 PHP 언어에 대한 기능 테스트를 수행하는 것이었습니다. 이것 또한, 거부감 없이 접근할 수 있었던 이유는 디아블로 게임을 하면서 당시 웹 사이트를 만들어서 운영하는 게 유행 같은 시절이 있었습니다. 그래서 저도 개인 홈페이지를 만들어서 운영을 좀 해보려고 공부를 했었고, 기본적인 Html의 사용법은 잘 알고 있었습니다. 그래서 좀 쉽게 접근할 수 있었으며, 당시 이슈 관리 시스템으로는 HP사의 QC라는 도구를 사용하였고, 처음으로 이슈 트래킹이라는 활동을 하게 되었죠.

개발자는 LG(갑)였고, 나름 LG 사람들과 일 한다는 무언가 자부심? 같은 것도 있었던 것 같습니다. 사실 그때는 아웃소싱이라는 개념이 없었고, 조금 시간이 흘러서 피쳐폰에서 스마트폰으로 팩터의 혁신이 생기던 시점이 있었습니다. 스마트폰으로 넘어가는 시점에 처음 테스트 케이스 작성을 할 수 있는 기회가 생겼었고, 지금은 많이 바뀌었지만 그 당시에는 안드로이드 2.0? 기억도 잘 안나는 그 안드로이드 버전의 설정 쪽의 요구 정의서(그땐 이게 요구 정의서인지도 모름)를 보고 테스트 케이스를 작성했었습니다.

지금까지 봐왔던 테스트 케이스가 있었기 때문에 메뉴를 트리 화하고, 요구사항을 매핑하여 작성했던 것이 기억이 납니다. 최대한 요구사항이 누락되지 않도록 작성했었고, 스마트폰이라는 것에 대한 경험이 없다 보니 예외 케이스는 상상을 할 수 없었습니다. 지금은 너무도 당연히 작성하고 있는데 말이죠.

대한민국에서 일한다면 가방끈을 포기하지 말자

그리고 첫 직장에서 저는 인생에 가장 중요한 결정을 하게 됩니다. 바로 대학원을 가야겠다고 마음을 먹게 되는데요. 대한민국 사회는 가방끈을 절대 배신하지 않습니다. 아니 가방끈을 인정하는 사회입니다. 아무리 고등학교에 실력 좋고 능력이 좋아도 고등학교 졸업으로 회사에 입사하여 10년 일한 사람과 대학원을 졸업하여 2년 일한 사람의 연봉 누가 더 높을까요? 장담하건대 대학원 나온 사람이 열이면 열 더 높고, 나중에는 승진에도 영향을 주게 됩니다.

그것을 깨달은 저는 입사 10개월 차에 돈을 벌면서 학위를 취득할 수 있는 방법을 찾다가 야간대학원을 선택하게 되었고, 당시 부장님과 사장님의 면담을 통해 대학원 추천서까지 받아서 3월 대학원에 입학을 하게 됩니다. 2011년 3월입니다. 선택한 전공은 테스트에서 좀 더 품질적으로 접근을 할 수 있는 학문이 무엇이 있을까 찾던 중 정보시스템 감리라는 학과가 있는 것을 알게 되었고, 딱 좋은 위치에 간판도 괜찮은 학교가 있어서 선택을 하게 되었습니다. 그리고, 학업과 일을 병행하기 위해 서울에 전셋집으로 이사도 하게 되었죠. 참고로 대학원은 2년, 논문학기가 있는 학과는 2.5년입니다. 이 이야기는 3년 차에 다시 이어서 하겠습니다.

2011년 5월. 그렇게 첫 직장의 사회생활은 1년 4개월 만에 종료하게 됩니다. 이유는 너무 공장 같은 느낌에 도태되는 느낌을 받았기 때문인데요. 좀 더 큰 무대? 에서 일하고 싶다는 생각이 커졌고, 이직이 확정되지 않은 상태에서 그냥 퇴직을 하게 되었습니다. 이때 처음, 인생 처음 비행기 타고... 홍콩/마카오. 해외여행을 갔습니다.

퇴직금을 다 쓰고 왔습니다. 머 연봉 1800만 원에 1년 4개월 일했으니 퇴직금이라고 해봐야 150만 원 정도 되었던 것 같아요. 다 쓰고 왔습니다.

버그 잡는 SW 테스터

이 회사에서 배운 것은 테스트하는 방법과 이슈를 트래킹 하는 방법, 그리고 잠깐이지만 테스트 케이스를 작성하는 방법을 알게 되었습니다. 사람들과의 협업이라는 것을 알게 되었고, 당시 사수도 있었는데 사수/부사수 간의 멘토링을 알 수 있었습니다.

결론을 말씀드리면 많이 들어보셨겠지만 첫 직장은 정말 중요합니다. 중요한 것은 첫 직장에서 무엇을 하던 연봉이 중요합니다. 이직 시에는 이 전 직장의 연봉에서 인상을 하기 때문에 이직하는 회사의 연봉 테이블이 높다 하더라도 인상률에서 OK를 해버리면 남들보다 낮은 연봉에서 일하게 되는 상황들이 발생합니다.

예를 들면, 연봉 1800만 원으로 이직할 때 2100만 원으로 이직을 하게 되어 우와 300만 원이나 올랐네? 해서 좋아할게 아니고, 그 회사 테이블을 보니 2년 차 연봉이 2300만 원이었네?라는 현실을 깨닫는 순간 나는 호구, 여긴 어디?

2025년 최근 들은 소식으로는

(물론, 회사의 규모에 따라서 개인의 역량 혹은 협상 능력에 따라 다를 수 있습니다.)

아웃소싱의 경우 신입 기준 2600 ~ 2800 정도라는 것 같습니다.

중소 기업의 경우 3000 초반정도 생각하시면 될 것 같고, 중견 기업은 3000 후반에서 4000 초 정도될 것 같습니다.

대기업은 말해 뭐해??

그래서 너무 낮은 연봉의 회사는 피하시길 바라며, 기승전 가방끈 얘기는 끝까지 하게 될 것 같습니다.

오늘은 끝 ~

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[테스팅] QA, 테스트 엔지니어와 개발자 하는 테스트는 왜 다른가?

품생품사(品生品死) — Sat, 6 Apr 2024 12:00:51 +0900

개발자는 분명 테스트 했는데 QA가 테스트하면 로그인부터 안 되는 이유?

[상황]

아래 상황을 예로 들어보겠습니다.
개발이 완료되고, QA 단계에서 테스트하게 된 상황입니다.

QA 담당자 : 빌드 주세요.
개발자 : 1.0.0 빌드 올렸습니다. 테스트 부탁드립니다.
QA 담당자 : 1.0.0 설치했는데 앱이 실행이 안 되네요? 재빌드 부탁드립니다.
개발자 : 빌드 옵션이 잘못돼서 재빌드했습니다. 1.0.1로 설치해서 재확인 부탁드립니다.
QA 담당자 : 설치는 되었는데 로그인이 안 됩니다. 확인 부탁드립니다.

한 번쯤은 경험해 보았을 상황이라 생각합니다.

[중략]

왜 이런 일이 발생할까요? 이유는 매우 간단합니다. 테스트 방법이 다르기 때문인데요. 간혹 정말 생각지 못한 범위에서 결함이 발생하기도 합니다. 이 경우에는 QA 단계에서도 발견하기 어렵기 때문에 개발자와 동일한 상황에 놓이게 됩니다. 이 부분은 뒷부분에 조금 더 자세히 말씀드리겠습니다.

위와 같은 상황이 발생하는 지극히 주관적이지만 제가 알고 있는 개발자의 개발/수정/테스트하는 경우를 예를 들어 보겠습니다.

첫 번째 경우,

한 사람이 A라는 Feature를 개발하기 위해 A-1, A-2, A-3, A-4, A-5의 작업을 생성해서 개발을 시작했다고 해봅시다.

A-1, A-2 개발이 완료되어 Resolved 처리 하였습니다.
A-3 개발 중 버그가 발견되어 A-3-b를 생성하여 작업하였습니다.
A-3–b 개발 완료 후 확인 테스트를 수행하였고, Resolved 처리 하였습니다.
A-4, A-5 개발이 완료되어 Resolved 처리 하였습니다.
A라는 상위 Feature에 대해서 Source Merge 후 테스트하고 상태를 Resolved 처리 하였습니다.

이런 상황에서 A(상위 Feature)를 Resolved 전에 A 기능에 대해 테스트하게 되면 개발 중에 발견한 버그도 확인이 되고 문제없이 QA로 인계가 될 것입니다.

중요한 것은 A-3-b를 수정하고 테스트할 때 기존 개발 완료 처리 했던 A-1, A-2에 영향이 없는지 분석/검토해야 합니다. 좀 더 나아가서 A-3-b가 B-3와 같이 개발 범위가 아닌 부분에 영향이 없는지도 검토가 되어야 하고, 필요에 따라 테스트가 수행되어야 합니다.

대부분의 경우는 위와 같은 상황에서 충분히 분석되지 않고 테스트도 수행되지 않아 QA로 인계하였을 때 결함이 발생합니다.

두 번째 경우,

A, B, C, D, E의 Feature를 한 사람이 아닌 여러 사람이 개발하는 경우입니다. 이 경우는 첫 번째 상황보다 매우 복잡하고 경우의 수가 무한에 가까운 수준으로 올라가게 됩니다.

하지만 매우 안타깝게도 대부분의 개발은 두 번째 상황으로 개발이 진행됩니다. 그렇기 때문에 개발자는 많은 시간과 다양한 케이스에 대해서 테스트를 수행하더라도 막상 QA 담당자가 테스트하게 되면 매우 기본적인 결함이 발견되는 것입니다.

그렇다면 이 상황을 어떻게 풀어야 할까요? 문제점은 명확하게 알고 있기 때문에 방치하거나 QA 담당자가 알아서 하겠지? 라기보다는 최대한 문제를 해결하기 위해 노력해야 합니다.

개발자가 Feature에 대한 개발이 완료된 경우 체크리스트를 작성해서 테스트하시길 권장해 드립니다. 단위 테스트를 위해서 가장 많이 활용하는 것이 체크리스트이며 체크리스트는 요구에 대한 검증이 아닌 기능의 동작에 초점이 맞춰진 방법입니다.

메뉴 트리 방식의 체크리스트도 좋고, 기능 명세에 대한 체크리스트도 좋습니다. 다양한 방식이 있으니 검토해 보시고 활용해 보시길 적극 추천해 드립니다. 체크리스트를 도입하게 되면 QA 단계의 테스트에서 기본적인 결함은 발견되지 않을 것입니다.

좀 더 나아가서 체크리스트의 목록을 자동화 테스트하는 방법입니다. 빌드 전 테스트가 수행될 수 있도록 CI/CD를 구축하는 것이 가장 바람직하며, 한번 정해진 시나리오로 매번 테스트하는 것이 아닌 시나리오는 점차 늘려가면서 커버리지를 높이는 것이 중요합니다.

그렇다면 개발자가 체크리스트도 수행하고 테스트 자동화도 구축해서 커버리지도 높였다고 하면 그러면 QA 담당자는 무엇을 하지? 라고 생각하실 수도 있을 것 같습니다.

가끔 QA는 무엇을 하는 사람들이지? 라는 질문을 받곤 하는데요. 회사에 개발자가 테스트하면 되지 QA 담당자 혹은 테스터가 무슨 필요 있어? 라고 하는 회사도 있습니다.

[테스팅] 테스트 자동화를 시작하려는 QA, 테스트 엔지니어들이 꼭 준비해야 하는 이것!!

품생품사(品生品死) — Fri, 5 Apr 2024 18:39:38 +0900

테스트 자동화를 처음 구축 하기 위해 필요한 정보

2024년 현재 QA 및 테스트 업계에는 테스트 자동화에 대한 관심이 많은 것 같습니다. 예전부터 관심이 많았지만 많은 기업의 수요도 많아지는 것이 느껴지기도 하고 질문도 많고 궁금한 것이 많은 시기인 것 같습니다. 그래서 조금이나마 테스트 자동화를 준비하는 QA 혹은 엔지니어분들을 위해 흩어져 있는 정보들을 조금씩 모아서 정리를 해보았습니다.

결론 부터 말씀드리면 테스트 자동화는 쉽지 않습니다. 개발 지식? 프로그래밍이 어려운 것이 아닙니다. 프로그래밍 언어는 습득 가능하고 노력하면 누구나 할 수 있습니다. 어렵다고 하는 부분은 끝없는 작업이기 때문입니다. 작은 변화에 매우 민감하기 때문에 어렵다고 말씀드리는 것입니다.

테스트 자동화에 성공하기 위해서 준비해야 하는 것, 고려해야 하는 것을 정리해 보았으니, 조금이나마 도움 되시길 바랍니다. 아래 링크도 제가 작성한 글이지만 회사의 콘텐츠이기 때문에 링크로 남겨 드립니다.

테스트 자동화를 시작하는 QA 혹은 테스트 엔지니어들을 위해

To. 테스트 자동화가 고민인 품질 관리자 혹은 테스트 엔지니어가 꼭 알고 시작하면 좋은 정보에 대해서

medium.com

본문 요약

테스트 자동화에 대한 개념 이해하기
테스트 자동화의 목적 명확히 하기
별도의 테스트 자동화 시나리오가 필요한 이유는?

참고로 필자는 전문 테스트 자동화 엔지니어는 아닙니다. 품질 관리자로서 테스트 자동화를 어떻게 설계하고 운영하는 것이 테스트 자동화를 최대한 성공으로 이끄는 방법에 대해서 말씀드리고자 합니다.

효율적으로 테스트 자동화 관리 방법 요약

테스트 자동화의 목적과 기준을 명확히 하기
테스트 자동화를 위한 별도의 테스트 시나리오 설계/작성하기

필자의 경우 테스트 자동화 시나리오는 직접 설계/작성하고 있으며 테스트 자동화 개발 리소스는 작성된 시나리오로 개발에만 집중할 수 있도록 프로세스를 운용하고 있습니다.

추가로 요구검증(Manual Tests)을 수행하는 사람이 테스트 자동화를 병행하는 것은 테스트 자동화 실패에 가장 큰 요인입니다. 리소스는 반듯이 분리해서 R & R(Roles And Responsibilities)을 명확히 하고 시작해야 합니다.

테스트 자동화는 테스트 커버리지가 높아지는 수단이며 잘 활용된다면 충분히 프로덕트나 서비스의 안정화를 유지하는 데 큰 도움이 되는 부분이니 잘 준비하셔서 성공적인 테스트 자동화를 구축/운영해 보시길 바랍니다.

[영상] 추억이지만 좋은 경험이었던 유튜브 준비하기, 기획하기, 시작하기

품생품사(品生品死) — Tue, 26 Sep 2023 12:00:30 +0900

유튜브를 시작하기 위한 준비 작업

이유? 정년하고 먹고 살 방법을 찾다가 데이터, 콘텐츠가 돈이 되는 시대가 도래했음을 느꼈습니다.

이미 크몽이라는 재능 기부 사이트에 초기 시장을 공략하여 약간의 부수입이 발생하고 있지만 수익이 목적이 아닌 나 자신을 세상의 데이터 베이스 안에 넣어야 살아갈 수 있을 거라는 것을 느끼게 되었습니다.

늦었을지도 모르지만? 더 일찍 시작했으면 좋았을 거라는 후회는 하지 않습니다.

지금 이 글을 쓰고, 블로그를 만들고, 유튜브를 고민하는 이 시간이 즐겁기 때문이죠.

나 자신을 데이터화 하는데 앞으로 시간을 할애 할 생각입니다. 앞으로 꾸준히 쭉~

내가 좋아하고, 잘하는 것이 무엇인지 고민해 본다

답을 찾았다.

그리 오래 걸리지 않았다.

내가 좋아하고, 잘하고, 꾸준히 할 수 있는 것은 하나밖에 없기 때문이다.

"테스트"

유튜브 공부를 시작해본다

책을 사본다.

- 프리미어 프로 공부는 많이 되었다.

- 영상 편집 도구도 나름 재미있더라.

유튜브 공부하기

네이버 검색을 통해 추천해주는 책을 사보았다.

채널까지 만들어보고 고민에 빠진다. ~ 어떻게 해야 하지?

장비를 준비한다

부족하다고 느끼면 장비빨 버프라도...에헴~

언택트 시대 : PC 캠은 필수...

화상 면접 & 화상 회의가 많아져서 겸사겸사 구매했다.

부모님 집에 가져놨던 DSLR을 다시 가져오고, 집에 DSLT를 배치한다.

난 한때 카메라를 좋아했던 적이 있었다.

10년 된 스탠드를 바꾼다. 조명빨 좋은 스탠드로...

마이크도 사본다.

장비 준비는 다 되었다.

유튜브를 기획한다

‍♂️ 기획안을 작성해 본다.

- 유튜브 목적

- 어떻게 촬영하고, 편집할지?

- 영상 하나 만드는 데 소비되는 시간은?

- 시간 대비 만족감은?

유튜브 기획안

프로필과 썸네일을 만든다

프로필을 만들어 본다.

아이디 : 품생품사

‍ 인포그래픽으로 만들어 놓은 나의 추상화를 넣어본다.

PPT로 작업하였다.

프로필

채널 아트를 만들어 본다.

CANVA(www.canva.com/)라는 사이트를 통해 만들어 보았다.

품생품사 채널아트

영상 썸네일을 만들어 본다.

영상 썸네일 컨셉

이제는 실전이다.

영상 편집? 한 번도 해본 적 없는 영역이다.

안 해봤으니 공부해야지.

영상 편집 공부용

인트로 영상을 만들어 본다.

현재 인트로 영상까지 완료된 상태이다.

지금까지는 만족스럽다.

영상 퀄리티는 공부하면서 높일 생각이다.

지금까지 앱 품질만 신경 쓰며 살아온 나였는데 이제 영상 품질도 신경 쓰게 되다니 커리어가 넓어진 기분이다.

누군가 유튜브를 시작하는 이에게 용기와 힘이 되시길 바랍니다. 누구든 할 수 있다는 것을 알려 드리기 위해 블로그에 모든 이력을 남기려 합니다. 영상 멘트와 시나리오는 블로그에 작성을 할 계획이고요.

사실 영상을 찍는 거까지에 대한 부끄러움이 저에게는 가장 큰 어려움이었습니다. 많이 느리겠지만(혼자 다해야 해서..ㅜㅜ) 그래도 성장하는 모습을 쭉 담아 보겠습니다. 영상에 성시경의 "잘 자요"와 같은 주력 멘트를 마지막으로 남겨 봅니다.

"버그 파티를 시작해 볼까요?"

[인포그래픽] 기억에 남는 이력서 작성하는 방법 공유!! (ft.캐리커처)

품생품사(品生品死) — Mon, 25 Sep 2023 12:00:09 +0900

이력서 - 캐리커처형

인포그래픽 이력서를 검색하면 캐리커처형 이력서들을 보실 수 있으실 겁니다. 예를 들면 아래와 같이 다양한 캐리커처형 이력서가 있습니다. 간단하게 작성법을 설명드리고, 소스 공유 드리도록 하겠습니다. 무료 백터 사이트 정보도 공유드리겠습니다.

캐리커처형 인포그래픽 이력서 예시

컨셉 잡기

1. 어디 부분에 어떤 정보를 입력할지 간략하게 그려봅니다.

2. 보통 이력서의 정보를 순서대로 나열하듯이 입력합니다.

3. 조금 작업이 진행되면 아래와 같이 배치도가 완성됩니다.

객체 배치도

캐리커처 만들기

1. 보통 캐리커처는 포토샵을 이용해서 많이들 작업하십니다.

2. 당시 포토샵 스킬이 없어서 잘하는 ppt로 작업을 했습니다.

3. 포토샵이 익숙하지 않으신 분들은 ppt로도 작업이 가능함을 알려드리고, 시간이 좀 오래 걸릴지 모르지만 여러 컨셉으로 작업하기에는 더 활용도가 높다는 점을 알려 드립니다.

4. 노가다라고 할 수도 있지만 완성되면 뿌듯합니다.

ppt 객체(이것도 그룹을 다 푼건 아니에요)

상세 내용 입력하기

1. 캐리커처가 완성되면 픽토 등을 입력하여 정보를 입력합니다.

2. 픽토는 무료 배포하는 사이트가 있으니 공유드립니다.

3. 외국 사이트들이라 영어로 검색하셔야 합니다.

Noun Project: Free Icons & Stock Photos for Everything

thenounproject.com

Flaticon, the largest database of free vector icons

Download all icons in SVG, PSD, PNG, EPS format or as webfonts

www.flaticon.com

입사 지원 시 심사관이 보든 안 보든 포트폴리오 첨부 파일에 넣고 있습니다. 긴 글보다는 한 장의 장표로 확인 가능한 이력서 하나쯤 가지고 있는 건 어떨까요? 인포그래픽의 매력이기도 합니다. 서류 심사는 전략입니다. 남들보다 기억에 남는 이력서를 만들기 위해서 조금만 노력하면 큰 도움이 될 겁니다.

[인포그래픽] 리니지2: 레볼루션 게임 분석서 공유!! (ft.넷마블)

품생품사(品生品死) — Sun, 24 Sep 2023 12:00:21 +0900

게임 분석서(포스터형)

* 넷마블과는 아무런 상관없는 공부용 기획서입니다. 재미로만 봐주세요 *

[작성 절차]

1. 인포그래픽(Infographic) 기획 및 설계

2. 분석 대상 선별

3. 특징 분석 및 장단점 작성(SWOT 분석 사용)

4. 미래 예측

5. 인포그래픽(Infographic) 작성

리니지2: 레볼루션 인포그래픽 게임 분석서

분석 대상 선별 - 성공 요인

1. 다양한 캐릭터와 다양한 직업군.

2. 오픈 필드 사냥 및 전투 방식.

3. 다양한 인스턴스 던전.

4. 5인 파티 시스템

5. 접근이 쉬운 가차&결재 시스템

- 가장 중요한 성공 요인은 리니지라는 Name Value!!!!!!

SWOT 분석

[S]

1. 화려한 그래픽(2017년 2월 기준 : 최고 수준)

2. 다양한 컨텐츠(던전, PvP, Main/Sub 퀘스트 등)

3. 기존 리니지2리니지 2를 그대로 전이함에 따른 이질감 배제

4. 리니지 1, 리니지2의 세계관 공유

5. 오픈 필드 사냥 방식

6. 유저 간거래 시스템

[W]

1. 불안한 게임 서버와 잦은 팅김 현상

2. 다양한 버그 발생

1) 블루 다이아 무한 장비 소환버그

2) 혈맹 무한 아데나 버그

3. 고사양의 디바이스를 권장

- iPhone 6, 갤럭시갤럭시 S5, G4

[O]

1. CBT를 취소하고, 지스타에서

2. 공식 발표로 인한 마케팅 전략

- 신뢰도를 좀 잃었지만 기대감을 상승 시킴

3. 어느 게임보다 심각한 노가다를 해야 함에도 불구하고, 서버 부족 및 대기 시간 발생

- 유저들의 관심이 많다고 증명됨

[T]

1. CBT 공지 취소

- 기다리던 유저들의 신뢰도 하락

2. 강화 확률 100% 실패

- 네트워크 환경으로 인해 강화 확률이 잘 못 표기된 것으로 해명

3. 최고 레벨 달성 시 무의미 컨텐츠 발생

- 경험치 던전 및 주간/일 퀘스트로 인한 보상이 무의미해짐

수익 구조 분석

1. 전형적인 모바일 결재 시스템

2. 블루 다이아몬드 결재

3. 아데나 거래

4. 장비 뽑기

5. 패키지 상품 거래

6. 결재 금액에 따른 마일리지 적립

유사 게임 실패 사례 분석

오픈 필드 시스템을 적용한 게임은 많지 않다. 대표적으로 뮤 오리진이 있지만 해당 게임은 국내에서 한 달 여간 관심을 보이다가 먼저 출시한 레이븐과 후발 주자 이데아가 출시하면서 조금씩 유저가 줄어드는 상황이 온다. 하지만 극단적으로 단순한 사냥 시스템과 리니지2:레볼루션과 마찬가지로 단편적(1회성 소모 시나리오 구성)인 시나리오 구성이 유저들을 떠나보내게 된 가장 큰 이유라고 생각된다.

1. 데스티니 차일드 : 리니지2:레볼루션이 출시하기 전까지 마켓 1위를 지키던 게임이면서 야릇한 일러스트가 매력적인 게임이다. 하지만 레이드 패치 이후에도 전투 시스템의 차이가 없어 유저들의 비난을 받기 시작한다. 최근 주 1회1 패치가 되지 않자 개발사 공식 공지에는 큰 개발팀이 아니라서 패치를 하지 못한 점 죄송하다는 글이 개제 되기도 했다.

2. 세븐나이츠 : 출시한지 3년의 시간이 흘렀지만 꾸준한 유저를 지키고 있는 게임이기도 하다. 하지만 1주년 대규모 패치 당시 장비 각성 시스템 이후 많은 유저가 게임을 탈퇴했다. 이유는 기존 게임 밸런스가 많이 무너지는 상황이 발생했기 때문이다. 비슷한 사례로 몬스터 길들이기 또한 더 이상 뽑을 캐릭터가 없어지자 별 7개의7개의 각성 시스템을 도입하였으나 역시나 밸런스가 무너지는 상황이 발생하여 유저들이 대거 탈퇴하는 상황이 벌어졌다.

3. 히트화려한 그래픽의 선두주자이다. 언리얼4 엔진을 적용하여 상당히 화려만 이펙트를 보여줌으로써 유저들의 관심을 독차지하게 된다. 하지만 히트는 시작이 문제였다. 짧은 듀토리얼을 이용한 리세마라가 등장하여 대부분의 유저가 최고 장비를 착용하고 시작하는 상황이 벌어졌다. 향 후 대규모 패치 및 새로 캐릭터를 추가하였으나 새로움이 없이 같은 패턴이 반복되면서 유저들이 탈퇴하기 시작했다. 또한, 비슷한 시기에 이데아가 출시되어 유저가 나눠지는 상황이 오기도 했다.

개선 방향

유저를 꾸준히 플레이할 수 있게 하는 것이 목적

종족별(휴먼/엘프/드워프/다크엘프)Main 시나리오 업데이트
- 시작 포인트가 다르게 설정
직업별 다양한 레어스킬을 사용할 수 있도록 업데이트
- 현재 로그가 미사일 볼트를 날리거나 힐을 할 수 있음.
던전 난이도는 유저가 선택할 수 있도록 개선 필요
- 스크롤을 이용한 난이도 선택(난이도에 따른 보상)
막일 유발 컨텐츠인 몬스터 코어 개선
- 장비 아이템 제작 재료를 드랍드롭하도록 개선하고, 장비 제작 레시피에 대한 업데이트 필요

리니지 2: 레볼루션의 향후 전망

최고 레벨이 늘어나고, 지역이 늘어난다.
케릭터가 추가된다.(직업은 추가되지 않을 것으로 생각됨)
레벨에 따른 진입 난이도가 있는 던전이 추가된다.
새로운 서버 오픈을 통해 신규 가입자를 유치한다.

결론은 지금까지의 모바일 게임에서 크게 벗어나지 않는 컨텐츠로 업데이트가 지속될 것으로 향후 전망이 예상된다. 2/9일 기사에 따르면 NC/넷마블이 블러드&소울을 리니지2리니지 2와 비슷한 방식으로 개발한다고 밝힌 바 있다. 하지만 리니지2리니지 2와 같은 성과는 없을 것으로 예상한다. 이유는 간단하다. 블러드&소울은 리니지와 같은 Name value가 없기 때문이다.

[인포그래픽] 게임 플랫폼 기획서 작성 예시 공유!! (ft.넷마블)

품생품사(品生品死) — Sat, 23 Sep 2023 12:00:43 +0900

게임 플랫폼 기획서(포스터형)

* 넷마블과는 아무런 상관없는 공부용 기획서입니다. *

[2025.03 어느날의 코멘트]

이것을 작성하게 된 가장 큰 이유는 '테스트를 개발 초기에 해야한다?'는 논리 때문에 기획에 대해서 공부를 했던 것 같습니다. 시간이 지난 지금은 아무짝에도 쓸모 없는 행동임을 깨달았는데요.

이유는 기획자들의 영역을 QA가 건드리면 불미스러운? 사이가 안좋아지는 상황만 발생했기 때문입니다. 기획자는 현업과 밤새고 고민해서 워딩을 작성해놨는데 기획 리뷰에 QA가 들어와서는 문서 한 번 읽어 보지 않고, '문구가 어색합니다.' 라고 했을 때 기획자의 자존심을 건드리는 상황이 되어 버립니다.

이건 거꾸로 테스트를 할 때도 마찬가지로 이슈 하나 나오면 '테스트 한 것 맞냐?'라는 말을 들은 것과 동일한 수준의 피드백이라 생각합니다. 물론, 정말 피드백에 대해 진심인 기획자라면 수용해서 수정하거나 재검토를 할지 모르지만 제 경우의 대부분은 자존심을 건드리는 상황에서 회의가 마무리되었던 경험이 더 많았습니다.

'개발 초기에 테스트해야 한다' 혹은 '개발 초기에 결함을 발견해야 한다'는 그냥 무시하세요. 그냥 기획자가 기획대로 개발이 되었는지 확인하는 것이 더 효율적입니다. QA는 그 선을 넘지 않도록 업무를 수행하시는 것을 추천합니다.

[작성 절차]

1. 인포그래픽(Infographic) 기획 및 설계

2. 디자인 소스 수집

3. 구성

4. 인포그래픽(Infographic) 작성

게임 플랫폼 기획서_넷마블

제목 및 개발 방식

1. Netmable Games or MableNet(넷마블 모바일 서비스 플랫폼)

2. 모바일 웹/하이브리드 앱

- 스토어 업데이트 방식이 아닌 서버/클라 패치 시스템 장점

배경 및 필요성

1. 넷마블에서 서비스하는 게임이 많다.

2. PC와 같이 모바일 클라이언트 플랫폼이 필요하지 않을까?(ex:배틀넷)

3. 소식, 공지사항, 사전예약, 통합ID

구성

1. Profile menu(계정 정보, 설치된 게임 목록)

2. News(넷마블 소식)

3. Chart(인기, 신규, 추천)

4. 사전예약(출시 정보), 이용중인 게임의 공지사항

분석

1. 개발 후 당장은 돈이 되지 않는다.

2. 개발 리소스 및 비용이 없다.(PM:1, 서버:2, 클라:2, QA: 1~2)

해결 방안

1. TFT 결성

2. 인력 채용

3. 외주 개발

미래 가치

1. 플랫폼으로써 퍼블리싱 기업에 판매 가능?

2. Store(케릭터 및 정액권 : 앱마켓 부가세 없음)

[N잡러] 소프트웨어 QA, 테스팅, 취업, 이직 관련 멘토링 (ft.크몽)

품생품사(品生品死) — Fri, 22 Sep 2023 12:00:00 +0900

QA가 무엇인지? 테스트가 무엇인지? 앞으로 어떻게 해야할지 고민이신 분

품질 시장이 전반적으로 어떤 분야인지 QA(품질 보증)이라고 얘기하면서 왜 테스트만 얘기하는지 알려 드립니다. 전공이 무엇이든 상관없으시고, 중요한 건 앞으로 정말 하고 싶은 것이 무엇(품질 분야)인지를 명확히 해주는 것이 좋습니다.

1회성으로 끝나는 것이 아니고 저는 후배님들에게 최대한 도움 드리고자 평소 궁금했던 내용들은 평소에도 연락하면서 답변해 드리고 있습니다. 그리고 최대한 많은 정보를 드리고, 노하우도 알려 드리도록 하겠습니다. 아래 이미지는 멘토링 서비스에 등록된 리뷰입니다. 멘티분들의 진심이 느껴지는 리뷰라서 저도 많이 뿌듯합니다.

크몽 서비스에 등록된 멘티분들의 진심어린 리뷰들

너무도 따뜻하게 리뷰를 남겨주셔서 저도 힘이되고, 다음 멘티분들께는 더 좋은 정보를 드리려고 하고 있습니다. 선한 영향력이라고 할까요? 상세 서비스는 아래 링크 참고해 주세요.

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. | 35000원부터 시작 가능한 총 평점 0점의 직무역량

0개 총 작업 개수 완료한 총 평점 0점인 품생품사의 직무역량, 기타 직무역량 레슨 서비스를 0개의 리뷰와 함께 확인해 보세요. 직무역량, 기타 직무역량 레슨 제공 등 35000원부터 시작 가능한 서

kmong.com

멘토는 이런 사람입니다.

"이런 분들께 추천해 드리는 서비스입니다."

1. 비전공자로 소프트웨어 테스트가 무엇인지 궁금하신 분

2. 전공자지만 QA(Quality Assurance)가 무엇인지 궁금하신 분

3. 소프트웨어 테스트 업계로 진로를 잡고자 고민하시는 분

4. 품질 분야로 커리어를 쌓고자 하시는 분

"저는 이런 사람입니다."

모바일 소프트웨어 테스트를 시작으로

전자책, 국가 사업, 의료, 반도체, 교육, 커머스 등

다양한 분야에서 10년 이상 테스트와 품질 관리의 경험을 바탕으로

소프트웨어 테스트 카페(네이버)와 블로그 커뮤니티 활동을 통해

소프트웨어 품질 분야에 기여하고 있습니다.

#경력(총 : 2023년 기준 15년차)

1. EES 솔루션 개발(인턴 3개월)

2. 모바일 QA (1년 5개월)

3. SI 프로젝트 Tester(1년 6개월)

4. 전자책 에디터 솔루션 QA(1년 4개월)

5. 그룹웨어 웹/솔루션 QA(6개월)

6. 반도체 모니터링 솔루션 QC(3년)

7. 의료 통합 웹/솔루션 QA, 관리자(1년)

8. 교육 앱/웹 QA, 관리자(3년 4개월)

9. 커머스 플랫폼 QA, 관리자(재직중)

#학력

- 건국대학교 정보통신 대학원 : 정보시스템감리 학과 졸업

- 논문 : 매트릭스를 이용한 EA 프레임워크 감리 개선 연구

#주요 멘토링 분야

- 소프트웨어 테스트 방법

- 소프트웨어 QA 방법

- 테스트 or QA 프로세스 개선

- OKR, KPI 수립

- 진로 상담

멘토링은 이렇게 해드리고 있어요

서비스 제공 절차

"서비스는 이렇게 해드리고 있습니다."

#[1회차] 테스트 멘토링

- 요약 : 테스트 혹은 QA에 대한 가벼운 소개와 방법을 멘토링 해 드립니다.

- 효과 : 해당 분야의 전반적인 상황을 알 수 있습니다.

- 제공 방식 : 1시간 온라인 교육과 1회 메시지 상담

#[2회차] QA 멘토링

- 요약 : 테스트 혹은 QA에 대한 심층 멘토링 해 드립니다.

- 효과 : 해당 분야의 스킬업을 위한 정보를 알 수 있습니다.

- 제공 방식 : 2시간 온라인 교육과 2회 메시지 상담

(2시간을 2회로 나눠서 1시간씩 진행 가능)

#[3회차] 실무자 멘토링

- 요약 : QA 분야로 신규 입사 혹은 이직에 대한 고민이나 팀 관리 방법 멘토링 해 드립니다.

- 효과 : 실무의 방향성이나 업계 동향, 앞으로의 진로/커리어에 대한 고민을 해결합니다.

- 제공 방식 : 3시간 온라인 교육과 무제한 메시지 상담

(3시간을 3회로 나눠서 1시간씩 진행 가능)

멘토링 제공 방식

- 기본 : Google Meet으로 온라인 교육

- 협의 : 의뢰인의 상황에 따라 다른 화상 도구 사용

- 문의 > 시간 예약 > 결제 > 멘토링 진행

"후배님들께 도움이 될 수 있는 업계 핵심 정보를 들려 드릴께요."

"품질이나 테스트 관련 고민을 털어 드릴께요. 해결되는 그 순간까지 ~"

의뢰인 준비사항

1. 현재 고민중이신 부분을 정리해 주세요.

2. 평소 QA나 테스트 관련 궁금했던 부분을 정리해 주세요.

3. 편안한 마음으로 교육에 참여해 주세요.

[템플릿] 'QA 테스트 프로세스' 관리 문서 패키지 (ft.크몽)

품생품사(品生品死) — Thu, 21 Sep 2023 12:00:28 +0900

QA를 위한 테스트 관리 문서 템플릿 패키지

테스트를 시작으로 현재 QA 관리자가 되기까지 수많은 문서와 프로젝트를 수행했습니다. 처음에 작성한 테스트 결과 리포트에는 우선순위에 따른 결함의 개수를 확인할 수 있는 매트릭 작성이 시작이었습니다. 이후 담당자별 이슈 처리 현황이 추가되었고, 더 나아가서는 결함을 구분하여 추적 관리 가능한 문서를 작성하였습니다.

최종적으로 품질률 측정이 가능한 문서를 작성하게 되었으며, 이 문서 또한 3년이라는 시간에 걸쳐 수많은 프로젝트를 수행을 통해 노하우를 문서에 녹이게 되었습니다. 이 문서는 현재에도 원격 환경에서 테스트하는 경우 매우 유용하게 활용하고 있으며 현재에도 개선되고 있는 문서입니다.

QA(품질 보증)을 하기 위해 필요한 가장 일반적인 활동을 산출물로 만들기 위한 문서 템플릿입니다. 일정관리부터 테스트 활동을 통해 발견한 결함을 추적관리하고, 개발팀이나 유관 부서의 커뮤니케이션을 돕기 위한 문서 템플릿입니다.

문서 활용을 통해 현재 서비스 및 제품의 상태를 파악하고, 나아가 품질을 높일 수 있는 데이터로 활용하기 위한 문서 템플릿입니다.

실무 적용 'QA 테스트 프로세스' 관리 문서 패키지 | 19000원부터 시작 가능한 총 평점 5점의 자료·

3개 총 작업 개수 완료한 총 평점 5점인 품생품사의 자료·템플릿, 문서 자료 서비스를 2개의 리뷰와 함께 확인해 보세요. 자료·템플릿, 문서 자료 제공 등 19000원부터 시작 가능한 서비스

kmong.com

자료, 템플릿 설명

"이런 분들께 추천해 드리는 문서 템플릿입니다."
1. 테스트 프로세스를 정립하고자 하는 스타트업이나 1인 QA이신 분
2. 테스트를 수행하면서 이슈(결함, 개선, 요구사항, 문의 등) 관리를 효율적으로 하고자 하는 분
3. 개발팀 혹은 유관 부서와의 테스트 협업을 원활히 하고자 하는 분

"저는 이런 사람입니다."
모바일 소프트웨어 테스트를 시작으로
전자책, 국가 사업, 의료, 반도체, 교육, 커머스
다양한 분야에서 10년 이상 테스트와 품질 관리의 경험을 바탕으로
소프트웨어 테스트 카페(네이버)와 블로그 커뮤니티 활동을 통해
소프트웨어 품질 분야에 기여하고 있다.

#이 문서는 이렇게 작성되었습니다.
1. QA 프로세스를 확립하기 위해 조직을 진단하였습니다.
2. 테스트 프로세스를 정립하기 위해 필요한 요소를 분석하였습니다.
3. 분석된 내용을 바탕으로 프로세스 품질을 개선하기 위해 구글 시트를 활용하였습니다.
- 당시 시스템 도입에는 비용적인 부담과 유관 부서의 거부감으로 인해 구글 시트 사용을 제안
- 구글 시트 사용에 대한 거부감은 0%에 가까움
4. 구글 시트를 활용하여 테스트 프로세스를 정립하였습니다.
5. 정립된 테스트 프로세스를 통해 개발 프로세스가 개선되었습니다.

#이 문서는 이렇게 구성되어 있습니다.
1. 템플릿 사용자 가이드
2. '부서명'_일정표
3. '플랫폼명'_이슈 관리 목록
4. '프로젝트명'_테스트 결과 리포트

#이 문서는 사용성이 증명된 문서입니다!
1. 2명이 150개의 제품과 서비스, 그리고 약 230개의 앱/웹 테스트 및 배포 관리를 할 수 있었습니다.
2. 테스트 수행 후 발견되는 이슈를 유관 부서와 긴밀하게 협업하고 관리하며 품질을 높이는 데 기여할 수 있었습니다.
3. 최종적으로 품질의 측정(품질률)을 통해 제품 및 서비스의 상태를 객관적으로 판단하는 데이터로 활용할 수 있었습니다.

"3년 동안 활용하면서 개선된 문서이며, 현재에도 개선이 진행 중인 문서입니다."

*문서는 주기적으로 업데이트 예정입니다.
*구매자분들께서는 업데이트 문서를 평생 받으실 수 있습니다.
- 크몽 메시지를 통해 업데이트 문서 제공

*필수기재 사항*
1. 저작권 귀속 여부 ( 전문가 귀속 )
2. 고객의 상업적 이용 가능여부 ( 상업적 이용 불가능 )
3. 폰트 사용 정보 ( 무료 폰트 이용 )

[전자책] 실전 노하우 '아주 쉽고 간단한 테스트로 투잡하기' (ft.크몽)

품생품사(品生品死) — Wed, 20 Sep 2023 12:00:52 +0900

전자책을 발간하기까지~

2018년도 10월부터 크몽에서 테스트 전문가로 활동하였으며, 이후 서비스를 점점 늘려가기 시작했습니다.

처음에는 SW 품질 확인 테스트 서비스를 시작하였습니다. 최종 품질 확인을 위한 방법으로 고려되지 않은 예외 케이스나 미처 발견하지 못했던 결함을 발견하기 위한 서비스입니다. 현재 가장 많이 이용중인 서비스로 크몽 2% 전문가 인증인 Prime 서비스가 되었습니다.

Android, iOS, Web 테스트해 드립니다. | 150000원부터 시작 가능한 총 평점 5점의 IT·프로그래밍, QA·테

kmong.com

두 번째는 테스트 케이스 설계/작성을 통해 요구 검증 서비스를 제공하였습니다. 요구 검증을 통해 품질률을 정량적으로 보여드리고, 앞으로 품질을 어떻게 챙겨야 하는지 기반 데이터를 확인하실 수 있습니다.

테스트케이스 작성 및 요구 검증 수행해 드립니다. | 300000원부터 시작 가능한 총 평점 4.9점의 IT·

kmong.com

세 번째는 테스트 프로세스 구축 서비스입니다. 테스트를 통해 품질을 잘 확보하고, 최대한 품질을 끌어 올릴 수 있는 프로세스를 컨설팅하였습니다.

QA 및 테스트 프로세스 구축, 정립, 확립해 드립니다 | 100000원부터 시작 가능한 총 평점 5점의 IT·

6개 총 작업 개수 완료한 총 평점 5점인 품생품사의 IT·프로그래밍, QA·테스트 서비스를 4개의 리뷰와 함께 확인해 보세요. IT·프로그래밍, QA·테스트 제공 등 100000원부터 시작 가능한 서비스

kmong.com

위 세가지 경험을 바탕으로 테스트 부업에 대한 전자책을 발간하게 되었습니다. 2023년 8월 기준 수익금 1억 원을 달성하였습니다.

실전 노하우 '아주 쉽고 간단한 테스트로 투잡하기' | 15000원부터 시작 가능한 총 평점 4.9점의 전

kmong.com

수강 대상자 ‍♀️️

시간이 많지 않은데 부수입을 만들고 싶으신 분
말도 안되는 고수익 보다는 현실적인 부수입을 만들고 싶은 분
성장을 통해 부수입을 만들고, 평소 테스트에 관심이 있으신 분

목차
0. 테스트 아직 모르니?
- 들어가기 전에
- 테스트란 무엇인가
- 테스트로 부업을 만들기까지

1. 테스트? 형만 믿고 따라와
- 소프트웨어 테스트 시장
- 무엇을 테스트하는가?
- 어떻게 테스트하는가?
- 왜 테스트 해야 하는가?

2. 테스트로 이만큼 벌었어
- 크몽에서 테스트 전문가로 벌어들인 수익 공개
- 테스트도 투잡이 될 수 있는 이유
- 너도 ‘테스트’할 수 있는 이유

3. 너도 테스트할 수 있어
- 테스트하기 위한 준비물
- 테스트 수행하기
- 테스트 결과 공유하기
- 피드백 반영하기

4. 이제 너도 ‘테스터’야
- 꾸준하게 투잡을 유지하기 위한 핵심 요소
- 꼭 당부하고 싶은 3가지
- "테스터"란?

보너스 자료
- 테스트 결과서

서비스 설명

# 목표 설정 : 쉽고 간단하지만 적은 시간과 노력으로 현실적인 부수입 만들기

저자 소개 : 품생품사(品生品死)
# 약 5년 동안 꾸준한 투잡으로 테스트 활동을 통해 출금 완료 수익금 1억 달성!!
# 수익만 목표로 하지 말고 성장을 통한 수익 만들기
- 1단계 : SW 품질 확인 테스트 - https://kmong.com/gig/115465
- 2단계 : 테스트 케이스 작성 - https://kmong.com/gig/202394
- 3단계 : 테스트 프로세스 구축 - https://kmong.com/gig/253263
- 3단계 확장 : 시스템을 활용한 프로세스 구축 - https://kmong.com/gig/408954
- 4단계 확장 : JIRA를 활용하여 업무 프로세스 구축 - https://kmong.com/gig/408954

[추천 서비스] 소프트웨어 QA, Test에 대한 멘토링 - https://kmong.com/gig/459068

# 소프트웨어 테스트 전문가
모바일 소프트웨어 테스트를 시작으로
전자책, 국가 사업, 의료, 반도체, 교육, 커머스
다양한 분야에서 13년간 테스트 경험을 바탕으로
소프트웨어 테스트 카페(네이버)와 블로그 커뮤니티 활동을 통해
소프트웨어 품질 분야에 기여하고 있다.

# 부수익 창출
- 다양한 플랫폼에서의 테스트 수익
- 티스토리 블로그 활동으로 광고 수익
- 카카오 뷰 큐레이션 활동으로 수익

# 주요 이력
- 2013년부터 소프트웨어 프로슈머 활동
- 2017년부터 오픈테스트 테스트 전문가로 활동
- 2018년부터 크몽에서 테스트 전문가로 활동
- 2021년부터 국대 대표 패널로 활동

# 개정 이력
- 2022년 10월 27일 : 부수익 활동 방법 추가
- 2023년 09월 05일 : 출금 완료 수익금 1억 인증 추가

[N잡러] 출시 전 최종 품질 상태를 확인하는 방법!! (ft.크몽)

품생품사(品生品死) — Tue, 19 Sep 2023 12:00:44 +0900

테스트 수행 - 작업 기간 2~4일

지금의 저를 있게 만들어준 서비스이며, 2023년 8월 기준 크몽의 Prime 서비스로 승격된 서비스입니다. Prime 서비스는 크몽의 2% 전문가에게만 주어지는 타이틀이며, 서비스 퀄리티를 인정 받은 전문가 입니다.

2018년 10월 크몽이라는 사이트를 알게 되었습니다.

"아? 테스트도 서비스화 할 수 있겠는데?"

서비스를 등록하고, 1개월 동안은 아무런 소식이 없었었습니다.

이후 한 건, 두 건 의뢰가 들어오기 시작했고, 전 수익 목적이 아닌 의뢰인 분들의 앱이 성공적으로 출시했으면 하는 마음으로 테스트를 수행했습니다. 이후 점차 수익도 늘어나면서 안정적으로 서비스를 운영할 수 있게 되었습니다. 처음에는 큰 기대 없이 시작했지만 지금은 더 나은 서비스를 제공하기 위해 하루 하루 고민하고 있습니다.

테스트 결과 리포트만 하더라도 시간이 지나면서 처음에는 .ppt 파일을 공유하는 방식에서 구글 시트로 공유하는 방법으로 바뀌게 되었고, 의뢰인 분들의 만족도는 높아졌습니다.

서비스라는 것이 처음과 똑같은 것을 고수하기보다는 시간이 흐르면서 개선되는 모습을 보여드리고, 더 나은 방법을 찾는 것이 만족도를 높이는 지름길?이라고 생각합니다.

Android, iOS, Web 테스트해 드립니다. | 150000원부터 시작 가능한 총 평점 5점의 IT·프로그래밍, QA·테

kmong.com

서비스 설명

"이런 분들께 추천 드리는 서비스입니다."

현재 소프트웨어(앱, 웹 혹은 제품 및 서비스)의 품질 상태가 궁금하신 분
출시를 앞두고 있는데 미처 발견하지 못한 결함이 있는건 아닌지 불안감이 해소되지 않는 분
알고 있는 결함은 모두 해결하였으나 사용성에서 좀 더 품질을 높이고 싶은 분

믿고 맡겨주시면 나중에 내가 사용하는 서비스라 생각하고, 최대한 품질을 끌어 올릴 수 있도록 테스트 해드리겠습니다.

서비스 제공 절차

"서비스는 이렇게 해드리고 있습니다."

기본적으로 탐색적 테스트 방법을 통해 제품 및 서비스에 대한 집중 테스트를 수행하고 있습니다.
최대한 모든 기능을 확인할 수 있도록 최초 테스트 시에는 전문가의 입장에서 테스트를 수행하고, 마무리 시점에는 사용자의 입장에서 테스트를 수행합니다.(보통 STANDARD의 경우 8~10시간 작업)
리포트는 요청 시 작업 완료 전 먼저 공유 드리고 있습니다.
이슈는 스크린샷은 기본으로 첨부하고, 필요 시 동영상 첨부 드립니다.
테스트 결과 레포트 1번 방식 - 구글 시트 양식으로 작성 후 URL 공유 및 파일로 송부 드립니다.
테스트 결과 레포트 2번 방식 - 공유 드린 구글 시트를 Excel로 익스포트하여 파일로 송부 드립니다.

"테스트 가능한 환경 정보는 이렇습니다."

#Mobile

Android(LG Q92) 테스트 가능 합니다.
iPhone(14, 14 Pro Max) 최신 버전 테스트 가능합니다.

#Tablet

iPad(mini1) 테스트 가능합니다.

#Wearable

애플워치 s3, 7: 호환성 테스트 가능합니다.
샤오미밴드 7세대: 호환성 테스트 가능합니다.

#Web Browser

Google Chrome
Mozilla Firefox
MS Edge
Naver Whale

의뢰인 준비사항

Application의 대략적인 정보를 알 수 있는 문서가 있으면 좋습니다.
인터랙션이 필요한 Application의 경우 테스트 계정을 준비해주시면 좋습니다.
VPN 연결이 필요한 경우 테스트 전에 준비 될 수 있도록 부탁 드립니다.
보안서약서 사인이 필요한 경우 말씀해주시면 미리 준비해서 송부 드리도록 하겠습니다.

포트폴리오 사이트

품생품사의 SW 품질 이야기

크리에이터링크에서는 HTML을 몰라도 누구나 직접 반응형 홈페이지를 무료로 제작 할 수 있습니다. 홈페이지 제작, 홈페이지 만들기

swqa.creatorlink.net

[N잡러] 테스트케이스(TC)로 요구 검증을 통한 품질률 확인하는 방법!! (ft.크몽)

품생품사(品生品死) — Mon, 18 Sep 2023 12:00:14 +0900

테스트 케이스 설계와 작성은 전문 영역이다.

내가 테스트 케이스(TC) 작성에 대한 서비스를 등록하게 된 이유는 바로 전문성이 필요한 부분이기 때문이다. 보통 회사는 '테스트 케이스 그냥 쓰면 되지 뭐 그게 어렵나?' 하는 회사도 있을 것이다. 하지만 막상 지시가 떨어지거나 테스트하면서 나온 상황들을 테스트 케이스화 하는 것은 단순한 작업이 아니다.

특히 내가 가장 많이 활용하고, 크몽 서비스로 등록할 수 있었던 영역은 바로 요구 검증 영역이었다. 테스트 케이스를 설계하고, 작성하는 시점은 도메인 별로 다를 수 있고, 필요나 목적에 따라 달라질 수 있다. 하지만 가장 손이 많이 가는 부분이며 자칫 설계를 잘 못하게 되면 아무도 사용하지 않는 문서. 그러니까 심한 말로 쓰레기가 될 수 있다.

그래서 난 세가지 나만의 규칙을 가지고 테스트 케이스를 설계하고 작성하고 있다.

첫째, 누구나 쉽게 따라 할 수 있는 테스트 케이스를 작성하자.
둘째, 재사용이 가능하도록 테스트 케이스를 작성하자.
셋째, 예외적인 테스트 케이스를 작성해서 테스트 케이스 수행으로도 예외 케이스에 대한 이슈를 검출할 수 있도록 하자.

테스트 케이스 설계와 작성이 전문 영역이라고 하는 이유도 위 세 가지 이유에서 나온 것이다. 어떤 사람은 누구도 알아볼 수 없을 정도로 복잡하게 설계해서 작성하는 사람도 있고, 무분별하게 테스트 케이스를 분리해서 양만 많아지는 경우도 생긴다. 이런 부분들은 자신만의 노하우나 전문성이 없으면 문서 품질을 보장받기 어렵다.

그래서 난 테스트 케이스 활용에 대해서 약간의 가이드도 해드리고 있으며 가장 효율적이고 효과적으로 테스트 케이스를 활용할 수 있도록 알려 드리고 있다.

테스트 케이스 설계/작성, 수행을 통해 품질률 측정하기

테스트케이스 작성 및 요구 검증 수행해 드립니다. | 300000원부터 시작 가능한 총 평점 4.9점의 IT·

kmong.com

서비스 설명

*Web/Mobile Application 테스트 케이스를 작성해 드립니다.*

다양한 분야의 QA 경험을 통해 가장 효과적이고, 효율적인 테스트 케이스를 설계하여 작성해 드리도록 하겠습니다.
제 3자가 테스트 케이스 수행 시에는 빠르고 이해하기 쉬운 언어로 작성하여 수행 후에는 보다 나은 품질로 의뢰인의 Application이 출시되는데 도움이 되도록 최상의 서비스로 만족시켜 드리겠습니다.

*이런 분께 추천드리는 서비스입니다.*

의뢰인의 Application이 요구사항대로 개발이 되었는지 확인이 필요한데 테스트 케이스가 없는 경우
출시 후에도 기존 기능에 문제가 없는지 테스트 케이스를 통해 확인이 필요한 경우
테스트 케이스를 통해 현재 품질 상태를 확인하고 싶은 경우

*제공되는 문서는 다음과 같습니다.*

테스트 케이스 수행 시 상태 관리에 필요한 포맷을 함께 제공해 드립니다.
아래와 같은 시트로 구성되어 있습니다.
[Test Report / Total Sum. / Issue List / TC Result Sum. / Update / Test Case]
테스트 케이스 작성 예시는 첨부된 이미지 확인 부탁드립니다.

서비스 제공 절차

1. 문서 공유
- 최대한 많은 정보를 주시는 것이 좋습니다.
- 출시 전의 경우 비밀 서약 동의해 드립니다.
2. 정보 분석 > 테스트 케이스 설계
3. 테스트 케이스 작성
4. 피드백 반영

의뢰인 준비사항

1. 화면 설계서(스토리보드)
2. 요구사항 명세서
3. 기능 명세서
4. 기획서
5. 메뉴 트리

- 위 문서가 없는 경우 개발 완료된 Application을 보면서 작성하는 방법이 있습니다. 이 방법은 매우 어려운 작업으로 추가 비용이 발생할 수 있습니다. 참고 바랍니다.

[N잡러] QA 및 테스트 프로세스 구축, 정립, 확립하는 방법!! (ft.크몽)

품생품사(品生品死) — Sun, 17 Sep 2023 12:00:23 +0900

테스트 프로세스를 구축하려는 이유?

크몽에서 테스트 프로세스 구축 서비스를 오픈하고 다양한 분야의 사람들이 문의를 하고 있습니다. 이 서비스를 오픈하게 된 가장 큰 목적은 테스트와 마찬가지로 스타트업이나 이제 막 시작하려는 회사에서 테스트를 체계적으로 하고 싶은데 배울 수 있는 채널이 많지 않다는 점에서 시작을 하게 되었습니다.

다른 서비스보다 조금 비용이 높은 이유는 제가 2년 동안 사용하고, 개선하면서 사용한 구글 시트를 통해 누구나 쉽게 테스트 프로세스를 이해하고 체계적으로 활용할 수 있는 문서를 제공해 드리고 있기 때문입니다.

제공해 드리는 문서를 간략하게 설명드리면 테스트 케이스를 작성하고, 수행만 하면 품질률을 계산해주는 아주 간단한 문서이지만 테스트 프로세스에 대한 이해도가 부족한 상태라면 만들기 어려운 문서라고 생각도 됩니다. 엑셀은 누구나 보면 사용 가능한 함수들로 구성되어 있으며, 추가적으로 산출물로 사용 가능한 테스트 결과 리포트도 반자동으로 생성이 되게 만들어 놓은 문서입니다.

그래서 보편적으로 사용하게 되면 테스트 결과에 대한 요약만을 볼 수도 있고, 산출물로 저장하기 위해서는 약간의 수작업을 통해 품질률이 개선됨을 확인할 수 있도록 구성이 되어 있습니다.

이 문서는 2년 동안 프로젝트를 수행하면서 지속적으로 수정과 개선을 하여 최대한의 효율성과 효과를 입증받은 문서라고 할 수 있습니다. 효율성은 테스트를 수행하고 개발하는 부서에서 느꼈으며, 효과는 보고를 받고 산출물을 관리하는 부서에서 충분히 느꼈던 부분입니다. 테스트 결과서에 작성된 품질률은 KPI(Key Performance Indicator - 핵심 성과 지표)의 측정 지표로 활용되기도 했습니다.

테스트에 관심을 가지고 체계적으로 테스트를 수행하고자 하고 품질에 대한 이해도를 높이기 위한 분들에게 적극 추천드립니다.

테스트 프로세스는 QA 프로세스가 아닙니다

QA 및 테스트 프로세스 구축, 정립, 확립해 드립니다 | 100000원부터 시작 가능한 총 평점 5점의 IT·

kmong.com

서비스 설명

*GoogleSheet를 활용하여 테스트 프로세스를 구축해 드립니다.*

"이런 분들께 적극 추천드립니다!"
1. 소프트웨어 테스트를 체계적으로 관리하고 싶은데 비용적으로 부담이 되는 분
2. 소프트웨어 테스트 프로세스를 처음 구축을 하려는 분
3. 소프트웨어 테스트 결과를 산출물로 보관이 필요한 분
4. 소프트웨어 품질률에 대한 정량적으로 기준이 필요한 분
5. 소프트웨어를 병목적으로 테스트해야 하는데 일정관리가 어려운 분

서비스 요약

[장점]
1. 비용의 부담 없이 엑셀 기반으로 누구나 쉽게 접근 가능합니다.
2. 클라우드 저장(Google Drive)으로 어디서나 접근이 가능합니다.
3. 테스트 케이스 수행만으로 링크된 결과를 통해 테스트 결과 리포트를 확인할 수 있습니다.
4. 테스트 결과 작성하는 시간을 최소화할 수 있습니다.
5. 체계적으로 테스트 프로세스를 관리할 수 있습니다.
6. 테스트 케이스와 이슈(결함, 개선 등)를 관리할 수 있습니다.
7. 등록된 이슈를 실시간으로 공유할 수 있습니다.
8. 최종적으로 정량적 지표를 통해 상품 및 서비스의 품질률을 확인할 수 있습니다.

[단점]
1. 접근성이 좋은 대신 보안 이슈가 있을 수 있습니다.
2. 이슈 등록 시 실시간 알림이 없어 불편할 수 있습니다.

서비스 프로세스

1. STANDARD : 일정표 / 테스트 관리 문서 / 유저 가이드 산출물로 제출드립니다.
- 자세하게 프로세스와 문서 사용법을 설명해 드립니다.
2. DELUXE : 일정표 / 테스트 관리 문서 / 유저 가이드 산출물로 제출드립니다.
- 유저 가이드를 기반으로 1시간 온라인(Google Meet) 교육해 드립니다.
3. PREMIUM : 일정표 / 테스트 관리 문서 / 유저 가이드 산출물로 제출드립니다.
- 제출된 산출물 검토 후 비즈니스 플로우에 맞게 테스트 관리 문서를 커스터마이징 해드립니다.
- 유저 가이드 및 커스터마이징 된 내용을 업데이트하여 2시간 온라인(Google Meet) 교육해 드립니다.

[N잡러] 지라를 활용하여 업무 프로세스 구축하는 방법!! (ft.크몽)

품생품사(品生品死) — Sat, 16 Sep 2023 12:00:37 +0900

Jira를 활용하시려는 분들께 추천 드립니다

기존 구글 시트로 테스트 프로세스를 구축하였다면, 이제는 테스트 프로세스를 포함한 업무 프로세스 구축 서비스를 제공하게 되었습니다. 사용하게 되는 도구는 아틀라시안의 Jira(지라) 입니다.

5년 이상 Jira 어드민 경험을 바탕으로 최적의 업무 프로세스를 세팅해 드리고자 크몽에 서비스를 올리게 되었습니다. 자세한 서비스 내용 및 요청 문의는 아래 링크를 이용 바랍니다.

JIRA를 활용하여 업무 프로세스 구축해 드립니다. | 1000000원부터 시작 가능한 총 평점 0점의 IT·프

kmong.com

해당 서비스를 잘 구축하기 위해서는 의뢰인 분이 Jira 라이센스를 가지고 사용하고 계셔야 합니다. 혹은 무료 라이센스로 사용중이고 앞으로 지속적으로 사용 계획이 있으신 분이어야만 합니다.

의뢰인 준비사항으로 꼭 확인 후 의뢰주시길 바랍니다.
- Jira 라이센스를 가지고 사용중이어야 합니다.
- 외부에서 IP접근(Jira 시스템)이 가능하도록 설정이 필요합니다.
- Jira > Admin 권한의 계정이 필요합니다.
- Admin 권한의 계정은 모든 이슈를 확인할 수 있기 때문에 보안상 공개 불가한 데이터(이슈)가 있는 경우 백업 후 삭제 부탁드립니다.
- 혹은 보안서약서가 필요한 경우 요청해 주시면 작성 후 회신 드리겠습니다.

서비스 설명

"이런 분들께 추천 드리는 서비스입니다."
1. Jira(지라)를 사용하고 있지만 이슈 트래킹으로만 활용 중인 경우
2. 이슈 유형을 구분하여 작업 관리를 하고자 하는 경우
3. 애자일(스크럼, 칸반) 보드를 활용하고자 하는 경우
4. Jira(지라)를 이용해 업무 생산성을 높이고자 하는 경우
5. 매달 Jira(지라) 비용을 내고 있지만 이렇게밖에 사용 못하는 건가? 고민하는 경우

"저는 이런 사람입니다."
1. Jira 시스템 관리자 8년차 입니다.
2. Jira/Confluence 사용 경험이 10년 이상입니다.
3. 대규모 개발 조직에서 Jira를 활용한 프로세스를 구축하였습니다.
4. Jira 관련 개인 블로그를 운영중입니다.

서비스 제공 절차

"Jira를 이용한 프로세스 구축은 장시간 구성원들과 함께 협업해야 하는 작업으로 아래 절차를 꼭 확인부탁 드립니다."
1. 사전 인터뷰를 통해 요구사항을 수집합니다.
- 온라인 미팅을 진행하고, 필요시 개별 문의 진행
2. 요구사항 분석을 통해 이슈 유형을 세팅합니다.
3. 정의된 이슈 유형에 따라 워크플로우를 세팅합니다.
4. 정의된 이슈 유형을 기준으로 이슈 화면을 세팅합니다.
5. 기존 생성된 이슈에 대해서 이관 작업을 수행합니다.
- 이관할 이슈는 필요에 따라 진행
6. 일주일 정도 사용해 보시고 피드백을 수집합니다.
7. 수집된 피드백 중 반영이 필요한 부분은 수정 작업을 진행합니다.
8. 유지보수가 가능하도록 교육을 진행합니다.

* 최대한 의견을 조율하고, 반영하여 의뢰인의 조직에 가장 효율적이고 효과적인 맞춤형 프로세스를 구축해 드립니다.

[품질 관리] 이론과 현실 사이에서 실무에 꼭!! 활용 가능한 테스트 프로세스 구축하기

품생품사(品生品死) — Fri, 15 Sep 2023 18:00:49 +0900

테스트 프로세스를 구축하려는 이유?

테스트 프로세스 이론의 모든 내용을 실무에 모두 적용하는 것은 불가능합니다. 다만, 우리는 이론에서 현실에 잘 맞는 프로세스를 선택하여 가장 효과적이고, 효율적으로 테스트를 수행하기 위해 선택을 할 뿐입니다.

프로세스 품질이 개발 완성도를 좌우한다

잘 맞는지는 해보지 않고는 알 수 없으며, 적용 후에는 후회보다는 좀 더 나은 프로세스를 만들기 위해 노력해야 합니다. 핏이 잘 맞는 프로세스 내에서 최고의 서비스 혹은 제품을 만들 수 있다는 점을 참고하시어 아래 내용들을 읽어 보시기 바랍니다. 기업 내에서 실제 테스트 프로세스 적용을 계획하고 계신다면 아래 서비스를 이용해 주시면 친절히 상담해 드리도록 하겠습니다.

QA 및 테스트 프로세스 구축, 정립, 확립해 드립니다 | 100000원부터 시작 가능한 총 평점 5점의 IT·

kmong.com

테스트 계획 - [현실편]

- 테스트의 목표를 달성하기 위해 필요한 활동 내역을 정의하는 단계입니다.

- 테스트 계획을 상세히 작성하게 되면 프로젝트가 종료되었을 경우 혹은 프로젝트 중간 계획 대비 결과물을 명확히 할 수 있게 되는 장점이 있습니다.

- 그렇다고 계획을 작성하는데 너무 많은 시간을 쏟진 않았으면 합니다.

[현실 테스트 계획 예시 - 참고]

1. 기간 : yyyy.mm.dd ~ yyyy.mm.dd(m/m or d/d)

2. 범위 : 테스트 범위

3. 테스트 전략 : 적용 가능한 테스트 전략을 모두 수립

- 범위 분석 후 테스트 전략을 선택하여 테스트 수행

- 필자는 해당 전략을 테스트 모듈화라고 칭하고 있습니다.

테스트 전략 리스트 업

요구사항 확인 테스트(테스트 케이스 수행)
이슈 확인 테스트(등록된 결함 수정 여부 확인)
회귀 테스트(소스코드 수정으로 인해 기존 기능에 문제가 없는지 확인)
유저 시나리오 테스트
크로스 브라우저 테스트 등등

테스트 계획

1차 : 요구사항 확인 테스트 - 수행/미수행

2차 : 이슈 확인 테스트 / 회귀 테스트 - 수행/미수행

3차 : 크로스 브라우저 테스트 / 회귀 테스트 - 수행/미수행

현실 업무에 적용하였을 때 시간도 많이 뺏기지 않고, 효과적이고, 효율적인 테스트가 가능했고, 계획 대비 수행율이 높게 나타났습니다.

- 테스트 전략 수행에 대한 프로세스가 명확해야 합니다.

- 테스트 범위 분석이 면밀하게 진행되어야 합니다.

테스트 전략 - [이론편]

SW 개발 프로세스 요구사항 분석의 마지막 단계에서 이루어지며, 사용자의 요구사항이 파악되는 시점에 개발시스템의 리스크 범위, 담당자 지정, 확보된 예산 등을 고려하여 향후 수행될 필요가 있는 테스트에 대한 전체 설계를 구상하는 활동이다.

【표 II-7. 테스트 전략】

테스트 전략 활동
착수 기준	입력물
▶ 사용자 요구사항 도출 ▶ 프로젝트 계획서 작성	▶ 고객요구 정의서(명세서) ▶ 프로젝트 개발계획서 ▶ 테스트 전략 가이드라인 ▶ 총괄 테스트 계획서
종료 조건	산출물
▶ 검토되고 승인된 테스트 전략	▶ 총괄 테스트 계획서
작업	① 테스트 요소 식별 ② 테스트 범위 정의 ③ 테스트 단계별 접근방법 정의 ④ 품질 목표 수준 정의 ⑤ 테스트 추진 체제 정의 ⑥ 테스트 산출물 및 책임자 정의 ⑦ 테스트 일정 계획 수립 ⑧ 총괄 테스트 계획서 작성 ⑨ 총괄 테스트 계획서 검토 ⑩ 총괄 테스트 계획서 승인

테스트 전략 활동의 상세 절차

① 테스트 요소 식별

개발 시스템에 관련된 위험을 평가하고, 그 위험과 관련된 테스트 요소를 정의한다.

- 테스트 요소 식별

▶ 테스트 대상 시스템 및 관련 비즈니스 위험을 식별
▶ 테스트 수행 중에 평가되어야 하는 위험을 기반으로 테스트 요소를 식별
▶ 심각도 및 위험도를 고려하여 테스트 요소를 분류

- 식별된 테스트 요소에 대해 테스트 단계/유형별로 테스트 전략을 정의

▶ 개발 프로젝트의 생명주기를 파악
▶ 테스트 요소와 관련된 위험을 최소화하기 위해, 개발프로젝트 생명주기의 각 단계에 적합한 테스트 유형을 정의
▶ 테스트의 유형별로 테스트 방법을 정의

② 테스트 범위 정의

개발 프로젝트의 범위 및 상위 요구사항을 분석하여 테스트 범위를 설정한다. 설정된 테스트 범위는 단계별 테스트에 대한 상세 계획 수립 시, 요구분석 및 설계단계에서 정의된 각 테스트 요구사항 등을 검토하여 테스트 항목, 테스트 항목의 특성, 테스트 하지 않을 항목의 특성을 명세화 하는 기반 자료로서 활용된다.

③ 테스트 단계별 접근방법 정의

프로젝트에서 적용할 테스트 단계와 단계별 테스트에 대한 수행방안을 정의한다.

- 개발생명주기별 테스트 단계 정의

▶ 개발 프로젝트에서 수행할 테스트 단계를 정의
▶ 시스템의 크기와 복잡도, 중요도, 개발 성숙도, 고객 요청사항, 테스트 일정, 테스트환경 등을 고려

- 각 단계별 테스트 수행방안 정의

▶ 개발 프로젝트의 생명주기를 파악
▶ 단계별로 필요한 테스트 유형 및 수행 방안을 정의

④ 품질 목표 수준 정의

테스트 단계에서 수집 및 관리가 필요한 품질 지표와 목표 수준을 정의한다.

⑤ 테스트 추진 체제 정의

상위 단계에서 정의한 테스트 단계 및 접근 방안을 기반으로, 테스트를 수행할 추진 조직 및 역할을 정의한다.

⑥ 테스트 산출물 책임자 정의

테스트 종류별 산출물을 선정하고, 작성 시점 및 책임자를 정의한다.

⑦ 테스트 일정 계획 수립

각 테스트 단계에 대한 전체적인 일정을 기술한다. 상세 일정 수립이 어려운 경우는 각 테스트 전체 일정을 기술하고, 상세 일정은 단계별 테스트 계획 활동에서 수립한다.

⑧ 총괄 테스트 계획서 작성

상위 단계를 기반으로 하여, 총괄 테스트 계획서를 작성한다. 총괄 테스트 계획서에는 식별한 테스트의 범위, 단계, 수행방안, 추진 체제, 산출물, 책임자, 일정과 같은 테스트 전략에 대한 내용을 기술한다.

⑨ 총괄 테스트 계획서 검토(테스트 전략 협의)

테스트 설계자는 총괄 테스트 계획서에 기술된 테스트 전략에 대하여, 프로젝트 관리자 및 품질보증 담당자와 검토 및 협의를 수행한다.

⑩ 총괄 테스트 계획서 승인

프로젝트 책임자는 총괄 테스트 계획서대로 테스트가 수행되면, 프로젝트 및 제품의 품질을 보증할 수 있는지 여부를 판단하고, 작성된 총괄 테스트 계획에 대하여 승인을 요청한다.

흐름도

테스트 계획

각 단계별 상세 테스트 계획을 수립하는 활동으로 각 단계별 테스트에 대한 계획은 개발 단계에 따라 작성되는 시점과 산출물이 다르다.

【표 II-8. 테스트 계획】

테스트 전략 활동
착수 기준	입력물
▶ 인수 테스트 계획 - 고객 요구사항 도출	▶ 인수 테스트 계획 - 고객 요구사항 정의서(명세서) - 프로젝트 개발계획서
▶ 시스템 테스트 계획 - 업무 설계서 작성	▶ 시스템 테스트 계획 - 총괄 테스트 계획서 - 프로젝트 개발계획서 - 고객 요구사항 정의서(명세서) - 설계서
▶ 통합 테스트 계획 - 업무 설계서 작성	▶ 통합 테스트 계획 - 총괄 테스트 계획서 - 프로젝트 개발계획서 - 고객 요구사항 정의서 - 설계서 - 프로젝트 표준
▶ 단위 테스트 계획 - 테크니컬 설계서	▶ 단위 테스트 계획 - 총괄 프로젝트 계획서 - 프로젝트 개발계획서 - 테크니컬 설계서 - 프로젝트 표준
종료 조건	산출물
▶ 테스트 계획서 검토 및 승인	▶ 각 단계별 테스트 계획서
작업	① 테스트 범위 정의 ② 테스트 착수기준과 완료기준 정의 ③ 테스트 환경 정의 ④ 필요 자원 및 일정 정의 ⑤ 테스트 리스크 정의 ⑥ 결함 및 이슈 보고 절차 정의 ⑦ 테스트 계획서 작성 ⑧ 테스트 계획서 검토 ⑨ 테스트 계획서 승인

테스트 계획 활동의 상세 절차

① 테스트 범위 정의

테스트 전략을 기반으로 테스트 범위를 정의한다. 모든 대상 영역을 테스트 하지 않을 경우, 테스트 제외 범위와 제외 사유를 기술한다.

② 테스트 착수 기준과 완료 기준 정의

테스트를 시작하기 전에 완료되어야 할 활동들과, 테스트 활동이 종료되어야 할 시점을 정의한다.

③ 테스트 환경 정의

테스트를 수행할 환경을 정의한다.

- 테스트 환경에 대한 HW 및 SW 구성을 기술한다.

- 테스트에 필요한 테스트 데이터 생성 및 유지 절차를 정의한다.

④ 필요 자원과 일정 정의

자원은 HW, SW, 인력으로 구분하여 정의하며 기존 보유 자원도 기술한다. 테스트 일정은 테스트 단계의 주요 활동 및 시작/완료 일자를 정의한다. 일반적으로 프로젝트 수행 일정과 함께 수립된다.

⑤ 테스트 리스크 정의

테스트 수행 시 고려되어야 할 사항과 위험 요소를 기술한다.

⑥ 결함 및 이슈 보고 절차 정의

테스트과정에서 발견된 결함 및 이슈 보고 절차를 정의한다. 보고 절차에는 발견된 결함 기록, 관련자의 정보 공유, 해결하기 위한 절차가 포함된다.

⑦ 테스트 계획서 작성

테스트 단계별로 상위 단계의 적업을 기반으로 하여, 상세한 테스트 계획서를 기술한다.

⑧ 테스트 계획서 검토

프로젝트 관리자 및 품질보증 담당자와 검토 및 협의를 수행한다.

⑨ 테스트 계획서 승인

테스트 계획서가 프로젝트 및 제품의 품질을 보증할 수 있도록 작성되었는지 여부를 판단하고 작성된 테스트 계획에 대하여 승인을 요청한다.

【그림 II-5. 테스트 계획 활동 작업 흐름도】

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[공지사항 - 2025.03] 블로그 개편 - 주제별 분리를 진행하였습니다.

품생품사(品生品死) — Fri, 24 Mar 2023 03:10:30 +0900

안녕하세요. 품생품사입니다.

제 블로그를 찾아와 주셔서 정말 감사합니다.

이번에 주제별 블로그를 분리하게 되었습니다.

기존에 참고하시던 블로그가 안보이실 수 있으니(SEO 세팅 전) 아래 URL에 접속하셔서 필요한 정보를 찾아보시기 바랍니다.

1. 소프트웨어 품질보증 및 품질관리 그리고 소프트웨어 테스트에 도움이 될만한 정보를 제공하고, 소소한 일상을 공유하는 블로그입니다.

- 메인 블로그 : https://qa-testing.tistory.com/

품생품사(品生品死)의 소프트웨어 품질 정보 창고

소프트웨어 품질보증 및 품질관리 그리고 소프트웨어 테스트에 도움이 될만한 정보를 제공하고, 소소한 일상을 공유하는 블로그입니다.

qa-testing.tistory.com

2. 관심 있는 문화(여행, 영화, 공연)나 여행에 대한 정보를 공유하는 블로그입니다.

- 준비중

좀 더 상세하고, 전문화를 위해 블로그를 분리하여 개편하였으니 관심 부탁 드립니다.

감사합니다.

[실전 취업/이직 준비] 경력 기술서를 눈에 띄게 하는 포트폴리오 작성하는 방법!!

품생품사(品生品死) — Thu, 2 Feb 2023 12:35:04 +0900

포트폴리오로 심사관 혹은 면접관에게 나를 각인시키기

오랜만에 취업/이직 관련 글을 작성하게 되었습니다.

최근 카페에 많이들 물어보시는 "QA / 테스터 이직 시 포트폴리오는 무엇을 준비해야 하나요?"라는 질문에 대한 답? 예시?를 설명드리려 이렇게 글을 쓰게 되었습니다.

포트폴리오 작성하는 방법

우선 기존에 작성된 포트폴리오 "1탄 : 보여주기를" 참고해 주세요. 1탄에서는 왜 포트폴리오가 필요한지? 기업에서는 왜 포트폴리오를 원하는지? 어떤 포트폴리오를 만들어야 하는지에 대한 예시를 다양하게 작성해 두었습니다.

[실전 이직/취업 준비] QA 혹은 테스트 직무에 지원하기 위한 포트폴리오 작성 방법 공유!!

포트폴리오 준비의 목적은?경력직의 경우 포트폴리오는 자기가 해왔던 것을 문서로 보여주면 됩니다. 간단하지만 쉽지 않기도 합니다. 면접관이나 서류 심사관은 한눈에 보이지 않으면 자세히

qa-testing.tistory.com

이번 2탄에서는 나를 각인시키는 목적으로 프로젝트 관점의 포트폴리오에 대한 설명과 예시를 보여 드리려 합니다. 취업/이직 시 잘 준비하셔서 도움이 되시길 바랍니다.

포트폴리오의 의미를 다시 생각해 보자.

ChatGPT에게 물어봤습니다.

[질문] 포트폴리오가 무엇입니까?

포트폴리오(portfolio)는 개인이나 조직이 보유한 자산, 경험, 업적 등을 체계적으로 
정리한 문서나 콘텐츠 모음을 의미합니다. 이러한 자산과 경험들은 주로 일자리 구직, 
대학 진학, 취업 면접 등에서 사용됩니다.

포트폴리오는 대개 이력서와 함께 제출되며, 이력서에서 제공하는 정보 이상으로 세부적인 내용과 
함께 실제 업무에서 수행했던 프로젝트나 작업물, 경험 등을 보다 구체적으로 제시할 수 있습니다. 
또한, 포트폴리오는 자신이 보유한 역량과 능력을 강조하기 위해 사용되기도 합니다.

포트폴리오는 주로 디자이너, 작가, 예술가, 개발자 등 창작 분야에서 자주 사용되지만,
최근에는 다양한 분야에서 활용되고 있습니다. 포트폴리오를 구성할 때는, 자신이 원하는 
메시지를 전달할 수 있는 구성과 디자인, 내용의 품질, 그리고 타겟 시장에 맞는 
적절한 분량 등이 중요한 요소로 작용합니다.

여기서 가장 중요한 포인트는 자신이 보유한 역량과 능력을 강조하기 위해 사용되기도 한다는 점입니다. GTP도 잘 알고 있네요? 또한, 마지막에 자신이 원하는 메시지를 전달할 수 있는 구성이 필요하다고 합니다.

1탄에서는 정말 기초적인 실무의 대한 포트폴리오였다면, 이제는 프로젝트 관점에서 QA가 어떤 포트폴리오를 보여주었을 때 서류 심사관이나 면접관이 "이 친구 면접 한 번 보자"라는 생각을 하게 될지... 제가 면접관일 때 어떤 포트폴리오를 보게 되었을 때 면접을 보고자 하는지 알려 드리려 합니다.

경력 기술서를 참조할 수 있는 포트폴리오를 만들자.

대부분의 회사는 입사 지원. 서류 지원 시 경력 기술서를 기본적으로 작성하게 되어 있습니다. 우리는 보통 경력 기술서를 아래와 같이 작성하곤 합니다.

매우 안 좋은 경력 기술서 예시입니다.

이렇게 작성하면 절대 안됩니다.

그리고 조금 보완된 경력 기술서 예시입니다.

보완된 경력 기술서

면접관이나 서류 심사관은 JD(Job Description)을 기준으로 경력이 부합하는지의 척도를 바로 경력 기술서를 보고 판단을 하게 됩니다. JD에 "ITSM 인증 경험"이라는 조건이 있다고 가정했을 때 어떤 경력 기술서를 보고 궁금증이 더 생겼을까요?

만약 그 궁금증이 두 번째 이미지에 관심이 갔는데 과연 저 문구 한 문장으로 나를 면접관에게 '각인시키기'가 가능할까요?

이럴 때 필요한 것이 바로 '포트폴리오'입니다.

자세한 경력기술서 작성에 대한 블로그는 아래 링크에서 확인 바랍니다.

[실전 취업/이직 준비] 서류 심사에 합격할 수 밖에 없는 경력 기술서 작성하는 방법!!

qa-testing.tistory.com

수행 프로젝트의 이력을 포트폴리오로 보여주자.

가장 중요한 부분입니다. 서류 심사관이나 면접관이 가장 중요하게 보는 부분이 바로 어떤 프로젝트를 수행했고, 프로젝트에 어떤 부분을 기여했는지를 서류에서 확인이 가능해야 합니다. 대부분의 사람들은 위와 같이 프로젝트를 나열만 하고, 내가 프로젝트에 어떤 부분을 얼마만큼 기여했고, 기여한 만큼 어떤 성과를 내었는지 상세히 작성하지 않습니다.

이 글을 읽으시는 분들은 꼭!!! 경력 기술서에는 프로젝트를 나래비하되 내가 어떤 부분의 얼마만큼을 기여했고, 기여한 부분이 반영되어 어떤 성과를 내었는지 반드시 작성하길 바랍니다.

그렇다면 분명 이전에 경력기술서를 참조할 수 있는 포트폴리오를 작성하라고 했으니 우리는 프로젝트에 기여한 부분과 얼마만큼 기여했고, 어떤 성과를 내었는지 보여줄 수 있는 포트폴리오를 만들면 됩니다.

이것이 진짜 회사에서 원하는 포트폴리오다.

첫 예시 - 게임회사 입사의 경우

N사의 JD는 아래와 같습니다.

- N사에서 퍼블리싱하는 게임 서비스 품질 관리
 . 프로젝트 품질 기준에 따른 QA
 . 서비스 품질 위험 요소 도출 및 해소 활동
 . QA 프로세스 개선

기본적으로 경력기술서에는 어떤 게임 프로젝트에 투입되어 기여한 부분이 어떤 부분이며, 게임 출시는 잘 되었는지? 혹은 출시 후 어떤 이슈가 있었는데 VOC를 모니터링 중 좀 더 빨리 캐치업 해서 개발팀이 대응할 수 있게 했다는 내용 등이 작성되면 매우 좋습니다.

[질문] 프로젝트 수행 시 작성한 테스트케이스만 포트폴리오로 제출하셨었죠?

테스트케이스를 왜 그렇게 설계하였는지? 혹은 무엇을 기준으로 테스트케이스를 이렇게 작성했는지 이유를 작성한 문서는 있었나요? 있었는지 잘 생각해 보시기 바랍니다. 테스트케이스의 포트폴리오는 작성 수준을 보고자 하는 것도 있겠지만 더 중요한 부분은 왜 이렇게 설계하였고 작성된 테스트케이스를 수행하였을 경우 얼마만큼의 제품이나 서비스를 안정화시킬 수 있는지가 중요합니다.

이런 내용을 좀 더 강력하게 어필할 수 있는 부분이 바로 "게임 플레이 이력"입니다. 이게 무슨 소용이 있을까?라는 의문이 드실 수 있는데 게임 회사의 기본 소양이 바로 "게임 매우 매우 매우 좋아합니다."입니다. 게임을 좋아하고, 얼마나 잘 플레이하는지 보여 줄 수 있는 포트폴리오가 매우 매우 유용합니다.

게임 회사 서류 지원 시 첨부했던 게임 이력

사실 이 포트폴리오를 확인하기 위해서는 면접에 물어보는 방법밖에 없기 때문에 면접에 불릴 수 있는 확률이 높아집니다. 진짜 게임을 했는지 안 했는지 확인을 해야 하기 때문이고, 보통은 지원한 회사의 게임 장르에 대한 질문을 많이 받습니다. 제가 게임 회사 지원 시 50%는 서류를 합격한 이유 중에 하나라고 생각합니다.

☠️ 참고로 게임회사 입사를 희망하였을 때 그동안 공부했던 인포그래픽을 이용해서 게임 기획서와 게임 분석서(지원 회사의 게임)를 작성해서 제출하기도 했습니다. 주의할 점은 QA 지원인데 분석서는 도움이 되었을지 모르지만 기획서는 공격을 당했던 기억이 있습니다. 아무런 도움이 안 되는 포트폴리오는 독약이 될 수 있다는 점도 명심하길 바랍니다.

두 번째 예시 - 서비스, 제품을 보유한 일반 회사의 QA

K사의 JD는 아래와 같습니다.

• 서비스 품질 및 개발 생산성 향상을 위한 QA Process 수립 및 개선
• 서비스 품질에 대한 지표 관리 및 유관부서와의 협업
• 서비스 완성도 향상을 위한 테스트 케이스 작성 및 수행

사실 위와 같은 JD는 매우 어려운 난이도의 JD라고 생각됩니다. 보통 제 경력(2023년 기준 15년 차) 정도 채용을 하기 위한 JD라고 보입니다. 저는 만약 위와 같은 JD를 보고 지원을 결심했다면 경력기술서는 위에서 말씀드린 것처럼 작성하고, 첨부하는 포트폴리오는 아래와 같습니다.

QA Process 수립 및 개선의 키워드를 참조할 수 있는 프로젝트의 목록을 이쁘게 정리한 사이트를 첨부할 것 같습니다.

현재 포트폴리오로 사용중인 프로젝트 목록

위의 프로젝트를 수행하면서 어떤 프로세스로 진행했는지와 진행하면서 느꼈던 점, 개선을 통해 좋아진 점을 어필할 것 같습니다. 또한, 크몽 서비스를 통해 의뢰 주시는 의뢰인 분들의 회사에 QA나 테스트 프로세스가 정립될 수 있도록 컨설팅하거나 Jira 프로세스 세팅에 경험이 있음을 강조할 것 같습니다.

QA 및 테스트 프로세스 구축, 정립, 확립해 드립니다 | 100000원부터 시작 가능한 총 평점 5점의 IT·

kmong.com

JIRA를 활용하여 업무 프로세스 구축해 드립니다. | 150000원부터 시작 가능한 총 평점 5점의 IT·프

2개 총 작업 개수 완료한 총 평점 5점인 품생품사의 IT·프로그래밍, 기타 서비스를 2개의 리뷰와 함께 확인해 보세요. IT·프로그래밍, 기타 제공 등 150000원부터 시작 가능한 서비스

kmong.com

그리고 마지막으로 테스트 수행을 통해 얻어질 결과를 기반으로 품질률 측정을 통해 제품이나 서비스 출시에 대한 기준을 정량화한 것을 보여줄 수 있도록 "QA 리포트 - 테스트 결과"를 첨부할 것 같습니다.

품질 리포트의 기준이 되는 테스트 결과 메트릭 정보 샘플

테스트 수행에 대한 결과를 통해 품질률을 어떻게 측정했으며, 어떤 리포트를 발행하였는지 보여주는 것이 제일 좋은 포트폴리오의 예시라고 생각합니다.

사실, 품질률을 측정하는 것은 매우 어려운 일이며, 경험하기도 어려운 일이기 때문에 희소가치 경험일 수 있다는 점도 참고해 주시기 바랍니다. 희소가치의 경험이 회사의 도움이 될만한 경험이라면 혹은 회사에서 해보고자 하지만 전문가의 부재로 시도조차 하지 못한 상황이라면 김칫국 100번 드링킹 하고 면접장에 가도 됩니다.

전체 글 10초 요약

포트폴리오를 요약하자면

QA? 테스터? 직군과 상관없이...

어떤 직군이던 상관없이

회사에서 작성한 JD(Job Description)을 잘 읽어보고 먼저 경력기술서를 잘 작성해야 합니다. 경력 기술서에는 경력 혹은 프로젝트의 나래비가 아닌 프로젝트의 기여한 점을 중점적으로 작성해야 합니다. 프로젝트에 기여한 점을 보충 혹은 서류 심사관이나 면접관에게 궁금증을 유발할 수 있는 포트폴리오가 첨부되어야 합니다. 증명하거나 궁금증을 유발하거나의 컨셉을 명확히 해서 첨부하는 것을 추천드립니다.

PS : 서류 지원이나 면접을 준비하시는 모든 취준생분들을 응원합니다. 불합격의 소식이 들려와도 더 좋은 회사를 가기 위한 밑거름이라 생각하시고 다음을 준비하시는 여러분이 되셨으면 하는 바램입니다.

긴 글 읽어 주셔서 감사합니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[프로세스] 사례 기반 - 도구만 잘 활용해도 프로세스 관리자가 될 수 있다!!(ft.지라)

품생품사(品生品死) — Fri, 16 Sep 2022 19:00:14 +0900

Jira는 프로세스 관리 및 커뮤니케이션 도구이다.

Jira 시스템 관리자로 업무를 수행한지 벌써 10여년이 되어갑니다.

그동안 개인적으로 Jira를 효율적으로 활용하기 위해 고민도 많이하고 구현도 많이 했는데요.

이번 크몽에서 테스트 프로세스, 나아가 품질 프로세스를 구축하기 위해 시작한 여정을 정리해 보았습니다. 해당 블로그는 회사에서 운영중인 블로그에 작성하였으며, 이력을 남기기 위해 큐레이션 합니다.

썸네일 이미지

크몽에서 만들어가는 Jira를 활용한 프로세스 구축은 저에게 또 하나의 도전이 될 것 같습니다.

[2022년] OO의 Jira 사용기 : 극대화 편

Jira 사용성 개선 계획

기존에도 Jira를 잘 사용하고 있었지만 좀 더 잘 사용해보고자 하는 의견이 많았습니다. 그래서 간단하게 Task를 정리하여 계획을 작성하였습니다.

현재 Jira 사용 분석

- 이슈 유형/워크플로우/이슈 화면 정리
- 이슈 유형/워크플로우/이슈 화면 재정의
- 보드 구성(메트릭)
- 리뷰 및 피드백 반영
- 모니터링 및 개선 활동

첫 번째, 무엇인가를 개선하기 위해서는 분석 활동이 매우 중요합니다. 무엇이 잘 되고 있는지 혹은 무엇이 부족한지를 판단하는 중요한 근거 자료를 발견할 수 있기 때문입니다.

현재 Jira를 어떻게 사용하고 있는지 Admin 권한을 받아서 살펴보았고 Jira 활용도가 높은 구성원의 인터뷰를 통해 평소 불편한 점과 좀 더 잘해보고자 하는 부분을 듣고 정리하였습니다. 이와 더불어 어떻게 구성하는 것이 좋을지 제 생각과 지식 또한 정리하고 공유하였습니다.

두 번째, 기존 Admin 페이지에는 사용하지 않는 일명 쓰레깃값들이 관리되고 있지 않았습니다. 앞으로 체계적인 관리를 위해서는 불필요한 값들을 선 정리하는 작업이 필요했습니다.

Jira의 강점 중의 하나는 삭제 시 유효성이 동작한다는 점으로 매우 논리적으로 구성되어 있기 때문에 그냥 삭제할 수 있는 데이터는 아무도 사용하지 않는다는 의미이기도 합니다.

세 번째, 인터뷰를 통해 얻은 결과물을 통해 이슈 유형/워크플로우/이슈 화면을 재정의합니다. 사용성 개선 활동의 가장 핵심적인 부분입니다.

네 번째, Jira를 사용하기 위한 속성값이 모두 정의되면 보드를 구성합니다. 보드 구성은 업무의 효율성을 극대화할 수 있도록 구성해야 합니다. Jira에서는 효율성을 최대화하기 위해 다양한 보드를 지원하는 것이 이런 연유에서입니다.

마지막으로 적용된 영역에 대해서 기존 구성원들에게 공유하고, 리뷰합니다. 그리고 피드백을 받아서 추가로 개선하거나 정해진 부분을 프리징합니다. 바로 모든 것을 포용할 수 없기 때문에 지속해서 모니터링하는 것도 개선 활동의 매우 중요한 부분입니다.

이슈 유형/워크플로우/이슈 화면 정리

기존에 Admin은 생성하고 삭제나 변경에 대한 관리가 되지 않았습니다. 새로운 이슈 유형이나 워크플로우, 그리고 이슈 화면을 생성하고 사용하기에는 매우 복잡한 상태였습니다.

대부분 Jira를 사용하는 기업의 Admin은 비슷할 거라 생각합니다. 생성과 변경만 하고 사용자 익명화와 같은 정리 작업을 하지 않기 때문입니다.

그래서 기존 사용하던 이슈 유형, 워크플로우, 이슈 화면을 Old Scheme로 구성하여 한 곳에 모아두는 작업을 하였습니다. 이렇게 작업할 때 좋은 점은 사용자들은 바뀐 것도 모르고 업무를 수행하는 데 아무런 영향이 없으면서 정리가 가능한 방법입니다.

사용하지 않거나 불필요한 항목을 삭제해야 하는 경우는 삭제 가능 여부를 판단하기 위해서 해당 이슈 유형이나 워크플로우를 직접 사용하는 구성원에게 개별 문의를 해야만 했습니다. 자칫 잘못 삭제하게 되면 현재 업무에 영향을 줄 수 있기 때문에 삭제 작업을 할 때는 꼭 현재 사용 중인지 미사용 중인지를 확인하고 삭제하시기 바랍니다.

좀 더 자세한 내용이 궁금하신 분들은 아래 링크를 통해 확인 부탁 드립니다.

크몽 개발팀 Jira 사용기 : 극대화 편

Jira를 이렇게까지 사용 가능한지 난 몰랐네?

medium.com

크몽 개발팀 Jira 사용기

민첩한 조직 구조를 유연하게 유지하는 데 도움을 준 Jira 사용기

blog.kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스

[지라 기본 가이드 - Chap.2] Jira를 시작하기 위한 기본 개념 알아보기!!(ft.Confluence)

품생품사(品生品死) — Mon, 21 Mar 2022 22:52:58 +0900

Jira 개념 알기(3분 컷)

Jira대한 기본 개념은 아래와 같습니다.

JIRA 사용의 시작은 이슈 생성 = 내가 할 일을 만드는 것
JIRA는 ALM(Application Lifecycle Management) 도구(이슈 관리 도구 X)

앞으로 계속 연재하다보면 나올 개념을 잠깐 언급하면

✨ 할 일은 곧 Jira에서 Backlog(백로그)라는 용어로 사용하게 된다. 사실 Backlog는 할 일로 단순한 의미는 아니지만 아직 처음 시작하는 우리에게는 어려운 의미를 깊게 알 필요없습니다. 앞으로 자연스럽게 알게 될 것입니다.

Jira에서 이슈를 해결해 나가는 것은 매우 중요한 일입니다. 이슈를 해결한다고 하면 대부분 소스코드를 작성하거나 수정해서 해결해 나간다고 생각할 수도 있는데 이것은 Jira 시스템에 대한 편견입니다. Jira에는, 정확히는 Jira의 프로젝트에는 이슈 유형이라는 것이 있습니다. 예를 들면 이슈 유형은 "화장실 가기"를 생성할 수도 있습니다.

Jira 시스템의 기본적인 컨셉은 아래와 같습니다.

구분	상세 내용
Project Categories	여러 프로젝트를 카테고리별로 분류하여 관리
Projects	조직의 요구사항에 따라 정의 된 이슈들의 모음 or 집합
Components	하나의 프로젝트를 세분화시킬 수 있는 단위 구성요소에 따라 이슈들을 분류하는 데 사용됨
Versions	프로젝트의 특정시점을 지정하기 위해 사용 Release 일정을 관리 할 때 사용됨
Issues	JIRA 에서 관리할 기본 항목, 내가 해야 할 일을 구분함
Issue Types	프로젝트를 진행하면서 생기는 이슈의 종류를 의미 , 기본적으로 Bug, Improvement, Task, New Feature가 기본 정의되어 있음
Sub Tasks	특정 Issue 에 부가적으로 생길 수 있는 하위 이슈로 사용됨

그리고 Jira의 사용목적이 명확해야 합니다. 사실 이슈 트래킹 용도로 사용한다면 그렇게만 사용하면 됩니다. 하지만 이슈 트레킹으로만 사용하기에는 Jira라는 시스템의 기능이 너무 많고, 활용도가 높기 때문에 저는 커뮤니케이션의 용도로 사용을 추천 드리는 것입니다.

만약 Jira를 이슈 트래킹의 용도로만 사용하고 계시다면 아래 연재 블로그를 참고해 주세요.

[ALM - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1

목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1 IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. Jira | Issue & Project Tracking Software | Atlassian Plan, track, and m..

qa-testing.tistory.com

Jira의 기본적인 사용목적은 아래와 같습니다.

특정 ‘이슈’를 누가 발견했는지, 누가 해결해야 하는지, ‘이슈’는 현재 어떤 상태인지 파악하고 한눈에 해결 및 관리함.
단순히 메일이나, 구두로 업무를 진행하는 것보다 팀원들과 유관 부서와의 작업 현황을 확인하고 스케줄과 우선 순위를 조절할 수 있음.
실무자의 경우 ‘이슈’에 대한 역할과 임무를 분명히 할 수 있음.
협업 시 불필요한 커뮤니케이션의 비용을 최소화 할 수 있음.
‘이슈’ 해결에 대한 히스토리가 남기 때문에 후에 비슷한 이슈가 발생했을 때 처리 과정을 되짚어 볼 수 있는 지식 자산이 됨.
개발 단계에서 버그를 관리하고, 개발 소스 혹은 이미지의 수정 내역을 남길 수 있다는 점이 강점임.

#1 일반적인 프로젝트 컨셉

우선 가장 먼저 알고 있어야할 것은 프로젝트 컨셉입니다. Jira를 이용하는데 있어서 프로젝트의 개념은 매우 중요하며, 프로젝트를 시작으로 종료하기까지의 모든 행위를 기록하는 곳이 바로 Jira의 프로젝트이기 때문입니다.

재미있는 것은 일반적인 프로젝트의 개념이 그대로 Jira 프로젝트의 개념에 녹아있다는 점입니다.

일반적인 프로젝트 컨셉

#2 아틀라시안에서 Jira를 이용한 컨셉

일반적인 컨셉을 그대로 차용하고 있기 때문에 동일한 아키텍처로 Jira에서도 프로젝트 컨셉을 가져가고 있다고 볼 수 있습니다. 위에 일반적인 프로젝트와 매칭하여 살펴 보시기 바랍니다.

Jira의 프로젝트 컨셉

일반적인 프로젝트에서는 이슈 유형(Issue type)을 구분하지 않지만 Jira에서는 이슈 유형을 구분해 놓을 것을 확인 할 수 있습니다. 위 이미지와 같이 Jira에서는 이슈 유형의 구분이 매우 중요합니다. 이것은 나의 할 일이며, Backlog(백로그)라고도 불리고, 프로젝트를 끝내기 위해 꼭 해결해야 하는 이슈이기 때문입니다.

#3 실제 프로젝트에 적용한 컨셉

그리고 실제로 Jira 프로젝트를 세팅하기 전 구성도를 한번 살펴 보도록 하겠습니다. 이 구성도는 실제 제가 Jira를 초기에 세팅할 때 그렸던 구성도이며, 이슈 유형을 어떻게 사용할지 간단하게 작성되어 있습니다.

실제 프로젝트 적용 컨셉

프로젝트 컨셉 중에 Level3에 대해서 구성한 것이며, 좀 추가된 내용은 요구사항 명세에 대한 내용입니다. 지금은 아주 간단하게 설명하면 요구사항 A에 대해서 A 이슈가 필요하고, A 이슈는 보통 Epic으로 생성되며 Epic(A)는 여러개의 Story, New Feature, Task로 구성됩니다. 또한 개발중 발생한 Bug도 포함되기도 합니다.

이슈 유형에 대해서는 다음 챕터에서 자세히 다룰 것이기 때문에 지금은 그런게 있구나하고 그냥 넘어가시면 됩니다. 이번 챕터에서 꼭 기억해야 하는 것은 Jira 프로젝트의 개념입니다.

"Jira의 프로젝트 = 할 일의 모음이다. 할 일을 모두 해결하면 프로젝트가 종료된다" 라는 것만 기억해 주시길 바랍니다.

[지라 기본 가이드 - Chap.1] Jira에 대해서 간단하게 알아보기!!(ft.Confluence)

품생품사(品生品死) — Thu, 17 Mar 2022 09:11:53 +0900

Overview

지라(JIRA)라는 이름의 유래는 고지라라는 일본식 이름에서 따왔다고 합니다.
아틀리시안에 따르면, 190개의 국가에 150,000명의 고객이 지라를 사용하고 있습니다.

Jira 간략 정보

Jira는 190 개국 180,000명 이상의 고객이 이슈 추적 및 프로젝트 관리에 사용하고 있으며, 버그 추적 및 프로젝트 관리를 위해 특정 시점에 Jira를 사용한 조직 중에는 Fedora Commons, Hibernate 및 Jira와 Bugzilla를 모두 사용하는 Apache Software Foundation이 있습니다.

Jira에는 경쟁 업체 Bugzilla에서 마이그레이션 할 수 있는 도구가 포함되어 있고, Jira는 4 가지 패키지로 제공됩니다.

- Jira Work Management는 일반적인 프로젝트 관리.
- Jira Software에는 애자일 프로젝트 관리.
- Jira Service Management는 IT 운영 또는 비즈니스 서비스 데스크에서 사용.
- Jira Align은 전략적 제품 및 포트폴리오 관리.

Jira는 Java 로 작성되었으며, Pico inversion of control container, Apache OFBiz 엔티티 엔진 및 WebWork 1 기술 스택을 사용하고 있습니다. 원격 프로 시저 호출 (RPC), JIRA는 이 REST , SOAP 및 XML-RPC의 인터페이스를. Jira는 Clearcase , CVS ( Concurrent Versions System ), Git , Mercurial , Perforce , Subversion , 및 Team Foundation Server와 같은 소스 제어 프로그램과 통합됩니다.

영어, 프랑스어, 독일어, 일본어 및 스페인어를 포함한 다양한 번역과 함께 제공되고 있으며, Jira는 고객 지원 티켓을 다른 문제 추적 시스템과 공유하기 위해 Networked Help Desk API를 구현하고 있습니다.

ATLASSIAN CI

#1 도구를 사용해야만 하는 이유

도구를 사용하려는 이유는 회사의 사정에 따라 다양한 이유가 있을 수 있지만 필자가 이야기하는 Jira 사용에 대한 이유는 크게 딱! 3가지라고 생각합니다.

- 커뮤니케이션을 원활하게 하기 위함입니다.

- 이슈를 체계적으로 관리하기 위함입니다.

- 프로젝트를 철저하게 관리하기 위함입니다.

앞으로 연재되는 글들은 커뮤니케이션과 이슈, 그리고 프로젝트 딱 3가지 만을 가지고 풀어갈 것입니다. 소프트웨어를 개발하고, 완성하는 데 있어서 이 3가지가 왜 중요하고, 꼭 도구를 이용해서 관리해야만 하는지 Jira를 이용해서 어떻게 풀어가는지를 알려드리도록 하겠습니다.

#2 ALM 도구 중에 왜 Jira여야만 하는가?

많은 BTS(Bug Tracking System)을 사용해 보았습니다. Redmine 같은 경우에는 개인적으로 서버도 구축해서 개인 블로그 같이 사용을 해보려 하기도 했습니다. 장단점을 걷어내고 결론을 내린 것은 'Jira만 한 도구가 없다.'입니다.

Jira의 장점

1. 확장성이 좋습니다.

- 내가 생각하고, 구현하고자 하는 기능들이 Plug-in으로 설치가 가능합니다.

- ADMIN 내에서 마켓플레이스 접근이 가능합니다.

2. 시스템이 논리적으로 구성되어 있습니다.

- 어드민을 사용해보면 알겠지만 무엇 하나 그냥 삭제되지 않고, 기능 사이의 부모관계가 명확하게 구성되어 있습니다.

- 과하다 싶을 정도로 논리적으로 구성되어 불편하다고 생각할 수도 있는 부분입니다.

3. UI가 심플합니다.

- 새로 개발되는 프로젝트 관리 도구들이 UI를 따라 할 정도로 기능의 위치나 구성이 잘 되어 있습니다.

ADMIN에서 확인 가능한 Plug-in 마켓플레이스

Jira의 단점

1. 확장성은 좋지만 확장을 위해서는 비용이 발생할 수 있습니다.

- 할 수 있다는 의미는 무료 Plug-in을 통해 무언가를 할 수 있지만 지극히 제한적일 것입니다.

2. 논리적인 구성이 불편하게 느껴질 수 있습니다.

3. UX가 불편하다고 느낄 수 있습니다.

- UI가 심플해서 기능이 없다고 할 수 없습니다.

- 기능들이 추가될 때마다 버튼이 늘어나고 컬럼이 추가되지만 이것은 아틀라시안에서 제공하는 UX를 따라가야 하기 때문에 불편하다고 느껴질 수 있습니다.

유무료 Plug-in이 설치된 목록

하지만 단점에서 이야기했듯이 전 "~~ 할 수 있다."라고 단점을 표현하고 있습니다. 도구의 사용은 처음부터 편하기 위해서 사용하는 것이 아닙니다. 긴 시간 동안 도구를 사용하고 있지만 도구를 사용하기 위해서는 익숙해 지기까지의 시간이 필요하다고 생각합니다. 처음에는 불편하고, 어렵게 느끼는 것이 당연합니다. 하지만 익숙해지는 시간이 지나고 나면 이 보다 편한 게 없다고 느껴질 것이고, 무엇보다도 우리는 업무 혹은 일(Work)을 명확하게 수행하기 위해서 도구를 사용하려고 하는 것을 명심해야 합니다.

또한, 저는 내부적으로 Jira 교육을 담당하고 있습니다. 다른 도구들을 교육하려고 할 때는 기능을 찾고 찾아 설명을 하는 상황이 많았으나 Jira의 교육은 심플하게 설명할 수 있었고, 응용하는 방법 등을 교육하는 시간을 더 많이 투자하고 있습니다. 저는 교육하기 쉬운 도구 또한 좋은 도구라 생각하기 때문에 이렇게 Jira 할 수 있는 사람이 되었습니다.

#3 Jira를 잘 사용하려면 무엇을 준비해야 하는가?

Jira를 잘 사용하려면 철저하게 준비해야 하는 사항들은 3가지 정도가 필요합니다. 도구를 도입하고 사용한다는 것은 비용과 직결되는 문제이기 때문에 섣불리 접근하기 어려운 부분이기도 합니다. 물론 무료 도구도 잘 사용하면 좋습니다. 하지만 사용에 대한 제약, 확장성 그리고 어려움이나 난관에 빠지면 지원이 안되기 때문에 그 시간을 전문가로부터 도움받아 빠르게 해결하고, 업무에 집중할 수 있는 투자라 생각하면 좋습니다.

1. 도구 사용의 목적을 명확히 해야 합니다.

- 이슈 관리용인지?

- 프로젝트 관리용인지?

- ITSM으로 활용하기 위함인지?

- 형상 관리용인지?

- CI/CD를 하기 위함인지? 등...

아틀라시안에서 권장하는 시스템 구성도

2. 사용 목적에 따라 시스템 구성을 명확히 해야 합니다.

- 사내 Jira 전문가(Admin 관리자)가 없다면 컨설팅을 받아보길 추천드립니다.

- 이슈 유형 / 작업 흐름(Work Flow) / 화면 구성 / 사용자 권한 관리 등 구성에 대한 지식이 필요합니다.

3. 몇 명이 사용할 것인지 혹은 누가 사용할지를 알아야 합니다.

- Jira는 유저 라이선스로 비용이 발생하는 도구입니다.

- 현재(2022.03)는 Cloud와 Data Center 버전만 판매되고 있습니다.(2021.02 Server 판매 종료)

앞으로 글을 읽어주시는 모든 분들이 쉽고 재미있게 Jira 할 수 있도록 연재를 해보려 합니다. 기초적인 정보부터 활용하고 응용할 수 있는 정보를 담아보려 하니 Jira 전문가 혹은 이제 사용을 준비하시는 분들께 조금이나마 도움이 되시길 바랍니다.

[실전 비대면 전략] 면접 합격을 위한 준비물과 끝나기 전 마지막에 임팩트 남기는 방법!!

품생품사(品生品死) — Mon, 27 Sep 2021 23:57:24 +0900

비대면 면접 시 준비물과 마지막 한마디 팁

최근 COVID-19로 인해 비대면 면접으로 진행이 되고 있습니다. 우선, 이 글을 보시고 검색하셨다면 서류에 합격하셨을 거라 믿고 먼저 축하를 드립니다. COVID-19가 시작되고, 저도 많지는 않지만 간간히 면접을 보았는데요.

제목과 같이 비대면으로 진행하는 경우가 있었습니다. 오늘은 비대면을 하기 위해 준비해야 할 것 그리고 마지막으로 하고 싶은 말이 있으면 해 보라는 면접관의 질문에 대한 대답. 개인적으로는 베스트 대답이라 생각되는 그 대답을 알려 드리도록 하겠습니다.

화상 면접과 대면 면접? 어렵긴 마찬가지

면접의 대한 준비물과 내용은 개인적인 의견이니 면접 시 참고만 하시기 바랍니다.

정답은 아닙니다. 꼭 명심! 면접에 정답은 없습니다.

비대면 면접 준비물

비대면 면접을 위해서는 준비를 철저히 해야 합니다. 장비만을 얘기하는 것은 아니고, 마음의 자세도 중요합니다. 대면 면접과는 달리 면접관은 얼굴의 표정과 대답만으로 판단해야 하기 때문에 사실 수검자보다도 면접관의 입장이 판단을 하기에는 매우 어려운 방법이라고 할 수 있습니다. 거꾸로 생각하면 수검자의 입장에서 조금만 잘 준비한다면 좋은 결과를 낼 수 있다는 말이 될 수 있습니다.

[준비물]

1. 장비 : 모니터, 캠, 마이크, 조명

블로그를 좀 둘러보셨으면 아실지 모르겠지만 유튜브를 해보려고 준비를 했었습니다. 그래서 캠, 모니터, 마이크를 기본적으로 세팅했었고, 오래된 스탠드를 바꾸면서 조도가 좋은 와이드 스탠드를 구매해서 완벽하지는 않지만 그래도 방송할 수 있는 환경을 세팅하였습니다.
이렇게 장비적인 모든 것을 준비하라는 것은 아닙니다. 앞으로 내가 구직 활동에 있어서 꼭 필요한 것이라면 준비를 해두면 좋다는 정도입니다.
조명빨로 이미지가 좋아 보일 수도 있지 않을까라는 생각도 하게 됩니다.
노트북이라면 최대한 눈높이가 맞도록 세팅하고, 모바일 기기도 최대한 눈높이에 맞춰서 세팅을 해야 합니다.
이어폰을 이용하기보다는 마이크와 스피커를 이용하시길 바랍니다.

2. 평소 카메라와 친해지자.

전 2주에 한 번씩 화상 스터디를 진행하고 있습니다. 팀 블로그에 참여하여 공부한 내용을 글로 작성하고 있습니다. 그러면서 자연스럽게 화상이 친해지기 시작한 것 같습니다.
회사에서 재택 시 화상회의를 가끔 진행해 봅니다.
카메라를 켜고 혼자 주저리도 해봅니다.
전 유튜브 영상을 만들어 보겠다고, 일주일 내내 카메라에서 이 각도 저 각도로 제 얼굴이 자연스러운 각도에 캠을 위치하였습니다.
처음 화상 면접을 진행할 때는 대면 면접보다 긴장되어 자기소개도 못할 만큼 어려웠었습니다.
카메라와 친해진 이후에는 긴장 1도 하지 않고, 면접을 볼 수 있었습니다.

3. 비대면도 정장을 입자.

비대면이라고 편한 옷을 입고 면접에 임하는 것보다 풀 정장으로 화상 면접을 보시길 추천드립니다.
다른 사람은 편한 옷으로 입었을 거라 가정하고, 난 풀 정장(넥타이도 함)으로 면접에 임하십시오.
자세가 된 사람으로 강한 인상을 줄 수 있습니다.

4. 주변 환경을 정리하자.

화상 주변에 불필요한 요소들은 가리거나 정리하시길 바랍니다.
비대면 면접은 온전히 나만 보는 것이 아니고, 카메라 내의 내 주변도 살피고 있다는 것을 인지해야 합니다.
시선이 분산되면 안 되기 때문에 최대한 깔끔하고, 정리된 환경에서 면접에 임하여야 합니다.

5. 카메라에 시선을 맞추자.

이게 굉장히 중요한 요소입니다.

카메라에 시선을 맞추지 않고, 모니터 내에 면접관을 보고 있다면 시선이 아래로 가게 되어 있으며, 눈을 마주치고 얘기하고 있다는 생각이 들지 않습니다.
이점은 저도 비대면 면접 주의 사항에서 본 내용이고, 꼭 카메라를 주시하고 면접에 임하도록 연습이 필요한 부분입니다.
면접관의 반응이 궁금해서 모니터로 시선을 계속 내리게 되면 보통 면접관은 빔으로 위를 보는 상황인데 수검자인 내가 눈을 위아래로 산만하다는 느낌을 줄 수 있습니다.

6. 기타

필수는 아니지만 화상 앱이나 프로그램 사용법을 숙지해 두시기 바랍니다.
회사마다 meet을 사용하거나 Zoom을 사용하거나 기타 여러 화상 시스템을 활용하고 있기 때문에 꼭 사용법이나 세팅 방법 등을 익히고 있어야 원활한 면접을 진행할 수 있습니다.

마지막으로 하고 싶은 말이나 질문이 있나요?

아주 간단하게 결론만 말씀드리겠습니다.

면접관: 마지막으로 하고 싶은 말이나 질문이 있으면 하세요.
수검자: 질문을 너무 잘해주셔서 제가 하고 싶은 말은 모두 말씀드린 것 같습니다. 다음에는 비대면이 아닌 직접 찾아뵙고 인사드릴 수 있는 기회를 주셨으면 좋겠습니다. 면접의 기회를 주셔서 정말 감사합니다.

짧은 한마디가 면접관에게는 감동과 여운, 그리고 간절함을 보여줄 수 있는 대답이라 생각됩니다.

꼭 입사하고 싶은 회사라면, 그리고 면접을 어느 정도 대답도 잘하고, 70% 이상 성공한 면접이라 생각이 된다면 마지막에 꼭 위와 같이 대답해 보시길 바랍니다.

면접 준비 잘 하시고, 좋은 결과 있으시길 바랍니다.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[실전 취업/이직 준비] 서류 심사에 합격할 수 밖에 없는 경력 기술서 작성하는 방법!!

품생품사(品生品死) — Wed, 15 Sep 2021 00:30:54 +0900

경력 기술서 잘 작성하는 방법은?

신입이라면 사실 경력이라고 할게 별로 없습니다. 신입은 가장 중요한 게 이 전 글에도 말씀드렸듯이 포부가 가장 중요합니다. 포부는 자기소개서에 작성해야겠죠. 그래서 신입은 자기소개서가 정말 중요합니다.

이직은 항상 진심된 마음으로 임해야 한다

중고 신입이라면 경력 기술서를 꼭 써야 합니다.

최근 기업 채용 트렌드를 보면 중고 신입 즉, 중소기업 1~3년 경력을 버리고 대기업 신입 지원하는 케이스를 가장 선호하는 타입이기는 합니다. 이때는 당연히 기존에 어떤 일을 했는지 경력기술서를 쓰는 게 좋은데요. 사실 경력 사항을 상세히 적는 것도 좋지만 면접관의 입장에서는 경력 연차와 연봉 정도만 보게 되는 게 사실입니다. 그래서 오늘은 어떻게 경력 기술서를 써야 면접관도 덜 피곤하고, 구직자도 편하게 쓸 수 있는 경력 기술서에 대해서 알려 드리도록 하겠습니다.

10여 년 간의 많은 입사 지원과 이직을 통해 얻은 경험이고, 객관적인 정답은 아니니 참고로만 봐주시길 바랍니다.

이력서든 경력 기술서든 자신을 제일 잘 표현할 수 있는 방법을 찾는 게 정답이기 때문입니다.

#1 5년차 때 작성했던 경력 기술서

4번의 이직을 하게 되었고, 5번째 이직을 준비할 때 썼던 경력 기술서입니다. 이때는 그냥 내가 했던 일을 모두 다 써야 좋은 줄만 알았던 시절이었습니다. 워스트 케이스니 상세히 보실 필요는 없습니다.

이렇게 쓰면 안 된다고 보여드리는 겁니다.

경력 기술서(1)
경력	직장명	부서	직위	기간	담당 업무	이직 사유
경력	OOO	Product Quality	선임	2015-01-12 ~ 재직중	Test Engineer	OOO
내용기술	2015년 1월 ~ 현재까지 1.EES : PCS군의 eDCP 제품을 담당(SECS, EDA, Y-TAP), EES는 반도체 공정을 모니터링 할 수 있는 솔루션 제품 (1) 프로젝트 활동: 테스트 계획 수립, 인시던트 관리(JIRA), Back-end ~ Front-end까지 테스트 환경 구축(Server, Client, DB Patch) (2) 테스트 활동: 애자일(JIRA 프로세스)을 이용한 테스트 진행(Alpha, Beta, RC, RTM), Jephyr를 이용한 TestCase 수정 및 작성, Test Cycle 수립, 탐색 기반 테스트, 성능 테스트, Onsite 테스트(Beta Version을 가지고 현지 방문하여 Set-up 후 테스트진행(일본 Toshiba 방문), 테스트 결과 보고서 작성, (3) 테스트 환경: Server – Linux, Client – Win7, Build 자동화 Jenkins 관리, MSG 통신(Socket, ActiveMQ, TIBrv) (4) 사용 툴: xShell(Linux 운영용), Baretail(Log 확인용), Toad(DB Oracle), MS-Office2010, JIRA, Slack(업무용 메신저), PIMS(회사 내부 Quality Board), MSG Sender(자체 개발) EES는 eDCP, eFDC, eSPC, eMPA, eRMS, eR2R 패키지 제품으로 eDCP는 Data Collection Plan의 약자로서 eFDC, eSPC, eMPA, eRMS, eR2R 제품에서 필요한 data를 수집하기 위한 Plan을 작성하는 제품입니다. 모든 제품의 Base가 되는 제품으로 Workflow 및 기능에 대한 사용이 매우 복잡한 제품으로 내부적으로는 가장 어려운 제품으로 인정받고 있습니다. Back-end ~ Front-end까지 테스트 환경을 구성하였고, 테스트 진행 시에는 Log 분석 및 DB 정보 확인 통해 Issue를 등록하고, 관리하였습니다.

경력 기술서(2)
경력	직장명	부서	직위	기간	담당 업무	이직 사유
경력	OOO	품질관리팀	대리	2013-03-25 ~ 2014-06-28	QA	OOO
내용기술	2013년 3월 ~ 2014년 6월 1. PubTreeEditor : HTML5 기반의 Epub3.0 표준을 준수한 전자책 저작 도구 (1) 프로젝트 활동 : 테스트 계획 수립, 인시던트 관리(CodeWorks), 공식적 리뷰 리드, 프로세스 관리, Checklist 작성, TestCase 작성, Version 관리, 사용자 이슈 관리 (2) 테스트 활동 : 리그레션 테스트, 단위 기능 테스트, 확인 테스트, 경험 기반 테스트, 비기능 테스트, 유지보수 테스트, 시리얼 연동 테스트, 벤치 마킹 테스트, 표준 준수 여부 확인 테스트, Checklist 테스트 2. PubTreeViewer : Windows/Android/iOS를 지원하는 전자책 뷰어 (1) 프로젝트 활동 : 테스트 계획 수립, 인시던트 관리(CodeWorks), 공식적 리뷰 리드, 프로세스 관리, Checklist 작성, TestCase 작성, Version 관리, 사용자 이슈 관리 (2) 테스트 활동 : Windows/Android/iOS 성능 테스트, 표준 준수 여부 확인 테스트, 리그레션 테스트, 확인 테스트, 경험 기반 테스트, 유지보수 테스트 3. WebTree : 클라우드 기반 스마트 웹 콘텐츠 플랫폼 (1) 프로젝트 활동 : 테스트 가이드, 인시던트 관리(Mantis) (2) 테스트 활동 : 경험 기반 테스트, 리그레션 테스트, 확인 테스트 4. CrossPub : 일본 SoftBank에 출시하는 PubTreeEditor의 웹 버전 (1) 프로젝트 활동 : 인시던트 관리(CodeWorks) (2) 테스트 활동 : Checklist 테스트, 리그레션 테스트, 확인 테스트 5. CrossEditor : 웹 접근성 및 웹 표준을 준수한 웹사이트 콘텐츠 저작 도구 (1) 프로젝트 활동 : 테스트 가이드 (2) 테스트 활동 : 경험 기반 테스트, 단위 기능 테스트, 확인 테스트 PubTreeEditor는 다국어 버전을 지원하여 국문, 영문, 일문, 중문 4개국어 버전과 기업용, 가정용으로 구분하여 개발되었고, ESD 버전과 Patch 버전, Package 버전으로 나뉘어 버전 관리에 어려움이 있었습니다. 솔루션 QA 활동을 함으로써 개발에서부터 제품 출시와 이후 유지보수까지 전반적인 프로세스를 알 수 있었습니다.

지금 봐도 너무 빽빽하게 많은 내용을 작성해서 아무도 보지 않았을 거란 생각이 듭니다. 면접관은 위 내용 중 연차와 이직사유만 대부분 보게 됩니다. 그리고, '이 친구 왜 이렇게 이직을 많이 했을까?'라는 의문을 가지게 되겠죠. 전 이직을 많이 했지만 면접 때 이직을 왜 이렇게 많이 했냐고 면접관이 물어보면 '어쩔 수 없는 이직이 있었고, 많은 이직은 다양한 경험을 쌓을 수 있었다'라고 얘기하곤 합니다.

좋게 보는 분들도 있고, 이직이 많으면 좀 힘들면 이 친구 나가겠네?라고 생각하시는 분들도 있죠. 케바케이기 때문에 이직이 많다고 해서 입사 지원을 망설이지는 마세요. 그리고 위에 경력 기술서는 안 좋은 케이스로 보여 드린 거니, 앞으로 작성할 경력 기술서는 아래의 양식을 참고하여 작성하시면 좋을 것 같습니다.

#2 10년차 때 작성한 경력 기술서

이직을 생각했을 때 경력 기술서부터 바꿔보자는 생각에 쓰게 되었습니다.

대기업의 경우 경력 기술도 시스템에 입력할 수 있는 곳이 많기 때문에 정리해두고 복붙을 위해 만들어 두기도 한 건데요.

용도는 첨부 & 복붙이 되겠죠.

한번 잘 정리해둔 경력 기술서는 앞으로 취업시장을 좀 더 빨리 뛰어들 수 있게 할 거라 생각합니다.

근무기간	직위	담당업무	최종연봉(만원)
근무처	직책	상세	이직사유
2019.01 ~ 재직 중	연구원	1. 부문 출시 상품 품질 관리 2. 상품 및 서비스 프로젝트 QA 일정 관리 3. 기획서 기반 TC 설계 및 작성(테스트 고도화) 4. QA 프로세스 구축 및 개선 5. QA 품질지표 정립(인수 기준) 6. ISO/IEC 20000-1:2018 IT 서비스 관리 인증 TF 참여 7. ITSM 구축 참여(2019.6 ~ 2019.12) 8. 고객 VOC/CS 분석 및 관리 지표 보고 - Tool : Google Sheet/Docs	OOO
OOO	팀원		OOO

2018.01 ~ 2019.01	책임	1. 품질 계획/테스트 계획 작성 2. 품질/테스트 프로세스 구축(애자일) 3. S/W, H/W 신뢰/호환성 테스트 4. 통합(치과/기공소/고객) 솔루션(MeditLink) 메인 QA - Tool : Jira/Confluence, TestComplete, TestLink	OOO
OOO	팀원		OOO

2015.01 ~ 2018.01	책임	1. 테스트 계획 작성 2. Zephyr TC 작성 및 테스트 사이클 구축 및 수행 3. DB log 분석 및 데이터정합성 테스트 4. 테스트 환경 구축(Window, Linux, DB) 5. 테스트 프로세스 정립 : On-Site 테스트(일본 도시바 3주) - Tool : Jira/Confluence/Zephyr, Toad/SQL Dev, Baretail, Linux	OOO
OOO	팀원		OOO

2013.03 ~ 2014.06	대리	1. 테스트 계획 및 품질관리 계획 작성 2. TC 설계 및 작성 3. 이슈 관리 및 보고서 작성 4. 테스트 자동화 관리 - Tool : Mentis, CodeWorks, eggPlant	OOO
OOO	팀원		OOO

위와 같은 방식으로 불필요한 정보는 삭제하고, 무엇을 하였는지와 어떤 스킬을 가지고 있는지만 작성하였습니다. 깔끔하면서도 한눈에 들어오는 좋은 경력 기술서라 생각됩니다. 이렇게 작성하게 되면 내가 어떤 일을 했었는지도 면접관이 보게 되는 건데요. 기존에 연차와 연봉, 이직사유만 보던 것과는 확실하게 차이가 난다고 생각됩니다.

최종적으로 경력 기술서를 첨부하는 공간이 있다면. pdf 파일로 만들어서 한 장으로 제출했었습니다. 세트로는 인포그래픽 이력서 / 자기소개서 / 경력 기술서를 한 pdf 파일로 제출을 했었습니다. 자기소개서는 현재 카테고리에 다양하게 등록을 해두었으니 아래의 링크를 참고해 보시길 바랍니다.

[실전 이력서 링크]

[실전 이력서 예시] 'LG CNS' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : LG CNS자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.분석 후 결론부터 작성하고, 설명을 풀어나가는 방식으로 작성하는 것이 중요합니다.LG CNS 자기소

qa-testing.tistory.com

[실전 이력서 예시] '한국재정정보원' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 기획재정부 산하 기관 - 한국재정정보원이력서의 자기소개서는 전략입니다.자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.분석 후 결론부터 작성하

qa-testing.tistory.com

[실전 이력서 예시] '현대 오토 에버' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 현대 오토 에버이력서의 자기소개서는 전략입니다.자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.분석 후 결론부터 작성하고, 설명을 풀어나가는 방

qa-testing.tistory.com

[실전 이력서 예시] 'Kt NexR' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : KT그룹 - Kt NexR이력서의 자기소개서는 전략입니다.자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.분석 후 결론부터 작성하고, 설명을 풀어나가는 방

qa-testing.tistory.com

[실전 이력서 예시] '한화 시스템' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 한화 그룹 - 한화 시스템이력서의 자기소개서는 전략입니다.자기소개서에서 기업이 원하는 점이 무엇인지 분석하세요.분석 후 결론부터 작성하고, 설명을 풀어

qa-testing.tistory.com

[실전 이직/취업 준비] 채용 사이트(사람인, 잡코리아, 원티드 등)에 작성된 자소서 공유!!

기본 자소서 작성하기이력서의 자기소개서는 전략입니다.신입 시절 사람인과 잡코리아를 통해 자기소개서 질문과 제가 작성했었던 답변 공유드립니다.한번 작성하고, 같은 맥락으로 입사 지

qa-testing.tistory.com

[실전 이력서 예시] '메디트(Medit)' 서류 지원 결과와 작성했던 이력서 공유!!

qa-testing.tistory.com

[실전 이력서 예시] 게임 QA 혹은 테스트 엔지니어에 지원했던 자기소개서 공유!!

qa-testing.tistory.com

[실전 이력서 예시] 'SK 이노베이션' 서류 지원 결과와 작성했던 이력서 공유!!

SK 이노베이션 : 배터리 PI 부서결론부터 말씀드리면 서류 탈락이었습니다. PI(Process Inovation) 영역은 제가 일하는 분야는 아니지만 도전하고 싶은 마음에 넣어봤는데 결과는 서류 탈락이었네요.

qa-testing.tistory.com

[실전 이력서 예시] '아시아나IDT' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 품질관리자(QA) - 아시아나IDT모집요강모집 분야담당 업무자격 요건 품질관리자 (QA)- 대외 SI 프로젝트 품질지원, 위험관리 　- 방법론 표준 제시, 테일러링, 산출

qa-testing.tistory.com

[실전 이력서 예시] '하나금융티아이' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : 운영품질관리 - 하나금융티아이모집요강모집 분야담당 업무자격 요건 및 우대사항운영품질관리✔ 품질관리 프로세스 수립/개선✔ SW 테스트 기획/수행✔ ITO

qa-testing.tistory.com

[실전 이력서 예시] '미래에셋자산운용' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : IT팀 - 미래에셋자산운용모집 요강PositionResponsibiltiesPreferred QualificationsIT 본부IT팀- 운용사 시스템 품질관리- 운용사의 시스템 안정화를 위한 이슈 식별, 테스트, Bu

qa-testing.tistory.com

[실전 이력서 예시] '코오롱베니트' 서류 지원 결과와 작성했던 이력서 공유!!

자기소개서 질문 및 답변 전략 : IT 서비스품질 - 코오롱베니트모집요강모집 분야담당 업무자격 요건 및 우대사항IT 서비스품질- IT서비스 품질 기획- IT품질 지표 운영 및 관리- IT서비스 프로세스

qa-testing.tistory.com

#3 결론

경력 기술서도 자기소개서와 마찬가지로 전략이 필요합니다. 서류심사라는 것 자체가 전략이 필요한 건데요. 특히나 경력직이 이직을 하는 경우에는 경력을 보는 비중이 가장 높기 때문에 최대한 심플하게 정보를 제공하는 것이 중요하다고 생각됩니다.

서류에 불합격하더라도 좋은 도전이었다고 마음에 새길 수 있도록 이력서/자기소개서/경력기술서/포트폴리오를 준비하시길 바랍니다.

PS : 수능 보신 분들 모두 고생하셨습니다. 언젠간 대학을 졸업하기 전 사회에 들어오기를 준비하는 모든 취준생들에게 도움이 되길 바랍니다.

[2021.09.13] 처음 이 글을 쓴지도 1년의 시간이 다 되어 가네요. 제 글이 누군가에게는 도움이 혹은 힘이 되시길 바랍니다. 틈틈이 업데이트하고 있는 살아 있는 글입니다. 현시점에는 COVID-19 조심하시고요. 취업도 중요하고, 이직도 중요하지만 무엇보다도 건강이 최우선입니다. 아프면 세상 모든 것이 무의미해질 수 있습니다. 건강 꼭 챙기세요.

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[실전 이력서 예시] '미래에셋자산운용' 서류 지원 결과와 작성했던 이력서 공유!!

품생품사(品生品死) — Thu, 9 Sep 2021 23:58:43 +0900

자기소개서 질문 및 답변 전략 : IT팀 - 미래에셋자산운용

모집 요강

Position	Responsibilties	Preferred Qualifications
IT 본부 IT팀	<SW QA(Quality assurance, 품질 보증> - 운용사 시스템 품질관리 - 운용사의 시스템 안정화를 위한 이슈 식별, 테스트, Bug Tracking 활동 수행 - 서비스 Workflow를 검토하며, 적합한 피드백을 적시에 제공 및 연관 테스트 활동 수행 - 테스트 자동화 환경 구성 / 품질을 위한 개선사항 제시	- 금융권 유경험자 - 다양한 개발 방법론을 통한 프로세스 개선 경험 - 테스트 커버리지 관리 / 테스트 효율을 위한 개선 경험 - 유관 부서 협업 시 유연한 사고를 기반으로 문제 해결

<경력 직원>

- 최소 2년 이상 경력자 지원 가능

- 경력직 포지션으로 지원하신 경우 인성검사는 실시되지 않습니다.

- 해당 포지션은 저규직 포지션 입니다.

(IT팀) Minimum Qualifications

- SW 테스팅 및 QA 경력 보유 / 설계 기법에 의한 테스트 계획, 설계, 수행 경험

- 테스트 자동화 설계 가능자 / 각종 Test tool 및 CI/CD 환경에서 테스트 수행 경험

- Logic 또는 Log 이슈 추적 / 스크립트(Java, C 등) 언어 가능자

- 새로운 것에 관심이 많고, 집중력과 추진력이 강하고 열린 사고를 가지신 분

항상 지나쳐가던 을지로에서 가장 큰 건물인 미래에셋에서 채용 공고가 있길래 지원해 보았습니다. 사실, JD가 저의 연차와는 좀 안 맞는 것 같지만 워낙의 대기업은 눈 높이가 높기 때문에 지원해봐도 괜찮을 것 같다는 생각이 들었습니다. 가만히 있어서는 기회가 오지 않습니다. 기회가 왔다고 생각되는 순간 움직여야 합니다.

지원은 힘들지만 결과는 금방이다

이력서는 기존에 준비된 내용에서 회사명만 수정하고, 좀 더 어필할 수 있는 부분만 수정하여 1시간 이내에 작성되었습니다. 개인적인 내용과 의견이니 이력서 작성 시 참고만 하시기 바랍니다.

#1 성장 과정(600자 제한)

30살이 되어 막상 사회생활을 시작하고 보니 친구들은 벌써 경력 3~4년 차고, 전 따라갈 수 없을 만큼의 차이를 확실히 알 수 있었습니다. `어떻게 하면 친구들하고 같이 걸을 수 있을까?` 직장을 다니면서도 고민에 고민을 더했습니다. 그리고 내린 결론은 QA에 대해서 심도 있게 공부하고 싶은 생각이 들었고, 전 대학원이라는 공부의 길을 선택하게 되었습니다.정말 쉽지 않은 길이었습니다. 낮에는 업무에 밤에는 수업을 받고, 11시가 넘은 시간에는 리포트를 작성했습니다. 학교에 다닐 때는 4시간 이상 잠을 청한 적이 없었던 거 같습니다.

또한, 학업에 문제가 생길 수 있는 상황이 있었지만 전 포기하지 않고, 학업에 충실했습니다. 저의 이 끈질긴 노력은 졸업식에 빛이 바랬고, 최우수 논문과 최우수 성적을 바탕으로 총장상을 받게 되었습니다. 졸업식 때 부모님이 오셨었는데 고등학교 3학년 때 대학교에 보내지 못한 것에 대해 10여 년간 미안한 마음을 가지고 있으셨지만, 대학원 졸업식 때 무거웠던 마음을 깨끗이 덜어드렸던 날이었습니다. 최근 10년간 제가 한 일 중에 가장 뜻깊고, 뿌듯했던 일을 고르라면 대학원을 선택한 일이라고 대답할 것입니다.

#2 성격의 장단점(600자 제한)

제 성격의 장점은 차분하고 정리를 잘하며 깔끔합니다. 서울에 자취하고 있을 때, 친구들이 놀러 오면 "남자 혼자 사는 집이 왜 이렇게 깨끗하냐?"라는 말을 많이 들었습니다. 성실함을 갖추었으며, 매사 신중을 기합니다. 첫 직장 출퇴근 시간이 5시간 정도 되었습니다. 서울에 자취 하기 전 집이 동두천이고, 사업장 위치가 양재에 있었기 때문에 아침 6시에 출발하면, 8시 40분쯤 도착하였습니다. 하지만 이사하기 전 7개월 동안 지각 한번 하지 않았습니다. 이동하는 시간이 많아 책을 보거나 영어 단어를 외우는 등 시간을 소비하지 않으려 노력하기도 하였습니다.

운동하기를 좋아하고, 활발한 성격에 `안된다`라기 보다는 한번 해보자는 자세로 임합니다. 업무 시간이 끝나면 8시 30분부터 대학원 수업이 시작되어 10시에 끝이 납니다. 수업이 끝나면 바로 귀가하는 것이 아니고 헬스장에 들려 1시간 정도 운동을 하고 귀가를 합니다. 제 성격의 단점은 한 가지 일에 집중하게 되면 주변 상황에 대해서 귀 기울이지 못하는 점이 단점이라고 생각합니다. 제 단점을 너무 잘 알고 있기 때문에 현재는 많이 고쳐져서 주변 상황들도 잘 챙기는 편입니다.

#3 지원동기(600자 제한)

미래에셋자산운용에 지원하게 된 동기는 어플리케이션이나 솔루션과 같이 작은 틀에서 벗어나서 프로젝트의 관점에서 품질 활동을 하고, 지금보다 더 큰 무대에서 꿈을 펼치기 위해 지원하게 되었습니다. 저는 프로젝트의 품질을 조금이나마 이해하기 위해 야간 대학원을 진학하였으며, 정보시스템감리를 통해 프로젝트의 전반적인 관리 활동을 알 수 있었습니다. 또한, 많은 프로젝트 수행을 통해 개발 방법론을 몸으로 익힐 수 있었고, 프로젝트 수행 기간 동안 조직이 인지하지 못하는 리스크를 선 예측하여 공유하는 활동을 통해 큰 문제를 미연 방지하기도 하였습니다.

품질보증 활동을 하지 않는 조직에서는 먼저 인수 기준에 대한 인식을 확고히 하고, 품질 지표를 설정하여 모두가 공감하는 정량적 지표를 정립하였습니다. 테스트가 완료된 시점에는 해당 지표를 달성하였는지 판단하여 보고하고, 추가 조치가 필요한 경우 모니터링 활동을 통해 품질 지표를 높일 수 있는 방안을 모색하고, 제안하기도 하였습니다. 제가 바라보는 미래에셋자산운용은 현재에도 성장하고 있고, 앞으로도 성장할 것을 알고 있기에 저 또한 미래에셋자산운용과 함께 성장하고자 지원하게 되었습니다.

#4 입사 후 희망업무(600자 제한)

회사에서 진행하는 모든 프로젝트의 품질에 기여할 수 있는 시스템 품질관리 업무를 하고 싶습니다.
현재에는 JIRA 시스템 도입을 통해 PI 활동을 주로 하고 있으며, WBS 작성이 완료되는 시점에는 해당 프로젝트를 수행하는 구성원들이 원활히 업무를 수행할 수 있는 Workflow 구축하고, 진척 관리를 할 수 있도록 시스템을 세팅하고 있습니다.

기본적으로 Bug Tracking 및 품질 보고서를 작성하고 있으며, 향후 필요시 테스트 자동화를 할 수 있는 환경을 만들어 테스트 커버리지를 높이고, 품질의 만족도를 높일 수 있는 업무를 하고 싶습니다.

#5 장래 포부(600자 제한)

제가 만약 미래에셋자산운용에 입사하게 된다면 가장 기여할 수 있는 분야는 바로 "품질"입니다. 제 슬로건이자 공식적으로 활동하는 분야의 아이디는 품생품사입니다. 좀 유치하게 보이실 수도 있지만 가장 중요한 순간에 프로젝트 출시 여부를 선택해야 할 때 딱 한 가지만 생각하면 너무 쉬운 결론이 나오는 것을 알게 되어 품생품사의 아이디를 사용하게 되었습니다. 출시 여부를 선택해야 할 때 "품질"만 생각하면 결론은 항상 명확했습니다. 만약, 메이저한 잔여 이슈로 인해 출시를 고민한다면 품질에 어떠한 영향이 있을지만 생각하면 되기 때문입니다. 개발 난이도와 일정, 비용 등을 고민하고 있다면 이미 잘못된 판단이라 생각합니다. 출시되었을 때 사용자의 입장에서 품질적으로 느끼는 불쾌감이나 만족도가 낮을 것이라 판단되면 앞서 얘기한 일정과 비용은 무조건 사용해야 하는 부분이기 때문입니다.

프로젝트의 품질뿐만 아니라 제가 자신 있는 부분은 바로 조직 간의 유기적인 협업을 통한 품질입니다. 프로세스 품질 또한 프로젝트가 진행됨에 있어 정말 중요한 부분으로 최적화된 프로세스와 커뮤니케이션이 이뤄질 수 있도록 환경을 만드는 것입니다.

#6 역량기술서(9999자 제한)

[품질 관리 프로세스 구축 경험]
최근 교원 크리에이티브에서 상품 약 150개, 앱/웹은 빌드 기준 약 250개에 대해서 품질 관리를 수행하고 있습니다. (구성원: 저 포함 5명)
처음 입사 시 프로세스 및 품질 관리를 위한 시스템 등 아무것도 없는 상태였습니다. 당시 QA는 저와 기존에 QA 업무를 하던 인원 1명뿐이었습니다. 그래서 프로세스의 필요성을 먼저 알렸고, 보고를 통해 공신력을 얻은 후 프로세스 구축에 대한 수행을 시작하였습니다.

1) 품질 인식에 대한 변화를 먼저 공유하고, 배포하였습니다. 아무리 좋은 프로세스와 시스템이 있을지라도 인식의 변화가 없으면 무용지물이 될 수 있다는 것을 너무 잘 알고 있습니다.
2) 환경 분석(구성원들이 가장 잘 사용하고, 활용도 높은 도구)을 통해 구글 시트의 활용도가 높다는 것을 알게 되어 품질관리에 필요한 모수(테스트 케이스)를 화면설계서 및 요구사항 명세를 통해 작성하여 확보하였고, 테스트 케이스 수행을 통해 엑셀 자동 계산을 매트릭으로 만들어 정량적으로 품질을 확인할 수 있도록 하고, 추가로 최소한의 입력으로 리포트가 가능하도록 하였습니다.
3) 메일을 통해 테스트 계획/요청/수행/결과에 대해 공유하도록 하였습니다.
4) 파일럿으로 프로젝트를 수행하는 팀부터 점차 프로세스가 자연스럽게 퍼지도록 하였습니다.
5) 보고서를 통해 기존과 현재를 비교하여 SW 품질이 얼마나 좋아졌는지 확인 시켜 드리고, 기안 승인을 통해 프로세스를 정립하였습니다.

[품질 관리 프로세스 개선 업무 수행]

2020년 11월 JIRA 시스템이 도입되어 현재 수행 중인 품질관리 프로세스를 JIRA 시스템에 적용하는 활동을 수행하였습니다.
1) 요건 분석을 통해 Jira 시스템에 필요한 항목들을 매트릭 및 마인드맵으로 작성하였습니다.
- 기존 프로세스를 적용하되 불필요했던 요건들을 정리하고, 최소한으로 가장 효율적인 프로세스를 만들기 위해 프로세스를 구축하였습니다.
2) Jira 시스템에 이슈 유형을 정립하고, 유형에 따른 워크플로우(프로세스)를 구축하였으며, Jira 등록 시 화면 구성도 하였습니다.
- Jira 시스템은 약 5년 정도 활용해본 경험이 있었고, 밴더 사는 시스템 설치만 해주었습니다.
- 이후 모든 설정 및 프로세스 설계 및 구축을 수행하였습니다.
3) 구축된 프로세스에 대해서 10차례 이상 관련자들에게 교육을 통해 최대한 시스템을 활용할 수 있도록 하였습니다.
4) 시스템 사용에 어려움이나 프로세스 내에서 불편한 점을 수렴하여 개선하여 반영하였습니다.

[추가적으로 정립한 프로세스]

1) 앱의 배포 관리를 QA가 해야 한다는 것에 대해서 인식의 변화를 정립하고, 보고를 통해 단일 채널에서 배포를 수행할 수 있도록 하였습니다.
- 기존에는 개발팀 내에서 무분별하게 배포하고, 배포되었는지도 알 수 없는 상황들이 발생했습니다.
- 단일 채널 배포를 통해 통제하고, 모니터링하게 되었으며, 나아가 배포에 대한 통계 자료도 정리할 수 있었습니다.
2) VOC 관리 프로세스를 정립하였습니다.
- 기존 VOC는 ITSM(SR) 시스템을 통해 접수하고, 바로 개발팀에 이관하였습니다.
- 현재는 접수된 SR을 Jira 이슈를 생성하여 VOC로 구분하여 처리하고 있습니다.
- VOC의 프로세스는 서버 데이터 변경/코멘트 처리/개발 처리 3가지 플로우로 구성하여 모니터링이 가능하게 구축하였으며, 월간/분기 별 리포트가 가능하도록 구축하였습니다.

[품질 관리 프로세스와 품질 관리 시스템의 연계성]
품질 관리 시스템을 통해 프로세스를 정립하고, 구축하는 것은 품질 경영을 위해 매우 중요한 요소라 생각합니다.
제가 가장 잘 사용할 수 있는 시스템 도구는 JIRA 시스템이고, JIRA의 전반적인 베이스 지식을 습득하고 있기 때문에 시스템을 사용하지 않더라도
필요시 구글 시트를 통해서도 품질 관리 프로세스를 구축할 수 있는 역량을 가지고 있습니다.

[품질 관리 프로세스 외 구축 사례 - 테스트 자동화]
1) 도메인에 가장 적합한 테스트 자동화 솔루션이 무엇인지 벤치마킹 조사를 수행했습니다.
2) 보고를 통해 테스트 자동화 솔루션을 선택하고, 컨설팅 업체와 미팅을 통해 장단점 매트릭스를 작성하였습니다.
3) 테스트 자동화 솔루션 구매 후 테스트 자동화 범위 및 시나리오 설계하고, 작성하였습니다.
4) 테스트 자동화 솔루션을 이용해 스크립트를 작성하고, 테스트 자동화를 구축하였습니다.
5) 기존 테스트 프로세스에 테스트 자동화를 추가하여 품질 관리 프로세스를 더 견고히 하였습니다.
6) 전사 발표를 통해 효과를 증명하고, 품질을 높이는데 기여하였습니다.

[마지막 하고 싶은 말]
만약, 미래에셋자산운용에 입사하게 된다면 최선의 노력을 다하겠습니다.
또한, 회사의 보탬이 되는 인재가 될 것을 약속드리고, 결실을 보여드리도록 하겠습니다.

서류 불합격

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

prohibition-of-unauthorized-email-collection

품생품사(品生品死) — Tue, 24 Aug 2021 00:07:45 +0900

이메일 무단수집거부

본 웹사이트(이하 "웹사이트") 게시된 이메일 주소가 전자 우편 수집 프로그램이나 그밖의 기술적 장치를 이용하여 무단으로 수집되는 것을 거부하며, 이를 위반시 정보통신망법에 의해 형사처벌됨을 유념하시기 바랍니다.

정보통신망이용촉진 및 정보보호등에 관한 법률 [시행 2020. 12. 10.] [법률 제17358호, 2020. 6. 9., 일부개정]

제50조(영리목적의 광고성 정보 전송 제한)

⑤ 전자적 전송매체를 이용하여 영리목적의 광고성 정보를 전송하는 자는 다음 각 호의 어느 하나에 해당하는 조치를 하여서는 아니 된다.

1. 광고성 정보 수신자의 수신거부 또는 수신동의의 철회를 회피ㆍ방해하는 조치

2. 숫자ㆍ부호 또는 문자를 조합하여 전화번호ㆍ전자우편주소 등 수신자의 연락처를 자동으로 만들어 내는 조치

3. 영리목적의 광고성 정보를 전송할 목적으로 전화번호 또는 전자우편주소를 자동으로 등록하는 조치

4. 광고성 정보 전송자의 신원이나 광고 전송 출처를 감추기 위한 각종 조치

5. 영리목적의 광고성 정보를 전송할 목적으로 수신자를 기망하여 회신을 유도하는 각종 조치

제74조 (벌칙)

① 다음 각 호의 어느 하나에 해당하는 자는 1년 이하의 징역 또는 1천만원 이하의 벌금에 처한다. <개정 2012. 2. 17., 2014. 5. 28.>2. 제44조의7 제1항 제1호를 위반하여 음란한 부호ㆍ문언ㆍ음향ㆍ화상 또는 영상을 배포ㆍ판매ㆍ임대하거나 공공연하게 전시한 자4. 제50조 제5항을 위반하여 조치를 한 자6. 제50조의8을 위반하여 광고성 정보를 전송한 자② 제1항제3호의 죄는 피해자가 구체적으로 밝힌 의사에 반하여 공소를 제기할 수 없다.
[전문개정 2008. 6. 13.]
7. 제53조 제4항을 위반하여 등록사항의 변경등록 또는 사업의 양도ㆍ양수 또는 합병ㆍ상속의 신고를 하지 아니한 자
5. 삭제 <2014. 5. 28.>
3. 제44조의7 제1항 제3호를 위반하여 공포심이나 불안감을 유발하는 부호ㆍ문언ㆍ음향ㆍ화상 또는 영상을 반복적으로 상대방에게 도달하게 한 자
1. 제8조 제4항을 위반하여 비슷한 표시를 한 제품을 표시ㆍ판매 또는 판매할 목적으로 진열한 자

[공지사항 2023 개정] Legal(책임의 한계와 법적고지)

품생품사(品生品死) — Tue, 24 Aug 2021 00:02:16 +0900

책임의 한계와 법적고지

본 블로그는 링크, 다운로드, 광고 등을 포함하여 본 블로그에 포함되어 있거나, 본 블로그를 통해 배포, 전송되거나, 본 블로그에 포함되어 있는 서비스로부터 접근되는 정보(이하 "자료")의정확성이나 신괴성에 대해 이떠한 보증도 하지 않으며, 서비스상의, 또는 서비스와 관련된 광고, 기타 정보 또는 제안의 결과로 구매 또는 취득하게 되는 제품 또는 기타 정보(이하 "제품")의 질에 대해서도 어떠한 보증도 하지 않습니다.

귀하는, 자료에 대한 신뢰 여부가 전적으로 귀하의 책임임을 인정합니다. 본 블로그는 자료 및 서비스의 내용을 수정할 의무를 지지 않으나, 필요에 따라 개선할 수는 있습니다. 본 블로그는 자료와 서비스를 최대한 설실히 제공하려 노력합니다.

어떤한 경우에도 본 블로그는 서비스, 자료 및 제품과 관련하여 직접, 간접, 부수적, 징벌적, 파생적인 소행에 대해서 책임을 지지 않습니다. 본 블로그는 본 블로그를 통하여 인터넷을 접속함에 있어 사용자의 개인적인 판단에 따라 하시기를 바라며, 본 블로그는 자료에 열거되어 있는 사이트상의 자료의 정확성, 저작권 준수, 적법성 또는 도덕성에 대해 아무런 책임을 지지 않습니다.

[공지사항 2023 기준] privacy policy(개인정보처리방침)

품생품사(品生品死) — Mon, 23 Aug 2021 23:49:54 +0900

Privacy policy(개인정보처리방침)

< 품생품사 >('https://qa-testing.tistory.com/'이하 '품생품사(品生品死)')은(는) 「개인정보 보호법」 제30조에 따라 정보주체의 개인정보를 보호하고 이와 관련한 고충을 신속하고 원활하게 처리할 수 있도록 하기 위하여 다음과 같이 개인정보 처리방침을 수립·공개합니다.

○ 이 개인정보처리방침은 2021년 1월 1부터 적용됩니다.

제1조(개인정보의 처리 목적)

< 품생품사 >('https://qa-testing.tistory.com/'이하 '품생품사(品生品死)')은(는) 다음의 목적을 위하여 개인정보를 처리합니다. 처리하고 있는 개인정보는 다음의 목적 이외의 용도로는 이용되지 않으며 이용 목적이 변경되는 경우에는 「개인정보 보호법」 제18조에 따라 별도의 동의를 받는 등 필요한 조치를 이행할 예정입니다.

제2조(개인정보의 처리 및 보유 기간)

① < 품생품사 >은(는) 법령에 따른 개인정보 보유·이용기간 또는 정보주체로부터 개인정보를 수집 시에 동의받은 개인정보 보유·이용기간 내에서 개인정보를 처리·보유합니다.

② 각각의 개인정보 처리 및 보유 기간은 다음과 같습니다.

1.<재화 또는 서비스 제공>
<재화 또는 서비스 제공>와 관련한 개인정보는 수집.이용에 관한 동의일로부터<지체없이 파기>까지 위 이용목적을 위하여 보유.이용됩니다.
보유근거 : 파기
관련법령 : 표시/광고에 관한 기록 : 6개월
예외사유 :

제3조(개인정보의 제3자 제공)

① < 품생품사 >은(는) 개인정보를 제1조(개인정보의 처리 목적)에서 명시한 범위 내에서만 처리하며, 정보주체의 동의, 법률의 특별한 규정 등 「개인정보 보호법」 제17조 및 제18조에 해당하는 경우에만 개인정보를 제3자에게 제공합니다.

② < 품생품사 >은(는) 다음과 같이 개인정보를 제3자에게 제공하고 있습니다.

1. < >
개인정보를 제공받는 자 :
제공받는 자의 개인정보 이용목적 :
제공받는 자의 보유.이용기간:

제4조(개인정보처리 위탁)

① < 품생품사 >은(는) 원활한 개인정보 업무처리를 위하여 다음과 같이 개인정보 처리업무를 위탁하고 있습니다.

1. < >
위탁받는 자 (수탁자) :
위탁하는 업무의 내용 :
위탁기간 :

② < 품생품사 >은(는) 위탁계약 체결시 「개인정보 보호법」 제26조에 따라 위탁업무 수행목적 외 개인정보 처리금지, 기술적․관리적 보호조치, 재위탁 제한, 수탁자에 대한 관리․감독, 손해배상 등 책임에 관한 사항을 계약서 등 문서에 명시하고, 수탁자가 개인정보를 안전하게 처리하는지를 감독하고 있습니다.

③ 위탁업무의 내용이나 수탁자가 변경될 경우에는 지체없이 본 개인정보 처리방침을 통하여 공개하도록 하겠습니다.

제5조(정보주체와 법정대리인의 권리·의무 및 그 행사방법)

① 정보주체는 품생품사에 대해 언제든지 개인정보 열람·정정·삭제·처리정지 요구 등의 권리를 행사할 수 있습니다.

② 제1항에 따른 권리 행사는품생품사에 대해 「개인정보 보호법」 시행령 제41조제1항에 따라 서면, 전자우편, 모사전송(FAX) 등을 통하여 하실 수 있으며 품생품사은(는) 이에 대해 지체 없이 조치하겠습니다.

③ 제1항에 따른 권리 행사는 정보주체의 법정대리인이나 위임을 받은 자 등 대리인을 통하여 하실 수 있습니다.이 경우 “개인정보 처리 방법에 관한 고시(제2020-7호)” 별지 제11호 서식에 따른 위임장을 제출하셔야 합니다.

④ 개인정보 열람 및 처리정지 요구는 「개인정보 보호법」 제35조 제4항, 제37조 제2항에 의하여 정보주체의 권리가 제한 될 수 있습니다.

⑤ 개인정보의 정정 및 삭제 요구는 다른 법령에서 그 개인정보가 수집 대상으로 명시되어 있는 경우에는 그 삭제를 요구할 수 없습니다.

⑥ 품생품사은(는) 정보주체 권리에 따른 열람의 요구, 정정·삭제의 요구, 처리정지의 요구 시 열람 등 요구를 한 자가 본인이거나 정당한 대리인인지를 확인합니다.

제6조(처리하는 개인정보의 항목 작성)

① < 품생품사 >은(는) 다음의 개인정보 항목을 처리하고 있습니다.

1< 재화 또는 서비스 제공 >
필수항목 : 서비스 이용 기록, 접속 로그, 쿠키, 접속 IP 정보
선택항목 :

제7조(개인정보의 파기)

① < 품생품사 > 은(는) 개인정보 보유기간의 경과, 처리목적 달성 등 개인정보가 불필요하게 되었을 때에는 지체없이 해당 개인정보를 파기합니다.

② 정보주체로부터 동의받은 개인정보 보유기간이 경과하거나 처리목적이 달성되었음에도 불구하고 다른 법령에 따라 개인정보를 계속 보존하여야 하는 경우에는, 해당 개인정보를 별도의 데이터베이스(DB)로 옮기거나 보관장소를 달리하여 보존합니다.
1. 법령 근거 :
2. 보존하는 개인정보 항목 : 계좌정보, 거래날짜

③ 개인정보 파기의 절차 및 방법은 다음과 같습니다.
1. 파기절차
< 품생품사 > 은(는) 파기 사유가 발생한 개인정보를 선정하고, < 품생품사 > 의 개인정보 보호책임자의 승인을 받아 개인정보를 파기합니다.

2. 파기방법

전자적 파일 형태의 정보는 기록을 재생할 수 없는 기술적 방법을 사용합니다

제8조(개인정보의 안전성 확보 조치)

< 품생품사 >은(는) 개인정보의 안전성 확보를 위해 다음과 같은 조치를 취하고 있습니다.

1. 개인정보에 대한 접근 제한
개인정보를 처리하는 데이터베이스시스템에 대한 접근권한의 부여,변경,말소를 통하여 개인정보에 대한 접근통제를 위하여 필요한 조치를 하고 있으며 침입차단시스템을 이용하여 외부로부터의 무단 접근을 통제하고 있습니다.

제9조(개인정보 자동 수집 장치의 설치•운영 및 거부에 관한 사항)

① 품생품사 은(는) 이용자에게 개별적인 맞춤서비스를 제공하기 위해 이용정보를 저장하고 수시로 불러오는 ‘쿠키(cookie)’를 사용합니다.
② 쿠키는 웹사이트를 운영하는데 이용되는 서버(http)가 이용자의 컴퓨터 브라우저에게 보내는 소량의 정보이며 이용자들의 PC 컴퓨터내의 하드디스크에 저장되기도 합니다.
가. 쿠키의 사용 목적 : 이용자가 방문한 각 서비스와 웹 사이트들에 대한 방문 및 이용형태, 인기 검색어, 보안접속 여부, 등을 파악하여 이용자에게 최적화된 정보 제공을 위해 사용됩니다.
나. 쿠키의 설치•운영 및 거부 : 웹브라우저 상단의 도구>인터넷 옵션>개인정보 메뉴의 옵션 설정을 통해 쿠키 저장을 거부 할 수 있습니다.
다. 쿠키 저장을 거부할 경우 맞춤형 서비스 이용에 어려움이 발생할 수 있습니다.

제10조 (개인정보 보호책임자)

① 품생품사 은(는) 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

▶ 개인정보 보호책임자
성명 :품생품사
직책 :대표
직급 :사장
연락처 :01012341234, ljm820928@gmail.com,

※ 개인정보 보호 담당부서로 연결됩니다.

▶ 개인정보 보호 담당부서
부서명 :
담당자 :
연락처 :, ,

② 정보주체께서는 품생품사 의 서비스(또는 사업)을 이용하시면서 발생한 모든 개인정보 보호 관련 문의, 불만처리, 피해구제 등에 관한 사항을 개인정보 보호책임자 및 담당부서로 문의하실 수 있습니다. 품생품사 은(는) 정보주체의 문의에 대해 지체 없이 답변 및 처리해드릴 것입니다.

제11조(개인정보 열람청구)
정보주체는 ｢개인정보 보호법｣ 제35조에 따른 개인정보의 열람 청구를 아래의 부서에 할 수 있습니다.
< 품생품사 >은(는) 정보주체의 개인정보 열람청구가 신속하게 처리되도록 노력하겠습니다.

▶ 개인정보 열람청구 접수·처리 부서
부서명 :
담당자 :
연락처 : , ,

제12조(권익침해 구제방법)

정보주체는 개인정보침해로 인한 구제를 받기 위하여 개인정보분쟁조정위원회, 한국인터넷진흥원 개인정보침해신고센터 등에 분쟁해결이나 상담 등을 신청할 수 있습니다. 이 밖에 기타 개인정보침해의 신고, 상담에 대하여는 아래의 기관에 문의하시기 바랍니다.

1. 개인정보분쟁조정위원회 : (국번없이) 1833-6972 (www.kopico.go.kr)
2. 개인정보침해신고센터 : (국번없이) 118 (privacy.kisa.or.kr)
3. 대검찰청 : (국번없이) 1301 (www.spo.go.kr)
4. 경찰청 : (국번없이) 182 (cyberbureau.police.go.kr)

「개인정보보호법」제35조(개인정보의 열람), 제36조(개인정보의 정정·삭제), 제37조(개인정보의 처리정지 등)의 규정에 의한 요구에 대 하여 공공기관의 장이 행한 처분 또는 부작위로 인하여 권리 또는 이익의 침해를 받은 자는 행정심판법이 정하는 바에 따라 행정심판을 청구할 수 있습니다.

※ 행정심판에 대해 자세한 사항은 중앙행정심판위원회(www.simpan.go.kr) 홈페이지를 참고하시기 바랍니다.

제13조(개인정보 처리방침 변경)

① 이 개인정보처리방침은 2021년 1월 1부터 적용됩니다.

② 이전의 개인정보 처리방침은 아래에서 확인하실 수 있습니다.

예시 ) - 20XX. X. X ~ 20XX. X. X 적용 (클릭)

[실전 이력서 예시] '하나금융티아이' 서류 지원 결과와 작성했던 이력서 공유!!

품생품사(品生品死) — Mon, 16 Aug 2021 00:30:13 +0900

자기소개서 질문 및 답변 전략 : 운영품질관리 - 하나금융티아이

모집요강

모집 분야	담당 업무	자격 요건 및 우대사항
운영품질관리	✔ 품질관리 프로세스 수립/개선 ✔ SW 테스트 기획/수행 ✔ ITO 운영 관리	✔ 품질관리 프로세스 수립/개선 경험자 ✔ SW 품질관련 자격증(ISTQB, CSTS 등) 소지자 우대 ✔ 금융권IT 개발 실무 경험자 우대 ✔ 관련 업무 경력 5년 이상 우대
테스트 엔지니어 (QC)	✔ 프로젝트 서비스 검증(동적테스트 수행) ✔ 테스트 설계 가이드 및 테스트 개선 활동	✔ 테스트 계획/수행/결함 관리 경함자 ✔ 관련 자격증 보유자 우대(ISTQB, CSTS 등) 소지자 우대 ✔ 금융권(이커머스, 결제 포함) 경험자 우대 ✔ 관련 업무 경력 3년 이상 우대

지원한 분야는 운영품질관리 분야입니다. 처음 서류를 작성할 때, 특히 자기소개서를 작성할 때는 꼭! 옆에 모집 요강을 켜 두고 작성하시길 바랍니다. 간혹 자기소개서를 작성하는데 모집요강에 없는 불필요한 정보들을 작성하는 경우가 생각보다 많이 있습니다.

면접관이 가장 중요하고, 궁금해하는 사항은 모집요강에 있는 내용이고, 저도 마찬가지지만 모집요강의 모든 내용을 경험하지는 못했습니다. 이때는 자기소개서를 쓰는 순간에도 면접의 질문이 올 때 어떻게 대답해야 하는지 이미지 트레이닝을 하는 것이 좋습니다.

최종 합격하였으나 오퍼가 안맞아서 입사 포기

간략 회사 정보 : 하나금융티아이는 1990년 창립이래 은행, 증권, 카드, 보험 등 금융 전 분야의 다양한 IT 시스템 구축과 운영 노하우를 바탕으로 보다 수준 높은 금융 서비스를 제공하고자 최선을 다해 왔습니다. 스마트 혁명이라는 큰 흐름 속에서, IT는 금융은 물론 모든 산업의 발전과 혁신을 주도하고 있습니다. 이러한 변화의 시기에 하나금융티아이는 2017년 청라 통합 데이터센터 오픈을 기점으로, 하나금융그룹 혁신의 중심이 될 금융 IT 전문 인재를 육성하고, 새로운 미래를 한 발 앞서 준비하며, 글로벌 수준의 IT회사로 도약해 나갈 것입니다.

지주사 정보

주의사항 : 하나금융티아이를 지켜본 결과 고용형태가 매우 특히 합니다. 대리급 이하는 정규직 채용이지만 과장급 이상은 계약직 채용 후 평가에 따라 정규직 전환 심사로 되어 있습니다. 이 부분은 면접 전 협의하던가 혹시나 과장급 이상이지만 정규직 조건이 아니라면 생각을 해봐야 하는 부분입니다.

작성해야 하는 이력서의 양식은 기존 대기업과 비슷한 수준의 포맷이고, 특이사항은 없습니다. 이력서는 기존에 준비된 내용에서 회사명만 수정하고, 좀 더 어필할 수 있는 부분만 수정하여 1시간 이내에 작성되었습니다. 개인적인 내용과 의견이니 이력서 작성 시 참고만 하시기 바랍니다.

경력 및 경력기술서

경력 사항 작성 후 간단하게 경력 기술하는 부분이 있었습니다. 최근 경력부터 간단하게 기술합니다. 500자 제한으로 길게 쓰고 싶어도 쓸 수 없으니 간단하게 쓰시면 됩니다.

[OOO / OOO / QA(품질관리)]
1) 스마트테크 출시 상품 품질 관리
- 에듀 상품 및 서비스, 구몬 상품 및 서비스, E-커머스 플랫폼
2) 구몬/에듀 상품 및 서비스 프로젝트 QA 일정 관리
3.) 기획서 기반 TC 설계 및 작성(테스트 고도화)
4) QA 프로세스 구축 및 개선
5) QA 품질지표 정립(인수 기준)
6) 상품 및 서비스 배포 관리
7) ISO/IEC 20000-1:2018 IT 서비스 관리 인증 TF 참여
8) ITSM 구축 참여(2019.6 ~ 2019.12)
- 인터뷰(요구사항 수집 및 프로세스 분석), ITSM 구축 후 통합 테스트 수행
9) 고객 VOC/CS 분석 및 관리 지표 보고 -사용 도구: Google Sheet/Docs, Jira/Confluence/Zephyr

[OOO / OOO / QA]
1) QA 계획/테스트 계획 작성
2) QA 및 테스트 프로세스 구축
3) S/W, H/W 신뢰/호환성 테스트
4) 통합(치과/기공소/고객) SI솔루션(MeditLink) 품질보증
- WEB(회원관리/장비등록 관리/결제 정보관리), MeditLInk솔루션(치과>기공 주문 관리), 3D Scan 솔루션(구강 3D 스캔 데이터 관리 – H/W 연결)
5) 사용 도구: Jira/Confluence, TestComplete, TestLink

[OOO / OOO / QC]
1) 테스트 계획 작성
2) 테스트 분석/설계서 작성 > 개발자 체크리스트 작성
3) Zephyr TC 작성 및 테스트 사이클 구축 및 수행
4) 테스트 환경 구축 및 수행
- DB 세팅(스크립트 수행), 서버 세팅(.jar 패치 및 .sh 파일 세팅), 웹서비스 세팅(Configuration 파일 세팅), 클라이언트 환경 구축

자기소개서

1. [지원동기] 하나금융티아이에 지원하게 된 구체적인 이유는 무엇이며, 입사 후 목표는 무엇인지 기술해주십시오.
하나금융티아이에 지원하게 된 동기는 애플리케이션이나 솔루션과 같이 작은 틀에서 벗어나서 프로젝트의 관점에서 품질 활동을 하고, 지금보다 더 큰 무대에서 꿈을 펼치기 위해 지원하게 되었습니다. 저는 프로젝트의 품질을 조금이나마 이해하기 위해 야간 대학원을 진학하였으며, 정보시스템감리를 통해 프로젝트의 전반적인 관리 활동을 알 수 있었습니다. 또한, 많은 프로젝트 수행을 통해 개발 방법론을 몸으로 익힐 수 있었고, 프로젝트 수행 기간 동안 조직이 인지하지 못하는 리스크를 선 예측하여 공유하는 활동을 통해 큰 문제를 미연 방지하기도 하였습니다.

품질보증 활동을 하지 않는 조직에서는 먼저 인수 기준에 대한 인식을 확고히 하고, 품질 지표를 설정하여 모두가 공감하는 정량적 지표를 정립하였습니다. 테스트가 완료된 시점에는 해당 지표를 달성하였는지 판단하여 보고하고, 추가 조치가 필요한 경우 모니터링 활동을 통해 품질 지표를 높일 수 있는 방안을 모색하고, 제안하기도 하였습니다.

개발 방법론은 애자일이 트렌드인 것을 오래전부터 인지하여 개인적으로 지식을 습득하였고, 프로젝트 진행에 있어 가장 많이 사용하는 도구인 Jira/Confluence 통해 최적화된 프로세스를 구축하기 위해 노력하였습니다. 또한, PM 및 개발 조직 간의 협업을 통해 최상의 품질로 프로젝트가 성공적으로 출시할 수 있도록 하였습니다. 저는 프로젝트의 품질이 상품 및 서비스의 기능/비기능 측면뿐 아니라 프로세스의 원활함. 그리고 부서 및 조직 간 커뮤니케이션의 중요성을 잘 알고 있습니다.

제가 바라보는 하나금융티아이는 현재에도 성장하고 있고, 앞으로도 성장할 것을 알고 있기에 저 또한 하나금융티아이와 함께 성장하고자 지원하게 되었습니다.

2. [자기소개] 본인에 대해 자유롭게 기술해주시기 바랍니다.
제가 만약 하나금융티아이에 입사하게 된다면 가장 기여할 수 있는 분야는 바로 "품질"입니다.
제 슬로건이자 공식적으로 활동하는 분야의 아이디는 품생품사입니다. 좀 유치하게 보이실 수도 있지만 가장 중요한 순간에 프로젝트 출시 여부를 선택해야 할 때 딱 한 가지만 생각하면 너무 쉬운 결론이 나오는 것을 알게 되어 품생품사의 아이디를 사용하게 되었습니다. 출시 여부를 선택해야 할 때 "품질"만 생각하면 결론은 항상 명확했습니다. 만약, 메이저 한 잔여 이슈로 인해 출시를 고민한다면 품질에 어떠한 영향이 있을지만 생각하면 되기 때문입니다. 개발 난이도와 일정, 비용 등을 고민하고 있다면 이미 잘못된 판단이라 생각합니다. 출시되었을 때 사용자의 입장에서 품질적으로 느끼는 불쾌감이나 만족도가 낮을 것이라 판단되면 앞서 얘기한 일정과 비용은 무조건 사용해야 하는 부분이기 때문입니다.

프로젝트의 품질뿐만 아니라 제가 자신 있는 부분은 바로 조직 간의 유기적인 협업을 통한 품질입니다. 프로세스 품질 또한 프로젝트가 진행됨에 있어 정말 중요한 부분으로 최적화된 프로세스와 커뮤니케이션이 이뤄질 수 있도록 환경을 만드는 것입니다.
애자일이 정답이 아니라는 것을 최근에 알게 되었습니다. 콘텐츠 분야는 애자일로 개발이 불가능하다는 것을 알게 되었습니다. 요구사항이 받아지면 콘티하고, 원화를 그리고, 채색을 하게 되고 디자인하여 개발에 이관하고 일련의 작업이 타임라인을 따라 움직이고 있었습니다. 이런 깨달음은 제가 회사에 기여할 수 있는 분야를 넓게 해주는 경험이 되었다고 생각합니다.

모집 분야와 관련된 경험으로는 모바일부터 SI 프로젝트, 그리고 솔루션, 통합 솔루션 등 다양한 프로젝트의 경험을 가지고 있습니다. 또한, 2015년부터는 NIPA에서 진행하는 SW프로슈머 활동을 통해 테스트의 감을 잃지 않기 위해 노력하고 있고, 현재에는 크몽 "IT·프로그래밍/QA·테스트 - 품생품사"이라는 재능 기부 사이트를 통해 1인 프로젝트를 수행하고 있습니다.

가장 자신 있게 사용할 수 있는 ALM 도구는 아틀라시안의 Jira/Confluence/Zephyr가 있고, 자동화 도구는 마이크로포커스의 UFT를 잠깐 사용해 보았으며, 스마트베어의 TestComplete은 테스트 자동화 구축 및 테스트를 수행해 보았습니다. 최근 ALM 도구의 지원 없이 Google Sheet/Docs를 통해 프로젝트 관리 및 이슈 모니터링을 하기 위한 프로세스를 구축하기도 했습니다. 프로젝트 품질 계획부터 테스트 계획 및 테스트 분석/설계를 할 수 있습니다.

저는 대학교에서 소프트웨어를 전공하여 짧은 기간 개발의 경험이 있으며, 정보시스템감리 전공을 통해 프로젝트를 이해하였고, 업무의 시작은 테스트 시작으로 3년 정도 시간이 지났을 때 품질이라는 것을 알게 되었습니다. 테스트는 품질을 확인하기 위한 활동이라는 것을 알게 되었고, 다양한 테스트 활동을 통해 품질을 확인하고, 보증해야 한다는 것을 알게 되었습니다.

역량 기술서

1. [역량기술] 경력 관련 본인의 역량과 업무 경험에 대해 자유롭게 기술해주시기 바랍니다.

[품질 관리 프로세스 구축 경험]
최근 상품 약 150개, 앱/웹은 빌드 기준 약 250개에 대해서 품질 관리를 수행하고 있습니다. (구성원: 저 포함 5명)
처음 입사 시 프로세스 및 품질 관리를 위한 시스템 등 아무것도 없는 상태였습니다. 당시 QA는 저와 기존에 QA 업무를 하던 인원 1명뿐이었습니다. 그래서 프로세스의 필요성을 먼저 알렸고, 보고를 통해 공신력을 얻은 후 프로세스 구축에 대한 수행을 시작하였습니다.

1) 품질 인식에 대한 변화를 먼저 공유하고, 배포하였습니다. 아무리 좋은 프로세스와 시스템이 있을지라도 인식의 변화가 없으면 무용지물이 될 수 있다는 것을 너무 잘 알고 있습니다.
2) 환경 분석(구성원들이 가장 잘 사용하고, 활용도 높은 도구)을 통해 구글 시트의 활용도가 높다는 것을 알게 되어 품질관리에 필요한 모수(테스트 케이스)를 화면 설계서 및 요구사항 명세를 통해 작성하여 확보하였고, 테스트 케이스 수행을 통해 엑셀 자동 계산을 매트릭으로 만들어 정량적으로 품질을 확인할 수 있도록 하고, 추가로 최소한의 입력으로 리포트가 가능하도록 하였습니다.
3) 메일을 통해 테스트 계획/요청/수행/결과에 대해 공유하도록 하였습니다.
4) 파일럿으로 프로젝트를 수행하는 팀부터 점차 프로세스가 자연스럽게 퍼지도록 하였습니다.
5) 보고서를 통해 기존과 현재를 비교하여 SW 품질이 얼마나 좋아졌는지 확인시켜 드리고, 기안 승인을 통해 프로세스를 정립하였습니다.

[품질 관리 프로세스 개선 업무 수행]
2020년 11월 JIRA 시스템이 도입되어 현재 수행 중인 품질관리 프로세스를 JIRA 시스템에 적용하는 활동을 수행하였습니다.
1) 요건 분석을 통해 Jira 시스템에 필요한 항목들을 매트릭 및 마인드맵으로 작성하였습니다.
- 기존 프로세스를 적용하되 불필요했던 요건들을 정리하고, 최소한으로 가장 효율적인 프로세스를 만들기 위해 프로세스를 구축하였습니다.
2) Jira 시스템에 이슈 유형을 정립하고, 유형에 따른 워크플로우(프로세스)를 구축하였으며, Jira 등록 시 화면 구성도 하였습니다.
- Jira 시스템은 약 5년 정도 활용해본 경험이 있었고, 밴더 사는 시스템 설치만 해주었습니다.
- 이후 모든 설정 및 프로세스 설계 및 구축을 수행하였습니다.
3) 구축된 프로세스에 대해서 10차례 이상 관련자들에게 교육을 통해 최대한 시스템을 활용할 수 있도록 하였습니다.
4) 시스템 사용에 어려움이나 프로세스 내에서 불편한 점을 수렴하여 개선하여 반영하였습니다.

[추가적으로 정립한 프로세스]
1) 앱의 배포 관리를 QA가 해야 한다는 것에 대해서 인식의 변화를 정립하고, 보고를 통해 단일 채널에서 배포를 수행할 수 있도록 하였습니다.
- 기존에는 개발팀 내에서 무분별하게 배포하고, 배포되었는지도 알 수 없는 상황들이 발생했습니다.
- 단일 채널 배포를 통해 통제하고, 모니터링하게 되었으며, 나아가 배포에 대한 통계 자료도 정리할 수 있었습니다.
2) VOC 관리 프로세스를 정립하였습니다.
- 기존 VOC는 ITSM(SR) 시스템을 통해 접수하고, 바로 개발팀에 이관하였습니다.
- 현재는 접수된 SR을 Jira 이슈를 생성하여 VOC로 구분하여 처리하고 있습니다.
- VOC의 프로세스는 서버 데이터 변경/코멘트 처리/개발 처리 3가지 플로우로 구성하여 모니터링이 가능하게 구축하였으며, 월간/분기 별 리포트가 가능하도록 구축하였습니다.

[품질 관리 프로세스와 품질 관리 시스템의 연계성]
품질 관리 시스템을 통해 프로세스를 정립하고, 구축하는 것은 품질 경영을 위해 매우 중요한 요소라 생각합니다.
제가 가장 잘 사용할 수 있는 시스템 도구는 JIRA 시스템이고, JIRA의 전반적인 베이스 지식을 습득하고 있기 때문에 시스템을 사용하지 않더라도 필요시 구글 시트를 통해서도 품질 관리 프로세스를 구축할 수 있는 역량을 가지고 있습니다.

[품질 관리 프로세스 외 구축 사례 - 테스트 자동화]
1) 도메인에 가장 적합한 테스트 자동화 솔루션이 무엇인지 벤치마킹 조사를 수행했습니다.
2) 보고를 통해 테스트 자동화 솔루션을 선택하고, 컨설팅 업체와 미팅을 통해 장단점 매트릭스를 작성하였습니다.
3) 테스트 자동화 솔루션 구매 후 테스트 자동화 범위 및 시나리오 설계하고, 작성하였습니다.
4) 테스트 자동화 솔루션을 이용해 스크립트를 작성하고, 테스트 자동화를 구축하였습니다.
5) 기존 테스트 프로세스에 테스트 자동화를 추가하여 품질 관리 프로세스를 더 견고히 하였습니다.
6) 전사 발표를 통해 효과를 증명하고, 품질을 높이는데 기여하였습니다.

[마지막 하고 싶은 말]
하나금융티아이에 입사하게 된다면 회사에서 진행하는 모든 프로젝트의 품질에 기여할 수 있도록 하겠습니다.

서류 결과 : 합격(8/27 발표)

인성 검사 : 합격

신체 검사 : 합격

1,2차 면접 : 합격

최종 처우 협의 : 거절

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[실전 이력서 예시] '코오롱베니트' 서류 지원 결과와 작성했던 이력서 공유!!

품생품사(品生品死) — Sat, 14 Aug 2021 23:17:34 +0900

자기소개서 질문 및 답변 전략 : IT 서비스품질 - 코오롱베니트

모집요강

모집 분야	담당 업무	자격 요건 및 우대사항
IT 서비스품질	- IT서비스 품질 기획 - IT품질 지표 운영 및 관리 - IT서비스 프로세스 관리 - 프로젝트 이슈 진단 및 Risk관리	(필수) IT서비스 품질관리 경험(ITSM) (필수) IT시스템 운영 및 개발 환경에 대한 경험 (필수) MS Office 기반 문서작성 역량 중급 이상 (우대) 대기업 품질 관리 경험 보유자

지원한 분야는 IT 서비스품질 분야입니다. 헤드헌팅을 통해 오퍼를 받아서 지원하게 되었습니다. 처음 서류를 작성할 때, 특히 자기소개서를 작성할 때는 꼭! 옆에 모집 요강을 켜 두고 작성하시길 바랍니다. 간혹 자기소개서를 작성하는데 모집요강에 없는 불필요한 정보들을 작성하는 경우가 생각보다 많이 있습니다.

필요하다면 이력서 컨설팅을 받기

간략 회사 정보 :코오롱베니트는 코오롱그룹의 IT서비스 전문기업입니다. 제조, 금융, 패션, 건설 등 각 산업 분야에서 쌓은 폭넓은 IT기술과 경험을 바탕으로 Big Data, IoT, Cloud, Smart Factory, Smart Construction 등 융·복합서비스 분야를 선도해 나가고 있습니다. 또한, IT솔루션 분야의 전문성과 파트너 네트워크를 통해 다양한 글로벌 IT솔루션의 No.1 Distributor로서의 입지를 공고히 하고 있습니다. IT서비스 사업 분야에서도 그룹 내/외 IT아웃소싱을 비롯하여 전자공시 및 시장감시, 금융IT 사업 등을 활발히 펼쳐나가고 있습니다. 매출액: 4000억 직원수: 510명

참고로 코오롱베니트는 2020년 5월쯤 개인적으로 지원을 해서 서류 탈락을 했던 회사로 이번에 헤드헌터를 통해 지원을 하게된 회사입니다.

자기소개서

[품질 관리 프로세스 구축 경험]
최근 상품 약 150개, 앱/웹은 빌드 기준 약 250개에 대해서 품질 관리를 수행하고 있습니다. (구성원: 저 포함 5명)
처음 입사 시 프로세스 및 품질 관리를 위한 시스템 등 아무것도 없는 상태였습니다. 당시 QA는 저와 기존에 QA 업무를 하던 인원 1명뿐이었습니다. 그래서 프로세스의 필요성을 먼저 알렸고, 보고를 통해 공신력을 얻은 후 프로세스 구축에 대한 수행을 시작하였습니다.

1) 품질 인식에 대한 변화를 먼저 공유하고, 배포하였습니다. 아무리 좋은 프로세스와 시스템이 있을지라도 인식의 변화가 없으면 무용지물이 될 수 있다는 것을 너무 잘 알고 있습니다.
2) 환경 분석(구성원들이 가장 잘 사용하고, 활용도 높은 도구)을 통해 구글 시트의 활용도가 높다는 것을 알게 되어 품질관리에 필요한 모수(테스트 케이스)를 화면설계서 및 요구사항 명세를 통해 작성하여 확보하였고, 테스트 케이스 수행을 통해 엑셀 자동 계산을 매트릭으로 만들어 정량적으로 품질을 확인할 수 있도록 하고, 추가로 최소한의 입력으로 리포트가 가능하도록 하였습니다.
3) 메일을 통해 테스트 계획/요청/수행/결과에 대해 공유하도록 하였습니다.
4) 파일럿으로 프로젝트를 수행하는 팀부터 점차 프로세스가 자연스럽게 퍼지도록 하였습니다.
5) 보고서를 통해 기존과 현재를 비교하여 SW 품질이 얼마나 좋아졌는지 확인시켜 드리고, 기안 승인을 통해 프로세스를 정립하였습니다.

[품질 관리 프로세스 개선 업무 수행]
2020년 11월 JIRA 시스템이 도입되어 현재 수행 중인 품질관리 프로세스를 JIRA 시스템에 적용하는 활동을 수행하였습니다.
1) 요건 분석을 통해 Jira 시스템에 필요한 항목들을 매트릭 및 마인드맵으로 작성하였습니다.
- 기존 프로세스를 적용하되 불필요했던 요건들을 정리하고, 최소한으로 가장 효율적인 프로세스를 만들기 위해 프로세스를 구축하였습니다.
2) Jira 시스템에 이슈 유형을 정립하고, 유형에 따른 워크플로우(프로세스)를 구축하였으며, Jira 등록 시 화면 구성도 하였습니다.
- Jira 시스템은 약 5년 정도 활용해본 경험이 있었고, 밴더 사는 시스템 설치만 해주었습니다.
- 이후 모든 설정 및 프로세스 설계 및 구축을 수행하였습니다.
3) 구축된 프로세스에 대해서 10차례 이상 관련자들에게 교육을 통해 최대한 시스템을 활용할 수 있도록 하였습니다.
4) 시스템 사용에 어려움이나 프로세스 내에서 불편한 점을 수렴하여 개선하여 반영하였습니다.

[추가적으로 정립한 프로세스]
1) 앱의 배포 관리를 QA가 해야 한다는 것에 대해서 인식의 변화를 정립하고, 보고를 통해 단일 채널에서 배포를 수행할 수 있도록 하였습니다.
- 기존에는 개발팀 내에서 무분별하게 배포하고, 배포되었는지도 알 수 없는 상황들이 발생했습니다.
- 단일 채널 배포를 통해 통제하고, 모니터링하게 되었으며, 나아가 배포에 대한 통계 자료도 정리할 수 있었습니다.
2) VOC 관리 프로세스를 정립하였습니다.
- 기존 VOC는 ITSM(SR) 시스템을 통해 접수하고, 바로 개발팀에 이관하였습니다.
- 현재는 접수된 SR을 Jira 이슈를 생성하여 VOC로 구분하여 처리하고 있습니다.
- VOC의 프로세스는 서버 데이터 변경/코멘트 처리/개발 처리 3가지 플로우로 구성하여 모니터링이 가능하게 구축하였으며, 월간/분기 별 리포트가 가능하도록 구축하였습니다.

[품질 관리 프로세스와 품질 관리 시스템의 연계성]
품질 관리 시스템을 통해 프로세스를 정립하고, 구축하는 것은 품질 경영을 위해 매우 중요한 요소라 생각합니다.
제가 가장 잘 사용할 수 있는 시스템 도구는 JIRA 시스템이고, JIRA의 전반적인 베이스 지식을 습득하고 있기 때문에 시스템을 사용하지 않더라도 필요시 구글 시트를 통해서도 품질 관리 프로세스를 구축할 수 있는 역량을 가지고 있습니다.

[품질 관리 프로세스 외 구축 사례 - 테스트 자동화]
1) 도메인에 가장 적합한 테스트 자동화 솔루션이 무엇인지 벤치마킹 조사를 수행했습니다.
2) 보고를 통해 테스트 자동화 솔루션을 선택하고, 컨설팅 업체와 미팅을 통해 장단점 매트릭스를 작성하였습니다.
3) 테스트 자동화 솔루션 구매 후 테스트 자동화 범위 및 시나리오 설계하고, 작성하였습니다.
4) 테스트 자동화 솔루션을 이용해 스크립트를 작성하고, 테스트 자동화를 구축하였습니다.
5) 기존 테스트 프로세스에 테스트 자동화를 추가하여 품질 관리 프로세스를 더 견고히 하였습니다.
6) 전사 발표를 통해 효과를 증명하고, 품질을 높이는데 기여하였습니다.

[마지막 하고 싶은 말]
만약, 코오롱베니트에 입사하게 된다면 최선의 노력을 다하겠습니다.
또한, 회사의 보탬이 되는 인재가 될 것을 약속드리고, 결실을 보여드리도록 하겠습니다.

경력 기술서

기간	회사명(PJT명)	회사현황(매출액, 직원수, 주요사업) / 업무 수행 내용 / 주요 성과 등
19.01 ~ 현재	QA(품질관리)	1. 스마트 출시 상품 품질 관리 A. 에듀 상품 및 서비스 B. 스마트 상품 및 서비스 C. E-커머스 플랫폼 – 약15억 프로젝트 D. OOO 수학(약80억) – SK C&C로부터 인수인계 문서 검토 2. 상품 및 서비스 프로젝트 QA 일정 관리 3. 기획서 기반 TC 설계 및 작성(테스트 고도화) 4. QA 프로세스 구축 및 개선 5. QA 품질지표 정립(인수 기준) 6. 상품 및 서비스 배포 관리 7. ISO/IEC 20000-1:2018 IT 서비스 관리 인증 TF 참여 8. ITSM 구축 참여(2019.6 ~ 2019.12) A. 인터뷰(요구사항 수집 및 프로세스 분석) B. ITSM 구축 후 통합테스트 수행 9. 고객 VOC/CS 분석 및 관리 지표 보고 10. ITSM 갱신 심사 TF 참여(2021.01 ~ 2021.05) A. 사전 심사: 상태 진단 및 인터뷰 진행 B. 시정조치 내역 대응 사용 도구: Google Sheet/Docs, Jira/Confluence/Zephyr
18.01 ~ 19.01	PQA팀 / QA	1. QA 계획/테스트 계획 작성 2. QA 및 테스트 프로세스 구축 3. S/W, H/W 신뢰/호환성 테스트 4. 통합(치과/기공소/고객) SI솔루션(MeditLink) 품질보증 A. WEB(회원관리/장비등록 관리/결제 정보관리) B. MeditLInk솔루션(치과>기공 주문 관리) C. 3D Scan 솔루션(구강 3D 스캔 데이터 관리 – H/W 연결) 사용 도구: Jira/Confluence, TestComplete, TestLink
15.01 ~ 18.01	리얼타임 코어 프로덕트 / QC	1. 테스트 계획 작성 2. 테스트 분석/설계서 작성 > 개발자 체크리스트 작성 3. Zephyr TC 작성 및 테스트 사이클 구축 및 수행 4. 테스트 환경 구축 및 수행 A. DB 세팅(스크립트 수행) B. 서버 세팅(.jar 패치 및 .sh 파일 세팅) C. 웹서비스 세팅(Configuration 파일 세팅) D. 클라이언트 환경 구축 및 테스트 수행 5. 테스트 프로세스 정립: On-Site 테스트(일본 도시바 3주) 사용 도구: Jira/Confluence/Zephyr, Toad/SQL Dev, Baretail, Linux
13.03 ~ 14.06	품질관리팀 / SQA	1. 테스트 계획 및 품질관리 계획 작성 2. 펍트리에디터 TC 설계 및 작성 A. 펍트리에디터 – epub 3.0 저작 솔루션 B. 펍트리 뷰어(Android/iOS) 3. 이슈 관리 및 보고서 작성 4. 테스트 자동화 관리 사용 도구: Mentis, CodeWorks, eggPlant

채용 사이트

KOLON RECRUIT

직무 이야기 직무에 대한 선배의 이야기에 귀기울여 보세요.

dream.kolon.com

✔ 참고 사항 : 헤드헌터 이용 시 유리한 점이라고 합니다.
1) 입사시 회사에서 최우선 순위
- 회사에서 헤드헌터에게 좋은 인재 추천 요청이 와서, 후보자님을 추천하였으므로 최우선 검토 대상임
2) 컨설팅
- 입사시 회사 정보, 연봉 중재, 복지 시설, 면접시 Tip, 회사 생활시 고충 문제 등을 컨설팅
3) 사후 관리
- 입사가 안되어도, 지속적으로 후보자님과 유대관계를 맺어 좋은 포지션이 있으면 추천함
4) 후보자님에게는 절대 비용 발생이 없습니다.
5) 모든 정보는 공개, 배포, 복사 사용하는것을 엄격히 금지하며 비밀을 보장 합니다.

서류 결과 : 불합격

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[실무 - Chap.4] 지라(JIRA)의 관리자가 쉽게 프로세스 구축하는 방법!!

품생품사(品生品死) — Fri, 11 Jun 2021 00:55:41 +0900

다이어그램을 활용하여 워크플로우 세팅하기

지난 글까지 이슈가 무엇인지 알아보았고, 작업 흐름(Workflow)을 왜 만들어야 하는지에 대해서 알아보았습니다. 그리고 작업 흐름에서 가장 중요한 것은 다양한 작업의 흐름을 통합(카테고리화)하는 것이라고 말씀을 드렸습니다. 그럼 다양한 작업의 흐름을 카테고리화가 되었다는 가정하에 아래의 스텝을 따라 해 보시기 바랍니다. 작업 흐름을 만들고, 커스텀 페이지를 만들어서 작업 흐름에 따라 트리거(팝업)가 어떻게 발생하는지에 대해서 설명을 드리겠습니다.

워크플로우는 다이어그램 방식으로 쉽게 세팅할 수 있다

트리거(팝업)의 활용이 왜 필요한지도 꼭 알아야 합니다. JIRA 데이터를 통해 보고서를 작성하기 위한 데이터 정제를 위해서 꼭 필요한 작업이기도 합니다. JIRA를 국문으로 설정했을 때는 업무 흐름으로 표시되고 있기 때문에 아래의 설명은 모두 업무 흐름으로 작성하였습니다.

이해가 안되시는 부분이 있으면 이전 글을 참고해 주세요.

[실무 - Chap.3] 지라(JIRA) 프로세스 간단하지 않지만 복잡하지 않게 구축하는 방법 공유!!

qa-testing.tistory.com

실전 업무 흐름(Workflow) 만들기

작업 흐름을 만들기 위한 메뉴의 위치는 로그인 > 우측 상단 설정 > 이슈(관리자 로그인) > 업무 흐름을 선택합니다.

국문으로 설정해 두었으면 업무 흐름으로 표시될 것입니다.

Workflow 메뉴 위치

업무 흐름을 추가하기 위해 [업무 흐름 추가] 버튼을 클릭합니다.

업무 흐름 추가 버튼

[업무흐름 추가] 버튼을 클릭하면 아래와 같은 업무 흐름의 이름과 설명을 입력할 수 있는 팝업이 표시됩니다.

적당한 이름과 설명을 작성하고, 추가 버튼을 클릭합니다.

업무흐름 추가 팝업

업무 흐름을 추가하게 되면 기본적으로 다이어그램 화면이 표시됩니다.

그리고 버튼스위치를 통해 문자열 보기가 가능합니다.

편하신 대로

업무 흐름을 만드시면 됩니다.

이때, 업무 흐름은 기존 분석되고, 카테고리화 된 프로세스를 다이어그램으로 그리거나 문자열로 작성을 해야 하는 것입니다.

좌측 상단 > [상태 추가] 버튼을 클릭하고, 할 일 다음 스텝에 들어갈 상태를 추가해 줍니다.

상태 추가 버튼 클릭	상태가 추가 되었을 때

상태가 하나 추가되고, 옵션을 설정할 수 있는 창이 표시됩니다. 이 창은 나중에 커스텀 화면을 트리거로 동작할 수 있게 설정할 수 있는 옵션이 존재합니다. 다음 파트에서 자세히 설명드리도록 하겠습니다.

이렇게 추가된 상태 다이어그램을 적당한 위치로 옮겨서 점과 점을 연결하면 [전환 추가] 팝업이 표시됩니다.

이 전환 추가 팝업은 할 일에서 QA 테스팅으로 상태를 변경할 수 있도록 설정됩니다.

점과 점을 연결	전환 추가 팝업이 표시됨

이때 중요한 것은 [전환 추가] 팝업의 이름과 화면입니다.

이름은 할 일에서 QA 테스팅으로 상태를 전환할 때 JIRA 이슈에 보이는 버튼명이 됩니다.

JIRA 이슈 내에 버튼 예시

전 이슈가 할 일 상태에서 분석이 필요한 상태 값을 넣기 위해 ANALYZING 버튼과 이슈를 바로 확인하지 못하는 경우의 상태를 확인하기 위해 WAITING이라는 버튼을 넣었습니다. 참고만 하세요.

이런 버튼의 구성은 프로세스의 카테고리화를 잘해놓으셨다면 금방 구성하고, 설정하실 수 있으실 겁니다.

잠깐 언급한 화면은 바로 ANALYZING이나 WAITING 버튼을 클릭했을 경우 트리거가 발동하여 해당 상태로 이동할 때 값을 입력하도록 팝업을 표시하는 옵션입니다. 그래서 다음 파트에서 말씀드릴 것이 바로 미리 트리거로 사용할 화면을 먼저 등록해 두시는 게 좋습니다. 화면은 나중에 등록을 해도 상관없으나 그렇게 되면 업무 흐름을 수정하여 재설정해야 합니다. 선후 작업 어떤 것을 선택해도 상관은 없습니다.

점과 점을 연결하여 전환 추가가 완료되면 아래와 같이 보이실 겁니다.

이때 좌측 상단 > [체크 박스:전환 레이블 표시]를 체크:ON 하면 전환 추가했던 버튼명이 라인 위에 표시되게 됩니다.

전환 레이블 표시 체크 ON

이런 방식으로 기존에 분석한 프로세스, 통합하고 카테고리화 한 프로세스를 다이어그램이나 문자열을 통해 작업해 주시면 됩니다. 문자열로 작성을 하시면 아래와 같이 표시됩니다.

문자열 작성 예시

커스텀 화면을 통한 작업 흐름 응용하기

이제는 JIRA를 좀 더 효율적으로 사용하기 위한 방법입니다. 일명 트리거를 활용하여 필수 입력 값을 입력하게 하고, 다음 상태로 변경 가능하도록 하는 것인데요. 방법이 조금 복잡할 수 있지만 천천히 따라 하시면 충분히 하실 수 있습니다.

전체적인 순서는

1. 커스텀 화면을 만든다.

2. 업무 흐름에서 1번에서 만든 화면을 사용한다.

아주 간단한 두 스텝을 통해 우리가 기대할 수 있는 것은 "아니 OOO 값 좀 꼭 넣으시라니까요. 그게 없으면 보고서에서 누락이 됩니다."라는 잔소리를 100%는 아니지만 90%는 줄일 수 있을 것이라 생각됩니다.

우선 커스텀 화면을 만들기 위한 메뉴의 위치부터 알아보겠습니다.

화면 메뉴 위치

해당 메뉴에 진입을 하게 되면, 화면 보기라는 페이지가 표시되고, 간단한 설명을 볼 수 있습니다.

화면은 이슈가 생성, 편집될 때나, 업무흐름에 따라 전환이 일어날 때 표시할 필드의 집합입니다.

이슈를 생성하거나 편집할 때 나타나는 화면을 고르려면, 화면 계획에서 이슈 동작에 화면을 대입하십시오.
특정 업무흐름 전환에 나타날 화면을 고르려면, 해당 전환이 속한 업무흐름을 선택하여 편집하십시오.
참고: 화면 계획에 일부가 아니면서 어떤 업무흐름에도 사용되지 않을 때만 화면을 삭제할 수 있습니다.

화면 추가 버튼을 클릭합니다.

화면 추가

팝업이 하나 표시되고, 임의 이름과 설명을 입력합니다.

화면 이름과 설명 입력

아? 여기서 말하는 화면은 우리가 흔히 이슈를 등록할 때 사용되는 팝업형 화면을 이야기합니다. 이슈 만들기 버튼을 누르면 어디서든 확인이 가능한 팝업입니다.

그리고 보이는 페이지는 화면에 표시될 항목을 추가할 수 있는 화면이 표시되고, 필수로 입력을 받을지 옵션으로 입력을 받을지는 필드(사용자 정의 필드) 편집을 통해 수정할 수 있습니다. 이건 나중에 화면 구성할 때 상세히 말씀드리도록 하겠습니다.

화면 구성 추가

필드에 {Epic}이라고 입력하게 되면 연관 검색이 되면서 화면에 추가할 항목들이 콤보 리스트로 표시됩니다. 그리고 우측 추가 버튼을 통해 필드 항목을 추가할 수 있습니다. 전 테스트를 위해 Epic과 우선순위 2 항목을 추가해 보았습니다.

화면 구성 임의 추가

여기까지 되었으면 이제 우리는 트리거를 사용할 준비 스텝 1번이 완료되었습니다. 다음은 이전에 만들어 놓은 업무 흐름 페이지로 이동합니다. 아마도 프로젝트를 연결하지 않았기 때문에 업무 흐름 메뉴 > 최하단 비활성 영역에 만들어 놓은 업무 흐름이 보이실 겁니다.

비활성에 추가된 업무 흐름

이것은 나중에 프로젝트 > 이슈에 업무 흐름을 연결하게 되면 자동으로 활성 리스트로 옮겨지게 됩니다. 우리가 지금 할 것은 업무 흐름을 활성화시키려는 것은 아니니 업무 흐름의 편집을 클릭해서 다이어그램 화면으로 진입합니다. 그러면 지난번에 만들어 놓은 업무 흐름이 보이실 텐데요. 이때, 좌측 상단 전환 레이블 표시 Check : On을 해줍니다. 전환 레이블은 이전 글에서도 잠깐 얘기했듯이 이슈의 상태 변경을 할 수 있는 버튼을 전체 적으로 표시해주는 기능입니다.

전환 레이블 표시

전환 레이블 : TESTING을 클릭해 봅시다. 그러면 팝업이 하나 표시됩니다.

전환 레이블 옵션

편집을 클릭하고, 팝업에서 화면을 확인합니다. 이 화면에 아까 만들어 놓은 커스텀 화면을 선택하면 됩니다.

커스텀 화면 매핑

여기까지 했으면 우리는 트리거 설정까지 완료하게 된 것입니다. 자 그럼 이게 어떻게 동작할까요?

현재 프로젝트 이슈에 우리가 만들어 놓은 업무 흐름을 연결해 놓지 않았기 때문에 바로 확인은 할 수 없습니다. 간략하게 동작에 대한 설명을 드리겠습니다.

1. 이슈를 만든다. > [할 일]로 생성이 될 겁니다.

- 이때 버튼이 TESTING이 표시됩니다.

2. TESTING 버튼을 클릭한다.

3. 그럼 Epic과 우선순위를 입력하는 테스트 팝업이 표시되게 됩니다.

4. 만약 Epic과 우선순위 입력이 필수 값이라면 입력하지 않고는 [QA 테스팅] 상태로 이동할 수 없게 되는 것입니다.

이 부분 또한, 다음다음 다음 블로그쯤 알려 드릴 수 있을 것 같습니다. 모든 세팅이 완료된 시점에 전환 레이블을 통해 상태 변화를 보여 드리도록 하겠습니다.

요약 - 전환 레이블 팝업을 어디에 넣느냐 따라 시스템 활용도가 달라진다.

오늘은 이렇게 실전 업무 흐름을 만들어 보았습니다. 앞에서도 얘기했듯이 업무 흐름은 JIRA를 사용하는데 중요한 부분이며, 업무의 절차 혹은 프로세스가 될 수도 있습니다. 그리고 해당 업무 흐름의 상태를 변경할 때 값을 인위적으로 받을 수 있도록 팝업을 설정하는 것을 알려 드렸습니다. 이 부분을 어떻게 활용하는지에 따라 시스템 사용이 불편해질 수도 있고, 혹은 정말 정재 된 데이터를 쌓을 수 있는 방법이 될 수도 있습니다.

왜냐하면 필수로 작성해야 하는 값은 나중에 보고서나 서머리 하게 되는 경우 많이 활용할 수 있기 때문입니다. 이 방법은 엑셀을 비교하면 잘 못된 값이 입력되지 않도록 하는 유효성 검사라고 생각하셔도 무방합니다. 시스템의 활용 목적에 따라 어디서 어떤 전환 레이블 팝업을 띄울지 어떤 값을 필수로 받아서 나중에 활용할지를 꼭 고민해 보시기랍니다.

JIRA를 활용하고자 고민하고 계신다면 아래 크몽 서비스를 이용해 보세요.

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

품생품사 전문가의 IT·프로그래밍 서비스를 만나보세요. <strong s...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스, jira, 업무 프로세스 관리

[실전 이력서 예시] '아시아나IDT' 서류 지원 결과와 작성했던 이력서 공유!!

품생품사(品生品死) — Sat, 5 Jun 2021 23:40:36 +0900

자기소개서 질문 및 답변 전략 : 품질관리자(QA) - 아시아나IDT

모집요강

모집 분야	담당 업무	자격 요건
품질관리자 (QA)	- 대외 SI 프로젝트 품질지원, 위험관리 　 - 방법론 표준 제시, 테일러링, 산출물 표준 수립 ㆍ단계별 성과물 품질점검 및 시정조치 가이드 ㆍ위험 모니터링 및 해결지원 ㆍ고객사 내부감리, 외부감리 대응 지원 - CMMI 인증유지 (내부심사) - 프로젝트 관리/절차 개선	-대외 SI 사업 QA 역할 유경험자 (3년 이상) -대외 SI 사업 상주수행 경험 필수 -관리/개발방법론 정립 유경험자 [우대사항] - CMMI 인증추진 경험자 우대 - Agile 방법론, MSA 경험자 우대

모집 요강을 봤을 때는 제가 가지고 있는 역량으로 충분히 서류 심사는 가능하다고 생각됩니다. 처음 서류를 작성할 때, 특히 자기소개서를 작성할 때는 꼭! 옆에 모집 요강을 켜 두고 작성하시길 바랍니다. 간혹 자기소개서를 작성하는데 모집요강에 없는 불필요한 정보들을 작성하는 경우가 생각보다 많이 있습니다.

여행을 좋아한다면 여행사 취업을 도전해보기

예를 들면, 전 CMMi 인증 추진에 대한 경험이 없습니다. 하지만, ITSM 20000 심사원 자격증을 취득했고, TF를 통해 ISO 20001 인증을 참여했습니다. 최근에는 갱신 심사 TF에도 참여하여 인증을 받기 위한 프로세스를 몸으로 익히고, 어떻게 진행되는지 그리고, 무엇이 필요한지 이해하고, 인지하고 있습니다.

위와 같이 생각하면서 자기소개서를 작성하곤 합니다. 생각의 정리와 면접의 준비를 동시에 하는 것이기 때문에 꼭 실천해 보시길 바랍니다.

자기소개서는 기존 작성된 자기소개서에 추가된 내용을 업데이트하여 복붙으로 지원하였습니다. 항상 마지막에는 맞춤법 검사하시는 걸 잊지 마세요. 꼭 제출하고 나면 오타가 보입니다. 이번에도 오타가 하나 있더라고요. 자기소개서는 아니고, 경력 사유 작성하는 곳에...

간략 회사 정보 : 아시아나 IDT는 누구나 알고 있는 아시아나 그룹의 SI를 주로 하는 회사이며, 네임벨류로는 좋은 회사입니다. 잡플래닛과 크래딧잡, 사람인, 잡코리아, 구글링을 통해 회사의 정보를 수집했고, 평균 연봉 상위 1%에 워라벨이 좋은 회사로 평가되어 있었습니다. 안 좋은 점도 있는데 이 점은 개인적으로 찾아 해 보시기 바랍니다.

자기소개서와 역량기술서는 자유 양식이었으며, 특이한 점은 잡플렉스 사이트에서 AI 테스트가 있었습니다. 마이다스아이티라는 회사에서 개발한 솔루션인데 많은 회사들이 인적성검사를 사용하고 있으며, 아시아나 IDT는 AI 테스트 전형도 넣고, 필수 제출로 해두었습니다. 참고하시기 바랍니다.

자기소개서

1. 자유롭게 기재하여 주시기 바랍니다.
[지원 동기]
아시아나 IDT에 지원하게 된 동기는 애플리케이션이나 솔루션과 같이 작은 틀에서 벗어나서 프로젝트의 관점에서 품질 활동을 하고, 지금보다 더 큰 무대에서 꿈을 펼치기 위해 지원하게 되었습니다.

저는 프로젝트의 품질을 조금이나마 이해하기 위해 야간 대학원을 진학하였으며, 정보시스템 감리를 통해 프로젝트의 전반적인 관리 활동을 알 수 있었습니다. 또한, 많은 프로젝트 수행을 통해 개발 방법론을 몸으로 익힐 수 있었고, 프로젝트 수행 기간 동안 조직이 인지하지 못하는 리스크를 선 예측하여 공유하는 활동을 통해 큰 문제를 미연 방지하기도 하였습니다.

품질보증 활동을 하지 않는 조직에서는 먼저 인수 기준에 대한 인식을 확고히 하고, 품질 지표를 설정하여 모두가 공감하는 정량적 지표를 정립하였습니다. 테스트가 완료된 시점에는 해당 지표를 달성하였는지 판단하여 보고하고, 추가 조치가 필요한 경우 모니터링 활동을 통해 품질 지표를 높일 수 있는 방안을 모색하고, 제안하기도 하였습니다.

개발 방법론은 애자일이 트렌드인 것을 오래전부터 인지하여 개인적으로 지식을 습득하였고, 프로젝트 진행에 있어 가장 많이 사용하는 도구인 Jira/Confluence 통해 최적화된 프로세스를 구축하기 위해 노력하였습니다. 또한, PM 및 개발 조직 간의 협업을 통해 최상의 품질로 프로젝트가 성공적으로 출시할 수 있도록 하였습니다. 저는 프로젝트의 품질이 상품 및 서비스의 기능/비기능 측면뿐 아니라 프로세스의 원활함. 그리고 부서 및 조직 간 커뮤니케이션의 중요성을 잘 알고 있습니다.

제가 바라보는 아시아나 IDT는 현재에도 성장하고 있고, 앞으로도 성장할 것을 알고 있기에 저 또한 아시아나 IDT와 함께 성장하고자 지원하게 되었습니다.

[주요 역량]
제가 만약 아시아나 IDT에 입사하게 된다면 가장 기여할 수 있는 분야는 바로 "품질"입니다. 제 슬로건이자 공식적으로 활동하는 분야의 아이디는 품생품사입니다. 좀 유치하게 보이실 수도 있지만 가장 중요한 순간에 프로젝트 출시 여부를 선택해야 할 때 딱 한 가지만 생각하면 너무 쉬운 결론이 나오는 것을 알게 되어 품생품사의 아이디를 사용하게 되었습니다. 출시 여부를 선택해야 할 때 "품질"만 생각하면 결론은 항상 명확했습니다. 만약, 메이저 한 잔여 이슈로 인해 출시를 고민한다면 품질에 어떠한 영향이 있을지만 생각하면 되기 때문입니다.

개발 난이도와 일정, 비용 등을 고민하고 있다면 이미 잘못된 판단이라 생각합니다. 출시되었을 때 사용자의 입장에서 품질적으로 느끼는 불쾌감이나 만족도가 낮을 것이라 판단되면 앞서 얘기한 일정과 비용은 무조건 사용해야 하는 부분이기 때문입니다. 프로젝트의 품질뿐만 아니라 제가 자신 있는 부분은 바로 조직 간의 유기적인 협업을 통한 품질입니다. 프로세스 품질 또한 프로젝트가 진행됨에 있어 정말 중요한 부분으로 최적화된 프로세스와 커뮤니케이션이 이뤄질 수 있도록 환경을 만드는 것입니다.

애자일이 정답이 아니라는 것을 최근에 알게 되었습니다. 콘텐츠 분야는 애자일로 개발이 불가능하다는 것을 알게 되었습니다. 요구사항이 받아지면 콘티 하고, 원화를 그리고, 채색을 하게 되고 디자인하여 개발에 이관하고 일련의 작업이 타임라인을 따라 움직이고 있었습니다. 이런 깨달음은 제가 회사에 기여할 수 있는 분야를 넓게 해주는 경험이 되었다고 생각합니다.

아시아나 IDT에 입사하게 된다면 회사에서 수행하는 모든 프로젝트의 품질에 기여할 수 있도록 하겠습니다.

역량기술서

1. 자유롭게 기재하여 주시기 바랍니다.
[1] 2019.01 ~ 재직 중 : 스마트기획팀 / CEL3(과장) / 에듀테크 앱/웹 SW 품질 관리
'교원 크리에이티브'에서는 구몬/에듀 외 법인에서 출시하는 모든 상품 및 서비스에 대한 QA 활동(계획 ~ 배포)을 수행하고 있고, QA를 위한 정량적 지표 정립과 프로세스를 구축하고 실행함으로써 부문 내의 높은 평가를 받았습니다. 테스트 계획, 수행, 테스트 케이스 설계 및 관리, 배포 관리, 이슈 관리를 수행하였습니다. 2020년 11월 프로젝트 관리 시스템의 필요성을 알렸고, 인식 개선부터 Jira 시스템을 도입까지 중심에 있었습니다. 도입 후에는 시스템 사용법에 대한 교육을 20차례 이상 수행하였고, Jira 시스템 관리자로서 프로젝트 프로세스 정립 및 이슈 유형을 정의하고, 작업 흐름을 구축하였습니다. 또한, ITSM을 통해 접수되는 VOC를 Jira 시스템과 연계하여 고객 만족을 위한 프로세스를 정립하였으며, 개발자들의 업무 효율을 높일 수 있도록 프로세스를 정립하고 배포하였습니다.

업무 외로 2019년 6월부터 ISO/IEC 20000:1-2018 인증 TFT에 참여하여 ITSM 구축의 요구사항 수집과 프로세스 구축을 위한 활동(인터뷰/문서작업/통합 테스트)을 수행하였으며, ISO20000 ITSM 심사원 자격시험에 합격하였습니다. 2021년 5월 갱신 심사 TFT에도 참여하여 성공적으로 심사를 완료하였습니다.

[2] 2018.01 ~ 2018.12 : PQA팀 / 책임(과장) / SW QA(통합 SI 솔루션)
'메 디트'에서는 SI 통합 솔루션으로 치과/기공소/고객이 한 흐름에서 가장 빠르게 서비스를 받을 수 있도록 회원 관리/주문관리/3D 스캐닝 데이터 관리/결재 관리까지 QA 활동을 수행하였습니다. Web에서는 회원 및 HW 장비의 시리얼을 관리하고, 윈도우 설치 프로그램에서는 3D 스캐닝 데이터를 수집할 수 있었고, 프로그램 내부적으로 주문/배송 관리 및 결재까지 할 수 있는 시스템에 대한 전체적인 품질관리를 수행하였습니다. 개발팀과 협업하여 테스트 프로세스를 구축하였으며, 요구사항 수집부터 테스트 요청, 배포 통제, 버전 관리, 품질 지표 보고 등의 활동을 수행하였습니다. 또한, 자동화 솔루션 비교 분석부터 도입과 테스트 자동화에 대한 프로세스를 구축하였으며 Test-Complete라는 자동화 솔루션을 도입하여 자동화 테스트에 관한 결과 리포트를 발행하였습니다.

[3] 2015.01 ~ 2018.01 : 리얼타임 코어 프로덕트팀 / 책임(과장) / 반도체 모니터링 솔루션 QC
'비스텔'에서는 반도체 모니터링 솔루션 패키지 중 DCP(Data Collection Plan) 제품을 담당하여 테스트 환경 구축(웹 서비스, DB, Configuration 등) 및 자동화 테스트 시나리오, 백 엔드부터 프런트 엔드 전반에 걸친 QA 활동을 수행하였습니다. 애자일 방법론을 통한 개발을 처음 경험하게 되었으며, 스크럼에 투입되어 프로젝트의 테스트 계획과 분석, 이슈 관리, 위험 관리를 수행하였습니다. ALM 도구인 JIRA를 통해 관리하였으며, Bit-bucket을 통한 코드 품질 관리와 Confluence와 Zephyr를 통해 체크리스트 및 테스트 케이스를 설계하고, 작성/수행하였습니다.

[4] 2013.03 ~ 2014.06 : 품질관리팀 / 대리 / epub 3.0 에디터 솔루션 QA
'나모인터랙티브'에서는 Epub 3.0 에디터에 대한 메인 QA를 수행하면서 개발 생명 주기 내에서의 QA를 처음 시작하게 되었습니다. 서드 파티 앱으로 뷰어를 제공하였으며, 모바일 오픈 마켓(Play/App Store)에 대응하여 테스트를 수행하였고, 테스트 케이스 작성은 엑셀을 사용하였고, 이슈 관리 및 결함 관리는 Code-works와 Mantis를 이용하여 관리하였습니다.

[5] 2011.09 ~ 2013.03 : 전자 공공부문 / 사원 / SI 프로젝트 테스터
'인투 데이터 시스템'에서는 삼성 SDS에서 수주하는 SI 프로젝트에 투입되어 사용자 테스트를 수행하였고, 1개월 이상 투입되는 경우는 통합 테스트부터 수행하였습니다. QC(HP)를 통해 이슈를 관리하였으며, 가장 기억에 남는 프로젝트는 행정안전부에서 발주한 가족관계 증명서 인터넷 발급 프로젝트였습니다. 짧게 테스트를 수행하였지만, 현재 전 국민이 이용하는 서비스로 가장 뿌듯한 프로젝트로 기억됩니다.

[6] 2010.02 ~ 2011.05 : MF2팀 / 사원 / 모바일 Web SW QA
'와이즈와이어즈'에서는 피처폰에 있는 웹의 HTML/XHTML을 담당하여 주 업무로 테스트를 수행하였습니다. 테스트 케이스 작성과 QC(HP) 도구를 통해 이슈 및 결함 관리를 하였습니다.

서류 탈락

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

[용기와 자신감] 서류 지원과 면접은 불합격이 익숙해질 때까지 도전해보는 거야!!

품생품사(品生品死) — Mon, 31 May 2021 00:32:34 +0900

이력서에 대해서 조언 해줄 수 있는 이유

15년 동안 9번의 이직을 하였습니다.

- 자의던 타의던 많이 해서 안 좋게 보는 회사도 있고, 경험 많아서 좋게 보는 회사도 있었습니다.

- 하나의 메일로만 지원의 이력이 남아 있어 정리를 해보려 합니다.

- 이전 메일에도 남겨두었으면 좋았을껄 이라는 아쉬움이 남습니다.

- 사람인/잡코리아/잡 플레닛/게임잡 등 사이트 내에서의 지원은 많이 빠져 있습니다.

이직을 웃으면서 할 수 있으면 베스트 이직이다

2009년부터 일을 했지만 네이버 메일을 사용한 게 2014년부터여서 이때부터의 이력을 정리해 봅니다.

입사 지원 시 지속적으로 업데이트 되고 있습니다.

No.	회사명	서류	면접
01	테크로스(인턴)	합격	합격
02	와이즈와이어즈	합격	합격
03	인투데이타시스템	합격	합격
04	나모인터랙티브	합격	합격
05	스탠다드네트웍스	합격	합격(입사 보류 - 노동부 신고)
06	유와이즈원(대웅 그룹)	합격	합격
07	SK플래닛(11번가)	합격	합격 > 입사 거절
08	스마일게이트 인터넷	합격	불합격
09	STEN	불합격
10	SK플래닛(본사)	합격	불합격
11	스마일게이트 스토브	합격	불합격
12	넥슨	불합격
13	카카오	불합격
14	NHN 테크놀로지 서비스	합격	불합격
15	엔씨소프트	불합격
16	블루홀 스튜디오	불합격
17	FinQ	불합격
18	넷마블 게임즈	합격	불합격
19	비스텔	합격	합격
20	데브시스터즈	불합격
21	스마일게이트 RPG	합격	불합격
22	넥슨	불합격
23	엔씨소프트	불합격
24	LINE+	불합격
25	아이즈소프트	헤드헌팅(불합격)
26	해커스	불합격
27	쿡앱스	불합격
28	카카오	불합격
29	인터파크	불합격
30	에이스프로젝트	불합격
31	교원그룹	불합격
32	알서포트	불합격
33	하이퍼커넥트	불합격
34	SK텔레콤	불합격
35	티몬	불합격
36	KT그룹(석박사 공채)	합격	인적성 불합격
37	메디트	합격	합격
38	카카오	불합격
39	SK엔카닷컴	합격	불합격
40	하나금융티아이	합격	2차면접 취소
41	교원그룹	합격	합격
42	한화시스템	포지션 제안	거절
43	비바버블리카	불합격
44	GS리테일	불합격
45	SSG.COM	불합격
46	KT ds	합격	불합격
47	LG CNS	불합격
48	GS 리테일	불합격
49	비바리퍼블리카(Toss)	불합격
50	코오롱 베니트	불합격
51	카카오	불합격
52	삼성증권	헤드헌팅(불합격)
53	KT NexR	불합격
54	티벨	포지션 제안	거절
55	카카오엔터프라이즈	불합격
56	한국재정정보원	합격	필기시험 불합격
57	현대오토에버	불합격
58	아시아나IDT	서류 결과 미통보
59	캐롯손해보험	불합격
60	오케이몰	불합격
61	한화시스템	불합격
62	티시스(태광 그룹)	합격	2차 불합격
63	하이브(기존 빅히트엔터테인먼트)	헤드헌팅(불합격)
64	SK이노베이션	불합격
65	아시아나IDT	불합격
66	코오롱베니트	헤드헌팅(불합격)
67	하나금융티아이	합격	처우 협상 결여
68	아이들나라(LG U+)	불합격
69	쿠팡 플레이	포지션 제안	코딩 테스트로 인한 거절
70	카카오페이 증권	불학격
71	메조미디어	합격	처우 협상 결여
72	크몽	합격

이 외에도 수 없이 많은 지원을 했습니다. 사람인과 잡코리아 지원을 통해서 정말 많이 지원을 했었습니다. 이력서는 못해도 100번은 넘게 지원했을 거라 생각됩니다. 서류 합격은 2~30% 정도 합격률이 되는 것 같고, 최종 합격한 곳은 10곳 정도 되는 것 같네요.

2014년에는 게임 회사에 입사해 보려 노력했으나 아쉽게도 입사하지 못했습니다. 스마일게이트에 정말 가고 싶었던 적이 있었는데 말이죠. 입사 지원에 대한 에피소드는 나중에 다른 블로그에 남기도록 하겠습니다. 서류 100번 찍어 안 넘어가는 회사 있을지도 모르지만 가고 싶은 회사의 목표를 두시고, 될 때까지 지원해 보시길 바랍니다. 서류라는 선을 넘으면 면접이라는 벽이 기다리고 있지만 그 또한, 부실 수 있으실 겁니다.

취업이 어려운 시기이니 남보다 더 노력해야 하는 것이 사실이고, 취업이 어려운 것도 사실입니다. 하지만 실력만으로 어렵고, 생각보다 운이 많이 필요한 것도 사실입니다. 조금이나마 이 글을 읽어 주시는 분들께 도움과 용기를 드리도록 하겠습니다.

You're gonna make it!!!

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

요약 : 포워딩 이직, 스타트업 이직, 경력직 이직, 경력 이직, 에듀윌 면접, 항해 99 취업, 에듀윌 대기업, 데이터 엔지니어 취업, 대기업 이직, 취업, 취준생, 삼성 sds 신입, skt 공채

[실무 활용] 간단하지만 꼭!! 필요한 정보로 타 부서로부터 테스트 요청서 받는 방법!!

품생품사(品生品死) — Thu, 20 May 2021 23:08:44 +0900

너무 많은 내용은 피로감이 늘어날 뿐이다

테스트 요청서는 테스트를 수행하기 위해 꼭 필요한 문서입니다. 테스트 요청서는 테스트에 필요한 정보를 모아놓은 문서이며, 테스트의 범위를 결정하기도 하는 중요한 문서입니다. 또한, 테스트가 완료되었을 때 필요한 정보를 통해 이후 작업을 수행할 수도 있습니다.

꼭 필요한 내용으로 요청을 받아야 업무가 수월해진다

오늘은 테스트에 꼭 필요한 테스트 요청서에 대해서 간단하게 알아보려 합니다. 그리고 테스트 요청서에 필요한 정보를 Confluence에서 JIRA 데이터를 어떻게 가져오는지도 간략하게 설명드리도록 하겠습니다.

Confluence에 테스트 요청 양식 만들기

테스트 요청서 양식

No.	구분	옵션 여부	상세 설명
1	프로젝트명	필	프로젝트의 이름을 작성.
2	담당 개발 부서	필	담당 개발 부서명을 작성
3	담당 개발 파트	옵	담당 개발 파트를 작성
4	담당 개발장	옵	담당 개발장 이름을 작성
5	개발 담당자	필	개발 담당자 이름을 작성
6	배포 마켓	필	타겟 배포를 선택(Check : On)
7	배포 예정일	필	배포 예정일을 작성(예시: 2021.05.20)
8	배포 시간	필	배포 시간을 작성(예시: 오전(후) 09시 00분)
9	요청 차수 구분	필	요청 차수를 작성(예시: 1차, 2차, 3차 ...
10	테스트 버전	필	테스트 버전을 작성(예시: 1.0.0.b1)
11	테스트 요청일	필	테스트 요청일을 작성(예시: 2021.05.20)
12	심상등록 희망일	옵	심사 등록 희망일을 작성(테스트 데드라인)
13	테스트 정보	옵	테스트 정보를 작성 - 계정, 환경, 영향 범위 / 체크리스트 등
14	테스트 차수	필	테스트 차수를 작성(예시: TEST_1차, TEST_2차 ...)
15	테스트 파일	필	테스트 해야할 파일 첨부 함
16	릴리즈 노트	필	테스트 대상 목록을 JIRA에서 불러옴

프로젝트명은 어떤 프로젝트에서 테스트 요청을 했는지를 구분하기 위해 사용합니다. 향후 해당 프로젝트명 내에 테스트 요청과 결과를 매핑시켜야 하고, 상위 페이지에는 업데이트 이력 등이 작성되어야 합니다. 그렇게 작성이 되면, 해당 프로젝트 내에서 어떤 버전에 어떤 항목이 업데이트되었는지 확인할 수 있게 됩니다.

담당 개발 부서 / 담당 개발 파트 / 담당 개발장 / 개발 담당자는 개발에 책임이 있는 정보를 입력합니다. 이때, 이야기하는 책임은 문제 발생 시 최대한 빨리 대응할 수 있는 부서나 담당자를 알기 위함입니다. "네가 개발 잘 못 했으니 알아서 책임져"의 목적이 아니라는 것을 명심하시기 바랍니다.

배포 마켓의 경우 테스트가 완료되었을 때 제품이나 상품이 배포되는 타깃을 간편하게 Confluence에서 체크박스를 이용하여 사용합니다.

배포 예정일 / 배포 시간은 앱이나 서비스가 배포될 날짜와 시간을 작성하되 유관부서가 모두 협의되거나 공유된 시간을 작성합니다. 저 같은 경우 배포 스케줄을 관리하기 위해서 JIRA에 배포 TASK를 등록하여 배포 날짜는 End Date로 사용하고, 커스텀 필드를 만들어서 배포 시간을 입력하여 배포 날짜와 시간을 관리하고 있습니다. 또한, 대시보드에 가젯을 통해 배포 스케줄을 한눈에 알아볼 수 있도록 구성하여 관리하고 있습니다.

배포 관리를 위한 대시보드

요청 차수 / 테스트 버전 / 테스트 요청일은 전체 테스트를 몇 번 수행하였으며, 테스트 버전과 요청을 개발 팀에서 몇 번을 하였는지 확인하기 위함입니다. 이것은 "왜 이리 많이 요청했어?"의 의미가 아닌 향후 테스트 결과서를 작성할 때 모수의 기준 범위를 잡기 위함입니다.

예를 들어, 1차 테스트 케이스 100개를 수행해서 5개가 실패하였고, 2차에서는 실패한 5개의 범위 내에 테스트 케이스 20개를 수행했다고 합시다. 그리고 사이드 결함이 5개 나왔다고 가정하였을 때, 1차에서 테스트 케이스의 모수는 100개지만 2차에서 테스트 케이스의 모수는 105개가 됩니다.(결함은 테스트 케이스화 하여 모수에 포함해야 함)

심사 등록 희망일의 경우 오픈마켓(구글 플레이 스토어 or 애플 앱 스토어)에 출시하는 경우 작성하며, 해당 심사등록 희망일은 보통 테스트 완료 데드라인으로 잡습니다. 가끔 출시일이 임박하여 테스트와 심사를 동시에 진행하는 경우도 있지만 지양하는 방식이므로 정석대로 진행해 주시는 게 좋습니다.

테스트 정보에는 테스트에 필요한 가능한 꼭 필요한 정보를 입력합니다. 저는 현재 계정 정보나 테스트 환경 정보, 혹은 개발팀에서 필수로 확인해야 하는 체크리스트를 작성하여 확인 후 요청하게 양식을 만들어서 사용 중입니다.

테스트 차수와 테스트 파일은 요청과 매핑되도록 작성하며, 테스트 차수는 TEST_1차 와 같이 작성하시길 권장드립니다. 이유는 릴리즈 노트에서 사용될 제이쿼리 때문인데요. 보통 JIRA의 이슈 목록이 릴리즈 노트가 되며, JIRA의 목록을 불러오기 위한 키값으로 사용을 하게 됩니다.

Confluence의 매크로(Jira 이슈 필터)를 통해 아래 제이쿼리로 목록을 불러옵니다. 사전 작업으로 해당 이슈에 출시 버전(커스텀 필드)과 label이 입력되어 있어야 합니다.

출시 버전은 사용자의 목적에 따라 커스텀으로 만들어서 사용해 주시면 됩니다. 꼭 출시 버전이 아니어도 상관 없습니다. JIRA에서는 Fixed Version과 Affect Version을 기본적으로 제공하고 있습니다.

제이쿼리 예시 : project = OOO and "출시 버전" = 1.0.0 and labels = TEST_1차

제이쿼리 키값으로 세 가지를 필수로 사용 중인데 해당 쿼리의 의미는 "출시 버전 내에 몇 번의 테스트가 수행되었으며, 해당 차 수내에 어떤 항목들이 테스트되었다"를 알 수 있게 됩니다. 또한, 이 정보는 향후 테스트 결과서를 작성할 때 아주 중요한 정보로 활용된다는 점 꼭 기억하시길 바랍니다.

그리고 배포된 후에는 테스트 버전을 병합하게 되는데 이때, 기존 테스트한 버전이 사라짐으로 labels을 꼭 사용하시거나 QA 고유의 컴포넌트라던가 커스텀 필드를 통해 꼭 구분자를 사용하셔야 합니다.

테스트 요청서는 이렇게 활용해야 한다.

우선 Confluence 최상위 페이지에는 업데이트 히스토리 페이지를 작성합니다.

어플리케이션 혹은 서비스의 업데이트 히스토리

기본적으로 담당 부서 및 개발자가 표시되어야 하고, 업데이트 일자 / 버전 / 릴리즈 노트 목록 / 테스트 케이스 / 테스트 수행 중 발견된 전체 결함 등을 테이블에 표시될 수 있도록 정리해야 합니다.

바로 하위 페이지에는 해당 버전 내에 히스토리를 정리합니다.

해당 버전 별 업데이트 히스토리

JIRA 이슈 링크를 통해 릴리즈 노트 확인이 가능하며, 출시 버전 기준 몇 번의 테스트가 수행되고, 몇 개의 이슈가 발견되었는지 알 수 있게 됩니다.

그리고 바로 아래에 테스트 요청서와 결과서를 하위 페이지에 두시면 아래와 같이 페이지 목록으로 표시될 것입니다.

페이지 구성 예시

앞서도 말씀드렸듯이 테스트 요청서는 개발에서 테스트 팀 혹은 QA로 테스트 요청을 위해 사용되기도 하지만 테스트가 완료된 이후에 행위를 하기 위한 정보의 문서로도 활용할 수 있다는 점을 알아 두시면 좋을 것 같습니다.

다음 글에서는 테스트 결과서에 대해서 설명드리도록 하겠습니다.

크몽: 테스트 문서 관리 패키지

문서 작성이 어렵거나 테스트 템플릿이 필요하신 분들은 멘토링(크몽 서비스)을 이용해 보세요

실무 적용 QA 테스트 프로세스 관리 문서 패키지 - 크몽

품생품사 전문가의 자료·템플릿 서비스를 만나보세요. "테스트 부업으로 수익 1...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스, qa 테스트, 소프트웨어 테스트

[QA : 업무 프로세스 관리] 간단하게 고객의 목소리(VOC)를 관리하는 프로세스 글로만 풀어보기!!

품생품사(品生品死) — Mon, 17 May 2021 22:37:58 +0900

심플한 VOC(Voice Of Customer)프로세스

VOC(Voice Of Customer)를 관리하는 이유는 CS(Custormer Service)의 만족도를 높이기 위함입니다.

VOC를 관리하기 위해서는 그에 맞는 프로세스가 필요한데요.

VOC 관리도 소프트웨 품질을 높이기 위한 중요한 활동이다.

간단하게 설명하면 VOC 영역은 회사와 고객 간의 커뮤니케이션을 이야기합니다. JIRA에서는 젠데스크를 통해 ITSM(IT Service Management) 구축이 가능하며, ITSM을 구축하게 되면 SLA(Service Level Agreement)를 관리할 수 있게 됩니다. 회사마다 SLA를 관리하는 방법은 다를 수 있으니 참고만 해주시면 되고, 아래 내용은 보편적인 시스템의 방식으로 ITSM과 JIRA가 구분된 시스템 내에서의 VOC 관리 프로세스를 글로 작성해 보았습니다.

JIRA는 보통 BTS로만 사용하고 있기 때문에 젠데스크라는 도구를 사용하지 않고 있어서 ITSM의 역할을 하지 못하는 경우가 많습니다.

[실무 - Chap.1] 지라(JIRA)를 활용하여 효율적인 프로세스를 구축하기 위한 방법 공유!!

qa-testing.tistory.com

JIRA 프로세스 관련 글을 연재한 것이 있으니 나중에 참고해 보시면 좋을 것 같습니다.

결과적으로 VOC를 관리해야 하는 이유는 브랜드의 이미지를 만들어 갈 수 있는 부분이기 때문에 꼭 챙겨야 하는 부분입니다. 예를 들어 장애로 인해 카페 등에서 "OO 앱 장애 나서 사용을 못하네요." 이런 글들이 보이기 시작하면 브랜드의 이미지가 낮아질 수 있게 됩니다.

이런 상황을 미연에 방지하고, 예방하고자 VOC를 관리하기 위한 프로세스는 선택 아닌 필수입니다. 모기업에서는 KPI(Key Performance Indicator)를 VOC를 줄이는 것을 통해 품질을 측정하기도 하였습니다.

VOC 현황 분석

관리 시스템의 이슈 생성 시 VOC 항목을 필수 선택 및 링크

VOC 수정 개발이 필요한 경우 업데이트 프로세스와 동일
VOC 긴급 수정이 필요한 경우 구두 협의 필요
운영 환경에 영향받지 않도록 배포 일자 및 시간 확인 필요

테스트 요청 계획서 작성(상시 작성)

테스트 요청 계획서 작성(상시 작성)
담당 부서 : 개발 담당 부서
개발 담당자 : 담당 개발자
요청일 : 테스트 요청 예정일
배포 예정일 : 배포 날짜 및 시간
상품명 : 배포 상품명
수정 내용 : 수정된 Jira 이슈 링크

테스트 요청

1. Confluence(00. [x.x.x] 테스트 요청서)을 작성하여 테스트 요청

프로젝트 사이트맵
해당 상품 및 서비스 선택
만들기(•••)
[업데이트] 테스트 양식 선택

2. 00. [x.x.x] 테스트 요청서 작성

상품 및 서비스명 : 상품 및 서비스명 작성
담당 개발 부서 : 개발 담당 부서
담당 개발 파트(장) : 개발 담당 파트
테스트 버전 : 테스트 요청 버전(1.0.0.b1 ~)
배포 버전 : 출시 버전(1.0.0)
테스트 가이드 정보 : 테스트 시 도움이 될만한 정보 입력(영향 범위 등)
테스트 요청일 : 테스트 요청 일자
심사 등록 희망일 : 오픈마켓의 경우 심사 등록 희망일자 작성
배포 예정일 : 배포 예정일자 작성
배포 시간 : 예정된 배포 시간 작성(배포 담당자 조율 필요)
개발 담당자 : 담당 개발자 이름
배포 마켓 : 배포되는 마켓 모두 선택
검수 파일 : 빌드 파일 차수별 링크 생성(직접 첨부 X)
테스트 정보 : 테스트에 필요한 계정 및 환경 정보
테스트 대상 목록 : Jira 이슈 링크

테스트 수행

Zephyr 테스트 케이스를 통해 테스트 수행 여부 확인
Jira 이슈 등록(결함, 개선 항목 등)
빌드 버전 별 테스트 사이클을 구성하여 테스트 반복 수행

테스트 결과

Confluence(00. [x.x.x] 테스트 요청서) 하단 테스트 결과 테이블을 통해 결과 공유
테스트 완료 시 배포 Task 생성 후 배포 여부를 Jira 이슈를 통해 공유
메일로도 배포 여부 공유(인바운드센터)
[대시보드] 품질관리 메인 홈에서 배포 현황 확인

크몽: 테스트 문서 관리 패키지

문서 작성이 어렵거나 테스트 템플릿이 필요하신 분들은 멘토링(크몽 서비스)을 이용해 보세요

실무 적용 QA 테스트 프로세스 관리 문서 패키지 - 크몽

품생품사 전문가의 자료·템플릿 서비스를 만나보세요. "테스트 부업으로 수익 1...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, QA 프로세스, 테스트 프로세스, 업무 프로세스 관리

[QA : 업무 프로세스 관리] 복잡하고 어려운 테스트 프로세스 간단하게 글로만 풀어보기!!

품생품사(品生品死) — Sat, 15 May 2021 23:22:31 +0900

테스트 프로세스 글로만 작성해보기

"QA = 테스트"라고 생각하시는 분들이 간혹 있습니다.

결론은 "QA ≠ 테스트"가 맞습니다.

QA(품질 보증)을 테스트라고 생각하면 아주 큰 오산입니다.

테스트는 품질 보증을 하기 위한 하나의 수단일 뿐입니다.

제품이나 서비스의 상태를 확인하기 위한 방법이 테스트(결함을 찾기 위한 행위)인 것입니다.

다른 말로 풀이하면 테스트 방법은 수 없이 많으며, 우리는 100%로 확인하지 못하는 소프트웨어를 최대한 결함 없이 출시하기 위해서 각양각색의 테스트를 통해서 확인 활동을 하는 것입니다. 그것이 바로 테스팅이라는 활동입니다.

테스팅은 결함을 발견하기 위한 활동이다

QA라는 단어는 아주 포괄적인 단어이고, 어떤 회사에서는 포지션명이 될 수도 있고, R&R이 될 수도 있으며, 직함, 직책이 될 수도 있습니다. QA는 테스터만 하는 것이 아니고, 프로젝트에 참여하는 모든 사람이 해야 하는 혹은 모든 사람이 챙겨야 하는 것이라 할 수 있습니다.

위의 개념을 유념하고, 아래의 내용을 보시면 쉽게 이해가 되실 겁니다.

테스트 일정 수립

WBS 작성 시점 테스트 일정 협의
[대시보드] 품질관리 로드맵 일정 적용

테스트 요청

1. Confluence([신규출시] 테스트 요청 양식)을 작성하여 테스트 요청

프로젝트 사이트맵
해당 상품 및 서비스 선택
만들기(•••)
[신규출시]테스트 요청 양식 선택

2. [신규출시] 테스트 요청 양식 작성

상품 및 서비스명 : 상품 및 서비스명 작성
담당 개발 부서 : 개발 담당 부서
담당 개발 파트(장) : 개발 담당 파트
테스트 버전 : 테스트 요청 버전(1.0.0.b1 ~)
배포 버전 : 출시 버전(1.0.0)
테스트 가이드 정보 : 테스트 시 도움이 될만한 정보 입력(영향 범위 등)
테스트 요청일 : 테스트 요청 일자
심사 등록 희망일 : 오픈마켓의 경우 심사 등록 희망일자 작성
배포 예정일 : 배포 예정일자 작성
배포 시간 : 예정된 배포 시간 작성(배포 담당자 조율 필요)
개발 담당자 : 관련 개발자 모두 입력
배포 마켓 : 배포되는 마켓 모두 선택
검수 파일 : 빌드 파일 차수별 링크 생성(직접 첨부 X)
개발 대상 전체 목록 : 해당 버전에 수정된 모든 Jira 이슈 목록 필터
n차 - 테스트 목록 : 요청 건수 입력 및 라벨 QA1차 입력 후 Jira 이슈 목록 필터

테스트 수행

화면 설계서 기준 테스트 케이스를 Zephyr 작성 후 해당 개발 아이템 링크
Jira 이슈 등록(결함, 개선 항목 등)
빌드 버전 별 테스트 사이클을 구성하여 테스트 수행
이슈(개발 아이템) 확인 테스트 > 요구 검증 > 리그레이션 테스트 > 세니티 테스트

Guru99 스모크 테스트와 세니티 테스트의 차이

테스트 결과

1. Confluence([신규 출시] 테스트 결과 보고서)를 통해 테스트 결과 공유

테스트 수행 결과 요약
테스트 완료 - 품질 지표 달성 요약(인수 기준 부합 여부)
해당 버전에 확인한 전체 이슈 목록
잔여 결함 목록
테스트 케이스 수행 현황
등록 대비 해결(번업 차트)

2. 테스트 완료 시 배포 Task 생성 후 배포 여부를 Jira 이슈를 통해 공유
3. 메일로도 배포 여부 공유(유관 부서 및 관련자 포함)
4. [대시보드] 품질관리 메인 홈에서 배포 현황 확인

크몽: 테스트 문서 관리 패키지

문서 작성이 어렵거나 테스트 템플릿이 필요하신 분들은 멘토링(크몽 서비스)을 이용해 보세요

실무 적용 QA 테스트 프로세스 관리 문서 패키지 - 크몽

품생품사 전문가의 자료·템플릿 서비스를 만나보세요. "테스트 부업으로 수익 1...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, sw 모바일 테스트

[실무 - Chap.3] 지라(JIRA) 프로세스 간단하지 않지만 복잡하지 않게 구축하는 방법!!

품생품사(品生品死) — Tue, 4 May 2021 00:15:09 +0900

Jira의 워크플로우 = 프로세스

지난 글까지는 이슈가 무엇인지에 대해서 알아보았습니다. 다시 요약하자면 JIRA에서 "이슈 = 해야 할 일"이고, JIRA에서 "프로젝트 = 이슈의 모음"이라는 점만 잘 기억해 주시면 아래의 내용을 이해하시는데 도움이 될 것입니다.

프로세스 구축은 건물을 잘 만들기 위한 초석이다

이 전 글을 읽어 보지 않으시고, 아래의 개념을 이해하려고 하시면 좀 어려울 수 있는 부분입니다. "난 JIRA의 이슈와 프로젝트에 대해서 조금은 알아" 하시는 분들은 자연스럽게 아래 글을 읽어 보시길 바랍니다.

[실무 - Chap.2] 지라(JIRA) 프로세스를 체계적으로 구축하기 위한 방법 공유!!

qa-testing.tistory.com

이번 시간에는 작업 흐름. JIRA에서는 Work Flow라고 하는 것을 알아보려 합니다. 이것은 JIRA의 꽃 중의 꽃이며, JIRA를 왜 BTS(Bug Tracking System)으로만 쓰는 것이 아까운지 이유가 바로 이 Work Flow에 있습니다. JIRA에서 Work Flow란 바로 이슈의 흐름을 이야기합니다. "이슈 = 해야 할 일". 그렇다면 Work Flow는 바로 "해야 할 일의 흐름"을 이야기합니다.

프로젝트 측면에서 Work Flow는 프로세스. 혹은 절차를 의미합니다. 약간 말장난 같지만 의미가 크게 다르다는 것을 유념해 주세요. 프로젝트의 Work Flow는 큰 의미로 착수부터 프로젝트의 종료까지의 프로세스를 의미하고, 세부적으로 산출물이 만들어지기까지의 일련의 절차를 의미합니다.

JIRA에서의 Work Flow는 개발을 하기 위한 나의 할 일의 흐름이 바로 그 차이입니다. 개발물을 산출물이라고 생각하면 프로젝트의 세부적인 프로세스라고 말할 수도 있습니다. 사실 크게 중요하지 않습니다. 그냥 알아만 주시면 됩니다.

작업 흐름(Work Flow)이 필요한 이유가 무엇입니까?

그렇다면 JIRA에서 Work Flow가 필요한 이유는 무엇일까요? Work Flow가 필요한 이유는 내가 할 일의 길을 정해 놓는 것입니다. 만약, 내가 할 일의 흐름이 정해져 있지 않는 경우를 상상해 보세요. 내가 버그의 이슈를 하나 등록했다고 가정해 봅시다. 근데, 버그의 다음 담당자로 인사팀 직원이 가져갔다고 해봅시다. 이슈가 처리될 수 있을까요?

이슈는 처음에 말씀드렸듯이 해야 할 일인데 하지 못하는 일이 되는 것입니다. 그래서 이슈는 명확한 흐름을 가져야 합니다. 그것을 JIRA에서는 Work Flow라고 명명하고 있습니다. 아래는 다양한 Work Flow 예시입니다.

JIRA 시스템 내에 다이어그램을 통해 아주 쉽게 작성 가능합니다. 제가 개인적으로 생각해 봤을 때 PPT 도형 넣고, 직선 연결할 줄 알면 누구나 할 수 있을 정도의 UI/UX를 가지고 있습니다. 다이어그램뿐만 아니라 텍스트 목록으로도 구성이 가능합니다. 하지만 사람은 그림에 눈이 먼저 가고, 이해하기 쉽기 때문에 다이어그램으로 Work Flow를 그려보시는 걸 추천드립니다.

이 글에서는 도구 사용법에 대해서는 자세히 설명드리지 않습니다. 워낙 공식 홈에 자세하게 설명되어 있으며, 다른 많은 블로거나 사용자 분들이 올려놓은 글이 많기 때문인데요. 찾아보시면 정말 상세하게 설명을 잘해두었으니 여기서는 도구에 대한 사용법은 최대한 줄여서 말씀드리겠습니다.

작업 흐름(Work Flow)을 만들기 전에 무엇을 해야 합니까?

Work Flow는 앞에서도 잠깐 언급했듯이 할 일의 흐름이기 때문에 말 그대로 할 일의 흐름을 만들어야 합니다. 하지만 먼저 선행되어야 할 것은 할 일의 구분 바로 "이슈의 유형"을 먼저 만들어야 합니다. 이슈의 유형은 보통 프로젝트를 생성하면 기본적으로 JIRA 시스템에서 만들어 주고 있습니다.

기본적으로 만들어지는 이슈의 유형

보통은 위와 같이 만들어집니다. 하지만 이것은 정해진 것이 아닙니다.

지금부터가 중요합니다.

이슈 유형은 곧 할 일의 구분. 그렇다면 할 일의 구분을 어떻게 만들어야 할까요?

내가 하는 일만 구분해서 난 QA니까 버그와 개선사항만 있으면 될까요?

이렇게 생각하셨으면 JIRA를 BTS로만 쓰겠다고 생각하는 것입니다.

이것은 조금만 다르게 생각해서 내가 출근했을 때부터 일상의 모든 일을 이슈 유형으로 구분해 봅시다.

예시 하루 일과	이슈 유형	설명
출근	작업(Task)	일상적 업무
오전 미팅	미팅(Meeting)	회의
A 프로젝트 일정 수립	작업(Task)	일상적 업무
B 프로젝트 테스트	테스트, 버그, 개선사항	테스팅
점심 시간	작업(Task)	일상적 업무
B 프로젝트 테스트 결과 작성	테스트	테스팅
B 프로젝트 배포	배포(Release)	출시 업무
퇴근	작업(Task)	일상적 업무

위 표에서 가장 중요한 것은 바로 할 일들을 카테고리화 해야 하는 것입니다.

회사는 여러 부서 그리고 수많은 사람들이 존재합니다. 또한, 부서별 하는 일도 다르고 원하는 것도 다르고, 명확하게 하는 일들이 다릅니다. 이것을 카테고리화 다른 말로 하면 통합을 해야 합니다. 이것은 굉장히 어려운 일입니다. 부서별 하는 일에 대한 분석을 필수적으로 해야 하며, 요구하는 바도 다르기 때문에 지속적으로 개선해야 하는 부분입니다. 그리고 이것을 하기 위해 사용되는 문서는 바로 R&R 정의 문서입니다.

JIRA를 처음 도입하고, BTS로밖에 사용하지 못하는 이유는 바로 하는 일을 카테고리화 하지 못하고, 유형을 통합할 수 없기 때문에 어쩔 수 없이 상황이 만들어지는 것입니다. 큰 비용을 들여 구매하였지만 아는 사람도 없고, 어떻게 해야 할지도 모르겠고, 컨설팅 회사에서 알려주는 것이라고는 시스템 사용법뿐이고, 초기 구축 후 유지보수는 어떻게 해야 하는지도 모르는 상황들이 빈번하게 발생하는 것입니다.

이슈 유형을 카테고리화 하게 되면, 할 일의 흐름을 정의할 수 있게 됩니다. 정의가 완료되면 작업 or 업무(Task) 이슈로 50% 이상의 사람들이 아래와 같이 이슈를 사용하게 될 것입니다.(예시)

할 일 ➡ 작업 중 ➡ 작업 완료 ➡ 이슈 종료

정리하면, R&R을 확인할 수 있는 문서와 인터뷰 등의 활동을 통해 각 부서의 업무 흐름을 분석하고, 카테고리화 하고, 카테고리화 된 이슈의 유형을 가지고, Work Flow를 만들어야 하는 것입니다.

그렇게 해서 만들어지는 이슈의 유형은 아래와 같습니다.

업무 분석을 통한 이슈 유형 정의

작업 흐름은 어떻게 사용해야 합니까?

앞에서 이슈(할 일)에 따라 카테고리화 한 작업 흐름은 어떻게 사용해야 할까요? 이때부터는 앞에서 잠깐 언급한 프로젝트의 프로세스에 적용하게 됩니다.

아래는 예시입니다.

최초 이벤트	액션	판단	분기	결과
ITSM VOC 접수	VOC 분석	개발 필요?	OK	개발 작업 흐름으로 이슈 처리
ITSM VOC 접수	VOC 분석	개발 필요?	NO	VOC 코멘트로 이슈 처리

위와 같이 하나의 이벤트를 프로젝트의 프로세스에 태워서 분기를 통해 작은 작업의 흐름으로 사용을 해야 합니다. JIRA 사용의 가장 큰 목적은 바로 "개발을 잘하기 위함"입니다. 필요에 따라 ITSM으로 구축할 수도 있지만 현재 글은 ITSM 구축은 아니고, BTS로 사용하기에 아까운 JIRA에 대한 설명임을 알고 글을 읽어 주시기 바랍니다.

이렇게 작은 작업의 흐름을 통해 세밀한 작업을 할 수 있게 되고, 세밀한 작업을 통해 일정 관리가 가능해지며, 일정 관리를 통해 베이스라인(데드라인)에 맞춰 개발을 할 수 있을지에 대한 것을 예측할 수도 있게 됩니다. 이 내용도 나중에 자세히 다뤄 보도록 하겠습니다.

또한, 너무 복잡하게 작업 흐름을 구축하게 되면, 하나의 이슈를 처리하는 데까지의 시간이 너무 오래 걸리기 때문에 이슈의 처리율은 분석이 가능하지만 프로젝트(이슈의 집합)의 관점에서는 이슈 하나 처리하는데 왜 이렇게 시간이 오래 걸리는지 의문을 가질 수도 있습니다.

제 경험상으로는 하나의 이슈에 5~10(리오픈을 포함) 스텝이 가장 적절하다고 생각됩니다.

작업 흐름의 기본적인 구성은 아래와 같습니다.

할 일(Open) ➡ 진행 중(In Progress) ➡ 완료(Done) ➡ 이슈 종료(Closed)

여기서 진행 중과 완료는 1 Set로 생각하시고 작업 흐름을 작성해야 합니다.

할 일(Open) ➡ A 진행 중(In Progress) ➡ A 완료(Done) ➡ B 진행 중(In Progress) ➡ B 완료(Done) ➡ 이슈 종료(Closed)

상태 값과 버튼명 예시

위와 같이 구성하는 이유는 완료된 Task를 다음 담당자가 완료되었구나를 알리기 위함이고, 이것은 스크럼/칸반 보드를 만들 때 유용하게 사용됩니다.

최초 분석된 프로세스를 JIRA의 다이어그램(or 목록)으로 작업 흐름을 만들어야 합니다.

1. ➡ 부분 : JIRA 이슈 상단 버튼명으로 정의됩니다.

2. 상태 값 : JIRA 이슈의 상태명으로 정의됩니다.

JIRA 이슈에서 버튼명과 상태 값 예시

여담으로 JIRA의 가장 큰 장점이 바로 확장성이기 때문에 내가 생각하는 그 어떤 프로세스(우선 제가 생각했던 건 다 그릴 수 있더라고요)도 시스템적으로 구축 가능하도록 되어 있습니다. 문제는 Money죠. 회사에서 Money를 마음대로 사용하지 못하기 때문에 한 번 구축할 때 필요로 하는 부분을 잘 분석하시어 초기에 견적을 내는 것도 중요합니다.

분석 관련 글은 #1을 참고하시기 바랍니다.

[실무 - Chap.1] 지라(JIRA)를 활용하여 효율적인 프로세스를 구축하기 위한 방법 공유!!

qa-testing.tistory.com

요약 - 작업 흐름을 통합할 수 있도록 이슈를 카테고리화 해야 한다.

이번 챕터에서 가장 중요한 것은 다양한 작업의 흐름을 카테고리화 하여 이슈(할 일)의 목록으로 정의하는 것입니다.

위에 주저리 많이 작성하긴 했지만 이것만 기억하시면 됩니다.

JIRA를 사용하는 데 있어서 가장 중요한 부분이며, 아마 가장 어려운 부분이기도 합니다. 이때부터 JIRA 사용자들의 불만과 불평 그리고 "못. 쓰. 겠. 다."와 싸움의 시간이 찾아올 것입니다.

"우리 프로세스 JIRA로 못 만들겠네?", "우리 이런 거 필요한데 없던데?" 등 새로운 것에 적응하지 못하는 사람들이 수면 위로 올라올 텐데요. 이때부터는 "이 사람들을 교육하고, 설득하느냐.", "나도 모르겠다. 대충 쓰자" 하는 기로에 서게 될 거예요.

이제 시작입니다. 지금까지 잘해 주셨습니다. 포기하지 마시고, JIRA를 잘 사용하여 개발이 잘 될 수 있도록 끝까지 힘내시길 바랍니다.

Jira를 활용해서 프로세스 구축을 위해 도움이 필요하시다면 크몽의 제 서비스를 이용해 보시길 바랍니다.

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

품생품사 전문가의 IT·프로그래밍 서비스를 만나보세요. <strong s...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스

[실무 - Chap.2] 지라(JIRA) 프로세스를 체계적으로 구축하기 위한 방법!!

품생품사(品生品死) — Tue, 20 Apr 2021 00:21:50 +0900

시스템 활용을 위한 최소한의 공통 기능 정의

이전 글에서는 JIRA를 도입하기 전에 무엇을 준비해야 하는지 알아보았습니다.

앞으로의 글은 JIRA의 기능 설명이 아닌 정말 프로젝트를 만들고 어떻게 설정해야 하는지에 대해 효율적인 방법을 제안하고, 수많은 프로젝트를 어떻게 관리해야 하는지에 대한 방안을 말씀드리려 합니다.

JIRA를 잘 활용하기 위해서 기능을 정의하자

현재 글을 이해하고, 적용하기 위해서는 꼭 이전 글을 읽어 보시고 이 글을 읽어 보시길 바랍니다.

[실무 - Chap.1] 지라(JIRA)를 활용하여 효율적인 프로세스를 구축하기 위한 방법 공유!!

qa-testing.tistory.com

이슈? 이거 꼭 만들어야 하나요?

보통 이슈란? 논점(論點) 또는 논쟁점. 순화어는 `논쟁거리', `쟁점', `논점'. 혹은 이벤트 성 심각도가 높은 활동을 의미합니다.

그렇다면 JIRA에서 이슈란 무엇일까요?

간단하게 설명하면 내가 해야 할 일을 구분해 놓은 것이 바로 이슈입니다.

예를 들면, "내가 개발을 해야 해 ~" 그럼 "신규 아이템"이라는 이슈 유형으로 이슈를 등록하고, 개발을 시작하게 됩니다. 이때, 이슈에는 많은 정보들을 입력하게 됩니다. 이 것은 차차 알아보도록 할 것이고, 이렇게 이슈들이 쌓이고, 모이게 되는 것이 바로 JIRA에서는 프로젝트라고 할 수 있습니다.

결론적으로 JIRA에서 프로젝트란? 이슈들의 모임이고, 이슈는 내가 할 일이라고 할 수 있습니다. 3단 논법으로 풀이하면 내가 할 일을 모아놓은 것이 프로젝트라는 결론을 얻을 수 있습니다.

이렇게 생성되고, 만들어진 이슈들(여기서 들은? JIRA에 백로그라 불립니다.)을 하나씩 해결해 나가면서 모든 이슈를 해결했을 때 비로소 프로젝트가 완료되는 것입니다. 이러한 이슈들을 해결해 나가는 방법으로 스크럼✔과 칸반✔이라는 방법론을 사용하게 되고, 이슈들(할 일들)은 유형을 분류하여 작업을 하게 되는 것입니다.

스크럼 프로세스

구분	스크럼	칸반
기간	기간이 고정된 이터레이션✔을 규정한다.	기간이 고정된 이터레이션은 선택사항.
약속	팀이 이터레이션에서 할 일의 양을 결정, 약속한다.	약속은 선택사항이다.
지표	계획하기와 공정 개선에 속도(velocity)를 기본 지표로 사용한다	리드 타임을 기본 지표로 사용한다.
팀	교차 기능 팀을 규정한다	교차 기능 팀은 선택사항, 전문가 팀도 허용한다.
아이템 크기	아이템들을 한 스프린트 안에 완료될 수 있을 정도의 크기로 잘게 쪼개야만 한다.	아이템 크기를 특별히 규정하지 않는다.
차트	번다운 차트를 규정한다.	차트 사용 규정 없다.
WIP	WIP 리밋을 간접적으로 한다.(스프린트마다)	WIP 리밋을 직접적으로 한다.(작업 흐름 단계마다)
추정	추정을 하도록 규정한다.	추정은 선택
아이템 추가	이터레이션이 진행 중일때는 아이템 추가 불가.	수용 능력이 허용한다면 새로운 아이템을 추가할 수 있다.
보드 소유	스프린트 백로그는 특정 팀이 소유한다.	칸반 보드는 다수의 팀이나 개인들 간에 공유하기도 한다.
역할	세가지 역할을 규정. (제품 책임자, 팀, 스크럼 마스터)	어떤 역할도 규정하지 않는다.
보드 초기화	이터레이션마다 스크럼 보드 초기화	칸반보드는 계속 유지
우선순위	제품 백로그에 우선순위를 정의할 것을 규정한다.	우선순위 정의하기는 선택 사항이다.

이터레이션은 어떤 객체의 원소에 하나씩 차례로 접근하는 것. 명시적으로든 암묵적으로든 반복문을 사용해 객체의 여러 원소에 하나하나 접근하면 그것은 이터레이션(iteration)이다.

어려운 용어들이 많이 나오지만 궁금한 용어는 구글링을 통해 알아보시고, 스크럼과 칸반의 가장 큰 차이점은 Time Boxing✔이 있고, 없고의 차입니다.

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

엔터프라이즈 애자일 개발에 대한 블로그입니다.

www.moreagile.net

JIRA가 처음 도입되고 나면 모든 사람들이 가장 어려워하는 부분이 바로 이슈를 만드는 것이라고 해도 과언이 아닙니다. 정말 필수 입력 값이 요약(제목)만임에도 불구하고, 그거조차도 어렵다고 하는 사람들이 많습니다.

이슈를 귀찮아하거나 만들지 않겠다고 하는 사람들의 유형은 아래와 같습니다.

이슈 만들 시간에 개발을 더 해야 한다.
이슈에 무엇을 작성해야 할지 모르겠다.
이슈를 등록하려고 보니 입력할 필드가 너무 많아서 모르겠다.
이슈는 만들었는데 이것 어떻게 써야 할지 몰라서 방치하게 되었다.

정말 다양한 케이스가 존재하지만 이슈는 처음에도 말씀드렸듯이 내가 해야 할 일을 글로 쓰는 것과 마찬가지이며, 내가 쓴 글(할 일 = 이슈)을 동일 프로젝트 혹은 JIRA 시스템을 사용하는 모든 사람들과 공유하는 것이 목적인 것입니다.

그럼 또, "난 내가 하는 일 남에게 알리고 싶지 않습니다."라고 하는 분들도 있을 겁니다. "같이 일을 하고 있지만 제가 하는 일은 너무 보안 등급이 높아서 다른 사람들이 알면 안 됩니다."라고 하는 분들을 위해 정말 미친 듯이 세밀한 권한 관리가 가능하기 때문에 해당 팀원 혹은 파트원들끼리라도 관리를 위해 JIRA를 사용하게 만들면 됩니다.

결론적으로 마음만 먹으면, 혹은 의지만 있다면 전 직원이 사용 가능한 시스템이 바로 JIRA인 것입니다.

이렇게 얘기하면 제가 아틀라시안 직원인가? 하실 분들도 있으실 거 같지만 잘 찾아보시면 제 프로필이 여기저기 뿌려져 있습니다. 참고로 제 도메인은 교육 업계이고, QA를 하면서 JIRA를 사용하고 있을 뿐이라는 점 다시 말씀드립니다.

오해 없으시길 바라고, JIRA를 좀 더 효율적으로 사용하고 싶은 분들께 도움이 되고자 글을 쓰는 것이니 필요하 신 분들만 읽어 주시길 바랍니다.

이슈 유형? 이것도 알아야 하나요?

네 알아야 합니다.

이슈 유형은 앞에서도 말씀드렸듯이 내가 할 일을 카테고리화 해놓은 목록이라고 생각하시면 됩니다.

예를 들면 아래와 같습니다.

No	이슈 유형	설명
1	디자인 아이템	디자인 작업을 위한 이슈
2	신규 아이템	신규 개발을 위한 이슈
3	개선 항목	기존 기능에 대해서 개선을 위한 이슈
5	작업	업무 관리용 이슈
6	부작업	작업을 완료하기 위해 세분화된 작업 이슈

위 항목들은 예시입니다. 당연히 이슈 유형은 커스터마이징이 가능하며, 필요에 따라 다양한 이슈 유형을 생성할 수 있습니다. 현재 제가 하는 일은 테스트, 작업, 부작 업, VOC, 배포 등의 R&R을 가지고 있는데 모든 항목은 이슈 유형으로 구분하여 사용을 하고 있습니다.

이슈 유형을 구분했는데 어떻게 사용되는 거예요?

이번 시간은 여기까지 말씀드리고 마무리하겠습니다.

결론적으로 이슈 유형에 따라 업무 흐름이 달라지게 됩니다.

예를 들면 아래와 같습니다.

No	이슈 유형	업무 흐름
1	디자인 아이템	할 일 > 작업 중 > 작업 완료 > 검토 중 > 수정 중 > 수정 완료 > 이슈 종료
2	신규 아이템	할 일 > 분석 중 > 개발 중 > 개발 완료 > 테스트 > 이슈 종료
3	개선 항목	신규 아이템과 동일한 업무 흐름
5	작업	할 일 > 작업 중 > 작업 완료 > 이슈 종료
6	부작업	작업과 동일한 업무 흐름

내가 할 일이 어떠한 업무 흐름을 타고 진행되는지 이슈 유형별로 구분 가능하며, 업무 흐름도 맞춤형으로 생성이 가능합니다. 여기서 중요한 점은 이슈 유형이 생성되어 있어야지만 업무 흐름을 생성할 수 있고, 생성된 업무 흐름은 이슈 유형에 매핑시킬 수 있다는 것을 알아 두시길 바랍니다.

기본적으로 프로젝트를 생성하면 이슈 유형과 업무 흐름을 JIRA 시스템 내부적으로 자동 생성을 해주고 있습니다. 자동 생성된 것을 고쳐서 사용하는 것도 편할 수 있겠지만 필자가 추천하는 방법은 모든 설정 항목들을 수정하고, 향후 카테고리 화하여 모듈식으로 사용할 수 있도록 만드는 것이니 다르다는 점을 기억해 주시길 바랍니다.

대신 이렇게 모듈화를 하게 되면 기존 자동 생성되는 부분들은 쓰레기 값이 돼서 매번 수동 삭제를 해줘야 한다는 불편한 점도 존재합니다. 참고하세요.

요약 - 이슈가 무엇인지? 이슈를 왜 만들어야 하는지 인식을 변화시켜야 한다.

위에 길게 작성하였지만 분석 활동이 끝나고 JIRA가 도입되었다면 아마도 컨설팅 업체에서 사용법에 대한 교육을 한 두 차례 진행하였을 겁니다.

하지만 실 사용자들은 멘붕이 와 있겠죠? 그래서? 어떻게 쓰라는 건데?

다 똑같이 들었지만 아무도 모르는 이상한 현상이 발생하게 됩니다.

이유는 하나입니다. 그들은 이슈를 왜 만들어야 하는지 모릅니다. 이슈를 만들어서 쓰라는데 이슈를 왜 만들어야 하는지 모르니 왜 해야 하는지를 모르게 되는 것입니다.

그래서 시스템이 도입되고, 어느 정도 기본 교육이 되었다면, 이슈를 왜 만들어야 하는지에 대해서 캠페인을 해야 합니다. "할 일이 생기시면 이슈를 만들고, 작업을 시작하세요." 혹은 "이슈 하나 만들어서 담당자에게 할당하세요."의 캠페인을 모두가 용인할 때까지 해야 합니다. 이 시간은 정말 오래 걸릴 수도 있고, 의지가 있는 조직이라면 금방 될 수도 있습니다.

가장 좋은 건 역시 탑다운. 위에서 바로 "JIRA 잘 써라. JIRA 데이터로 평가할 거다." 하면 위에 활동이 매우 쉬워질 것입니다.

한 줄 결론을 말씀드리면, "이슈는 곧 내가 할 일이고, 이슈를 모아 놓고, 쌓아 놓은 것이 바로 프로젝트다." 첨언하면, "그래서 이슈를 모두 해결하면 프로젝트를 종료한다."로 말씀드릴 수 있을 것 같습니다. 이슈를 모아놓고, 혹은 쌓아 놓은 것이 JIRA에서는 백로그라는 개념으로 사용되는데 이것은 애자일을 공부하시면 알 수 있는 개념이니 따로 설명드리지 않고, 링크 하나 남겨 놓도록 하겠습니다.

백로그 개념도

JIRA 관련 도움이 필요하시면 아래 크몽에 등록된 제 서비스를 이용해 보세요.

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

품생품사 전문가의 IT·프로그래밍 서비스를 만나보세요. <strong s...

kmong.com

스크럼의 진행 과정

■ 스크럼이란?

medium.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스

[실무 - Chap.1] 지라(JIRA)를 활용하여 효율적인 프로세스를 구축하기 위한 방법!!

품생품사(品生品死) — Sat, 17 Apr 2021 00:36:48 +0900

Jira를 추천하는 이유?

IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. 개발자던 QA이던 구인 공고 단골 Job Description이기도 합니다.

거의 공통적인 JD

보통 기업 혹은 개인이 JIRA를 사용한다고 하면 BTS(Bug Tracking System)로 많이 사용을 하고 있습니다.

하지만 JIRA Software는 단편적으로 BTS로만 사용하기에는 너무도 아까운 시스템이기 때문에 버그 트래킹뿐만이 아니라 실제로 실무에서 확장성 있게 어떻게 적용을 해야 하는지에 대해서 말씀드리고, 어느 부분부터 적용하는 것이 효율적인지에 대해서 말씀드리려 합니다.

지라 시스템을 이용한 프로세스 구축

아래 글은 필자가 경험한 10여 년 간의 경험을 바탕으로 작성되었으며, 정답은 아닙니다.

조금이라도 아래와 같이 적용을 생각해 보셨거나 하고자 하는 의지가 있으시다면 꼭 실천해 보시기 바랍니다. 개발 프로세스 품질이 좋아질 것이고, 출시 후 품질도 향상되실 겁니다.

개요 - 우린 BTS로만 쓰려고 Jira 구입한 것은 아닌데?

이미 아틀라시안에서는 가장 효율적인 프로세스를 하나의 이미지로 설명하고 있습니다. 아래와 같이만 구축하고, 프로세스가 잘 수행되고, 정책도 잘 지켜진다면 따로 얘기하지 않고도 개발 품질이 정말 좋아질 겁니다. 왜? 아틀라시안의 수많은 전문가들이 아래와 같이 쓰라고 권장했기 때문이죠.

아틀라시안에서 권장하는 시스템 구축도

추천하는 도구는 Confluence, Jira, Bitbucket, Bamboo 4가지입니다.

간단하게 요약해서 말씀드리면 Confluence는 보통 산출물이나 보고서, 커뮤니케이션을 위한 도구이고, Jira는 프로젝트를 관리하고, 이슈를 트래킹 하기 위한 도구입니다. Bitbucket은 형상을 관리하기 위한 도구이며, Bamboo는 빌드를 관리하기 위한 도구라고 생각하시면 됩니다.

위와 같이 권장함에도 적용하지 못하는 이유는 보편적으로 아래와 같습니다.

비용적인 문제
도구 사용법의 문제
시스템 도입 후 운영 문제

Jira를 도입하기 위해서는 우선 돈이 필요합니다. 딱 잘라서 250 user로 Confluence / Jira만 사용하게 되더라도 VAT 포함 1억(Data Center / Cloud / Server(2021.03 서비스 종료) 정도 생각하시면 됩니다. 도입 환경과 밴더사 별로 가격의 차이가 있음은 감안해 주세요.

또한, 도구를 도입하고 밴더사로부터 교육을 받았지만 막상 사용을 하려고 보니 막막하기만 합니다. 이게 현실입니다. 회사에 아무도 사용해 본 사람이 없습니다.(저희 회사 같은 경우 100명 중 사용 경험자 저를 포함해 2명) 좀 극단적인 예시 기는 합니다.

시작도 못했는데 운영을 하려니 더더욱 막막해집니다. 무엇부터 손을 대야 하는지 알 수도 없습니다.

그나마 이슈 만들고, 밴더사에서 만들어준 워크플로우대로는 사용이 가능하니 결국은 BTS로 밖에 사용하지 못하는 상황이 발생하는 것입니다.

접근 - 무엇을 먼저 시작해야 할까?

가장 먼저 해야 할 일은 분석입니다.

분석이라고 해서 엄청 거창하거나 그런 일은 아닙니다.

Jira를 통해 무엇을 할지부터 명확히 해야 합니다.

그러기 위해서는 기존의 프로세스에서 무엇을 사용하고 있었는지 어떤 점들을 Jira에 녹일 것인지를 정리해야 합니다.

Jira 도입 전 프로세스를 분석하고, 필요한 구성 요소를 정리

현재 프로세스를 분석해서 Jira로 구축을 했으면 하는 부분들을 엑셀에 정리하였습니다.

크게는 사용자 / 이슈 유형 / 워크플로우 / 해결책이고, 가장 중요한 부분은 이슈 유형의 정리입니다.

지금까지 여러 부서와 협업을 했기 때문에 어느정도는 무슨일을 하고 있는지 알고 계실겁니다. 그것을 추상화 개념으로 정리를 하는 것인데요.

이슈 유형은 TASK 즉, 담당자가 할 일을 구분해 놓은 구분자로 예를 들면, 개발자가 신규 기능을 개발해야 한다면 이슈 유형으로 "신규 아이템" 등과 같은 이슈 유형이 존재해야 하는 것입니다.

앞으로 이슈 유형은 워크플로우라는 프로세스를 탈 것이며, 프로세스 간 상태 별 다른 화면을 볼 것이고, 최종적으로 이슈가 종료되기까지 어떠한 과정을 거치는지에 대해서 확인하게 될 것입니다. 이번 시간은 개요이기 때문에 이슈 유형에 대해서는 다음 글에 상세히 설명드리도록 하겠습니다.

또한, Jira는 굉장히 논리적인 시스템으로 A를 만들기 위해 A-1, A-2가 등록되거나 작성되어 있지 않으면 A를 만들 수 없게 되어 있습니다. 반대로 이야기하면 A를 지우기 위해서는 A-1과 A-2를 삭제 후에 A를 삭제할 수 있다는 이야기도 됩니다.

유효성✔이 아주 강하게 적용된 시스템이라 생각하시면 됩니다.

"유효성(validation)"이란 특정 요구사항이 충족되었다는 것을 객관적 증거의 조사 및 제공에 의해 확인하는 절차를 말한다.

대략적으로 기존 프로세스에 대해서 분석하고, 필요한 요소들이 정리되었다면 시스템을 어디에 적용할지 범위를 정리합니다. 전 간단하게 도식화했습니다.(아틀라시안에서 권장하는 영역을 조직에 맞게 도식화)

팀별 시스템 적용 범위

위와 같이 범위까지 정리되었다면 첫 번째로 정리한 이슈 유형들을 어떻게 사용할지 정리를 해야 합니다. 처음 Jira를 도입하게 되면 이슈에 대한 개념도 그냥 이벤트로만 생각할 수 있습니다. 내가 할 일이 이슈라는 것을 먼저 인식시켜야 합니다. 교육을 통해서도 좋고, 정기적인 메일로 리마인드 해도 좋습니다. 전 교육도 진행하면서 개별적으로 알려 드리면서 인식시켰습니다.

이렇게 이슈에 대한 개념이 잡히게 되면, 기본적으로 사용하는 이슈 유형에 대해서 설명이 필요하게 됩니다. Jira 프로젝트를 생성하게 되면 기본적으로 큰틀(에픽) / 이야기 / 신규 아이템 / 버그 / 개선 사항 / 작업 / 부작 업이 생성되게 됩니다.

특히, 에픽과 이야기에 대한 이슈를 잘 모르는 경우가 많습니다. 사실 필수 항목은 아니기 때문에 꼭 써야 한다 이런 것은 아닙니다. 향 후 리포트에 대한 데이터를 정재 하기 위해서는 아주 좋은 정보로 유용하게 쓰일 수 있다는 것만 알고 계시면 좋을 것 같습니다. 자세한 설명은 이슈 유형 정리할 때 말씀드리도록 하겠습니다.

이슈 유형에 따른 포함 관계

위 도식은 요구사항이 이슈(할 일)로 만들어질 때 어떻게 만들어지는지에 대해서 표시해 둔 것입니다.

명세 1은 에픽 1로 만들어지는 건데요. 예를 들어 알려 드리도록 하겠습니다.

명세1	에픽 1	포함된 이슈(할 일)	이슈 상세 작업
로그인 기능 개발	로그인 기능	Story : 로그인 시나리오
		New Feature1 : ID 입력란	Task1 : 기능 개발 Sub-Task1 : DB 구성
		New Feature2 : Password 입력란	Task2 : 기능 개발 Sub-Task2 : DB 구성
		Bug : 로그인 버튼 안눌림

이렇게 요구 명세로부터 이슈들 간의 링크가 생성되게 되면 최종 산출물에서는 이슈들 간의 추적성이 생기게 되고, 요구 추적이라는 활동을 할 수 있는 환경이 구축되게 됩니다. 요구 추적이 왜 중요한지는 마지막 장에서 다루겠습니다.

요약: 현 상태를 분석하고, 무엇이 필요한지 정리하자.

Jira를 도입하기 전 위와 같이 정리하였고, 미리 공지하여 필요한 요소나 플로우가 있는 경우 회신을 달라고 요청하였습니다. 사실 Jira를 사용해 보지 않은 조직은 몰라서 무엇을 요청해야 할지도 모르는 상황이 대부분입니다. 부담 없이 "앞으로 이런 거 할 건데 필요한 것 있으면 얘기해" 정도의 가볍지만 가볍지 않은 메일을 공유하시기 바랍니다.

위의 정리한 정보들은 정답은 아니고, 정확할 필요도 없습니다.

참고할 만한 수준으로 작성하시길 바라며, 이후 진짜 시스템에 내용을 적용할 때는 실 사용자들에게 이슈 유형(할 일)에 대한 요구사항을 취합✔하여 어떤 부분이 필요한지 피드백을 받아야 합니다.

이슈 유형에 대한 요구 사항 취합 : 담당자들이 무슨 일을 하는지에 대해 조사하고, 카테고리화 하여 이슈 유형으로 정리해야 합니다.

이제 시스템을 도입하기 전까지 준비작업이 완료되었습니다.

다음 글에서는 정리된 내용을 시스템에 어떻게 적용하였는지에 대해서 설명드리도록 하겠습니다.

JIRA를 활용하고자 고민하고 계신다면 아래 크몽 서비스를 이용해 보세요.

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

품생품사 전문가의 IT·프로그래밍 서비스를 만나보세요. <strong s...

kmong.com

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스, jira, 업무 프로세스 관리

[실전 이력서 예시] 'SK 이노베이션' 서류 지원 결과와 작성했던 이력서 공유!!

품생품사(品生品死) — Sat, 3 Apr 2021 22:48:56 +0900

SK 이노베이션 : 배터리 PI 부서

결론부터 말씀드리면 서류 탈락이었습니다. PI(Process Inovation) 영역은 제가 일하는 분야는 아니지만 도전하고 싶은 마음에 넣어봤는데 결과는 서류 탈락이었네요.

도전하고 싶은 직무가 있다면 가만히 있어서는 기회가 오지 않습니다.

꼭 지원해 보시길 추천 드립니다.

이번 이력서는 질문이 한 개뿐이었습니다. 블라인드 방식이라 사진 첨부도 없었습니다. 한개뿐인 질문이라도 체계적으로 자기소개서를 작성하는 습관을 길러 보세요. 서류 심사관이 내 자소서를 다 읽기만 해도 50%는 성공했다고 할 수 있습니다. 전략적으로 작성하시길 바랍니다.

대기업의 도전은 항상 용기가 필요하다

자소서 질문 : 본인의 전문분야를 명시하고, 보유한 기술 및 해당 분야 수행 경력/경험, 수준을 기술하여 주시기 바랍니다. (경력의 단순 나열은 지양, 본인의 차별적 전문성이 간결/효과적으로 드러나도록 작성하여 주시기 바랍니다.)

품질 관리 프로세스 구축 경험

최근 교원 크리에이티브에서 상품 약 150개, 앱/웹은 빌드 기준 약 250개에 대해서 품질 관리를 수행하고 있습니다. (구성원 : 저 포함 4명) 처음 입사 시 프로세스 및 품질 관리를 위한 시스템 등 아무것도 없는 상태였습니다. 당시 QA는 저와 기존에 QA 업무를 하던 인원 1명뿐이었습니다. 그래서 프로세스의 필요성을 먼저 알렸고, 보고를 통해 공신력을 얻은 후 프로세스 구축에 대한 수행을 시작하였습니다.

1) 품질 인식에 대한 변화를 먼저 공유하고, 배포하였습니다. 아무리 좋은 프로세스와 시스템이 있을지라도 인식의 변화가 없으면 무용지물이 될 수 있다는 것을 너무 잘 알고 있습니다.
2) 환경 분석(구성원들이 가장 잘 사용하고, 활용도 높은 도구)을 통해 구글 시트의 활용도가 높다는 것을 알게 되어 품질관리에 필요한 모수(테스트 케이스)를 화면설계서 및 요구사항 명세를 통해 작성하여 확보하였고, 테스트 케이스 수행을 통해 엑셀 자동 계산을 매트릭으로 만들어 정량적으로 품질을 확인 할 수 있도록 하고, 추가로 최소한의 입력으로 리포트가 가능하도록 하였습니다.
3) 메일을 통해 테스트 계획/요청/수행/결과에 대해 공유하도록 하였습니다.
4) 파일럿으로 프로젝트를 수행하는 팀부터 점차 프로세스가 자연스럽게 퍼지도록 하였습니다.
5) 보고서를 통해 기존과 현재를 비교하여 SW 품질이 얼마나 좋아졌는지 확인 시켜 드리고, 기안 승인을 통해 프로세스를 정립하였습니다.

품질 관리 프로세스 개선 업무 수행

품질 관리 프로세스와 품질 관리 시스템의 연계성

품질 관리 시스템을 통해 프로세스를 정립하고, 구축하는 것은 품질 경영을 위해 매우 중요한 요소라 생각합니다. 제가 가장 잘 사용할 수 있는 시스템 도구는 JIRA 시스템이고, JIRA의 전반적인 베이스 지식을 습득하고 있기 때문에 시스템을 사용하지 않더라도 필요시 구글 시트를 통해서도 품질 관리 프로세스를 구축할 수 있는 역량을 가지고 있습니다.

품질 관리 프로세스 외 구축 사례 - 테스트 자동화

1) 도메인에 가장 적합한 테스트 자동화 솔루션이 무엇인지 벤치마킹 조사를 수행했습니다.
2) 보고를 통해 테스트 자동화 솔루션을 선택하고, 컨설팅 업체와 미팅을 통해 장단점 매트릭스를 작성하였습니다.
3) 테스트 자동화 솔루션 구매 후 테스트 자동화 범위 및 시나리오 설계하고, 작성하였습니다.
4) 테스트 자동화 솔루션을 이용해 스크립트를 작성하고, 테스트 자동화를 구축하였습니다.
5) 기존 테스트 프로세스에 테스트 자동화를 추가하여 품질 관리 프로세스를 더 견고히 하였습니다.
6) 전사 발표를 통해 효과를 증명하고, 품질을 높이는데 기여하였습니다.

마지막 하고 싶은 말

제조의 경험이 많지 않아 "배터리 품질 관리 프로세스를 잘 구축할 수 있을까?" 걱정하실 수도 있을 것 같습니다. 전 품질 관리의 베이스는 하나이고, 경험이 풍부하다면 어떠한 조건이라도 최적의 프로세스를 구축할 수 있다고 생각합니다. 비스텔(반도체 관련), 메디트(치과/기공 관련) 회사에서 프로세스를 경험하였고, ITSM 시스템 구축 TF에도 참여한 경험이 있습니다. 또한, 다양한 도메인의 경험은 품질 관리 프로세스를 구축하는데 많은 도움이 되고 있습니다.

만약, SK이노베이션에 입사하게 된다면 최선의 노력을 다하겠습니다.
또한, 회사의 보탬이 되는 인재가 될 것을 약속드리고, 결실을 보여드리도록 하겠습니다.

서류 : 불합격

크몽: 멘토링

이력서 작성이 어렵거나 취업의 고민이 있으신 분들은 멘토링(크몽 서비스)을 이용해 보세요

소프트웨어 QA, Test에 대한 멘토링 해 드립니다. - 크몽

품생품사 전문가의 직무역량 레슨 서비스를 만나보세요. <strong s...

kmong.com

품생품사(品生品死)의 소프트웨어 품질 정보 창고

[개발] 소프트웨어 테스트 케이스(TC)를 의미 있게 작성하는 방법 공유!!

오프닝: 일상의 테스트는 정말 쉽지만 체계적인 테스트는 매우 어렵다

의미 있는 테스트 케이스를 작성하려면?

관련 참고 자료 및 서비스

[분석] 소프트웨어 테스트 케이스(TC) 작성 전 요구사항 문서 보는 방법 공유!!

오프닝: QA나 테스트 엔지니어도 개발자다

테스트를 위한 요구사항 문서를 보는 방법은?

관련 참고 자료 및 서비스

[준비] 쉽게 작성하고 빠르게 수행할 수 있는 테스트 케이스(TC) 작성하는 방법 공유!!

오프닝: 내가 하는 일이 세상에서 가장 힘든 이유는?

테스트 케이스를 작성하기 전 준비할 것 정리하기

관련 참고 자료 및 서비스

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

오프닝: QA의 역할과 책임에 대한 오해와 진실 풀어보기

테스트를 시작하기 위해서 꼭!! 준비해야 하는 항목들

관련 참고 자료

[준비] 프로젝트 종료까지 관리되는 테스트 계획서 작성하는 방법 공유!!

오프닝: 프로젝트를 준비하는 QA의 자세는?

오해가 풀리고 진실을 알게 되었을 때 테스트 계획서를 작성하는 방법

관련 참고 자료 및 서비스

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

오프닝: 테스트를 분석한다고? 무엇을 설계한다는 거야?

잡썰

본론의 시작

테스트 분석과 설계를 꼭 해야 하나?

관련 참고 자료 및 서비스

[기회] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 11년에서 12년 차)

오프닝: 기회라고 생각한다면 망설임은 사치일 뿐

나에게 왔던 '기회'라는 녀석은 노다지였다.

크몽: 멘토링

[난관] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 10년 차의 시작)

오프닝: 관리의 결과 = 성과

10년 차를 시작하면서 ~

크몽: 멘토링

[도약] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 9년 차 날아올라)

오프닝: 품질, 테스트 관리 업무의 첫 시작

9년 차 경력 사항

크몽: 멘토링

[성취] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 6년에서 8년 차)

오프닝: 품질, 테스트 관리를 선택한 나

6 ~ 8년 차? 경력 사항

크몽: 멘토링

[성장] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 3년에서 5년 차)

오프닝: 나의 길을 정해야 할 때

3에서 5년 차의 경력은?

크몽: 멘토링

[적응] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 2년 차는 거둘 뿐)

오프닝: 신입같은 중고 신입

2년 차 경력은?

크몽: 멘토링

[취업] QA, 테스트 엔지니어의 연봉 정보 공개!! (ft. 신입, 경력의 시작)

오프닝: 경력의 시작

0년 차 경력은? 그런게 있을리가? 아니다. 있었다!

1년 차의 경력은?

크몽: 멘토링

[테스팅] QA, 테스트 엔지니어와 개발자 하는 테스트는 왜 다른가?

개발자는 분명 테스트 했는데 QA가 테스트하면 로그인부터 안 되는 이유?

[상황]

[중략]

첫 번째 경우,

두 번째 경우,

관련 참고 자료

[테스팅] 테스트 자동화를 시작하려는 QA, 테스트 엔지니어들이 꼭 준비해야 하는 이것!!

테스트 자동화를 처음 구축 하기 위해 필요한 정보

본문 요약

관련 서비스

[영상] 추억이지만 좋은 경험이었던 유튜브 준비하기, 기획하기, 시작하기

유튜브를 시작하기 위한 준비 작업

내가 좋아하고, 잘하는 것이 무엇인지 고민해 본다

유튜브 공부를 시작해본다

장비를 준비한다

유튜브를 기획한다

프로필과 썸네일을 만든다

이제는 실전이다.

관련 서비스

[인포그래픽] 기억에 남는 이력서 작성하는 방법 공유!! (ft.캐리커처)

이력서 - 캐리커처형

컨셉 잡기

캐리커처 만들기