문성준의 단단해지기

오늘은 정말 오랜만에 또 글을 쓰게 되었습니다.

경력직으로 이직했지만

신입사원의 마음으로 일을 하고 있습니다.

그래서 잠도 22시 ~ 23시면 골아떨어집니다.

그래서 티스토리에 포스팅해야 하는데~

라고 생각만 하고 침대에 몸을 맡기는 게 일상이 되어버렸네요.

어쨌든!

오늘의 주제는 

협업 도구

입니다.

QA 실무를 하면서 회사의 특성상 사용하는 도구가 다 다를 텐데요.

어떻게 활용하고 있는지 오늘은 간단하게 알아보도록 하겠습니다.

알기 쉽도록 Before & After로 말이죠.

주요 업무 소통 방식

인트라넷 + 내선전화 VS Slack입니다.

●인트라넷 + 내선전화 ●

인트라넷(intranet)은 단체의 직원만 접근이 가능한 사설망을 말합니다.

모든 업무는 인트라넷에서 이루어졌으며 인트라넷의 모든 기능을 통해 업무를 진행하였습니다.

인트라넷에서 각 부서 게시판으로 이동 후 글을 작성하고, 댓글을 달아서 업무를 진행했습니다.

업무에 관한 모든 정보가 인트라넷에 남아있는 장점이 있습니다.

그러나 대부분의 작성글은 비밀글이고, 퇴사자가 발생하게 되면 관련문서를 찾아가기 힘든 적이 한두 번이 아니었습니다.

그리고 내선전화로 이해를 돕고, 급한 용무도 처리하였습니다.

●Slack ●

Slack 은 인스턴트 메시징 프로그램입니다.

비공개 채팅 또는 채널, 워크스페이스 등을 만들어 음성 통화, 화상 통화, 미디어 및 파일 통신이 가능합니다.

그리고 또 여러 소프트웨어와도 통합하여 사용할 수 있고요.

그렇기 때문에 긴 설명이 필요 없습니다.

저는 슬렉을 통한 업무가 딱딱한 대화환경을 조성하지 않음으로

다양한 커뮤니케이션이 가능하다는 것을 몸소 깨달았습니다.

보고를 하는데 형식적인 문서와 언어 사용을 위해 시간이 걸리지도 않고

허들을 통해 논의하고, 브레인 스톰을 즐길 수 있습니다.

메신저

메신저가 無 VS Slack입니다.

●메신저 없음 ●

메신저가 없습니다.

모든 업무는 인트라넷으로 진행했으니깐요.

그래서 다른 직원과 사담을 나누는 것은 자리에서 잠깐 얘기하는 것뿐이었습니다.

간단한 업무 지시도 메신저가 없었으므로 빠르게 전달되지 않았습니다.

●Slack ●

Slack 은 조직적인 커뮤니케이션을 위해 개발되었지만 커뮤니티  플랫폼으로도 활용하고 있습니다.

이모지를 제작해서 쓸 수도 있고, 개성 넘치는 프로필도 꾸밀 수 있습니다.

DM을 통해 비공개적인 교류도 할 수 있습니다.

공통 관심사가 있는 사람들을 모아 채널을 만들어서 소통하기도 합니다.

기획서 & 디자인 가이드

PowerPoint 와 ZEPLIN VS Notion, Miro, Figma입니다. 입니다.

●PowerPoint 와 ZEPLIN ●

기획서는 PowerPoint로 버전별로 확인할 수 있었습니다.
PowerPoint 첫 페이지에 버전관리 항목을 작성하여 관리를 합니다.
단, PowerPoint는 한 번에 모든 기획을 볼 수 있지만 새로운 정책, 기획이나 수정사항이 반영되기까지 시간이 오래 걸립니다.
디자인 가이드는 ZEPLIN으로 화면별 디자인가이드를 확인할 수 있었습니다.

●Notion, Miro, Figma ●

User Story와 Acceptance Criteria(인수테스트 시나리오)를 Notion으로 확인할 수 있습니다.
그리고 전반적인 기획은 Miro로 확인이 가능하고요.
UX와 Flow에 따른 최종 디자인은 Figma에서 확인할 수 있습니다.
비교적 많은 도구를 통해 기획문서를 확인해야 하지만 직관적이며 도구 내에서 소통이 가능한 장점이 있고
빠르게 반영된다는 장점이 있습니다.

BTS

REDMINE VS Jira 입니다.

●REDMINE●

인트라넷과 연동해서 쓸 수 있는 Redmine입니다.
Redmine 도 다양한 기능을 추가할 수 있습니다만 참고문서를 쉽게 찾을 수 없고 플러그인을 적용하는 데에 어려움이 있었습니다.
전 직장에서 Redmine은 전 직원이 들어올 수 없었습니다.
개발, QA, 기획자가 주로 협업하는 공간이었습니다.
그렇기 때문에 디자인, 사업부 정책논의가 필요할 경우에는 해당 이슈를 캡처해서 공유해줘야 하는 불편함이 있었습니다. (지금 와서 생각해 보면 왜 그랬는지는 모르겠음, 수정권한을 빼고 입장했으면 좋았을 텐데...)

●Jira●

처음에 우아한 형제들이나 다른 기업 면접을 봤을 때, 티켓관리는 어떻게 하느냐?
라는 질문을 들었을 때 의아했던 부분이 있었습니다.
Redmine을 사용하면서 티켓이라는 단어를 들어본 적이 없었거든요.
Jira를 사용하면 일감, 이슈들을 티켓으로 관리할 수 있습니다.
티켓으로 소요시간을 측정하거나, 우선순위 산정, 히스토리 남기기, 다른 티켓과의 연결이 용이합니다.
Jira는 활용방법이 무궁무진합니다.
JQL로 필터 기능을 사용하여 내가 원하는 정보만 확인할 수 도있고요.
아직 사용한 지 2개월밖에 지나지 않아 설정된 값만 확인이 가능하지만 자유자재로 쓰게 된다면 업무 효율이 향상될 것입니다.

팀 내부 문서 & Test Case 

Excel, Google Drive VS Confluence, TestLink입니다. 입니다.

●Excel, Google Drive●

팀 내부문서나 Testcase는 구글 스프레드시트 혹은 엑셀로 작성하여서 개인 폴더에 보관하거나 팀 드라이브에 공유를 했습니다.
계정을 연동하면 오프라인에서도 작업이 가능하고요.
수정이력도 확인할 수 있지만 문서의 양이 많아질 때를 대비하여 카테고리별로 정리가 확실해야 합니다.
딱히 엑셀과 구글 스프레드시트, 드라이브는 단점이 없다고 생각합니다.
상황에 맞게 적절한 선택을 하면 되니깐요.
그러나 텍스트에 최적화되어있다는 느낌을 많이 받습니다.
따라서 팀 내 가이드문서를 만들 때는 살짝 아쉬웠습니다. 그림과 같이 설명하기에는 가독성이 떨어졌거든요. 물론 제가 잘 활용하지 못했을 수도 있지만...

●Confluence, TestLink●

팀 내부 문서는 컨플루언스에 모두 저장하고 있습니다.
업무 공유부터 시작해서 회의록, 가이드문서까지 컨플루언스에 작성합니다.
작성했을 때, 관찰자에게 알림을 보내줄 수 돈 있고 관찰자에게 알리지 않고 게시할 수도 있습니다.
직접 코멘트를 추가할 수도 있고 댓글로 소통이 가능합니다.
테스트 링크는 저도 처음 봤습니다. 테스트 케이스를 관리하는 툴은 생각도 못했어요.
오픈소스 도구이고 쉽게 접근할 수 있는 도구인데요. 
Test Spec을 정하고 Test case를 작성하여 Test Suite를 형성합니다.
여러 Step actions을 Expected results에 매칭시킬 수 있고, 각자 사용 방법에 따라 Testcase 뿐만 아니라 Test 시나리오도 작성할 수 있습니다.
그렇게 작성된 Testcase를 plan을 세우고 build version을 구분하여 자유자재로 활용할 수 있습니다.
BTS와 연동도 가능하여 Testcase 수행할 때도 버튼클릭으로 상태를 바꿀 수 있습니다.
성공/ 실패 히스토리도 파악할 수 있고요.
좀 더 연구해 볼 만한 도구입니다.

이렇게 해서 오늘은 간단하게 

전 직장과 현 직장이 사용하는 협업 도구를 비교해 봤습니다.

갑자기 늘어난 협업 도구부터 숙지해야 했기 때문에

업무 피로감이 늘어났었어요.

그런데 이러한 협업 도구들을 사용하면서 

왜 피곤하게 이런 걸 쓰냐?

라는 생각보다는

뭔가 조금 더 익숙해지고, 잘 활용하게 된다면

업무 효율을 높이거나 커뮤니케이션을 할 때 시간을 단축시킬 수 있겠구나

라는 생각이 들었습니다.

즉, 비효율적인 건 아니라는 겁니다.

그러나 무분별하게 잘 나가는 회사들이 쓴다더라

해서 무조건적으로 도구만 많이 쓴다면 그건 닭 잡는데 소 잡는 칼을 쓰는 것과 다름없는 행동이겠지만요.

일단은 이 정도로만 소개하고

시간이 된다면 각 도구에 대해 자세한 설명과 활용방법에 대해 포스팅하고 싶습니다.

언제가 될지는 모르겠지만 그때가 빨리 오면 좋겠네요!!

그럼 이만!

오늘은 일회용 이메일 주소를 만들어주는 사이트에 대해서 공유하려고 합니다. 

일회용 이메일 주소가 왜 테스트와 연관이 있지?

라고 궁금해하시는 분들이 있는데요.

일단 사용법 부터 소개해드리도록 하겠습니다.

욥메일

https://yopmail.com/

입니다.

일단 위의 링크에 접속해 보겠습니다.

위의 링크 따라 욥메일 페이지에 들어가면 위와 같이 나옵니다.

저는 구글의 번역기능을 썼어요.

왼쪽 상단에 보면 원하는 이메일 이름을 입력하세요.

라는 칸이 보입니다.

여기서 자기가 원하는 대로 이메일을 생성할 수 있습니다.

예를 들면 회사에서 어떤 네이밍 규칙으로 QA 팀에서 사용하는 메일을 만든다. 

라고 가정 합시다.

그러면 오늘이 2월 6일이고 여러 개를 만들어야 하니 아래와 같이 

qa_0206_001

qa_0206_002

qa_0206_003

.

.

.

.

.

이렇게 이메일주소를 만들 텐데요.

원하는 이메일 이름을 적어주고 화살표 버튼을 클릭하면

qa_0206_001@yopmail.com이라는 이메일이 생성되었습니다.

그러면 생성된 이메일로 메일을 하나 보내보겠습니다.

네이버에서 이렇게 보내보겠습니다.

왜 안 왔지? 

새로고침을 눌러볼게요.

메일이 온 걸 볼 수 있습니다.

어때요 참 쉽죠?

클릭 한 번으로 이메일을 받아볼 수 있는 일회용 이메일을 생성했습니다.

사용법을 보고 나니 이제 어떤 상황에 쓰일지 감이 오시나요?

예를 들면, dev 서버 또는 qa 서버에서 회원가입 페이지를 테스트할 때,

내 개인이메일 주소가 아닌 일회용 이메일 주소를 등록해서 

인증번호를 받거나, 알림 메일 또는 프로모션 메일을 받아볼 수 있습니다.

또한 위와 같은 방법을 반복해서 여러 개의 일회용 이메일 주소를 받아

여러 계정에 대한 테스트도 진행할 수 있기 때문입니다.

물론 더 많은 활용방법이 있겠지만 그건 나중에 생각해 보려고요.

그럼 이만!

오늘은 QA 산출물 중에 하나인 프로젝트 중간 보고서에 대해 이야기해보려고 합니다.

프로젝트의 결과도 중요하지만

결과만큼이나 과정도 중요합니다.

늘 과정에서 배우고 결과로 증명하기 때문입니다.

프로젝트 중간 보고서는 말 그대로 프로젝트 중간에 보고서를 쓰지만

주간 보고서, 현황보고 등

프로젝트가 어떻게 진행되는지 공유가 필요한 시점에 작성합니다.

예를 들어보겠습니다.

11월 1일~ 11월 30일 1달간 진행되는 프로젝트가 있습니다.

언제 중간보고서를 작성해서 공유해줘야 할까요?

1. 매주 금요일 주간 보고서

11월 4일 / 11월 11일 / 11월 18일 / 11월 25일 

총 4번 작성되어집니다.

2. 프로젝트 중간 보고서

11월 18일 

프로젝트 중간에 1번 작성되어집니다.

4번 작성하느냐 1번 작성하느냐 차이지만 각자 회사의 환경 또는 프로세스에 따라 작성하는 것을 권장드립니다.

( 저는 주로 주간 보고서 형태로 작성합니다.)

중간 보고서 작성하기 #01 : 이 보고서를 꼭 봐주세요.

1. 수신, 참조자 파악하기 

저는 주로 [수신 : 실무 진행자], [참조 : 관리자, 내가 소속되어 있는 팀]으로 작성합니다. 

실무 진행자는 꼭 프로젝트의 현황을 알아야 하고, 숙지해야 합니다.

그래서 남은 일정 동안 프로젝트를 완성할 수 있을지에 대해 늘 생각해야 합니다.

만약, 본인이 맡은 업무 중 어떠한 요인으로 인해 수행하기 어렵다면 QA에게 공유가 되어야 합니다.

관리자 ( 각 팀 팀장), 내가 소속되어 있는 팀으로 참조를 포함시킨 이유는 각 팀의 팀장들 또한 현재 프로젝트 업무

상황을 확인하여 팀 운용에 참고를 할 것입니다. 또한 프로젝트에 참여하지 않더라도 중간보고를 받음으로써 프로

젝트 진행상황이 와전되는 것을 방지하기 위함입니다.

그리고, 팀원들에게 공유하는 이유는 제가 부재중이더라도 다른 인원이 대응할 수 있도록 공유를 해주고 있습니다.

중간 보고서 작성하기 #02 : QA팀은 이러한 환경에서 검증하고 있습니다.

1. QA가 어떤 환경에서 진행되고 있는지 공유합니다.

예를 들면 Test Device, Test App ver, OS ver 등 이 있겠죠?

2. QA 범위에 대해서 공유합니다.

신규 프로젝트일 경우 Front, Admin 둘 다 진행하겠지만 기존에 운영되고 있던 제품을 리뉴얼할 때는 일부 기능에 대해서는 검증 범위가 제외될 수 있으므로 범위에 대해 명확하게 적어줍니다.

3. 기획서 Histroy에 대해 공유합니다.

저는 주로 명세 기반 작성법으로 Testcase를 작성합니다. 

업무 프로세스상 [사업부 & 연구소 → 기획팀]으로 요구사항을 반영하여 기획서를 작성하기 때문에 기획서가 어떻게 변화했는지 중요합니다.

어떤 사람은 1.0ver 초기기획서를 보고 업무를 진행하고, 어떤사람은 1.5 ver의 최신 기획서를 보고 업무를 진행하는 불상사가 일어나는 것을 방지하기 위함입니다.
 

중간 보고서 작성하기 #03 : 본론입니다. 현재 상황을 숙지해주세요.

1. 한눈에 알아볼 수 있도록 진척률을 도식화하여 작성합니다.

기획서에 명시된 I.A ( Information Architecture )  기준으로 각 기능별 %에 대한 Progress bar를 작성합니다.

2. Test scope에 대한 CheckList를 작성합니다.

기능별 분류 값을 Depth 별로 구분을 합니다.

그리고 [확인] 칸에는 해당 기능(Depth)에 어떤 주요 기능이 확인되어야 하는지 기입합니다.

그리고 진행 여부에 [ 완료 / 진행 중 / 진행 예정 / X ] 항목을 만들어서 프로젝트 진행 현황을 공유합니다.

중간 보고서 작성하기 #04 : 결함 분석을 진행하겠습니다.

1. 진행된 Issue tracking or Bug tracking을 표와 차트를 이용하여 제공합니다.

현재 검출된 결함이 어느 정도이고, 수정률은 어느 정도인지 한눈에 파악할 수 있어야 합니다.

중간 보고를 통해 앞으로의 결함 도출 및 수정률을 예상하여 

예정된 일정을 앞 당길지, 아니면 연장할지 생각할 수 있습니다.

2. Critical 한 결함은 따로 기입을 진행합니다.

Critical 한 결함은 교과서라고 생각하시면 됩니다.

개발자는 추후 프로젝트 진행 시, Critical 결함이 왜 나왔는지에 대해 Feedback을 통해 재발을 막을 수 있습니다.

3. 기획 관련 이슈도 공유되어야 합니다.

이는 기획서 관리에도 도움이 될 뿐만 아니라 관련 정책을 재확인할 수 있는 기회입니다.

중간 보고서 작성하기 #05 : 특이사항입니다. 

1. 마지막으로 프로젝트 기간 도중 발생된 특이사항에 대해 모두 기록합니다.

저번에도 말씀드렸듯이 모든 업무는 투명하게 진행되어야 합니다.

숨기지 않아야 대처가 가능합니다. 

본인이 실수를 했다거나, 타인이 실수를 해서 지연되는 사항이 있더라고 하더라도 목표를 위해 다 기록되어야 합니다.

그것이 제가 말씀드렸던 " 늘 과정에서 배우고 결과로 증명한다 " 의 철칙입니다.



▼참고▼

2022.10.25 - [QA로 단단해지기/내가 업무 할 때 소통하는 이야기] - [내소기] Episode_#07 : 모든 업무는 투명하게 기록한다.

오늘은 QA 담당자로써 프로젝트 중간보고서는 어떻게 쓸까?

감이 안 오시는 분들에게 조금이나마 도움이 되고자

제가 작성하는 방법을 공유해봤습니다.

물론 각자 회사에서 사용하고 있는 보고서 양식이 있으시다면 사용하셔도 무방합니다.

저 같은 경우에는 QA 프로세스가 확립되어있지 않은 회사에서 

프로세스 구축을 진행하며 여러 양식으로 중간보고서를 작성해 보고 난 후

제일 깔끔하고, 전달력이 좋았던 방법이 위의 방법처럼 작성하는 것이었습니다.

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

다음에도 QA 산출물에 대해 작성해보도록 하겠습니다.

그럼 이만!

두 번째 에피소드입니다.

오늘은 명세 기반 작성법으로 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 마무리하도록 하겠습니다.

오늘은 제가 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 카테고리를 만들어서 여러 에피소드별로 간단하게 포스팅할 예정입니다.

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

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

몇 가지 상황에 어떻게 대처하는지 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 마무리하도록 하겠습니다.

2019년 3월 7일에 작성한 제 게시글 중 가장 인기가 많은 게시글 중 하나인 

https://ddanx2.tistory.com/96

실무에서 쓰이는 ad-hoc testing, 그리고 random testing에 관련된 글이 있습니다.

이때는 QA 경력이 1년차일때, QA 보다는 Tester에 가까운 입장에서 쓴 글이었습니다.

그러나 지금은 하나의 part를 관리하는 part manager 로써 Ad-hoc testing에 관한 제 생각을 써보려고 합니다.

그때 제가 Ad-hoc testing에 대해 마지막으로 제 생각을 적었는데요 한번 보겠습니다.

이때 제가 쓴 글을 하나하나 분석해보겠습니다.

제 생각은 프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때는 Ad hoc, Random testing 둘 다 진행해도 좋다고 생각됩니다.

이 때는 Ad-hoc testing의 매력을 느끼지 못한 상태에서 단순 사전적 의미로 분석하고 제 생각을 적었었는데요.

사실 이때는 Tester의 입장에서 작성해서 둘 다 진행해도 좋다고 썼습니다. 

두 가지 테스트 방법을 동일선상에서 생각했기 때문이죠.

그러나 적재적소에 맞는 Testing 방법이 있습니다. 본인이 판단하기에 Ad-hoc Testing이 필요한 경우에는 Ad-hoc testing을 진행하면 되고, Random Testing 이 필요한 경우에는 Random Testing을 진행하면 됩니다.

다만 제가 하고자 했던 말의 요점은 Ad-hoc Testing 안에 Random Testing 이 포함된다고 느꼈기 때문에 저런 워딩이 나왔다고 생각됩니다.

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.
기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때
결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

이 부분을 작성한 이유는 제가 업무를 할 때 1~2달 사이의 프로젝트 업무를 많이 진행하였습니다.

3일 정도의 기획서 리뷰 기간을 가진 후 5일 정도 Testcase를 작성했습니다.

명세 기반의 Testcase를 작성하다 보면 느끼는 점이 많은데요.

사실 명세서는 유저의 요구사항이나, 유관부서의 요구사항이 반영되어있다고 하더라도 

소프트웨어의 품질을 높이는 데에는 한계가 있습니다.

어떻게 보면 사용설명서 같은 느낌으로 정해진 Step과 정해진 Result 가 나오기 때문입니다.

그래서 정해지지 않은 Step으로 진행하였을 때 소프트웨어 특성상 예기치 못한 Result 가 나오기 때문에

Ad-hoc testing을 진행해야 한다고 생각했던 것 같습니다.

그리고 이 생각을 뒷받침하는 근거로 실제 제가 근무하는 환경에서 Ad-hoc testing으로 나온 critical 한 이슈가 많았기 때문에 더욱더 그렇게 생각한 것 같네요.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.
그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이 부분의 생각은 3년이 지난 지금 많이 바뀌었습니다.

2019년에 간과했던 부분은 Ad-hoc Testing을 진행할 때, Tester 나 QA 엔지니어의 역량이라는 필수 요소를 배제했었던 점이 가장 크게 작용했는데요.

Ad-hoc testing을 매력적으로 보는 이유는 보이지 않는 "역량"에 따라 결과물이 달라지기 때문입니다.

Part manager가 된 지금 QA Team을 구성할 때 제일 먼저 보는 것이 구성원의 경력입니다.

예를 들면,  신입직원, 1년 차, 3년 차, 5년 차 총 4명의 테스터가 있다고 한다면, 저는 신입직원, 5년 차의 Ad-hoc testing 의 결과에 주목할 것입니다.

왜 신입직원의 testing 결과를 주목할 것이냐 의문을 가지실 수 있는데요.

Testing 경력이 얼마 없기 때문에 고정관념이 없고, 예외적인 시도에 대해 열려 있기 때문입니다.

그리고 5년차의 Testing을 주목하는 이유는 베테랑 테스터의 실력을 믿기도 하는 것이지요.

물론 경력이 테스팅 역량을 대변해 줄 수 있는 수단은 아니지만 위험성을 줄일 수 있기 때문에 업무 분배에 참고하고 있습니다.

그래서 제가 하고 싶은 말은

"역량"이 높은 사람은 일정이 촉박해도 Testcase 나 CheckList 설계가 가능하며 동시에 Testing 도 무사히 마칠 수 있습니다.

그래서 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 생각이 바뀌었습니다.

아래 관련 게시글을 보면서 더 이어나가겠습니다.

https://ddanx2.tistory.com/125

제가 Flow Chart 기반으로 Test Case를 작성하는 방법에 대해 공유한 적이 있습니다.

주로 기획문서가 없는 소프트웨어에 대해 Testing을 진행할 때 사용하는데요.

옛날에는 기획문서가 없는 소프트웨어에 대해 Ad-hoc Testing으로만 진행될 수 있다고 말했지만

이제는 역으로 기획문서가 없어도 소프트웨어를 보고 Flow Chart를 작성할 수 있고, 그 Flow Chart 를 기반으로 Test case , Scenario 등 여러 문서를 작성할 수 있는 실력을 갖추었습니다.

그래서 2019 년과는 다르게 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 말하고 싶습니다.

결국 지금 와서 생각해보면 2019년의 제 QA 역량과, 2022년의 제 QA 역량이 다르고 그만큼 성장했기 때문에 생각이 바뀌었다고 볼 수 있습니다.

이제 또 3년 뒤에 저는 해당 글을 다시 가지고 와서 2025년에 작성하는 Ad-hoc testing에 대한 나의 생각 이런 식으로 포스팅을 할 수도 있겠네요.

아무튼 밤에 두서없이 쓴 글이긴 하지만 읽어주셔서 감사합니다.