문성준의 단단해지기

오늘 포스팅할 내용은

나는 어떤 강점이 있는 QA 엔지니어일까? 

태크블로그에 작성했던 글에 대한 회고입니다.

https://tech.socarcorp.kr/qa/2023/05/15/qa-skills-marktang.html

올해 1월에 새로운 회사로 이직한 이후로, TECH 블로그에 글을 업로드하는 것은

제 목표 중 하나이자 작은 소망이었습니다.

.면접 때 블로그 운영 경험을 어필한 후,

수습기간 동안 TECH 블로그에 글을 작성하는 과제를 제안 받았고,

이를 위해 3개월 동안 글을 작성했습니다.

당연히 하루 종일 글만 작성한 것은 아니었고,

온보딩을 받고 업무도 진행하다 보니 글을 작성하는 기간이 길어졌습니다.

호기롭게 TECH 블로그에 등록될 글감을 작성하려고 보니, 주제는 어떻게 선정해야할지가 막막했습니다.

첫번째 : 주제 정하기

QA엔지니어로써 TECH 블로그에 주제를 정하기 위해 5가지의 큰 기준을 잡아봤습니다.

1. 관심 분야 파악:  자신이 관심 있는 기술, 도구, 프로그래밍 언어, 프레임워크 등을 파악합니다.

자신의 전문성을 강조할 수 있는 주제를 선택하여 독자들에게 정보를 공유하고 피드백을 받는 형태로 글감을 작성합니다.

2. 업계 동향과 트렌드: QA 시장에 최신 업계 동향과 트렌드를 파악합니다. 새로운 기술의 도입, 현재 시장의 트렌드, 미래에 대한 핵심기술을 선정하여 독자들과 토론하는 형태으로 글감을 작성합니다.

3. 문제 해결과 가이드: QA엔지니어 또는 Software엔지니어(Dev)가 자주 마주치는 문제를 해결하는 방법이나, 실용적인 가이드를 제공하는 주제를 선정하여 독자들에게 가이드를 전달하는 형태로 글감을 작성합니다.

4. 프로젝트 경험 공유: 자신이 진행한 프로젝트나 QA 경험을 공유하는 주제를 선정합니다. 프로젝트의 참여한 QA 엔지니어의 A to Z 를 공유하고, 어려웠던점이나 갈등이 있었던경우 어떻게 극복했는지 본인의 경험을 독자들에게 전달하여 공감대를 형성할 수 있드록 글감을 작성합니다.

5. 튜토리얼과 팁: QA 엔지니어가 사용하는 특정 기술이나 도구의 사용법을 소개하는 튜토리얼이나,  유용한 팁을 제공하는 주제를 선정합니다. 본인의 주관적인 생각도 좋지만 정보의 전달은 객관적으로 정확하게 전달되도록 글감을 작성합니다.

관심 분야, 문제 해결과 가이드, (프로젝트) 경험 공유

저는 이 3가지 기준을 잘 조합해서 글을 작성하기로 했습니다.

주제는 "QA 엔지니어로 어떻게 성장을 해야할까?" 로 말이죠!

두번째 : 대상 독자, 독자가 얻을 수 있는 내용 정하기

주제를 선정하였으므로 

이제 두번째는 내 글을 누가 읽어줬으면 좋겠고, 어떤 정보를 얻어가면 좋을지 고민해야 됩니다.

대상 독자에 맞게 어휘력, 단어 사용을 고려해야 합니다.

또한 누구나 아는 내용을 적는 양산형 정보글을 작성하는 건 개인 블로그에서 충분히 작성해왔으니.. 

독자가 얻을 수 있는 내용을 확실하게 정해야 합니다.

저는 위와 같이 대상 독자와 독자가 얻을 수 있는 내용을 정하였습니다.

세번째 : 글의 주요 내용은?

.주제와 대상 독자가 정해졌으니, 글의 주요 내용을 정해야 합니다. 

제 경험에서 발생한 문제를 먼저 공유해드리고, 이 문제는 독자들이 궁금해하고 관심있어하는 주제일 것입니다. 

또한, 문제 해결을 위해 어떻게 노력하고 있는지에 대해 글을 설계하으므로 

위의 인과관계가 물 흐르듯 자연스럽게 이어져야 읽기에도 편한 글이 될 것입니다.

머릿말 : redgate의 Test Engineering Skill Map (https://www.red-gate.com/blog/test-engineering-skills-map)을 참고하여 QA엔지니어는 어떤 Skill 을 향상시켜야 하는지 방향성을 제공해 줍니다.
(쏘카 QA팀도 해당내용을 참고하여 본인이 어떤 Skill이 부족한지 확인하고 장기적인 Skill up 목표를 세워 달려나갑니다.)
내가 QA엔지니어로써 어떤 부분이 부족한지 확인하고, 구체적인 목표를 달성할 수 있습니다.
QA Skill영역은 단순히 노력이냐, 재능이냐 두 가지의 불분명한 관점이 아닌 Specialist, Product/Domain, Leadership, Project를 기준으로 여러 가지 사례를 확인하며 보다 구체적인 관점으로 QA Skill을 완성시킬 수 있습니다.

서론 :   전 직장에서 면접관 업무를 진행했던 경험으로 여러 면접자들이 Skill을 어필하지 못했던 사례에 대해 알아봅니다. 그리고 본인이 느꼈던 착오에 대해 간단하게 설명합니다. 

 본론 : 주요 Skill 과 각 항목에는 어떤 능력들이 필요한지 알 수 있습니다. 쏘카에서 본인이 QA엔지니어로 성장하기 위해 어떤 목표를 설정하고 진행하는지 확인할 수 있습니다.

 결론 : 본론을 바탕으로 QA엔지니어가 어떻게 자신을 단련시키고, 어필하는지에 대해 제 생각을 정리하여 글을 마무리합니다.

위의 3가지 단계로 글을 작성하였습니다.

여기서 끝!

이라고 생각하였으나

막상 글을 작성하고 보니 일기장인지, 어떤 내용을 전달하려고 하는지 감이 오지 않았습니다.

뭐가 잘못된 것일까?

1. 정보 공유를 위한 목적이아닌 위에서 언급했던 수습과제를 끝내기 위해 작성한 글 같다.

2. 글의 목적이 명확하지 않다. (QA SKILL 에 관한 내용인지 REDGATE에 대한 설명인지...)

3. 과도한 접속사 사용으로 글을 읽기에 불편하고, 문장이 길다.

4. 한글 영문 혼용규칙을 설정하지 않아 어디서는 엔지니어, 어디서는 Engineer ...

5. 본문과 내 경험과 맞지 않다..

등 여러 피드백을 받고 다시 작성을 했습니다...

글을 작성하는데만 초점을 둔 결과였습니다.

결국 다시 피드백을 보고 하나씩 수정을 하였고,

이 과정에서는 많은 분들의 도움이 있었습니다.

우여곡절 끝에 SOCAR  Tech Blog 에 제가 작성한 글이 올라가게 되었습니다!

링크드인에서도 확인가능 합니다.

https://www.linkedin.com/posts/socarkr_scitcu-qzcstkrzorxgqyy-qa-activity-7066276503264645120-wNdw?utm_source=share&utm_medium=member_android 

QA엔지니어로써 막연한 목표만 가지고 계신 분들에게는 도움이 되었으면 합니다.

1년에 1개이상의 글감을 TECH 블로그에 등록 할 수있도록

QA분야에 많은 관심을 가지고 업무에 임하는것이 이번년도 작은 목표입니다.!

이번 글을 작성하면서 

저를 제일 많이 도와주신 분께 책 선물도 받았습니다.

"우리글 바로 쓰기"

우리가 모르고 사용하고 있는 외래어 표현에 대해 우리말로 어떻게 표현할 수 있는지 

우리말 표현에 대한 이야기와 방법에 대해 알 수 있습니다.

앞으로 제 블로그도 외래어 표현을 자제하고 

아름다운 우리말로 작성될 수 있도록 노력할 것입니다.

그리고

"조직의 습관을 바꾸는 일"

책도 선물받았는데요.

(아직 한글자도 못봤어요 ㅠㅠ)

이건 다음에 리뷰할 수 있도록 살펴봐야 겠습니다. 허허

그럼 오늘은 여기까지 ㅡ ★

오늘은 cypress 2번째 시간입니다.

2023.03.19 - [자동화 QA로 단단해지기/cypress로 단단해지기] - [cypress]#00_cypress 무작정 시작해 보기 전에! 자동화 왜 합니까?

첫번째는 왜 자동화가 필요하고, E2E TEST가 무엇인지에 대해 간단하게 알아봤습니다.

오늘은 cypress 무작정 시작을 위해 인프런에서 눈에 띄는 강의를 발견해서

따라해보는 시간을 갖도록 하겠습니다.

https://inf.run/Yb4d

하루만에 Cypress로 작성하는 자바스크립트 E2E 테스트 코드 강의입니다.

11개 수업에 45분이라는 부담스럽지 않은 수강시간입니다.

물론 유료입니다.

저는 회사에서 교육비 지원이 되기 때문에 이걸 아주 잘 활용해볼 예정입니다.

자 그럼  교육 과정에 대한 자세한 설명은 생략하고 무작정 따라해보겠습니다.

궁금하면 인프런 가입 해서 제가 적은 링크 따라가시면 됩니다.

저는 MAC 환경으로 시작하겠습니다.

수업을 위한 git hub 저장소를 로컬에 clone 하기

교육용 git hub 저장소에서 코드를 복사 한 후 터미널에서 git clone 진행

$ git clone https://github.com/~~~~

교육내용에서 과제를 주고 이를 어떻게 해결하는지 알려주는 방식입니다.

처음 해볼 과제는 counter 하는 방법입니다.

vscode 에 Live Server 확장

Live Sever 를 다운 받아 주어야

Open with Live Server 항목이 생깁니다.

그래야 이제 내가 테스트할 페이지 URL 을 확인할 수 있습니다.

클릭하면 아래와 같은 테스트 페이지가 나오게 됩니다.

vscode 이동 후 터미널을 열고 cypress 를 설치합니다.

터미널을 열어 준 후

https://www.cypress.io/

에 접속해서 문서대로 따라만 하면됩니다.

문서가 비록 영문이지만 잘 정리되있습니다.

꼭 확인해보세요.

https://docs.cypress.io/guides/getting-started/installing-cypress

npm install cypress --save-dev

를 입력해 줍니다.

설치하고 cyperss 열기

https://docs.cypress.io/guides/getting-started/opening-the-app

./node_modules/.bin/cypress open

The long way with the full path 방식으로 cypress open 합니다.

Welcome to Cypress!

화면을 확인하고

E2E Testing 을 클릭합니다.

Choose a browser화면에서

사용할 브라우저를 선택하고

Start E2e Testing in Chrome 를 눌러줍니다.

E2E specs 에 도착했습니다.

여기서는 examples 로 어떻게 동작하는지에 대한 예시를 간단하게 보여줍니다.

 과제를 하기 위해 New spec 을 클릭해서 cy.js 파일을 만들어주거나

vscode에서 e2e 폴더 하위에 cy.js 파일을 만들어줍니다.

과제 분석

이 counter 라는 서비스의 요구사항은 무엇일까요?

- [ ] counter의 초기값은 0이다.
- [ ] + 버튼을 클릭 시 count가 1증가한다.
- [ ] - 버튼을 클릭 시 count가 1감소한다.
- [ ] + 버튼을 클릭 시 count가 10이 넘는 경우 더이상 증가하지 못한다. (Max 값이 10)
- [ ] - 버튼을 클릭 시 count가 0보다 작아지는 경우 감소하지 못한다. (Min 값이 0)
- [ ] reset 버튼을 클릭 시 counter가 0으로 초기화된다.

위의 요구사항에 맞게 테스트 코드를 짜야합니다.

과제하기 1. 서비스 접속하기

describe("example counter app", () => {
  beforeEach(() => {
      cy.visit("http://127.0.0.1:5500/index.html");
  });
});

어떤 테스트 코드들인지 묶어주는 함수 describe

beforeEach 하나의 테스트 코드(it)들을 실행시키기전에 실행하는 함수

it 하나의 테스트 코드 

cy.visit 을 사용해서 테스트할 페이지를 방문한다.

사진에서 보이는 것처럼 

테스트 케이스마다 BEFORE EACH 로 테스트할 사이트를 visit 해줍니다.

그리고 it 에 적은 테스트 케이스를 볼 수 있습니다.

과제하기 2. 첫번째, 두번째, 세번째 요구사항 진행

describe("example counter app", () => {
  beforeEach(() => {
      cy.visit("http://127.0.0.1:5500/index.html");
  });

  it("최초의 카운터 값을 0으로 보여준다", () => {
      cy.get("#value").invoke("text").should("eq","0");
  });

  it("+버튼 클릭 count 1 증가한다",() => {
    // 먼저 기존 값으 가져오고
    // + 값 클릭
    // 변화된 값이 기존값 + 1인지 체크
    cy.get("#value")
    .invoke("text")
    .then((value) => {
      const preValue = Number(value);
    cy.get(".increase-btn").click();
    cy.get("#value")
    .invoke("text")
    .should("eq", String(preValue + 1));
  });
});

it("-버튼 클릭 count 1 감소한다", ()=> {
  // + 버튼 클릭 해서 1로 만듬
  // 기존 값 1 가져오고
  // - 버튼 클릭
  // 변화된 값이 기존값 0인지 체크
  cy.get(".increase-btn").click();
  cy.get("#value")
  .invoke("text")
  .then((value)=>{
    const preValue = Number(value);
    cy.get(".decrease-btn").click();
    cy.get("#value")
    .invoke("text")
    .should("eq", String(preValue - 1));
  });
})

it 최초의 카운터 값을 0으로 보여줍니다.

html의 span 의 요소 #value 가 어떤 값이여야 합니다.

invoke 를 써서 text 값을 가져옵니다.

그 값이 should ("eq" , "0") 0 과 같아야 합니다.

it + 버튼을 클릭하면 count 1 증가합니다.

html 에서 + 버튼에 대한 class 를 확인 후 가져온 후 클릭

cy.get(".increase-btn").click();

then 으로 메소드를 체이닝(연결) 시켜줍니다.

숫자비교를 위해 String 사용합니다.

두번째와 같은 방법으로 세번째 과제 clear 입니다.

과제하기 3. 네번째, 다섯번째 요구사항 진행

it("+ 버튼을 클릭 시 count가 10이 넘는 경우 더이상 증가하지 못한다. (Max 값이 10)", ()=> {
  for(let i=0; i<11; i++) {
    cy.get(".increase-btn").click();
  }
  cy.get("#value").invoke("text").should("eq","10");
});

it("- 버튼을 클릭 시 count가 0보다 작아지는 경우 감소하지 못한다. (Min 값이 0)", ()=>{
  cy.get(".decrease-btn").click();
  cy.get("#value").invoke("text").should("eq","0");
});

For 문을 사용해 + 버튼을 클릭합니다.

이런식으로 계속 클릭하는 것을 볼 수 있습니다.

그리고 다섯번째 요구사항은

그리고 0에서 - 버튼을 눌럿을 경우 0보다 작아지지 않아야 하므로

-버튼을 클릭 한 다음 0과 비교를 합니다.

과제하기 4. 여섯번째 요구사항

it(" reset 버튼을 클릭 시 counter가 0으로 초기화된다.", () =>{
  cy.get(".increase-btn").click();
  cy.get(".reset-btn").click();
  cy.get("#value").invoke("text").should("eq","0");
});

reset 버튼을 클릭하기 위해 임의의 값을 주고

reset btn 클래스를 사용해서 reset btn 을 클릭하면

그 값은 0 과 같아야 합니다.

잘 돌아가는지 봅시다.

이렇게 해서 설치부터 ~ 간단한 과제까지 마무리 해보았습니다.

저도 무작정 따라하다보니 이게 한 15~20 분과정인데

3시간은 걸린것 같습니다.

처음이라 그런지 쉽지않네요.

자주 해봐야 실력이 늘겠죠?

다음 과제는 계산기 테스트 코드를 작성하는 과제를 진행할 예정 입니다.

그럼 이만!

여섯 번째 에피소드입니다.

제목이 오늘 엄청 특이하죠?

가수 임재범의 "너를 위해"를 패러디했습니다.

제목 : 프로젝트를 위해

거친 개발자와~~ 불안한 기획자와~~ 그걸 지켜보는 QA~~

실무를 하다 보면 여러 사람이 있습니다.

개발자로서의 프라이드가 엄청 강하신 사람이 있고,

경력이 얼마 되지 않아 자신이 한 기획에 대해 자신감이 없는 사람도 있습니다.

모든지 완벽할 수 없습니다.

제가 생각하기에는 완벽한 프로젝트는 개발&기획&QA가 서로 마주 보고 손바닥을 쳤을 때

짝 소리가 나야 합니다.

삼위일체가 되어야 한다는 뜻이죠.

오늘은 프라이드가 강한 거친 개발자, 경력이 부족한 불안한 기획자, 그걸 지켜보는 QA에 대해서 이야기해보겠습니다.

오늘도 쉬운 예를 들어보겠습니다.

여기 기획서가 있습니다.

구매하기 BTN을 클릭하면

구매하기 Alert 이 출력되어야 합니다.

QA 도중 해당 페이지에서 구매하기 BTN 을 클릭했는데 

바로 결제 페이지로 이동되는군요.

결함을 등록합시다.

이게 왜 결함이야!!!

개발자가 엄청 화가 났습니다.

왜일까요?

QA에서 BTS에 등록한 결함을 보고 왜 결함이냐고 묻습니다.

●QA : 기획서에 명시된 대로 BTN 클릭 시 Alert 이 출력되어야 합니다.

●Dev : 어차피 유저는 구매할 생각으로 눌렀는데, 왜 Alert을 띄워줘야 하죠?
그리고 또 결제 페이지로 이동되면 정상 동작 아닌가요?
이 issue #001 은 수정하지 않겠습니다.

●Planner : 헉! ㅠㅠ 

●QA : 흠... 

냉정하게 분석하기

●QA : 기획자님 해당 기능에 대한 기획의도가 무엇일까요?

●Planner : 어... 그냥 다른 사이트도 구매하기 BTN을 클릭하였을 때, Alert 이 나와서 동일하게 기획하였습니다.

●QA : 흠... 그러면 해당 기능에 대해서 수정을 진행할 수 없습니다.
사실 구매하기 BTN을 클릭하였을 때, 결제 페이지로 이동되는 현상은 정상적입니다.

●Planner : 어떻게 하죠 ㅜㅜ

●QA : 잠시만요...

기획자가 경력이 부족하여 자세한 히스토리를 모르는 업무에 대해

기획서를 쓰다 보니 이런 사소한 기능에서도 

Description이 왜 이렇게 정의되어 있는지 모르고 있습니다. 

이전 대화에서 기획자가 "다른 사이트도..... 동일하게...."

라고 말한 것 기억하시죠?

자 그럼 다른 사이트를 확인해보면 QA가 해야할 일은 두가지가 있습니다.

히스토리 파악하기

1. 다른사이트를 기획한 사람에게 히스토리를 물어봅니다.

●QA : 혹시 00 사이트를 기획하실 때, 해당 Alert을 띄우는 이유에 대해 알고 계신가요?

●다른 기획자 : 흠... 잘 모르겠지만 CS 관련 부서에서 요청이 들어왔었어요.


2. 관련된 프로젝트 문서를 확인해보기 

CS 관련부서에서 요청이 들어왔기 때문에 CS 확인할 수 있는 게시판에서 특정 키워드로 검색을 하거나 

관련된 프로젝트 문서에 대해 열람 권한을 획득한 후 히스토리를 파악할 수 있습니다.

●QA : 그럼 해당 프로젝트를 진행할 때에 문서를 확인할 수 있도록 열람 권한을 주시겠습니까?

●다른 기획자 : 네 ~ 드렸습니다.

관련 프로젝트 문서를 확인하던 도중 

CS 관련부서의 요청을 확인할 수 있었습니다.

이유는 두 가지였습니다.

1. 강성 컴플레인 유저

2. 구매하시겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많았던 점.

자 그럼 이제 개발자를 설득할 시간이 되었습니다.

수정해주세요. 얼른!!

●QA : 개발자님

●Dev : 왜요! 

●QA : Issue #001 수정해주셔야겠습니다.

●Dev : 왜요!! QA 도 개발팀 소속이면서 기획자 편을 들어주는 거예요?!

●QA : 해당 기능은 과거 유저 CS로 인해 생긴 기능입니다.
바로 구매 페이지로 이동하여 강성 컴플레인을 건 유저가 있었습니다.
그리고 구매하겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많아 다른 사이트에도 모두 Alert 을 노출시켜주고 있습니다.
그래서 이번 00 사이트에서도 구매하기 BTN을 클릭하였을 때, Alert 이 출력되어야 합니다.

●Dev : 깨갱.. 알겠습니다. 수정되었습니다.

이렇게 해서 잘 마무리되었습니다.

물론 위의 예시는 쉽게 설명하기 위해 들은 예시입니다.

실무를 하다 보면 많은 사람들과 커뮤니케이션을 하지만

늘 잘되는 일은 없습니다.

실제로 저는 위와 같은 경험을 굉장히 많이 겪었습니다.

Minor 한 결함이고, 당연하다고 생각되는 기능이지만

의문을 가지고 자신이 한 개발이 항상 맞다!

이런 식의 대화도 많이 겪었습니다.

여기서 QA는 그 누구의 편도 아니며, 항상 품질만을 생각해야 되기 때문에

이런 상황에서는 "근거"가 명확해야 합니다.

저는 회사를 다닐 때, 항상 다른 사람과 친하게 지냅니다.

물론 사람들과 대화하는 걸 좋아해서 그렇죠.

이런 상황이 오면 또 다른 사람들에게 도움을 받기에도 엄청 좋습니다.

물론 저도 제 일이 아니더라도 도움을 받는 만큼 돌려줍니다.

그리고 항상 확인하는 것이 프로젝트를 진행할 때에 유사한 프로젝트는 어떻게 진행되었으며

특이사항이 있었는지에 늘 체크를 합니다.

그리고 이번 프로젝트에서 예외적인 상황이 나올 수 있는지 미리 체크리스트를 작성하여 대비를 하는 것이지요.

오늘은 거친 개발자, 불안한 기획자 사이에서 QA는 어떻게 행동해야

품질을 높일 수 있는지 알아보는 시간을 가졌습니다.

QA 는 항상 품질만 생각해야 합니다. 

커뮤니케이션은 양팔저울처럼 어느 하나 기울어진 곳 없이 

동등하게 대해야 합니다.

그럼 Episode 06 마무리하겠습니다.

다음에 또 만나요~