오늘 포스팅할 내용은

나는 어떤 강점이 있는 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분야에 많은 관심을 가지고 업무에 임하는것이 이번년도 작은 목표입니다.!

이번 글을 작성하면서 

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

"우리글 바로 쓰기"

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

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

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

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

그리고

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

책도 선물받았는데요.

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

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

그럼 오늘은 여기까지 ㅡ ★

오늘 포스팅할 내용은

state-of-quality-report-2022

을 주관적으로 분석한 글입니다.

관련 자료는 아래 링크에서 다운로드하여보실 수 있습니다.

제 글을 읽으시기전에 한 번 본인의 생각은 어떤지 

정하고 보시는 걸 추천드려요.

팀 내에서만 공유했지만 혼자보기 아까워서 개인 블로그에 올립니다~!

https://katalon.com/state-quality-2022

요약

Katalon 에서 소프트웨어 품질에 대한 설문 조사와 분석을 바탕으로 작성된 리포트입니다.

QA 업계에서 일어나는 변화, 테스트 자동화와 인공지능 기술의 활용 등에 대한 정보를 제공하는 문서입니다.

머리말

요즘 빠르게 변화하는 세상에서, 조직들은 소프트웨어 품질(QA) 관행에서의 개선을 위해 내부와 외부 모두를 살펴야 합니다. 소프트웨어 품질을 빠른 속도로 제공하는 데에 대한 강점과 약점을 결정하기 위해 자신들의 관행에서 생성된 정보와 데이터를 수집하고 분석해야 합니다. 동시에, 그들은 각자의 산업에서 현재 상황과 트렌드를 찾아내야 합니다.

이 보고서는 3,000명 이상의 응답자를 대상으로 한 조사 결과를 바탕으로, 현재 소프트웨어 품질의 상태를 스냅숏으로 담아내며, QA 기술, 관행, 도구에 대한 통찰력과 트렌드를 예측합니다. 우리의 연구는 소프트웨어 엔지니어, QA 엔지니어, 분석가 및 관리자를 대상으로 조사되었으므로, 이러한 소프트웨어 품질을 보장하는 데 직접 관여하는 사람들의 의견과 목소리를 반영합니다.

본문

결론(이라 쓰고 3줄 요약이라고 적기)

자동화 테스트는 생각보다 많은 팀이 사용하지 않는다.

그럼에도 필요한 기술이다.

왜냐면 자동화를 도입한 팀들은 시간과 비용을 절약했기 때문이다.

상업적인 목적으로 만들어진 자료이기 때문에 100% 맹신할 필요는 없습니다.

그냥 이런 흐름이 있구나~라고 가볍게 보는 걸 추천드려요!

58 page 중에 3분의 1 정도는 Katalon이 어떤 회사인지... 알 수 있습니다.

참고 링크

https://xmlangel.kr/posts/2023-04-10-Katalon-2022-Report : 다른 분들은 어떻게 분석했나 보고 싶었는데 해당 블로그가 많은 도움을 주었습니다.

위 글은 Katalon에서 만든 자료를 제 개인적인 생각을 넣어서 분석한 글이기 때문에 모든 저작권 및 권한은 Katalon에 있습니다.

안녕하세요!!

오늘은 처음 써보는 유머글입니다.

인터넷에서 재밌는 걸 봤는데

이걸 QA 엔지니어 관점에서 봤을 때

단위테스트만 진행하고 통합테스트를 진행하지 않은 결과물

관련한 짤(gif)을 보도록 하겠습니다.

옷 다 젖는 수도꼭지

잠금장치만 확실한 문

이중 보안

보는 사람만 재미있는 워터 슬라이드

좋지 못한 곳에 설치된 물비누 디스펜서

위의 짤(gif)만 봐도

왜 통합테스트가 이뤄져야 하는지 이해가 되시죠??

그냥 웃고 넘길 수 있는 짤(gif) 지만

QA엔지니어 관점에서 다시 보니 웃음과 교훈도 얻을 수 있었습니다.

그럼 이만!

출처 : https://m.cafe.daum.net/dotax/Elgq/3359298?svc=topRank

1. JMeter 초기 진입 상태

초기 화면입니다.

테스트를 위해 왼쪽 상단의 Test Plan 에 마우스 커서를 올려 놓은 후 우측 클릭

Add > Threads(Users) > Thread Group 를 순차적으로 클릭해 줍니다.

2. JMeter 테스트를 위한 기본 설정

위에서 만든 Thread Group 에서 

설정하고 싶은 값을 설정합니다.

위와 같이 

Action to be taken after a Sampler error : Continue

Number of Threads (users) : 10

Ramp-Up Period (in seconds) : 1

Loop Count :3

으로 설정을 하였다면

3. JMeter 테스트를 할 페이지 설정

테스트 페이지 설정 위해 왼쪽 상단의 Thread Group 에 마우스 커서를 올려 놓은 후 우측 클릭

Add > Sampler > HTTP Request 를 순차적으로 클릭해 줍니다.

Http 요청을 서버에 전송하여 결과를 받아오기 위한 설정단계입니다.

설정 후 결과 보기는 다음 포스팅에 진행하도록 하겠습니다.

1. JMeter 설치하기

링크(https://jmeter.apache.org/) 를 클릭하고, APACHE JMeter 에 접속합니다.

왼쪽 상단에 Download Releases 클릭

apache-jmeter-5.4.1zip 을 클릭하여 다운로드 받습니다.

압축파일 풀어주시면 설치는 끝납니다.

2. JMeter 실행해보기

apache-jmeter-5.4.1\bin (bin 폴더 경로로 이동)

으로 가서 jmeter Windows 배치 파일을 실행해 줍니다.

JMeter Windows 배치 파일을 실행해주면

위와 같은 cmd 창이 뜨면서 실행이됩니다.

(cmd창을 종료하면 JMeter 도 종료되니 조심!)

cmd 창과 JMeter가 같이 실행되는걸 보실 수 있으십니다.

그럼 간단하게 설치방법과 첫 실행까지 알아보았습니다.

다음 포스팅은 기본적인 사용법을 알아보도록 하겠습니다.

감사합니다.

1. JMeter 란?

→ 웹 애플리케이션을 중심으로 다양한 서비스의 성능을 분석하고 측정하기 위한 부하 테스트 도구로 사용할 수 있는 아파치 프로젝트이다.(요약)

→ 웹 애플리케이션 처럼 클라이언트-서버 구조로 된 소프트웨어의 성능 테스트를 위해서 만들어진 자바 프로그램이고,  JMeter는 단위/성능/스트레스 테스트 등 많은 곳에서 활용할 수 있다.

→ JMeter는 통신 프로토콜 단계에서만 동작하고 웹 브라우저에는 동작하지 않는다.

즉 , 통신규약에 맞도록 클라이언트와 서버 간 메시지만 송수신할 뿐이고 클라이언트 자체에서 행해지는 연산동작은 하지않는다.

2. 성능테스트 란?

→ 서비스 및 서비스 시스템의 성능을 확인하기 위해 실제 사용 환경과 비슷한 환경에서 테스트를 진행하는 것을 말한다. 이를 통해서 Response Time(응답시간) 과 Throughput(처리량), 병목구간 등을 확인할 수 있다.

성능 테스트로 얻은 정보로 서비스나 서비스 시스템의 문제점을 확인하고 이를 개선하여 보완할 수 있다.

ⓐLoad 테스트

▶ 시스템의 성능을 벤치 마크하기위한 테스트를 의미한다.

Load(부하) 를 순차적으로 증가시키면서 응답시간이 급격히 증가하거나 더는 처리량이 증가하지 않거나 시스템의 CPU와 Memory 등이 기준값 이상으로 증가하는 등 비정상 사태가 발생하는 접점(임계점)을 찾아내고 이를 바탕으로 성능 이슈에 대한 튜닝과 테스트를 반복한다.

ⓑStress 테스트

▶ 임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태를 확인하고 시스템의 최고 성능 한게를 측정하기 위한 테스트를 의미한다.

ⓒSpike 테스트

▶ 갑자기 사용자가 몰렸을 때 요청이 정상적으로 처리되는지 그리고 그 업무 부하(Workload) 가 줄어들 때 정상적으로 반응하는지를 확인하기 위한 테스트를 의미한다.

ⓓStability 테스트/ Soak 테스트

▶ 긴 시간동안 테스트를 진행해서 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의 변화를 확인하는 테스트를 의미한다.

출처: Apache JMeter
오픈소스로 대용량 웹 서비스 성능 테스트하기

한빛미디어

장재만

사용자 기준의 속도측정 테스트를 통해 알게된 동영상 분석 소프트웨어 Kinovea

오늘은 설치하는 방법과 간단한 소프트웨어 소개를 해보겠습니다.

https://www.kinovea.org/

다운로드 링크입니다.

Kinovea 는  스포츠 분석을 위한 비디오 플레이어지만,

사용자 UX 기반의 테스트를 해보려고 하다가 알게된 비디오 분석 tool 입니다.

일단 링크로 들어가셔서 다운로드를 누른 후

실행파일을 더블클릭 해줍니다.

아쉽게 도 한국어는 지원되지 않습니다.

[NEXT] 눌러주시고요.

kinovea License 에 동의해주시면 됩니다.

저장 파일을 지정해주시고요.

32.5mb 필요합니다!

Stat Menu Folder 를 지정해주시고 

Install 눌러주시면 됩니다.

설치 완료입니다.

간단한 사용법은 

다음글에 포스팅하도록 하겠습니다.

오랜만에 QA 관련 글을 포스팅해봅니다.

QA 업무를 진행하다 보면

테스트 케이스를 모두 수행한 프로젝트에 대해 종종 ad hoc testing을 진행하곤 합니다.

ad hoc의 사전 의미는

입니다.

즉, 다시 정리해서 말하자면

비공식적으로 수행하는 테스팅이다.

 

공식적인 테스트 준비 작업 없이, 공인된 테스트 설계 기법을 적용하지 않고, 예상 결과를 사전에 정의하지 않고, 자의적이고 임의적으로 실행하는 테스트 활동을 의미한다.

실 업무에서 설계한 테스트 케이스를 모두 마친 후, 말 그대로 예상 결과를 정의하지 않고 테스트를 하다 보면

소프트웨어 특성상 결함이 발생될 수 있기 때문입니다.

실제로도 AD-HOC testing에서 발생된 결함은 예상외의 결과를 가져다 주기 때문에 결함의 중요도가 크리티컬 하거나 또는 엄청 마이너 하게 나타나지요.

그리고 저도 헷갈렸지만. 흔히들 하는 실수로

랜덤 테스팅 (Random testing)과 애드 혹 테스팅(ad hoc testing)을 동일 의미로 사용하는 경우가 많습니다.

의미상은 비슷한 것 같지만

테스팅적으로 깊게 들어가자면 엄연히 다른 내용입니다.

테스트 케이스를 설계할 때, 특정 범위나 값, 집합에 대해서 동등 분할, 경곗값을 등을 주고 테스트 케이스를 설계하고 수행하게 됩니다.

근데 Random testing은 테스트 설계 기법을 통해 입력값을 따로 설정해 주지 않고 임의로 값을 선택해서 수행하는 방법입니다.

어떻게 보면 비슷한 기법이지만 미묘한 차이가 있다는 점을 알아주셨으면 좋겠습니다.

그렇다면,

Ad hoc testing , Random testing은 언제 이루어져야 할까요?

프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때?

아니면 기간이 촉박한 프로젝트에서 테스트 케이스 수행이 어려울 때?

기획문서가 없는 소프트웨어의 테스트를 진행할 때?

모두 사용 가능합니다. 물론 다른방법도 있으니 Ad hoc testing 이 최선의 방법은 아니라는 점!!

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

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.

기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때

결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.

 

그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이상입니다..

피드백 환영입니다.!!


++ 2022년에 해당 글에 대한 제 생각을 적은 게시글입니다.
https://ddanx2.tistory.com/133