문성준의 단단해지기

내가 업무 할 때 소통하는 이야기

야심차게 준비하였습니다. 내 소 기 !!!

내가 업무 할 때 소통하는 방법들을 정리해놓은 이야기를 펼쳐보려고 합니다.

Episode 별로 상황에 따라 소통했던 방법들을 재미로 보는 시간을 가지려고 합니다.

왜 이 코너를 준비했냐면,

QA 업무는 꼼꼼함? 높은 집중력? 다 좋습니다.

그러나 저는 개인적으로 높게 평가하는 능력이 하나 있습니다.

제가 면접관 업무를 볼 때나, 신규 인력 교육할 때 파악이 되는 능력 중 하나입니다.

바로 커뮤니케이션 능력인데요.

거의 5년 가까이 QA 업무를 하면서 느낀 점은 효과적인 커뮤니케이션은 

내 부족한 능력치를 채워줄 수 있다고 느꼈습니다.

그래서 실무에서는 제가 어떻게 커뮤니케이션을 하며 

임기응변을 진행했는지 공유해보려고 합니다.

일단은 경험의 기록의 목적으로 쓰려고 했으나

재미적인 요소도 있어야 할 것 같고요 또 교육적인 목적도 있어야 할 것 같습니다.

그리고 QA 업무를 지망하는 취준생들에게도 많은 도움이 되었으면 좋겠네요.

 다음 에피소드로 만나요~~

실무를 할 때, 요구사항 명세서 (기획서) 기반으로 Testcase를 설계하는 경우가 많습니다.

그래서 업무를하면서 과장하면 100개 이상의 기획서를 확인했다고 해도 과언이 아닐 정도인데요.

같은 기획서를 봐도 QA 엔지니어의 역량에 따라 다른 Testcase가 설계되는 경우가 많습니다.

물론, Testcase가 다르더라도 소프트웨어의 품질 향상이 목적이기 때문에 큰 문제는 없습니다만

효율적으로 업무를 하기 위해서는 우리는 빠르게 접근할 수 있어야 합니다.

그래서 제가 Testcase를 설계할 때 사용하는 방법 중 하나는

FlowChart를 작성하고 그 FlowChart 기반으로 Test case, Scenario 를 작성하는 것입니다.

Flow Chart 를 작성하는 방법은 아래와 같습니다.

위의 세 가지만 구분된다면 Flow Chart를 쉽게 작성 할 수 있습니다.

예를 한번 들어보겠습니다.

세가지 STEP으로 진행해보겠습니다.

Flow Chart를 도식화 하기 위해서는 소프트웨어의 간단한 설명(또는 기획서)에서 

요구사항이 무엇인지, 핵심이 무엇인지 빠르게 파악을 해서 요약을 해야 합니다.

그리고 여기서 Flow Chart의 세 가지를 도출해낼 수 있어야 합니다.

#Step 1#

▶Condition : 유저, 교육용 App

▶States : 메인 화면, 내비게이션 드로어 화면, 학습 유형 선택 화면, 자음/모음 선택 화면, 학습 화면

▶Actions : 유저가 각 화면에서 상호작용 할 수 있는 항목들을 기록( 선택, 클릭, 스와이프, 스크롤 등등..)

##Step 2##

요구사항 도식화

###Step 3###

Flow Chart 기반의 Test case, Scenario 작성

위에서 작성한 Flow Chart 기반으로 아래와 같은 case가 도출됩니다.

예시를 들기 위해서 만든 요구사항과 Flow Chart 이므로 굉장히 간단하고 쉽습니다.

이를 응용하는 것은

프로젝트에 참여하는 이해당사자(기획자, 디자이너, 개발자 등등) 에게 프로젝트를 쉽게 설명할 수 있을뿐더러

접근하는 데에 오랜 시간이 걸리지 않습니다.

Testcase 리뷰 기간에 사용하는 것이 적절할 수 있겠네요.

마지막으로

저는 실무를 진행할 때, 유스 케이스 다이어그램을 사용하여 프로세스를 따로 정의하지 않습니다.

제가 하고 있는 업무 환경에서는 불필요한 동작이기 때문이죠.

그러나 Testcase 설계를 진행할 때에는 꼭 노트와 펜으로 도식화나 Flow Chart를 그린 후 Testcase 설계를 진행합니다.

Flow Chart를 그리다 보면 기획서의 오류에 대해 알 수 있고,

전반적인 테스트 흐름도 머릿속에서 시뮬레이션할 수 있기 때문입니다.

따라서 이번 글에서 하고 싶은 말은 제가 쓴 글은 단순 참고 대상입니다. 

본인이 QA를 진행할 때, 설계 때부터 테스트가 어떻게 진행되는지에 대한 시뮬레이션을 2~3번 머릿속으로 진행해 봐야

미리 예정해두었던 일정에 차질이 없이 진행될 것입니다.

그럼 모든 QA 엔지니어 분들 파이팅입니다.

1. JMeter 란?

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

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

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

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

2. 성능테스트 란?

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

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

ⓐLoad 테스트

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

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

ⓑStress 테스트

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

ⓒSpike 테스트

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

ⓓStability 테스트/ Soak 테스트

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

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

한빛미디어

장재만

안녕하세요

이번에는 PICT 의 설치 및 실행 방법에 대해 알아보겠습니다!

cmd 창에서 명령어를 입력해야하니

미리 cmd 명령어를 숙지하는게 좋을 것 같습니다.

오랜만에 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

더위에 지쳐 무기력 해져 있을때,

이대로 있으면 더욱 무기력해질까 싶어 "50000\" 을 주고 신청한 CSTS 자격시험!!

CSTS는 SW 테스트 전문가 자격증이다.

자세한 설명은 TTA 홈페이지에 나와있다.

TTA 아카데미 ( https://edu.tta.or.kr/) 에서 신청할 수 있습니다.

개인적인 능률도 올리고, 직무적으로도 도움이 될 것 같아 신청을했다.

신청하고 놀다보니 10일도 안남았다...

물론 첫술에 배부르면 좋겠지만 (정보처리기사때 쓴 맛을 너무많이 보았기때문에...)

아무튼 열심히 해보려고 한다.

good luck!

 "테스트 프로세스의 기초"에 대해 이야기 해보려고 한다. 

 테스트 프로세스 주요활동 에는 아래와 같이 5개로 구분할 수 있다.

<<테스트 프로세스 주요활동>>

 

1. 계획과 제어(Planning and Control)

 

2. 분석과 설계(Analysis and Design)

 

3. 구현과 실행(Implementation and Execution)

 

4. 완료 조건의 평가와 보고 (Evaluating exit criteria and Reporting)

 

5. 테스트 마감 활동(Test Closure activities)

테스트 프로세스는 순차적이지만, 프로세스 내의 활동들은 중복되거나 동시에 발생할 수 있다.

1.     테스트 계획과 제어

-계획 : 테스팅의 미션과 목표를 정의하고 이를 만족 시키기 위한 테스트 활동을 수립하는 과정 , 모니터링 및 통제 활동의 피드백에 따라 조치를 할 수 있도록 수립되어야 한다.

 

-제어 : 실제 진행 상황과 계획을 비교하고 보고하는 활동 ,프로젝트의 미션과 목표를 위해 조치가 이루어 질 수 있다.

이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어야 한다.

2.     테스트 분석과 설계 

 

-테스팅 목적에 부합하는 테스트 상황과 테스트 케이스를 생성한다.

 

-자료 리뷰( 요구사항 ,디자인 등) , 테스트 케이스 설계와 우선 순위를 선정한다.

 

-테스트 상황과 테스트 케이스에 필요한 데이터 식별 및 환경과 도구를 확보한다.

 

3.     테스트 구현과 실행 

 

-테스트의 조건들을 테스트 케이스로 전환하고 이를 위한 환경을 갖추는 일련의 활동을 말한다.

 

-계획된 절차에 따라 테스트 케이스를 직접 또는 자동화 툴을 사용하여 수행한다.

 

-테스트 실행 결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전 등 테스트 기록을 남긴다.

 

-실제 결과와 기대 결과를 비교 후 불일치 시에 원인을 기록하거나 원인을 모르겠다면 발생 되기 까지의 프로세스를 남긴다.(반복적 , 간헐적인지 기록)

 

4.     테스트 완료 조건의 평가와 보고 

 

-테스트 수행 결과를 목적과 비교하여 평가한다.

 

-이해관계자들을 위한 테스트 요약 보고 작성한다.

 

5.     테스트 마감 활동 

 

-모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합하기 위해 모든 데이터를 수집하고 완료한다.

이론적으로 이러한 프로세스를 바탕으로 테스트를 진행하게 된다.

그러나 이론과 실무에는 크다고하면 크고 작다고하면 작은 차이가 있으니

기본에 중점을 두고 테스팅하면 결함을 발견하는데 도움이 될 것이다.

후회없는 결정을 하기위해 집어든 책!

어쩌면 4차 산업혁명 시대인 지금에 딱 걸맞는 책인 것 같은 생각도 든다.

롤프 도벨리의 스마트한 선택들에 관한 얘기이다.

‘ 손 하나 까딱 안하고 실적을 올리는 방법’ 이 있을까?

아래의 예를 보면 이해할 수 있을것이다.

텔레비전 채널 A 의 시청률은 높고, 채널 B 의 시청률은 낮다. 회사에서는 당신에게 이 두 채널의 시청률을 높이라고 요구한다.

만약 높이지 못한다면 해고의 위기가 발생하고, 높인다면 엄청난 금전적 보상을 받게 될 것이다.

기간은 6개월 , 당신은 어떻게 할 것인가?

 (채널 A의 평균 시청률은 40% 채널 B의 평균 시청률은 15%)

답은 간단하다. 채널 A 의 평균 시청률에는 못 미치지만 채널 B 보다는 높은 시청률의 채널 A의 프로그램 하나를 채널 B로 옮기는 것이다.

그렇게 된다면 A의 평균시청률을 하락시키고 있던 프로그램이 B로 옮겨지는 것이기 때문에 채널 A의 평균 시청률은 소폭 증가할 것이고, 

채널 B의 시청률도 새롭게 편성된 A의 프로그램으로 인해 시청률이 올라가게 될 것이다.

프로그램의 편성만 바꿨을 뿐이다. 새로 편성하거나 , 기존 프로그램을 삭제하지도  않았다.

(채널 A의 평균 시청률은 45% 로 5%증가, 채널 B의 시청률은 20%로 5% 증가)

간단한 ‘무대의 이동’ 만으로 평균 수익률을 상승시킬 수 있다.

이런 효과를 미국 오클라호마 출신의 코미디언 윌 로저스의 이름을 따서 ‘윌 로저스 현상(Will Rogers Phenomenon)” 또는 ‘무대의 이동’ 이라고 부른다.

이 개념은 윌 로저스가 ‘오클라호마를 떠나 캘리포니아로 이주한 사람들 덕분에 오클라호마와 캘리포니아 양쪽 주에 사는 주민들의 평균 지능지수가 상승했다’ 라는 농담을 한 것에서 생겨났다.

어떻게 보면 조삼모사일 수도 있는 기발한 현상은 이미 우리가 무의식중에 사용하고 있을지 모른다.

 

테스팅 예를 들어보면 '프로그램 테스팅을 1,2,3차수를 모두 할 것인가' 아니면 '사전 테스팅 진행 후 1,2차 테스팅을 진행할 것인가' 의 차이이다.

 

결국엔 두 테스팅 모두 3번의 테스팅을 진행해야 하지만 사전 테스팅을 진행함으로써 제품 전반적인 이슈에 대해 파악하는 것이 더 효율적일지도 모른다는 내 개인적인 생각이다.