문성준의 단단해지기

오늘 점심은 뭐 먹을까 고민하던 중!!

맥도널드 신메뉴가 나왔다고 하길래

한번 봤습니다.

참고로 저는 맥도날드 손절한 지 오래된 사람입니다.

이유 : 작고 맛이 평범하기 때문에 굳이 먹을 필요가 없다.

그런데 제가 워낙 피자를 좋아하기 때문에 페퍼로니 버거가 나왔다고 했을 땐 솔깃했습니다.

그래서 바로 시켜봤습니다.

저 같은 성인 남성은 햄버거 1개로 배가 안차기 때문에 페퍼로니 메가 피자 버거를 시켜먹어 보겠습니다.

그냥 피자버거와 달리 패티가 4장 들어간다네요.

도착했습니다.

크기는 제 손바닥보다 살짝 더 큽니다.

사진 찍어놓은걸 보니까

기존에 맥도널드 버거보다 좀 더 큰 느낌입니다.

패티가 4장 들어있습니다.

FIFA 월드컵 기념 축구공 모양의 사커번이에요

햄버거 뒤입니다.

거북이 같지 않나요?

하하하

후기입니다.

맛 : ★★★★

배부름 : ★★★

생각 이상으로 괜찮습니다.

버거킹의 스테커 4보다는 배가 안차지만, 맥도널드에서 이런 맛 이난 다고?

할 정도의 맛이었습니다.

페퍼로니 피자 좋아하시는 분들은 엄청 좋아할 거 같아요.

이상으로 맥도널드 신메뉴 후기였습니다.

오늘은 강남역 만두, 칼국수 맛집 소개를 해드리겠습니다.

바로 명동칼국수입니다.

자세한 위치는 아래 링크 첨부해드리겠습니다.

강남역 10번 출구에서 가깝고요, 해커스 학원 근처여서 공부하다가 가셔도 될 것 같습니다.

▼▼▼▼▼▼▼▼▼▼▼

https://naver.me/F0cZHtZN

갑자기 날씨가 추워졌습니다.

오늘 같은 날은 뜨끈한 국물이 생각나는데요.

바로 명동칼국수로 가줍니다.

기가 막히죠?

칼국수를 시키면 밥도 조금 줍니다.

근데 밥을 먹은 적은 거의 없어요

왜냐면요 양이 무지하게 많습니다.

저는 항상 만족하고 나와요.

그런데 저랑 같이 간 다른 팀원분들은 배부르다고 많이 남기시더라고요.

아무튼 칼국수만 먹어도 맛있지만, 

저 같은 경우에는 만두도 한판 시킵니다.

이걸 또 간장에 찍어먹으면 기가 맥힙니다.

만두를 먹고 좀 텁텁하다.

바로 국물 드링킹 한 후에 

칼국수를 먹으면 깔 끔 합니다.

테이블마다 김치통이 있어서

먹을 만큼만 덜어 먹으면 되고요.

전 매운 거 잘 못 먹는데

여기 김치는 안 맵고 맛있습니다.

사진을 몇 장 찍으니

같은 팀원분께서 왜 이렇게 아저씨 같이 사진 찍냐고 하시더라고요.

얼마나 잘 찍나 핸드폰을 드렸더니 

이렇게 찍어 주셨습니다.

저는 별 차이 못 느끼겠지만

어쨌든 음식만 맛있으면 좋은 거 아니겠습니까?

요즘 국밥 1만 원 시대에 

만원 이하로 배 채울 수 있는 정말 맛있는 칼국수 집입니다.

추천추천~

두 번째 에피소드입니다.

오늘은 명세 기반 작성법으로 TestCase를 작성한 후에

TestCase를 보완하는 CheckList를 작성하는 이유와 방법에 대해 간단하게 포스팅해보겠습니다.

가기 전에 두 가지 Keypoint를 짚고 넘어가겠습니다.

입력 값에 대한 예상 출력 값을 정해놓고 그대로 결과를 나오는지 확인한다.

테스트 혹은 평가해야 할 항목을 정리하고 누락 없이 검증하는 것을 목적으로 한다.

얼핏 보면 같은 내용 아닌가요?

라고 생각할 수 있습니다만

포커스를 어디에 맞추느냐 생각해보면 달라질 수 있습니다.

첫 번째 키 포인트는 예상 출력 값에 포커스를 맞췄습니다.

즉, 기대 결과를 중심으로 작성한 TestCase입니다.

두 번째 키 포인트는 항목에 포커스를 맞췄습니다.

경험이나 TestCase를 보완할 테스트 항목에 대해 작성한 CheckList입니다.

각각 차이를 쉽게 볼 수 있도록 아래 표를 준비해 보았습니다.

공통된 목적을 가지고 있으나 미세하게 다른 차이가 있습니다.

물론 사람마다 다르겠지만 제가 업무를 할 때는 위의 표처럼 구분지어서 사용하고 있습니다.

간단하게 예를 들어보겠습니다.

여기 로그인 페이지에 대한 기획서가 있습니다.

Description 1번 로그인 항목에 대한 Test Case를 작성해 보겠습니다.

# 명세 기반의 TestCase 작성

명세서 기반으로 작성하였기 때문에 위의 TestCase 에는 Test Step 동작 후 로그인 처리 동작에만 포커스를 맞췄습니다.

물론 로그인이 동작하면 Pass 처리가 되겠지만

우리는 그동안의 업무 경험으로 인해 우리는 추가로 보완해야 할 항목이 무엇인지 알고 있습니다.

회원에 대해 분류를 해야 하는데요.

이는 어떠한 사이트를 가도 공통된 항목이 있을 것입니다.

대표적으로, 비밀번호가 만료된 계정 또는 일정 기간 동안 접속하지 않아 휴면 처리된 계정 등 

해당 사이트를 접속하는 여러 회원에 대해서 테스트가 누락될 수 있습니다.

그렇기 때문에 CheckList를 추가적으로 작성합니다.

# 업무 경험 기반으로 CheckList 추가 작성

이런 식으로 회원별 CheckList를 추가로 작성하는 겁니다.

그렇게 된다면 TestCase로 1차적으로 로그인 기능에 대해 확인을 하고,

2차적으로는 회원을 분류하여 회원 타입별로 로그인 기능이 정상 동작을 하는지 확인할 수 있습니다.

오늘은 "TC 다 썼는데 CheckList도 작성해야 돼요?"

라는 의문에 대한 답을 어떻게 내렸는지에 대해 다뤄봤는데요.

사람마다 생각하고 실무에 적용하는 것이 각자 다르겠지만

우리 QA 엔지니어의 목적은 하나입니다.

어떻게 품질을 상승시킬 수 있고, 효율적으로 문서들을 관리할 수 있는지에 대해 늘 고민해야 됩니다.

그럼 Episode 02 마무리하도록 하겠습니다.

오늘은 강남역 고기 맛집 추천 시간입니다.

자세한 위치는 아래에서 확인할 수 있습니다.

강남역 4번출구에서 5~10분 정도 걸으면 나오는 거리입니다!

▼▼▼▼▼▼▼

https://naver.me/56IDilbX

메뉴입니다.

소고기 메뉴가 있고요

돼지고기와 식사메뉴가 있습니다.

저는 오늘 소고기, 돼지고기 모두 즐겼습니다.

말이 필요 없죠. 사진으로 보겠습니다.

이렇게 1인 1 식판으로 쌈장, 소금, 카레가루?? , 파절이 , 양파절임이 밑반찬으로 나옵니다.

토마호크

우대 꽃갈비

초벌구이를 해서 주기 때문에 적당히 잘 구워 먹으면 됩니다.

육식주의자에서는 마늘과 치즈를 함께 구워서 먹을 수 있는데요.

치즈가 정말 맛있어요.

모든 고기에 싸 먹어도 조화롭습니다.

다시 봐도 군침이 도네요.

와규 꽃등심

왜 와규냐면, 와규와규 먹기 때문에 와규라고 부릅니다. 껄껄껄

삼겹살을 먹게 되면 불판을 바꿔줍니다.

엄청난 폭식의 현장입니다.

기름진 고기를 먹었으니

시원한 비빔냉면으로 입가심을 해줘야겠지요?

3명이서 20만 원 넘게 먹고 나왔습니다.

고기가 부드럽고 맛있어서 더부룩하다는 느낌도 없었습니다.

그래서 가격표 보고 사장님이 3명인데  잘못 찍힌 게 아닌가 갸우뚱하셨는데요.

그만큼 먹었습니다... 술도 안 먹고 고기만 먹었어요 ㅋㅋㅋ

아무튼 인테리어도 굉장히 깔끔합니다.

화장실도 깔끔하고요. 남녀 구분되어있고 각각 1명씩 사용 가능합니다.

저는 음식점을 갈 때, 외관과 인테리어를 많이 봅니다.

음식점 같은 경우에는 주방뿐만 아니라 음식을 먹는 환경도 깨끗해야 된다고 생각해요.

그렇기 때문에 강남역 육식주의자 추천드리겠습니다.

오늘은 제가 PC Web Test를 진행할 때

사용하는 방법 중 하나인 개발자 도구(F12) 이용하는 법에 대해 간단하게 설명드리겠습니다.

1. 개발자 도구 켜기

개발자 도구를 켜는 단축키는 웹 브라우저에서 F12를 누르면 됩니다.

그러면 사진과 같이 개발자 도구가 나오죠?

톱니바퀴 도구를 눌러봅시다.

여기서 한국어로 변경 가능합니다.!!

2. Network 탭 사용하기

일단 Network 탭 사용하기에 앞서 간단하게 Network 탭을 사용하면 좋은 점에 대해 알아보겠습니다.

일단 Naver에서 개발자 도구(F12)에 Network 탭에 대한 구성을 확인해볼까요?

Waterfall 마우스 커서를 올리면 자세한 지표를 보여줍니다.

사실 제가 여기서 활용하는 정보는 Status Codes입니다.

Web QA를 할 때, 제가 우선순위를 높게 보는 것은 Web page를 잘 불러오느냐부터 확인을 하는 것이지요.

그럴 때 가끔 아래와 같이 페이지를 불러올 수 없을 때가 있는데요.

Status Codes로 어떤 점이 문제인지 확인할 수 있습니다.

자세한 Status codes 정보는 아래 링크에서 확인할 수 있습니다.

▼▼▼▼▼▼▼

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

3.throttling 설정

Fast 3G, Slow 3G, Offline.. 등의 느린 네트워크 환경을 설정할 수 있습니다.

아무것도 설정하지 않은 상태의 Naver를 불러오는 속도입니다.

Finish :7.56s / DOM : 867ms / Load : 1.05s

여기서 Slow 3G 환경으로 변경하면 어떻게 될까요?

눈에 띄게 차이가 나는 것을 확인하실 수 있을 것입니다.

Finish :48.37s / DOM  : 4.30s / Load : 12.71s

DOM이나 Load 같은 경우에는 단위가 바뀔 정도이고 7초에서 49초가량 7배나 느려진 속도를 확인하실 수 있습니다.

throttling 설정 같은 경우는 QA에서 어떻게 활용하냐면

정상 동작하는 Web 사이트에서 가끔 콘텐츠가 제대로 노출되지 않는다고 CS 유입될 때가 있습니다.

재현도 어렵고요.

그럴 때 제일 먼저 하는 방법이 throttling 설정을 통해 유저가 혹시 느린 네트워크 환경에서 

Web 사이트를 이용하지는 않았는지 확인합니다.

대부분 유저가 일시적으로 느린 네트워크 환경을 사용하여 발생되는 사건일 때가 많았습니다.

원래 주말에 포스팅했어야 했는데 주말에 큰 사건이 있었죠,

물론 티스토리도 예외는 아니었죠.

그래서 뒤늦게 작성한 감이 있지만 오늘은 개발자 도구(F12)의 Network 탭을 사용하여 

어떻게 Web QA에 활용하는지 간단하게 알아보았습니다.

그럼 다음 에피소드도 기대해주세요.

오늘은 제가 PC Web Test를 진행할 때

사용하는 방법 중 하나인 시크릿 모드 이용하는 법에 대해 간단하게 설명드리겠습니다.

01. Chrome 의 시크릿 모드 사용하기

여러 브라우저 중 Chrome 을 기준으로 잡는 이유는

여러 이유가 있지만, 유저 입장에서 보면 점유율이 높은 PC 브라우저기 때문에 Chrome 기준을 잡고 진행해보겠습니다.

시크릿 모드(Secret Mode)는 명칭이 브라우저마다 사실 조금씩 다릅니다.

Firefox 같은 경우에는 사생활 보호 창이라고 하고, Safari에서는 개인정보보호 브라우징 모드라고도 불리죠.

시크릿 모드 같은 경우에는 웹 서핑의 기록이 남지 않는 것이 가장 큰 특징입니다.

그리고 사용자의 사이트 방문 기록, 다운로드한 파일의 기록이 사용자의 브라우저에만 저장되지 않습니다.

저는 실무를 할 때, 제가 일하는 사이트 특성상 한 아이디로 여러 사이트를 접속하는 경우가 많은데요.

그럴 경우 로그인 세션이 겹치는 것을 방지하고자 시크릿 모드로 Web Test를 진행합니다.

 Chrome 창에서 단축키 Ctrl + Shift + N을 누르면 시크릿 모드로 전환된 새 창이 열리게 됩니다.

 또한 아래에 보시면 

시크릿 모드에 대한 간단한 설명과 함께 타사 쿠키를 차단할 수 있도록 선택도 가능합니다.

타사 쿠키는 이미지 같은 웹페이지에 표시되는 일부 콘텐츠가 사이트에 의해 생성되는 것을 말합니다.

자세한 설명은 google chrome 고객센터를 한번 읽어보시는 것을 추천드립니다.

https://support.google.com/chrome/answer/95464?hl=ko 

너무 간단한 이야기 같지만 누군가는 제 포스팅을 보고 도움이 된다고 생각합니다.

그래서 Web QA 카테고리를 만들어서 여러 에피소드별로 간단하게 포스팅할 예정입니다.

그럼 다음 에피소드에서 만나요~

카르마 : 미래에 선악의 결과를 가져오는 원인이 된다고 하는, 몸과 입과 마음으로 짓는 선악의 소행

흔히 말하는 "업보"입니다.

갑자기 웬 카르마(Karma)??라고 생각하실 수 있는데요? 

오늘 배운 단어이기 때문에 까먹지 않기 위해 포스팅을 하였습니다.

저는 오늘 회사 동료와 대화를 하고 있었습니다.

주제는 학창 시절 개구쟁이 행동에 대한 얘기를 하던 중

순간 제 머릿속에는 

리그 오브 레전드 게임의 카르마...?라고 생각하였습니다.

하지만 검색해보니 인도계 종교에서의 인과율 개념이라고 정의되어 있었습니다.

관련해서는 위키백과에 "업"에 대한 항목을 참고하면 좋을 것 같습니다.

▼▼▼▼▼▼▼▼▼▼

https://ko.wikipedia.org/wiki/%EC%97%85

아까 그럼 회사 동료가 말한걸 예를 들어 볼까요~?

어렸을 때 이성 학우에게 못된 장난을 많이 쳤습니다.

놀리는 당신에는 재미있었지만 이성 학우는 많이 속상했겠죠.

이렇게 카르마(Karma)가 쌓이고 쌓인

그 결과

성인이 된 지금

다른 이성에게 호감을 얻지 못하고 연애를 못한다는 결론이 나올 수 있습니다.

정말 슬프지 않나요?

그러나 업보입니다. 전혀 슬프지 않습니다.

그래서 항상 과거에 제가 했던 짓궂은 장난에 대해서는 항상 속죄하는 마음으로 살고 있습니다.

철이 없었다, 아무것도 모르는 나이였다.. 하는 건 중요하지 않습니다.

나중에 자식을 교육할 때, 남한테 상처를 주면 자신에게 돌아온다라는 

카르마(Karma)에 대해 제일 먼저 교육을 해야겠습니다.

이상 카르마(Karma)에 대해 알아보는 시간을 가졌습니다.

오늘은 제가 실무에서 명세 기반 테스트 케이스 작성을 하면서 드는 생각과

몇 가지 상황에 어떻게 대처하는지 Episode 형식으로 간략하게 포스팅을 할 예정입니다.

상황 설명에 앞서 명세 기반 테스트 케이스 작성법에 대해 간략하게 짚고 넘어가겠습니다.

일단 명세기반 테스트 케이스 작성법이란?

요구 분석 명세서나 설계 설명서에서 테스트 케이스를 추출하여 테스트한다.

입력 값에 대한 예상 출력 값을 정해놓고 그대로 결과를 나오는지 확인한다.

위의 두 문장 정도가 key point 입니다.

자세한 설명은 Naver 지식백과 링크에서 확인할 수 있습니다.

▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼

https://terms.naver.com/entry.naver?docId=3533034&cid=58528&categoryId=58528 

주로 저는 소프트웨어 기획서를 전달받고, 그 기획서에 나온 logic , description을 토대로

Pre-condition(사전 조건), Test Step(테스트 스텝), Expected Result(예상 결과) 3가지를 구분하여 작성합니다.

기획서에 명확하게 명시되어있다면 정말 빠르고 손쉽게 작성할 수 있지만

기획서의 logic이 불분명하거나 description의 내용이 부족하면 작성하는데 조금 시간이 걸리곤 합니다.

오늘 다룰 상황은 "생략"된 description입니다.

# 다른 페이지의 기능과 동일하다.

여기 2페이지의 기획문서가 있습니다.

1페이지 에서는 [A] Tab에서 Web BTN을 클릭했을 때의 Description 이 명시되어 있지만

2페이지에서는 이전 페이지와 동일한 기능을 한다고만 적혀 있습니다.

그러면 2페이지에 대한 Test case는 어떻게 작성해야 할까요?

어떻게 보면 똑같이 [B] Tab에서도 Web BTN이 있고, 동일한 URL로 이동하기 때문에 큰 문제는 없겠지만

Expected Result에 "이전 페이지와 동일하게 동작해야 한다."라고 적을 수는 없습니다.

TestCase를 작성하는 이유 중 하나는 문서화를 통해 문서를 참고하는 사람들에게 이해를 도울 수 있어야 합니다.

이전 페이지와 동일하게 동작해야 한다.라고 작성할 경우에는 

해당 프로젝트를 진행할 때는 이상 없이 진행될 수 있겠지만

추후 관련 프로젝트 개발을 위해  또는 새로운 인력이 소프트웨어 이해를 돕기 위해 해당 문서를 참고할 경우

[A] Tab의 기능 부분을 다시 숙지해야 하는 번거로움이 생기거나, 누락된 Case로 인해 오류가 발생할 수 있기 때문입니다.

Test Step이나 Expected Result 가 같을 순 있겠지만, Pre-Condition 이 다르기 때문에 꼭 구분해서 작성합니다.

간단한 예시를 들었지만, [A] Tab에서 나올 수 있는 Test Step 이 10가지 이상으로 Description 이 명시되어있는 상황에도

똑같이 [B] Tab 에 대한 Case를 구분하여 작성합니다. 

제가 실무를 할 때, 기획자마다 스타일이 정말 다릅니다.

어떤 기획자는 Description 상세하게 적어서 Ctrl + C, Ctrl + V를 해도 될 정도로 상세하게 Description을 적어주는 반면,

어떤 기획자는 예상 결과를 QA 가 추측을 해서 작성해야할 정도로 간략하게 Description 을 적어주기도 합니다.

물론, 유능한 QA 엔지니어라면 어떤 기획문서가 와도 입력값에 대한 정확한 예상결과를 도출해 낼 수 있어야 합니다.

오늘은 "다른 페이지의 기능과 동일합니다."

라는 상황에 어떻게 대처했는지에 대해 다뤄봤는데요.

앞으로 명세 기반 테스트 케이스 작성을 하면서 발생했던 상황과 예시를 많이 작성할 예정입니다.

많은 관심 부탁드리며~

그럼 Episode 01 마무리하도록 하겠습니다.