열린 공간, 누가바닷컴

무료로 사용가능한 Testcase를 공유 합니다.

∞ 기시감 — Mon, 20 May 2013 17:49:27 +0900

안녕하세요. 오랫만의 테스팅 관련 글입니다. 그동안에 뭘 했냐면 구글 드라이브의 스프레드시트를 이용한 무료 Testcase 서식을 만들었습니다.

구글 드라이브 무료 Testcase

문서를 열면 Summary 페이지가 먼저 보입니다. 아래 탭을 확인하면 Summary Data, Testcase, Bug List의 4개 탭이 있습니다. 우선 Summary 페이지부터 보겠습니다.

맨 위에는 진행중인 프로젝트 명이 들어가고 아래에는 진행된 테스트중 나온 버그들중 중요한 이슈를 담고 있는 버그 리스트를 넣습니다. 중요도 높음인 문제가 주로 들어 갈 수 있겠지요. 문서를 보는 사람에게 중요한 문제를 각인시키는데 필요한 내용입니다. 참고로 버그의 중요도는 사전에 개발자들과 어느정도 합의가 되어 있는 것이 좋습니다. 물론 문제란게 그 합의된 범위 외에서 나오는 경우도 많습니다만. 사전 상의를 통해 개발자들과의 불필요한 커뮤니케이션 시간을 줄일 수 도 있습니다.

그 아래에는 진행된 테스팅 차수에 대한 결과를 볼 수 있습니다. 예제 문서에는 버전별 결과물로 나오지만 사정에 따라 차수별로 바꾸셔도 됩니다. 문제의 중요도별 변화량과 Testcase의 차수별 성공율 변화를 확인 할 수 있습니다. 막대 그래프는 아래로 깔릴 수록 좋은 것이고 Test 성공율은 올라갈 수록 좋은 것입니다. 해당 그래프에 데이터를 반영하기 위에서는 아래의 탭중 Summary data 탭으로 이동해야 합니다.

Summary Data탭의 화면입니다. 매우 단순합니다. 그냥 셀에 맞는 내용을 적어주시면 반영됩니다. 반영이 잘 안 될 경우에는 챠트의 고급수정에서 데이터 영역을 다시 지정해 주면 됩니다. 엑셀과 거의 동일하니 엑셀을 좀 다루 실 줄 아시면 쉽게 수정 가능합니다.

다음은 Testcase 탭입니다. 프로젝트 이름은 당연히 해당 프로젝트의 이름을 적습니다. 오른쪽에는 Version을 넣는 곳이 있습니다. SVN의 Revison으로 관리하는 곳이 있기도 하니 입맛에 맞춰서 수정하면 됩니다. 아래를 보면 pass, fail, block의 수와 함께 총 Testcase 갯수, Test 성공률이 나오는 영역이 있습니다. 이쪽은 자동으로 입력이 되도록 만들어져 있습니다. 그럼 그 아래가 진짜 Testcase 입니다. 참고로 해당 Testcase는 게임 도메인에서 주로 쓰는 서식입니다. 그리고 위에 대중소분류 및 조건 결과와 같은 내용이 있는데 해당 내용은 꼭 맞춰서 쓰지 않아도 됩니다. 적당히 수정해서 사용하면 됩니다. 테스트 결과는 o,x,b만 입력가능하게 되어 있습니다. 조건부서식과 데이터 확인 옵션이 들어가 있는데 역시 환경에 맞춰 수정해서 사용하시면 됩니다. 참고로 열을 추가하거나 삭제 할 경우 테스트결과를 참조하여 위에 테스트 결과 영역이 자동으로 입력되도록 한게 어긋 날 수 있습니다. 기본 엑셀을 다룰 줄 아신다면 쉽게 고치는 법을 아실거라 생각합니다.

마지막 Bug list 탭입니다. 테스트 중 발견된 Bug를 정리하는 부분입니다. 왼쪽부터 입력되는 내용은 다음과 같습니다.

no. : 번호
Version: 문제가 발생한 Client Version 을 기록합니다. Revison을 사용하기도 합니다.
Tester : 해당 문제를 발견한 테스터의 이름을 적습니다.
담당자 : 해당 문제를 담당한 사람의 이름을 적습니다. (ex: 프로그래머, ui, 아티스트 등등)
분류 : 문제를 분류 할 수 있다면 분류를 적어 두는 것이 좋습니다. (ex: UI, 파티 시스템, 채팅 시스템, 성장 시스템 등등)
중요도 : 문제의 중요도를 기록합니다. 당연하지만 심각 일 수록 바로 수정되어야 하는 문제입니다. 모든 문제를 심각으로 할 경우 개발팀과 살인 피구가 벌어 지기도 합니다.
상태 : 문제의 상태를 기록합니다. BTS의 기본 시스템을 따르고 있습니다.
- 새로운문제: 테스터가 새로운 문제를 등록 시 지정
- 문제확인: 담당자가 해당 문제를 확인 했을 경우 지정. (담당자가 직접 변경)
- 문제수정: 담당자가 해당 문제를 수정 했을 경우 지정 (담당자가 직접 변경)
- 완료: 테스터가 해당 문제가 수정 된 것을 확인 했을 때 지정 (테스터가 직접 변경)
- 재수정요청: 테스터가 해당 문제가 수정 되지 않은 것을 확인 했을 때 지정 (테스터가 직접 변경)
내용 : 문제의 내용을 상세하게 기록합니다. 문제를 적는 방법은 이전 포스트 "당신의 버그 리포트에 꼭 들어가야 할 내용들"을 참고 합니다.
담당자 comment는 필요할 경우 담당자가 Comment를 남길 때 사용합니다.

해당 문서의 사용 방법은 위 내용만 알면 끝입니다. 문서를 사용 하실 때는 위 링크의 문서에 바로 수정은 안되니 사본을 만들어 본인의 구글 드라이브로 복사 후 이용 하시면 됩니다. 엑셀과 관련된 내용에 대해서는 구체적인 언급을 안하고 있습니다만 위 문서에 사용된 엑셀 관련 스킬은 정말 난이도 하급으로 어렵지 않습니다. 독학으로도 어렵지 않게 배우 실 수 있을거라 생각합니다. 이제 해당 문서를 만들게 된 경위에 대해서 썰을 풀까 합니다. 혼자 썰을 푸는건 심심하니 저희 집 고양이를 불러 대담을 진행해 보도록 하겠습니다.

: 안녕하세요. 성장이 없는 8Bit Dog의 주인 하선생입니다.

기시감 : (사료통을 흔든다)

: 죄송합니다. 바로 질문으로 넘어가죠. 왜 이 문서를 만들게 되었죠?

기시감 : 이유는 여러가지가 있습니다만 현재의 목표는 2개 입니다. 편하게 공동 작업을 할 수 있도록 하는 것과 테스트에 대해 생소한 분들에게 쉽게 다가가기 위한 이유 입니다.

: 공동 작업을 할 수 있다는 건 동시에 일을 할 수 있다는 것인가요?

기시감 : 게임 테스트의 경우 게임의 장르에 따라 한 게임에 몇십명이 되는 테스터가 같이 테스트를 하는 경우가 많습니다. 아마도 대부분의 작업 환경은 테스터 모두 따로 엑셀 문서에 테스트 결과를 작성하고 그걸 lead에게 보내면 lead가 취합하는 경우 일 것입니다. 하지만 구글 드라이브 문서를 이용하면 동시에 여러명의 사용자가 하나의 문서를 열어 동시에 작업을 하는게 가능 하더군요. 거기에 작업 내용또한 수시로 백업이 됩니다. 온라인에서만 사용 할 수 있다는 제약이 있지만 효율성 높은 작업 환경을 만들어 준다고 생각합니다. 그리고 모바일 디바이스에서도 쉽게 문서를 작성 하고 수정 할 수 있다는 점도 장점입니다. 클라이언트와 엑셀을 왔다갔다하며 작업 하는 것보다 외부 디바이스에서 테스트 결과를 바로바로 처리 할 수 있다는 점은 분명한 장점입니다.

: 테스트에 생소한 분들에게 쉽게 다가가기 위함이란 건 무슨 말인가요?

8 Bit Dog : 해당 문서를 만들던 초반에 운 좋게도 한 모바일 게임 스튜디오의 테스트 업무를 도와주게 되었습니다. 개발자 분들은 QA에 대해서 처음 경험하는 상황이었고 저는 간단하게 그분들과 커뮤니케이션과 업무를 할 수 있는 Tool 이 필요하게 되었죠. 맨티스나 레드마인과 같은 툴도 있습니다만 그런 걸 준비할 환경은 안되었기 때문에 작업중인 문서에서 해당 툴의 기능을 최소한적으로 적용 할 수 있도록 해봤습니다. 그 결과 거창한 툴보다는 오히려 최소화 되었지만 집중된 기능이 더 낫다는 생각을 가지게 되었습니다. 기본적인 테스트의 프로세스를 경험 시켜 드릴 수 있었으며 엑셀 문서와 가깝기 때문에 친숙했죠. 아마도 맨티스, 레드마인 툴을 사용하게 될 기회가 오더라고 금방 적응 하실 수 있을 거라 생각합니다.

: 지금까지 주구장창 장점만 얘기 하셨는데 단점은 없는 겁니까?

기시감 : 물론 있습니다. 온라인 상태에서만 제 역활을 할 수 있다는 점이지만 요즘 같은 시대에 이정도는 커버 되겠죠. 그리고 또 단점을 꼽자면 간략화 되어 있기 때문에 파워풀하게 사용 할 수는 없다는 것입니다.

: 파워풀이요? 이건 무슨 보그병신체인가요..

기시감 : 죄송합니다. 파워풀하다는건 예를 들자면 이 문서의 Bug list는 맨티스와 같은 전문 BTS 툴과 비교하자면 트래킹 기능에서 매우 약합니다. 이런 부분은 전문 툴만이 가질 수 있는 강점이죠. 뭐 그런 걸 얘기하는 거였습니다.

: 그렇군요. 그럼 마지막으로 하실 얘기 부탁 드리겠습니다.

기시감 : 모바일 디바이스 시장이 활짝 열리며 작은 개발 스튜디오가 매우 많이 생겨 났습니다. 모두들 좋은 게임을 만들기 위해 노력하고 있다고 생각합니다. 테스트라는 것은 언제나 성공 이후에 따라오는 것이었습니다. 하지만 그건 이제 과거 이야기라 생각합니다. 성공하기 위해서 더욱 필요한 것이 테스트입니다. 여러분들이 만드는 좋은 게임에서 버그가 1개가 있으면 그 버그를 체험하는 유저가 1000명이라면 1000명의 실망하는 유저가 생겨나는 것입니다. 테스트는 어려운 것이 아닙니다. 제 문서가 조금이라도 도움이 되어 좋은 게임이 좋은 품질로 완성 되었으면 합니다. 감사합니다.

더불어 누가바의 경우 현역으로 쟁쟁하게 일하는 테스터분들도 많으니 해당 문서를 보고 더 개선할 점들을 얘기해 주신다면 많은 도움이 될것이라 생각합니다.

감사합니다. :)

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그)

별의카비 — Sun, 12 May 2013 15:47:04 +0900

글리치와 그래픽버그

안녕하세요. 그러합니다. 글리치를 알아보기 위한 모험을 위해서 준비중입니다.

글리치는 어떤 것일까요. 어감상 글리치는 어딘가 긁힌 듯한 느낌을 주곤 합니다. 그리고 셀버그도 알아볼 것입니다.

언뜻보면 두가지가 그래픽이 깨지는 비슷한 유형처럼 보입니다. 물론 게임에서는 그렇게 분류를 하는 경우도 있긴합니다.

(윗분들은 셀버그나 글리치나.. 그냥 깨지는걸로 보이니까요) 셀 버그는 공식적인 용어는 아닙니다. 뭐 여러가지의 업계

용어가 있겠지만 이게 다 다를 수도 있어요. 툴마다 게임엔진마다 게임마다 그리고 성향에 따라 방식에 따라서 말이지요

뭐라고 표현하기가 모호해서 그래픽 오류라고 하기에도 좀 그래서, 비교적 알기 쉽게 풀어서 하나의 그래픽 인터페이스가

오동작을 일으킨다고 생각하시면 편하실 겁니다.

http://noogabar.com/357

이미 천재모노님께서 쓰신 글리치와 버그의 글은 있으니 참조 하시고 오신다면, 이해가 더 쉬우실 겁니다. 물론 제가 잘못

알고있는 사실도 있을 수 있으니, 지적도 주시면 감사하겠습니다.

1. 글리치

글리치를 정의를 하자면, 많은 설명까지 해야 할 수 있습니다. 글리치는 주로 하드웨어적인 문제가 대부분인 경우가

많습니다. 원인에 대해서는 아래에서 살펴보기로 하고, 글리치는 하드웨어의 오동작에 의해 생기는 잔상 / 오동작 / 그래픽적인 문제 / 전송 오류 / 노이즈

등을 포함 한다고 할 수 있습니다.

글리치가 왜 일어나는건가?

글리치의 예를 들기 위해 몇가지 예를 들어보겠습니다.

-모바일

> 모바일 글리치는 주로 주파수가 일정치 않거나, 전력 부족 현상, 메모리 누수가 대표적인 예입니다.

피쳐폰 보다도, 스마트 폰에서 매우 많이 나타나곤 합니다. 스마트폰의 경우 피쳐폰 보다도 여러가지 기기가 내장 되어있습니다.

예를 들면 배터리를 중심으로 액정 / 터치 패널 혹은 칩셋 / 스피커 / GPU / 카메라 기기 / 통신 칩 / 메인 보드버튼(쿼티자판이 있을

경우- 예 = 블랙베리) 외에도 수많은 부품이 들어 갑니다. 이 중에서 단연 충돌이 많이 나서 터치가 안되는 문제를 발생시키는

부분은 메모리나 / SD카드 인식속도나 포멧 문제 / 블루투스의 채널이 00000(NULL) 이라던가/내가 충전한 배터리는 분명히

15%가 남았는데 계속 꺼지거나 화면이 줄어들었다가 커진다던가 배터리를 연결해 달라던가 하는문제들이 휴대폰에 오류를 일으키는

부분이 있습니다. 이러한 것은 비단 소프트 웨어적인 문제만이 아니라 기기간의 호환성충돌로 나타나는 경우가 있습니다.

전력부분이 무슨 상관이냐 할 수 있지만. 요사이에 대부분의 글리치의 원인은 호환성 보다도최근 추세가 전력소모량과 열이

화두가 됨에 따라서 많은 민감함이 있곤 합니다.

모바일 기기는 글리치를 보기가 어려운 이유는, PC와는 다르게 조립이 이미 되어 나오기 때문에, 어느정도는 호환이 된 상태의

패키지 모델을 준비하지 않으면 출시가 될 수도 없기 때문입니다. 그래픽적이나 주파수 적인 글리치를 경험하는 경우는대걔

커스텀 롬으로 자기가 직쩝 할 경우에 나타납니다. 이유는 1000짜리 크기의 G라는폰이 있는데. 운영체제는 900짜리 A라는 폰에

맞추게 되면 버튼이나 이런 애들이 터치랑 따로 놀거나 겹쳐지는 증상이 나타납니다. 하지만 터치는 정확히 먹히고 있지요. 이유는

해상도 문제와 터치 패널의 위치가 다름에 있는 기기문제가 될 수 있지요. 애시당초 커스텀롬 자체는 이런 규격을 맞추어 주지 않습니다.

<유니티엔진과 퀄퀌칩과의 삼각관계.jpg- 게임은 멀쩡합니다. 스샷만 이렇지..>

-PC / 콘솔

> PC에서의 글리치는 콘솔과 매우 닮아 있습니다. 콘솔이 주로 PC의 형태처럼 진화를 해서 그렇긴 합니다. 주로 나타나는 글리치는

바로 GPU 성능이 받혀주는데도 제대로 표시도 못하거나 튀는 현상이 있다던지, 아니면 그래픽을 표현하는 지점 및 코드는 정확한데

그래픽카드에서 표시를 할 수가 없어 게비스콘 아저씨처럼 허얘진다던지, 아니면 각기춤을 추듯이 사람들이 움직인다던지 하는 문제가

생깁니다. 또 색이 번져버린다던가 아니면 아예 레이져를 쏘기도 합니다. 주파수가 너무 많이 나오면 찌익~ 하는 고주파음도 나죠.

하드웨어 리소스가 적어도 글리치는 일어납니다. 분명 게임에서는 핑이 정상인데 P2P를 켜놓거나, 바이러스 검사 중에 게임이 중간에

뚝뚝뚝 끊기는데 이게 대충 프레임이 50 > 10 요런식으로 사실은 주기적으로 떨어집니다. 이건 정상입니다. 리소스를 너무 많이 쓰거나

하는거니까요.

하지만!! FPS(프레임 퍼 세컨드= 초당 장면 깜빡임 지수)가 50 >120 >10 > 50 >120 >10 이런 식으로 끊긴다면 하드웨어 충돌을 의심 해보셔야

할 수 도 있습니다. 그래픽 카드가 과부화 혹은기기와 충돌하는 게임이거나 파워서플라이의 전력 부족도 원인이 됩니다.

정격 600W 를 써야 하는 PC가 정격 500W 파워를 달고 게임을 하게되면 그래픽 카드 및 하드웨어는 제 성능을 발휘하지 못합니다.

사람도 밥을 100주고 일 시켜야 하는데 50주면 얘가 이를 했다가 안했다가 하듯이 리소스가 부족하면 그래픽 카드나 기타 기기들도

힘을 50 밖에는 못 내는거지요 문제는 이 50의 경계가 정해진게 아니라 들쭉 날쭉하다는 겁니다. 이게 글리치의 원인이 됩니다.

즉 게임상에는 정상적인 표기 및 입력이 되고 있는데.. 정작 PC에서는 그래픽카드가 처리를 못해서 이미 플레이어가 손을 쓸 수

없게 되어버리는 경우이지요.

한때 게시판을 뜨겁게 달구던 파워가 있었습니다. 터지는 파워 "뻥궁" 이라고 하는 별명이 있는 "천궁" 파워를 예를 들어보면(회사 없어짐)

제 친구도 희생양이긴 하지만.. 이 파워가 정격은 600W인데 실제 내는 양은 저항이랑 캐피시터 포함해서 견디는게 472W 정도 밖에 안되는데,

이러한 전력을 과도하게 600W 를 뽑아내려니 뽑아지지도 않고, 급기야 최고의 불량 제품은 폭발도 하는 불의의 사태도 난적이 있었지요.

사양이 일반적인 PC방 사양으로 돌아가는 게임이 있다고 가정을 해봅시다. 뭐 AOS 장르의 L 게임이라고 쳐봅시다.

그럼 일반적으로는 GTS 250 이면 돌아가고도 남을 수 있습니다. 물론 사양을 협의해야 할 수도 있지만. 일반적으로는 돌아갑니다.

그러나 친구는 GTX560을 쓰고 있었고. CPU도 I7 1세대였습니다. 근데 그게임이 랙이 엄청 걸립니다. 움직이면 모션이 생길정도로요

보니까 120 프레임으로 비 주기적으로 튀고 있었죠. 5분을 못 버티는 겁니다. 친구의 원인은 하나였죠. 그래픽카드가 문젠가 보다.

그래피카드를 바꾸러 갔죠. 네? 그대로 안됩니다. 메인보드 고치러 갔습니다. 네? 역시 안됩니다. 램도 바꿨어요. 넵 안됩니다.

하드디스크 스왑인가 해서 다 끄고 SSD 달았는데도? 넵. 5분뒤 120프레임이 나왔습니다. SSD 달고도 랙걸리는 이 상황은 과연.

제가 가서 파워가 뭔지를 보고 기겁을 했습니다. 천궁이였죠 천궁 600W 였던 겄이였죠. 그냥.. 이거다 싶더군요. 모든 원인은 이 천궁의

글리치 덕분에 나는 것이죠. 물론 설계는 그렇게 하지 않았겠지만.. 실체는 그렇치 않습니다. 애시당초 PCB가 문제가 있긴 합니다.

자세한게 궁금하심 천궁 쳐도 분해기가 나오니 보심 됩니다.

어쨌든 원인은 정격과 다른 파워의 비정상적인 전력 공급이 원인입니다.

이런게 뭔 글리치랑 상관이 있느냐! 라고 하신다면 실험을 하셔도 됩니다. 최신사양에 400W를 달고 해 보시면 절로 마우스를 모니터에 던지실

준비가 되신겁니다. 최악의 상황이라면 VGA가 주파수를 제대로 못 내서 주파수를 탁탁 튀면서 모니터가 꺼지는 진 관경도 목격 하실수 있습니다.

모니터들은 주파수가 초과하면 안 켜집니다. (이런 주파수 따위 못켜!! 하면서 말이지요). 제친구 모니터가 자주 꺼집니다..

말로는 이정도 하고 그림을 몇개 넣어보겠습니다. 그래야 이해가 되실랑 말랑 하실거 같으니 말이지요. 글리치 여러분도 할 수 있습니다!

(절대 하지마세요!!)

<검색창에 "뻥궁"을 쳐보세요~>

요약

귀찮은 분은 여길 읽어주세요

- 글리치는 주로 하드웨어의 주파수나 전력소모에 따른 성능의 불안전성 하드웨어간의 충돌로 나타나는 느려짐 / 오동작 / 데이터 깨짐등을 나타냅니다.

- 분명히 게임을 돌리는 충분한 사양인데도 소프트웨어적으로 위치도 정확하고 처리도 정확한데 그래픽이 깨지거나 느려짐 표현을 못 할 수 있습니다.

- 사양이 충분하지 않은데 하려고 든다면 그건 글리치라고 보긴 힘들고.. 그냥 사양 문제입니다.

- HW 적인 문제가 주인 글리치가 아닌 SW 적인 문제를 지칭하는 버그는 수정시간이 HW적인 문제보다는 적은 경우가 많습니다.

즉, 의도가 되었느냐 의도 하지 못하는 HW나 외부의 오류로 오는 문제냐에 따라서도 달라진다고 보시면 되겠습니다.

2. 그래픽 버그

버그중 그래픽 버그는 일반적으로는 마이너한 개념 입니다.

그러나 이 버그는 그리 주요하지 않다고 생각하지만.

사용자간의 인식의 차이가 매우 심합니다. 그래픽 버그가 A급 버그라고 보는 사람도 있지만,

굉장히 알아보기 힘들정도의 그래픽 문제가 발생해도 돌아가서 내가 게임을 할 수 있으면 된다는

대단한 인내심의 소유자도 존재합니다. 요런 유형은 나중에 살펴보기로 하

그렇다면, 그래픽 버그는 어떨때 일어나는가? 이런건 다 의도가 된 버그에 속합니다.

즉, 휴먼에러에 가깝다고 볼 수 있습니다.

휴먼에러는 주로 사람의 아래와 같은 문제로 나타납니다. 대부분은 스트레스로 표현을 하는데요

이러한 실수를 하는 요인은 많습니다. 그 중 몇가지는

- 적용 할 시간이 모자람

- 육체적 피로에 의한 잊어버림

- 인식과 행동의 차이가 발생

- 아예 요구사항을 잘못 알고 있거나 적용될 기기에대한 정보를 아예 모름.

- 처음에는 적용하였지만, 이 후 수정된 사항을 모름.

- 적용된 사항을 확인하여야 하나, 그냥 넘어감.

이런 사례를 보면 주로 시간적 스트레스, 돌발 대처능력 부족의 스트레스, 안일함, 미숙함에서

주로 오게 됩니다.

그래픽 버그의 사례는 다음과 같습니다.

- 도트 버그

- 셀 버그

- 폴리곤 깨짐 버그

- 텍스쳐 깨짐 버그

- 접합부 버그

- 파일 없어서 ? 로 나옴

- 위장약을 부은듯한 백옥같은 그래픽

(일부 환경에 의해서 글리치급에 들어갈 수 도 있는 버그지만 대부분은 그래픽 오류입니다.)

그 외 눈으로 확인 가능한 그래픽이 일정한 노이즈 증상이 아닌 단순하게 돌아오는경우는 일반적으로 포함됩니다.

그럼 이런 그래픽버그를 어떻게 일일히 발견하나요!!! 라면서 화내 실 수도 있습니다.

사실 증상 자체는 글리치가 명확합니다. 아예 동작하기 힘들정도의 심각한 수준이 대부분이기 때문이죠.

이런 단순 그래픽 버그의 경우 몇 가지 해결의 제안사항이 있을 수 있습니다.

-영업 / 기획 부서 혹은 프로젝트 매니져와 이슈 합의 (시간적이거나 프로젝트성 일 경우)

-개발 부서와의 합의 (3D 기술이거나 좌표 오류일 경우 수정을 요청함)

잠깐 여기서!

>협의가 잘 안 됩니다. 왜냐면 사실 마이너한 버그이기 때문이죠. 이러한 그래픽버그가 문제가 많음을

보여주지 않고, 단순하게 이거 깨지는데요? 라고하면 바로 협의가 되지 않겠죠.

그렇다면!? 버그도 주요도를 매겨야 하는겁니다.

뭐가 있을까요? 아래와 같이 생각을 해보면 되지 않나 싶습니다. 장르에 따라다르지만

1. 장르를 생각해봅시다.

투사체가 발생하는 것은 슈팅 / 액션 / RPG / RTS 뭐 엄청 많군요.. 이들에서 그래픽 버그가.

중요할 수도 있습니다. 예를 들어보죠

-RPG에서의 보스 레이드 / 공성전 / PVP에서의 셀버그 그래픽 버그를 유저가 이용함 혹은 불편을 겪음.

-슈팅에서의 적 비행체가 쏘는 탄환의 그래픽이 실제와 다르게 크다던가 반대로 너무 작고 위치도 달라 도저히 피할 수 없다.

-기획팀과 개발팀의 음모였다.(이건 농담입니다. 돌던지지 마세요..) = 기획의도가 있을 수 있습니다. 예를들면 실제 칼은 작은데

캐쉬칼이라서 조금 길게 매겼다던가. 반대로 소검인데 길게 보이는 캐쉬템이다던가.. 아니면 그냥 위에서 하라고 했던가.. 뭐 거런거죠.

그러나. 낚시 게임이나 카드게임 고정형 퍼즐게임 등과 같은 장르는 그 다지 리스크가 크지 않는 경우가 많습니다.

(만약 카드게임인데 여성 캐릭터 카드의 이미지가 내 의도아 다른건 그래픽 버그가 아닙니다.)

<그러니까 낚시대 빼고 신경을 안쓴다니까..거북이가 튀어나오던지 말던지..>

2. 시간을 따져봅시다.

과연 이 그래픽 버그를 수정하기 위해서 얼마나 시간이 걸릴까? 생각을 한번 해보시기 바랍니다.

예를 하나 들어서 도트를 보죠. 요즘 2D가 없긴 하지만 아이템은 여전히 도트를 쓰곤합니다.

3D가 조립이라면 도트는 미친듯히 점으로 이루는 예술일지도 모릅니다. (개인적으로 말이죠)

이거 문제 나와서 갈아엎으면 수정하는데 꽤 걸립니다.

그럼 어떻게 할건가.

<이건 납기에 문제가 없는게 아닐건데요? - 수정됐습니다 이거. 잘 하고 있어요 동물특공대.>

-납기에 문제없으니 협의한다.

-유저가 발견해도 문제가 없다.

-시간대비 리스크가 크지 않다.

아마 대걔 이렇게 갈겁니다.

3. 자원을 따져보고 심각하다고 할지 아니면 차차 고칠지에 대한 보고를 하는 편이 서로에게 좋을 수도 있습니다.

과연 이걸 잡아내더라도 어떻게 보고할건가? 문제가 생깁니다. 역시 자원을 따져봐야 합니다. 디자이너가 3명이

풀로 일을 하고 있는데 도트를 던져준다. 이건 화냅니다. 즉 캐릭터 손과 발이 빅장을 읃어맞아서 떨어진게 아닌이상

그리 큰 문제가 아닐거라고 생각을 할겁니다. 요런애들은 모아주세요.

큰 업데이트말고 뭔가 널널한 시즌에 몰아서 처리할 수있도록 남겨 놓으면 나중에 일거리없다고 핍밥받는 경우가

(다 바빠서 그런거 없겠지만.) 이런거 있더라구요 하고 주도록 합시다. 가끔 어쩌다가 운이 떨어질 만큼의 확률로

널널할 때가 있는데 일이 없다고 투덜댈때 주면 아마 이거 하면서 시간을 보낼겁니다. 물론 윗분들 입장에서는

엄~청 안 좋지만, 크게 생각해 본다면 결국 버그 수정의 측면은 똑같기 때문에 뭐라도 하게 하는것도 하나의 관리

측면이라고 볼 수 있겠지요.

반대로 유저에게 주기도 합니다. 대부분 유저들한테 버그잡으라고 던져주면, 그래픽 버그나 스트링 버그가 대부분이기 때문이죠.

개중엔 강력한거도 나오긴 합니다.. 이건 유저한테 나왔다면 긴장해야 할 지도 모르는게 가끔은 나오기도 합니다.

그러나 이 열심히 쓴거는 결국.이론에 다나오는겁니다. 결국 이슈관리툴에 어떻게 올릴건가 고민하게 되는 내용일 뿐이라는 겁니다.

정말로 리스크한게 아닌이상 그래픽 버그는 대부분이 약소합니다. 하지만 이러한 조그마한 노력이 어떻게 고쳐지냐는 위에처럼

내부에서만큼은 생각을 해봐야 할 문제는 된다는 겁니다.

글리치의 해결방안도 위와 동일 합니다. 하지만, 이는 많은 부서와 리소스와 시간이 얽혀있어 보고도 대부분 껄끄럽습니다.

거의 대부분은 심각한 버그가 많아서 A급 버그가 되기도 합니다. 정말 심하면 그래픽카드 태워먹는 버그도 있을 수 있지요.

역시나. 귀찮으실테니 아래만 봐 주시기 바랍니다

- 그래픽버그는 주로 소프트웨어 제작 도중에 나오는 대부분의 휴먼에러나 요구사항 분석이나 이해 문제로 일어날 수 있습니다.

- 주로 외향적으로 보이며, 일정하게 나오지 않거나 사라지기도 합니다. 파일을 빼먹거나 아예 적용이 안되지 않는다면 대부분은

버그 발생면적이 작습니다.

- 유저들도 특별한 사항이 아니라면 크게 개의치 않는 경우가 많습니다. 일부 유저는 목과 다리가 떨어져도 재밌어 하기도 합니다.(흠..)

- 글리치보다 빠르게 고쳐지는 경우가 많으므로 이는 협의 하거나 모아서 해결하기도 합니다.

마지막으로 글리치이던 그래픽 버그이던, 둘다 문제점인건 마찬가지입니다. 문제점이 발견된다면,

이를 어떻게 하는가가 더 중요하다고 생각을 하면서 마칩니다.

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

Simple & Fast Android UI Automation Test

Showstopper — Tue, 07 May 2013 12:35:54 +0900

오늘 설명할 내용은 간단하고 (작성이) 빠른

안드로이드 UI 터치 입력에 대한 자동화 테스트를 만드는 것이다.

본 자동화는 간단한 시나리오의 Repetition Test에 적합하다.

Repetition Test를 통해 Load/Stress Test나 Memory Leak Checking을 할 수도 있다.

중요한 것은 getevent 명령어의 출력값들에서

군더더기 없는 터치 이벤트를 걸러내는 것과 각 터치 이벤트 간에 Delay를 주는 것이다.

몇 번 해보면 어렵진 않으나 제대로 하려면 공부가 필요하다.

ADB.7z

GetEvent.bat

[Modeling]SendEvent.xlsx

1. 첫번째 할 일은 ADB 파일을 여러분의 로컬 경로에 저장하는 일이다.

첨부파일 ADB.7z를 다운로드하길 바란다.

필자는 C:\ADB 안에 파일들을 복사했다

7zip으로 압축된 파일 안에는 아래와 같은 세 개의 파일이 담겨져 있다.

adb.exe

AdbWinApi.dll

AdbWinUsbApi.dll

2. 여러분의 안드로이드 디바이스에 접속한다.

필자는 Private Network을 구축하여 IPv4 Address를 이용하여 디바이스에 접속했다.

C:\>adb connect 192.168.100.100

3. GetEvent.bat를 실행한다.

배치파일의 내용은 별 것 없다.

여러분이 UI 상의 뭔가를 터치할 때마다 일어나는 이벤트를 텍스트 문서에 옮겨담는 일을 한다.

나는 환경변수를 건드리기 싫어하기 때문에

배치파일에서 ADB가 있는 경로로 이동하는 명령어를 넣어두었다.

getevent 명령어는 터치할 때마다 일어나는 이벤트들을 보여주는 명령어이고,

'> GetEvent.txt'를 하면 출력값들을 모조리 텍스트 문서에 저장하게 된다.

필자는 안드로이드 UI 상에서 [Home] 버튼을 한번 눌렀다.

GetEvent를 켜두고 너무 많은 터치 이벤트를 하게 되면 나중에 뭐가 뭔지 구분해내기 어렵다.

이를 위한 getevent 옵션들이 몇 가지 있지만 썩 유용하진 않다.

정말 긴 시나리오에 대해서 자동화를 할 생각이라면

그냥 자동화 프레임워크를 만들거나 이미 있는 걸 갖다 쓰거나 하길 바란다.

@echo off
cd c:\adb
adb shell getevent > GetEvent.txt

4. GetEvent.txt를 연다.

아마 아래와 같은게 적혀 있을 것이다.

주의할 점은 여기에 있는 값들은 Hex값이다. 자동화에 쓰려면 10진수로 변환이 필요하다.

일단은 Ctrl+A, Ctrl+C를 해둔다.

/dev/input/event3: 4 4 1
/dev/input/event3: 1 46 1
/dev/input/event3: 0 0 0
/dev/input/event3: 4 4 1
/dev/input/event3: 1 46 0
/dev/input/event3: 0 0 0

5. SendEvent.xlsx를 연다.

아래 빨간색 테두리 안에 아까 복사한 내용을 붙여넣는데,

텍스트 마법사를 이용하여 공백을 탭으로 구분해주면 4개의 열 - A, B, C, D에 딱 맞게 들어간다.

그리고 E열에는 자동으로 hex값이 10진수값으로 변환되어 명령문 형태로 변환되어 나타난다.

실제 자동화에 필요한 값은 바로 이 E열이다

쭈욱~ 복사하자. 이 예제에서는 E2 ~ E7 값을 복사하면 된다.

(이때! 텍스트 마법사를 이용할 때 열들의 속성은 '텍스트'로 바꿔라. 안그러면 엑셀이 hex값을 제대로 처리하지 못한다.)

6. 배치파일 작성을 위해 Notepad를 연다.

필자는 두개의 배치파일을 만들 것이다.

첫번째는 위에서 복사한 값을 이용하여 '[Home] 버튼을 누르는 동작'에 대한 배치파일이고,

두번째는 '여러가지 터치 이벤트에 대한 배치 파일들을 호출하는 자동화 테스트'에 대한 배치파일이다.

첫번째 배치파일부터 작성해보자.

마지막에 ping 127.0.0.1 -n 3 > nul 를 넣은 것은 터치 이벤트 간에 delay를 주기 위함이다.

적정 수준의 delay를 설정하기 바라며, 배치파일들을 호출하는 자동화 테스트 배치파일에서 delay를 제어해도 무방하다.

나는 이것을 [State]_Home_Screen.BAT라고 이름지었다.

adb shell sendevent /dev/input/event3 4 4 1
adb shell sendevent /dev/input/event3 1 70 1
adb shell sendevent /dev/input/event3 0 0 0
adb shell sendevent /dev/input/event3 4 4 1
adb shell sendevent /dev/input/event3 1 70 0
adb shell sendevent /dev/input/event3 0 0 0
ping 127.0.0.1 -n 3 > nul

두번째 배치파일을 작성해보자.

필자는 Auto_Test.BAT이라고 이름지었다.

set /p Cpy=Repeat Count? 는 이 테스트를 몇 번 반복을 할 지를 정하는 것이다.

사용자가 숫자를 입력하면 Cpy라는 변수에 값을 저장하고

그 횟수만큼 루프문을 돌게 된다.

echo [State]Home_Screen 는 현재 자동화 테스트의 위치를 나타내주기 위함이고

call [State]Home_Screen.BAT은 다른 배치파일을 호출하기 위함이다.

이때, call이 없으면 다른 배치파일을 실행하고 그냥 종료해버린다.

@echo off

cd c:\adb
set /p Cpy=Repeat Count?

echo.

for /l %%a in (1,1,%Cpy%) do (
echo [State]Home_Screen
call [State]Home_Screen.BAT

echo [Event]Select_App

call [Event]Select_App.BAT

echo [Event]Select_[Back]button

call [Event]Select_[Back]button.BAT

)

echo.
pause

필자는 위에서 직접 사례를 든 [State]Home_Screen.BAT 이외에

두 가지 배치파일을 더 만들었다.

UI 상에서 각 화면들을 State로 정의하고

버튼이나 아이콘을 터치하는 동작을 Event로 정의하여

각 배치파일들을 잘 구분하여 만들면

단순한 Model-Based Testing도 가능하다.

단, Oracle Problem은 해결하지 못한다.

하지만 정말 MBT를 하고 싶다면 자동화 테스트 프레임워크를 사용하는 것이 정신 건강에 좋다.

7. 자동화를 돌려보자.

필자는 Command 창에서 3을 입력했다.

결과는 다음과 같았다.

[Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 > 2-3초 지연 > [Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 > 2-3초 지연 > [Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 >

한번 해보자.

'▶ 테스팅을 말한다 > 테스트 설계' 카테고리의 다른 글

Simple & Fast Android UI Automation Test (0)	2013/05/07
테스트 케이스 작성 시 표현은 명확하게 (0)	2013/04/02
DRAKON: The Human Revolution in Understanding Programs (1)	2012/11/06
테스트 케이스와 체크리스트의 차이가 뭐여? (1)	2012/09/24
[번역] Intelligent Test Automation (4)	2012/09/10
[번역] 테스팅 기법 - 왜 귀찮게 하는가? (1)	2012/08/22
소원의 나무로 테스트 케이스 만들기 (2)	2012/08/22
[번역] 유스 케이스로부터 테스트 케이스에 대한 추적성 (2) (1)	2012/08/02
Effective Risk Based Testing – Part 1 (8)	2012/07/30
[번역] 유스 케이스로부터 테스트 케이스에 대한 추적성 (2)	2012/07/04
System Level의 NFR Testing에서 유의할 사항들 (13)	2012/06/25

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting)

ikooya — Mon, 06 May 2013 22:40:11 +0900

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting)

저는 요즘 취미로 와인 테이스팅(Wine Tasting) 을 즐기고 있습니다. 와인을 마시기 시작한지는 이제 반년 정도 되었네요. 공교롭게도 제 직업은 소프트웨어를 테스팅(Testing) 하는 것과 연관이 깊고, 취미 생활은 와인을 테이스팅(Tasting) 하는 일입니다. 저는 한가지 주제를 정해놓고 끝까지 파고들면서 여러 가지 부가적인 사실을 알아갈 때 재미를 느끼는 성격이다 보니, 자연스럽게 와인을 좋아하게 되었습니다.

와인 테이스팅과 소프트웨어 테스팅, 이름만 들어보면 전혀 상관이 없는 것 같지만 와인을 마시면 마실수록 여러 가지 비슷한 점이 많다는 것을 느꼈습니다. 그래서 공통점이라고 느낀 몇 가지를 적어보았습니다.

1. 품질과 가격은 비례하지 않는다.

가격이 비싸다고 해서 소프트웨어의 품질이 뛰어나지는 않듯이, 와인도 비싸다고 해서 품질 좋고 맛있는 와인만 있는 것은 아닙니다. 가격은 저렴하지만 40년된 고목에서 포도를 손수 손으로 따서 정성스레 만든 와인도 있고, 비교적 재배가 힘든 포도로 만들어 시중에서 구하기가 어렵기 때문에 가격은 비싸지만, 제조 과정과 맛은 가격에 비해 떨어지는 와인도 있습니다. 소프트웨어도 마찬가지죠.

만약 같은 가격에 같은 기능을 가진 2개의 소프트웨어 중 하나를 선택해야 한다고 하면, 어떤 기준을 갖고 선택하게 될까요? 여러 방법이 있겠지만 아마 브랜드가 그 판단 기준이 되지 않을까요? 브랜드 이미지가 좋은 제품이 왠지 같은 기능이라도 더 편리하게, 더 안정성 있게 구현되어있을 거란 생각이 들거든요.

이점은 와인도 비슷합니다. 만약, 최악의 빈티지(포도 재배 년도). 이 해에 수확한 포도들은 모두 형편없다는 평을 들을 정도로 기후조건이 좋지 않았던 해에 수확한 포도로, 같은 양조 과정을 거쳐 만든 와인 2병이 있다면 아마 많은 사람들이 와이너리의 이름을 보고 와인을 선택할 것입니다. 특히 오래된 와이너리 일수록 자신만의 노하우와 철학을 갖고 있어서, 기후 조건이 좋지 않았던 해에는 평소보다 와인을 적게 만들고 배의 노력을 들여서라도 어느 정도의 품질을 유지하려 노력하기 때문입니다.

2. 테스터에 따라 결과가 많이 좌우됩니다.

경험기반 테스팅은 테스터에 따라 결과가 천차만별이지요. 같은 시간 제한과 같은 목적을 주고, 초보 테스터와 경력 테스터가 동시에 테스트를 수행해보고 결과를 리뷰 해보면, 테스트 방법부터 제품을 바라보는 관점에 이르기 까지 얼마나 큰 차이가 나는지 실감할 수 있습니다. 이런 점을 보완하기 위해서 테스트 케이스를 아주 견고하게 만들어서 누가 테스트를 하던지 일정 수준의 테스트 결과를 유지하기도 하고요.

와인을 테이스팅 하는 것도 마찬가지 입니다. 와인에 대한 경험이 많은 사람일수록 와인을 테이스팅 할 때 맛만 보는 것이 아니라 와인의 향이나 색깔을 살펴보기도 하고. 맛에 대한 표현도 더 맛깔스럽고, 이 와인은 어떤 온도에서 먹어야 더 맛있는지, 어떤 음식과 어울리는지 등의 풍부한 테이스팅 결과가 나옵니다.

저도 처음 와인을 마셨을 때는, ‘음.. 씁쓸한 술 맛이군.’ 정도였는데. 요즘엔 다른 사람들의 테이스팅 결과나 전문도서를 읽으며 마시다 보니 처음보단 표현력이 많이 늘었더랬죠.

3. 테스트를 기록으로 남긴다.

테스트 할 때 기록을 함께 남기는 것은, 테스터들에게 좋은 습관으로 알려져 있습니다. 기록을 남겨두면 남기는 과정에서 스스로 정리가 되기도 하고, 기록을 가지고 다른 테스터와 회고를 나눌 수도 있고, 테스트를 하면서 놓칠 수 있는 많은 부분들을 붙잡을 수 있게 되죠.
와인을 마실 때에도 ‘테이스팅 노트’ 라는 걸 작성합니다. 색깔, 향, 맛 이렇게 크게 3단계로 나누어 작성하는데요. 번거롭더라도 와인을 마실 때 마다 꾸준히 적어가다 보면, 어느새 눈에 띄게 테이스팅 스킬이 늘어났다는 걸 실감하기도 하구요. 역시 기록은 중요한 것 같아요.

여담이지만, 요즘 들어서 자유롭고 행복하게 일하는 방법에 대한 고민이 듭니다.
아무리 좋아하는 분야였어도, 막상 내 일이 되고 나면 그건 더 이상 ‘하고 싶은 일’ 이 아니라
‘해야 만 하는 일’ 이 되어버리잖아요. 일을 하면서 자유롭기 위해선, 일을 하지 않는 일상 생활 속에서도 일 때문에 억압받지 않기 위해선, 저의 사사로운 일상, 취미, 그리고 목표, 그리고 일이 한 방향으로 일치해야 한다는 결론이 나왔습니다. 그런 의미에서.. 저의 취미인 와인 테이스팅을 소프트웨어 테스팅과 연관지어 이런저런 생각을 해보는 것은 저에겐 참 재밌는 시간이기도 했구요. (쓰고 나서 다시 읽어보니, 별 내용이 없다는 생각이 들기도 하지만.)
어쨌든 이런 취미 생활을 즐길 수 있는 힐링 타임 덕분에 내일 더 열심히 테스트 케이스를 쓸 수 있으리라 믿으며.. 또 와인을 마시다가 연관 지을 부분이 생기면 연재 포스팅으로 이어가도 재밌을 것 같아요.

'▶ 테스팅을 말한다 > 테스팅 일반' 카테고리의 다른 글

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting) (6)	2013/05/06
왜 개발자들이 유닛 테스팅(Unit Testing)을 싫어할까? (1)	2013/03/18
테스터들의 사고방식 (1) - 제로베이스 사고 (1)	2013/02/18
와인 테이스팅(Wine Tasting)과 소프트웨어 테스팅(Software Testing) -#1 (3)	2013/02/11
Google CodePro AnalytiX 소개 - 안드로이드 개발/테스트를 위한 정적분석 도구 (1)	2012/12/10
소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기 (0)	2012/12/03
탐색적 테스팅에서의 세션과 차터 (0)	2012/11/05
Bug Olympics (2)	2012/10/06
서비스의 불균질성 (1)	2012/09/21
버그 리포팅을 도와주는 7가지 팁 (5)	2012/08/16
당신의 버그 리포트에 꼭 들어가야 할 내용들 (3)	2012/08/05

테스트 케이스 작성 시 표현은 명확하게

Showstopper — Tue, 02 Apr 2013 21:32:05 +0900

당신의 조직에서 사용하는 테스트 케이스가

IEEE 829나 ISTQB에 나오는 형식을 취한다면,

테스트 케이스는 그 목적이나 의도에 맞게 그 표현도 명확하게 작성되어야 한다.

예를 들어, 어떤 애플리케이션을 테스트할 때 테스트 케이스가 다음과 같다면,

테스트 케이스 1

1. 애플리케이션 UI 상단 메뉴바에서 메뉴 A를 클릭한다.

2. 후략

테스트 케이스 2

1. 애플리케이션 UI 상단 메뉴바에서 메뉴 B를 클릭한다.

2. 후략

테스터 A는 테스트 케이스 1을 수행하기 위해

애플리케이션을 최초 실행한 다음,

테스트 도중 종료/재실행하는 절차 없이

테스트 케이스 2를 이어서 수행할 수도 있고,

테스터 B는 각 테스트 케이스마다

애플리케이션을 종료/재실행하는 절차를 이어서 할 수도 있다.

실제 테스트 케이스 작성자의 의도는

매 테스트 케이스 수행 전 애플리케이션을 종료/재실행하는 것이라면

테스터가 당연히 그렇게 하겠지, 하고 판단하지 말고

명확히 명시해주는 게 좋다.

위에 예를 든 것은 설명을 용이하게 하기 위해 아주 쉬운 예를 들어본 것이다.

지금 즉시 당신이 작성한 테스트 케이스를 검토해보자.

모든 테스터가 당신의 의도대로 생각하는가?

아니면, 오해의 소지가 많은가?

'▶ 테스팅을 말한다 > 테스트 설계' 카테고리의 다른 글

Simple & Fast Android UI Automation Test (0)	2013/05/07
테스트 케이스 작성 시 표현은 명확하게 (0)	2013/04/02
DRAKON: The Human Revolution in Understanding Programs (1)	2012/11/06
테스트 케이스와 체크리스트의 차이가 뭐여? (1)	2012/09/24
[번역] Intelligent Test Automation (4)	2012/09/10
[번역] 테스팅 기법 - 왜 귀찮게 하는가? (1)	2012/08/22
소원의 나무로 테스트 케이스 만들기 (2)	2012/08/22
[번역] 유스 케이스로부터 테스트 케이스에 대한 추적성 (2) (1)	2012/08/02
Effective Risk Based Testing – Part 1 (8)	2012/07/30
[번역] 유스 케이스로부터 테스트 케이스에 대한 추적성 (2)	2012/07/04
System Level의 NFR Testing에서 유의할 사항들 (13)	2012/06/25

왜 개발자들이 유닛 테스팅(Unit Testing)을 싫어할까?

Wisedog — Mon, 18 Mar 2013 12:01:43 +0900

개발자들이 유닛테스트를 싫어하는 이유라고 제목은 달았지만, 정확한 질문은 'What bothers you about Unit Testing?' - '유닛테스팅시 어떤점이 가장 당신을 괴롭히나요??' 라는 질문입니다.

LinkedIn에서 'What bothers you about Unit Testing?'이란 질문으로 투표를 했었습니다. 참가인원은 적어서(66명) 그다지 큰 의미를 부여하지 못하지만 나름 실무에서 활동하고 있는 개발자가 많은 LinkedIn이기에 나름 생생한 정보라 생각되서 포스팅해봅니다.

안녕하세요, Wisedog입니다.

본 글은 제 개인 블로그에도 게재된 글입니다.

유닛테스트 시 가장 어려운점 5가지

제일 큰 이유는 "Can't keep up with the evolution of code" , 직역하자면 '코드의 진화를 유지할 수가 없어서'입니다. 즉, 코드는 계속해서 변경하고 발전하는데 유닛테스팅을 그 코드에 맞춰서 따라가기가 힘들다는게 그 첫 번째 이유죠.

두 번째 이유는 개발하다보면 저 역시 자주 겪는 일입니다. 어떤 유닛(메소드, 함수)을 테스팅하기 위해서는 어떤 유닛테스트가 필요로 하는 사전 조건 및 데이터가 있습니다. 유닛테스트는 그 실행순서에 구애받지 않고 그 유닛 테스팅 자체만으로 구동이 되야되기 때문에(이것이 원칙이긴 합니다), 구동에 필요한 사전 데이터를 설정하기가 상당히 곤란할 때가 많습니다. 예를 들어 다른 유닛이 실행된 후에 생성된 데이터를 가지고 테스팅을 해야하는데 데이터가 많고, 크고, 다양할 경우 정말 울고싶을 정도죠.

세 번째 이유는 교육적인 이유입니다. 좀 더 많은 좋은 예제가 필요하다는 답변이 의외로 많았습니다.

네 번째 이유는 False Positive를 살펴보는 일입니다. False Positive란 유닛테스트는 실패한걸로 나오지만 실제고 기능이 동작하는 경우입니다. 이 경우 작성한 유닛테스트와 실제 코드를 일일이 살펴보면서 무엇이 잘못되었는지를 찾아야하기 때문에 힘듭니다.

다섯번째 이유는 하나의 유닛, 즉 한 메소드나 함수를 고치면 다른 곳에서 문제가 생기기 때문입니다.

아래는 응답한 사람의 나이, 성별, 직급입니다. 외국도 개발자는 남자가 많군요.(웃음)

'▶ 테스팅을 말한다 > 테스팅 일반' 카테고리의 다른 글

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting) (6)	2013/05/06
왜 개발자들이 유닛 테스팅(Unit Testing)을 싫어할까? (1)	2013/03/18
테스터들의 사고방식 (1) - 제로베이스 사고 (1)	2013/02/18
와인 테이스팅(Wine Tasting)과 소프트웨어 테스팅(Software Testing) -#1 (3)	2013/02/11
Google CodePro AnalytiX 소개 - 안드로이드 개발/테스트를 위한 정적분석 도구 (1)	2012/12/10
소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기 (0)	2012/12/03
탐색적 테스팅에서의 세션과 차터 (0)	2012/11/05
Bug Olympics (2)	2012/10/06
서비스의 불균질성 (1)	2012/09/21
버그 리포팅을 도와주는 7가지 팁 (5)	2012/08/16
당신의 버그 리포트에 꼭 들어가야 할 내용들 (3)	2012/08/05

[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1

별의카비 — Sun, 17 Mar 2013 18:26:22 +0900

안녕하세요. 곰돌군입니다.

글을 뭔가 완벽하게 쓰려고 하다보니 산으로 가는게 너무 많고, 성격상 주제를 빼먹고 뜬금없이

이야기를 하는게 너무 많다보니.. 포스팅이 산으로 가는거 같아서, 차근차근 올려보려고 합니다.

사실 지금은 QC를 하고 있으니 SQA에서는 조금 멀어진듯 하지만. 이젠 좀 차근차근 하려고 합니다.

오늘 포스팅 되는 글은 일반적인 게임에서 나타나는 오류에 대한 표와 예시를 정리해서 올려보고자 합니다. 아주 일반적인 분류이니.. 참조만 하시기 바랍니다.

<표1> 서버 / 클라이언트 이슈 분류

기능 / 이슈 분류	세부 분류	주요 원인	예상되는 결과
로그인실패	웹 연동 / 서버	:로그인 서버 연동 실패 :클라이언트 DB 오류	로그인 실패
업데이터 오류	웹 연동 / 서버	:업데이터 자체오류 :업데이터 서버와 연동실패 :웹 서버의 DB 엉킴 :패치파일 / 데이터 오류 :방화벽 실패	업데이트 실패 게임 실행 실패 (백 업데이트 방식 게임은 예외 배틀넷 서비스 처럼 백그라운드 업데이트 되는 게임을 칭함)
게임런처 오류	웹 연동 / 서버	:런처자체 버그 :웹 포탈의 오류 :혹은 플러그인 오류 :방화벽 실패 :넷 반응속도의 딜레이 :외부망 실행 실패	게임 실행 실패 혹은 사내에서만 동작 사외에선 동작안함
게임실행 오류	서버 / 클라이언트	:클라이언트 파일깨짐 :패키지에 포함될 파일 누락 :서버와 파일 연동 실패	게임 실행 실패 게임 실행 지연 게임 도중 튕김
캐릭터 생성 오류	서버 / 클라이언트	:캐릭터 기본 데이터 오류	게임 실행 실패
게임 글리치 오류	클라이언트	:그래픽 리소스 파일 부재 / 적용 실패 텍스쳐와 뼈대가 안 맞음 셀버그 및 위치버그 :사운드 리소스 깨진 사운드 파일 지연된 응답 및 재생	그래픽 깨짐 모션 오류 그래픽 오류 사운드 오류 캐릭터 빠짐 증상
확률 공식 적용 오류	서버 / 클라이언트	:관리자 DB 적용 누락	서버 / 클라이언트에 직접적인 증상은 없음
동기화 오류	서버 / 클라이언트	:네트워크 장애 :서버 내부 장애 :외부 해킹 시도	게임 응답속도 지연 서버 적용 되는 값에 오류 수치 응답 발생
보안 실패 / 해킹	서버 / 클라이언트	:해킹 시도 :방화벽과 서버간 응답 오류 :내부 보안 사고 등	서버/클라이언트 종료

<표2> 기획 / 유저 관련 오류 (서버 / 클라이언트와 중복 항목 있으나 다른 문제임)

기능 / 이슈 분류	세부 분류	주요 원인	예상되는 결과
로그인실패	유저	:과도한 유저 접속 :의도적인 유저공격 :해킹 / 도용 시도	로그인 실패
게임실행 오류	기획 / 유저	:과도한 유저 접속 :유저 게임 실행 지식 부족	게임 실행 실패
캐릭터 생성 오류	기획 / 유저	:유저의 동일한 이름 사용 :특수문자 필터링 문제 :유해단어 필터링 문제 :유저의 캐릭터명 악용	클라이언트 종료 캐릭터 생성 불가 유해단어 캐릭터 생성
게임 리소스 오류	기획 / 유저	:유저의 클라이언트 해킹 :유저가 업데이트를 다 안함 :클라이언트 동기화 실패	유저 리소스 악용 (업데이트 내용을 미리 입수 / 글리치를 이용한 보스 혹은 유저간 PVP에 악용)
게임 데이터 오류	기획 / 유저	:데이터 수치 입력 오류 : 이미 삭제 되었으나 :적용이 안된 데이터 :필요 없는 찌꺼기 데이터	유저 데이터 악용 오류 팝업등 으로 불편
확률 공식 오류	기획 / 유저	:관리자 DB 적용 누락 :의도된 기획 사항 (민감한 부분이나 확률이 있는 게임 자체에서 확률 유도를 할 경우 윤리 및 관용적 문제가 있을 수는 있으나 기획 의도일 수 있음) :물가 기획 실패 :유저의 학습에 의한 학률 악용	유저 악용 게임 내 인플레이션 발생함
스크립트 / 대사 오류	기획	:단순 대사오류 :스크립트 오류	유저 불편 발생
사용성 문제	기획 / 유저	:기획 구현에 리소스 부족 (시간 / 비용 등) :유저가 게임을 하기에 불편한 인터페이스 :유저 PC 사양 최적화 실패	유저 재미 반감
게임성 문제	기획 / 유저	:기획 실패 :유저가 재미를 못 느낌 :과도한 현금 결제 유도에 의한 유저 변심 :게임 내 밸런싱 문제	사회적 문제의 원인이 될 수 있음 유저 재미 반감 신규 유저와 기존 유저 결재와 비 결재 유저간 격차가 심하게 벌어짐

이 표에서 빠진 사항은 시스템 내부에 컨텐츠적 오류. 개발 오류는 해당되지 않습니다.

자 이제 여기서 몇 개만 실질적인 예시로 한번 알아보도록 합시다.

일단 게임성문제는 복합적인 문제로.. 기획 개발 품질 서비스(운영) 영업 다 필요한 사항이니 빼도록 하고요..

다음시간엔 글리치 오류 / 사용성 문제 / 게임 리소스 오류 / 정도를 살펴보도록 하겠습니다.

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

하이젠버그와 하이젠베르크

Showstopper — Wed, 13 Mar 2013 09:55:03 +0900

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

게이머 구분하기

∞ 기시감 — Mon, 04 Mar 2013 12:30:00 +0900

게이머 구분하기에 대한 글을 썼습니다.

사실 누가바에 어울리는 글은 아닌듯도 합니다만 게임에서의 사용성?(재미?) 테스팅과 연관이 되지 않을까 싶기도 해서 올립니다 :)

표 같은게 삽입 되느라 블로그에 재가공해 올리기 어려워서 PDF 버전으로 바로 볼 수 있도록 링크를 공유 드립니다.

감사합니다.

본문 내용 중 서론 부분만 올려 봅니다. :)

———-

옛날부터 하드코어 게이머와 캐쥬얼 게이머를 어떻게 나눌 것인가에 대해서는 게임 업계 혹은 게이머들 사이에서도 논란이 있는 화제 거리였다.
하지만 그 대부분이 게임의 장르 혹은 게임의 플랫폼을 기준으로 삼고는 하였다.

위키피디아의 게이머 설명 (http://en.wikipedia.org/wiki/Gamer)

간단하게 표로 정리해 보았다.
분명하게도 논란이 있는 기준이다. 나는 MMORPG를 하지만 레이드나 공대(길드) 활동은 하지 않고 퀘스트만 즐긴다. 는 사람이 있다면 하드코어 게이머라고 부르기 애매할지도 모르겠다. (그래서인지 미들코어 게이머, 익스트림 게이머등의 신조어가 생겨난다.)

왜 하드코어 게이머와 캐쥬얼 게이머를 구분 지으려고 노력하는 것일까?

———-

본문 전체는 아래 링크에서 보실 수 있습니다.

https://docs.google.com/file/d/0B4CK_OCon1K7Z05iQjN5NGNxbzg/edit?usp=sharing

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

액션러닝과 테스팅

Showstopper — Wed, 27 Feb 2013 01:00:00 +0900

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

피닉스 체크리스트와 테스팅

Showstopper — Tue, 26 Feb 2013 12:27:37 +0900

View the story "Conversation with @OEHANs" on StorifyConversation with @OEHANsStorified by O· Mon, Feb 25 2013 17:45:26피닉스 체크리스트(Phoenix Checklist)는 CIA가 정보요원들로 하여금 다양한 각도에서 문제의 본질을 이해할수 있도록 만든 기법이다. 왜 이런 이름인지 그 유래는 잘 모르겠다만 피닉스의 의미 때문에 국내에는 불사조 체크리스트로 더 알려졌다.O원문으로 된 질문지는 여기( http://goo.gl/OfkcN )를 참조하고, 번역된 질문지는 저기( http://goo.gl/YtUCb )를 참조하시라. 이 질문들은 실제로 탐색적 테스팅을 하는데도 좋은 휴리스틱이 된다. @OEHANsOIMO, 이건 제임스 바크의 휴리스틱이나 와인버그의 Context-Free Question보다 더 간결하고 명확한 질문 모음이라고 여겨진다. @OEHANsO좋은 질문이란 마주한 문제를 둘러싼 선입견과 고정관념을 허물고 문제를 해결하기 위해 올바르고 냉정한 관찰과 분석을 가능케 해준다. 켐 캐이너 교수는 테스팅은 제품에게 질문을 하여 답을 얻는 것이라고 했다. @OEHANsO답이 아니라 정보였던가? 짧은 단문으로 이어 쓰다보니 일부 틀린 정보나 문맥이 어색한 건 알아서 넘어가시라. @OEHANsO

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

고객경험지도와 테스팅

Showstopper — Tue, 26 Feb 2013 12:26:25 +0900

View the story "Conversation with @OEHANs" on StorifyConversation with @OEHANsStorified by O· Mon, Feb 25 2013 16:14:08고객경험지도(Customer Experience Map)는 고객의 경험을 세분화하서 더 높은 수준의 고객만족을 줄 수 있는 요인을 분석하고 개선하는 기법이다. 기획 단계에서 잘 하면 끝인데 테스터는 왜 이런 걸 자꾸 알아야 하냐고?O(1) 기획 단계에서의 분석은 이미 개발 단계에서 낡은 분석일 수도 있고, (2) 기획의 방향성을 크게 벗어나지 않는 선에서 더 디테일한 부분에서의 이슈들을 찾아낼 수 있으며, @OEHANsO(3) 다음 과제에서 얼리 테스팅할 때 좀 더 비판적인 시야를 가질 수 있는 준비가 되지 않을까? @OEHANsO고객경험지도를 작성하는 첫단계는 ‘고객관찰’이다. 고객이 필요로 하는 것이 무엇인지, 고객이 원하는 것이 무엇인지를 파악하는 것인데 고객의 목소리를 듣거나 행동을 관찰하는 데는 여러가지 방법이 있다. @OEHANsO할리 데이비슨의 경우는 오토바이 소유주들의 모임인 HOG에 엔지니어, 마케터, 사회인류학자들을 직접 파견시켜 소유주들이 오토바이를 사용하는 방법이나 튜닝 방식, 트러블슈팅 등을 관찰하고 기록했다고 한다. @OEHANsO고객경험지도 작성의 두번째 단계는 ‘지도작성’이다. 고객의 경험을 최대한 상세히 그리고 시간의 추이에 따라 나열하는데 이때 고객의 경험은 ‘터치포인트’를 기준으로 구분하면 된다. @OEHANsO터치포인트란 고객이 기업과 관계를 맺을 때 접촉하는 물리적인것, 인적상호작용, 커뮤니케이션 등의 모든것을 말한다. 예를들어 배고픈 고객이 식당문으로 들어오는 행위도 터치포인트이고, 점원이 맞으러 나와 자리안내를 하는 것도 터치포인트다. @OEHANsO또 점원이 메뉴판을 전달하는 것, 식사 주문/서빙/식사, 계산 등등… 그리고 집에 와 후기를 올리기 위해 그 식당 웹사이트를 방문하는 것 모두가 터치포인트가 된다. @OEHANsO좀 더 관찰력이 뛰어난 기록자라면 고객이 기업과 관계를 맺는 동안에는 무수히 많은 터치포인트가 있음을 알게 될 것인데, 그 무수히 많은 것들 중 핵심 터치포인트를 찾는 일 또한 중요하고 어렵다. @OEHANsO그 다음으로는 터치포인트 별로 고객 경험이 매우만족인지 만족인지 보통인지 불만족인지 매우불만족인지 등을 기록하기 되는데, 보통 이하로 나온 터치포인트들은 고객의 기대와 실제 경험을 통한 만족도 간에 어떠한 갭이 있는지를 분석해봐야 한다. @OEHANsO고객 경험 지도의 예는 다음 링크를 참조하시라. http://goo.gl/1AoFb @OEHANsO

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

테스터스 초이스 #19 - 타임라인 뉴스

Showstopper — Mon, 25 Feb 2013 21:50:45 +0900

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

애자일 테스팅은 왜 필요한가 - Part 1

ikooya — Sun, 24 Feb 2013 15:46:03 +0900

애자일 테스팅은 왜 필요한가 - Part 1

- iKooya

프로젝트 자체가 갖고 있는 가장 큰 리스크는 무엇일까요? 제가 생각하기엔

프로젝트 결과물이 프로젝트 초반에 만들어진 요구사항이나 기획 의도와는 전혀 다르게 나오는 것이 아닐까 합니다. 그리고 이렇게 될 가능성을 가장 높게 만드는 장본인은 아직도 많은 곳에서 사용되고 있는 폭포수 개발 방법론인것 같습니다. 좀더 생각해보면..

SRS Checklist 나 요구사항 가이드라인을 보면..

사용된 언어, 요구사항의 명확성, 예외사항, 타이밍, 성능 등 이런 내용들이 빠지지 않고 잘 적혀있나? 라고 묻는 경우가 많습니다. 분명 요구사항 명세서에 작성되어있어야 하는 사항들이고, 꼭 필요한 내용임은 알지만 보통의 폭포수 모델 프로세스를 따르는 회사에서 요구사항 설계서 작성 기간 동안 저런 내용들을 모두 고려해서 작성하는 것이 가능할까요? 초반 설계 기간이 충분히 주어지지 않으면 저런 모든 경우를 작성해 놓는 것이 힘들다. 라는 것은 둘째 치더라도, 과연 요구사항 명세서의 작성자가 프로젝트 초반에 그만큼 요구사항을 이해하고 있는가에 대한 의문점이 듭니다.

요구사항 이란 것이 초반에 다 정의되고 만들어지는 것 자체가 불가능하다고 생각하기 때문입니다. 고객 조차도 자신의 요구사항이 뭔지 잘 알지 못합니다. 프로젝트가 진행되고 프로젝트 관계자들과 의사소통 하는 과정에서, 고객도 자신의 요구사항을 구체화 시키죠.

그래서 프로젝트는 요구사항을 기준으로 주기적으로 분석되어야 하고, 계획되어야 합니다.

이것을 가능하게 하려면 어떻게 해야 할지.. 그 방법에 대해 요즘 고민하고 있습니다.

고민 초기단계이지만 제 생각을 몇 가지 적어보자면.

초반에 작성되는 요구사항 명세서는 최대한 간단 명료하게 요약하여 작성 되어야 합니다. 위에 적은 Checklist 의 내용들을 적지 않아도 된다 라는 뜻이 아닙니다. 모든 사항들이 포함되도록 ‘요약’시켜야 한다는 말이죠. 아마 요구사항을 요약시키는 과정은 프로젝트 관계자들이 요구사항에 대해 좀더 고찰해볼 수 있는 기회가 될 것입니다.

그리고 이렇게 만들어진 요구사항을 대분류, 소분류화 시킨 다음 리스크 분석을 통해 우선순위를 정합니다. 여기 리스크 분석을 하는 과정이 가장 어려운 작업이 될 수도 있겠네요. 리스크 분석 결과를 통해 프로젝트 진행 순서가 결정되고, 경우에 따라 포기해야 하는 부분도 생기니 프로젝트 관계자들이 최대한 많이 참여하여 의견을 공유하고 분석 결과에 동의하고 넘어가야 추후 의견충돌이 없을 것입니다.

다음은 프로젝트 기간을 나눕니다. 나뉘어지는 프로젝트 기간은 제품의 속성이 충분히 고려되어야 할 것입니다. 예를 들면 제품이 모듈 별로 종속성을 갖고 있지 않고, 독립적이라면 프로젝트 주기가 짧아도 문제가 없겠지만, 종속성이 크다면 리그레션 테스트나 개발이슈 등을 고려해서 주기를 약간 길게 잡아야 할 것입니다.

프로젝트 기간이 나눠지면 기간별로 요구사항과 요구사항에 매칭되는 디자인 문서를 결정합니다. 이때는 위에서 수행한 리스크 분석을 기준으로.. 제가 예전에 포스팅 했던 방법인 Test Cycle 을 만들고 리스크 우선순위에 맞게 계획을 세워야 합니다.

(참고 : http://noogabar.com/410 , Effective Risk Based Testing – Part 1)

그리고 실행 될 때는

테스트 케이스가 만들어지면서 앞에서 작성한 요구사항 명세서 및 디자인 문서가 구체화 되고, 개발되고 검토되고 개발되고 검토되고 이런 주기가 반복됩니다. 그런데 이때 주기 별로 새로운 계획이 세워지다 보면 빠지는 항목이 생길 수 있는 위험성도 있으므로, 별도의 Checklist 를 마련해두는 것도 좋을 것 같습니다.

제가 생각하는 이 방향이, 애자일과 어느정도 일치하지 않나요?

애자일이.. 3년전쯤? 제가 대학교 3학년 때 붐(?)이 일어나서 각종 모임도 많고, 세미나도 많았는데 그때 여기저기 다녀본 결과로는 ‘좋은 건 알겠는데.. 실무에 적용할 수 있을까?’ 하는 의문점만 들었거든요. 근데 지금은 분명이 필요하고, 실무에 적용할 수 있는 구체적인 방안이 필요 하다는 걸 느꼈어요.

오늘 서점에서 애자일 테스팅 책을 구매해서 볼 생각입니다..

해외에 사례들도 많이 있던데, 충분히 고민해볼 가치가 있는 내용들인 것 같아요.

'▶ 테스팅을 말한다 > 테스트 프로세스' 카테고리의 다른 글

애자일 테스팅은 왜 필요한가 - Part 1 (0)	2013/02/24
History of test process improvement models (0)	2012/08/29
[번역] 코딩과 테스팅: 테스터와 프로그래머가 함께 작업하기 (1)	2012/06/04
효율적인 개발과 테스팅 프로세스??? (3)	2011/11/01
Automation testing process #1- 프로세스 관점에서 쉽고 간단하게 적용하기 (0)	2011/06/30
TMMi(Test Maturity Model Integration) (0)	2011/04/13
소프트웨어 테스팅 개선 모델 - TMMi와 TPI Next (0)	2011/03/02

TESTER’s CHOICE #18 – 타임라인 뉴스

Showstopper — Thu, 21 Feb 2013 17:54:43 +0900

When Security Experts Forget Passwords twb.io/U6Fvks
— InformationWeek (@InformationWeek) February 11, 2013

애플다니는 친구의 푸념: 애플의 가장 큰 강점은 SW와 HW의 최적화. 그로인해 저렴한 HW부품을 쓰면서도 높은 성능을 낼수있었음. 그런데 잡스 사망후에는 SW와 HW 간에 갈등 심화. 최적화는 고사하고 일 자체가 진행이 안됨. 애플 미래에 적신호!
— Gibs Song (송승구) (@gibssong) February 13, 2013

Adobe Reader, Acrobat Under Attack twb.io/12yHVHL
— InformationWeek (@InformationWeek) February 13, 2013

It's really poetry: bit.ly/11HEXWs. #testing
— Michael Bolton (@michaelbolton) February 14, 2013

Finding bugs in old bank's systems. I get notification of secure emails waiting for me before those emails are available. Race condition?
— Ben Simo (@QualityFrog) February 14, 2013

The beauty of testing is in the question. Each test we create a hypothesis, and as we run it, we discover not just the answer, but clues 1/5
— Lanette Creamer (@lanettecream) February 14, 2013

아이폰 잠금화면 보안 헛점 dlvr.it/2xwL2b
— techneedle (@techneedle) February 14, 2013

Testing with the system clock:Party like it's 2017.Then party like it's 2009.Hilarity ensues.
— Marlena Compton (@marlenac) February 15, 2013

Provably correct software isn't yet possible but greater rigor is. Here are some specific steps. is.gd/gHWppfby @mheusser
— Artie (@CoffeeGeekGuy) February 15, 2013

All web app testers should know and understand OWASP Top 10. They show the importance of input validation owasp.org/index.php/Cate… #testing
— Teemu Vesala (@teemuvesala) February 15, 2013

요즘 웹 런타임이 대세입니다.: 코드를 웹에서 테스팅할 수 있는 7개의 사이트입니다.sitepoint.com/7-code-playgro… j.mp/VVPxXj
— okjsp (@okjsp) February 15, 2013

I will write the names of these test users onto Partisan Rock so they will not be forgotten when the database is cleared.
— The Director (@QAHatesYou) February 15, 2013

"Minimum complexity requirements not met." But... but... but, I want less complexity.
— Ben Simo (@QualityFrog) February 15, 2013

The concept of "bad smells" when discussing design and coding might be popular specifically because its proponents lack the sense of smell.
— James Marcus Bach (@jamesmarcusbach) February 16, 2013

Software dev w/o automated regression ✅s is like telling a high-wire artist: no need for a net, just don’t fall. How high is the wire?
— Brice Ruth (@bdruth) February 16, 2013

#mindmap on 7 ways to find #software defects before they hit production blog:bouldertester.blogspot.com by @booksrg8 inspired by @mheusser
—JeanAnn Harrison (@JA_Harrison) February 17, 2013

Observation: an essential #testing skill. youtube.com/watch?v=bsX7T1…
— Ben Simo (@QualityFrog) February 17, 2013

[AllofSoftware]고쳤으니 테스트 해주세요. durl.me/4h8ygr
— Raymond(전규현) (@gracegyu) February 18, 2013

물론 초기 개발 계획의 전부가 실제 게임으로 구현되는 것은 아니지만, 번지의 신작 데스티니는 여러모로 큰 파장을 일으킬 것 같은 기분 좋은 예감이 든다. 오오...
— 방영훈 (@zerasion) February 18, 2013

개발팀에게 버젼관리, 지속적인 통합, 이슈트래커, 코딩 컨벤션은 선택이 아닌 필수임을 매우 깨닫는 요즘. 개발팀이 병목자원이 되지 않으려면 개발자가 쉽게 코드를 보고, 히스토리 추적, 테스트 결과 확인등이 필요하고 이슈 트래킹도 잘 되어야 함.
— Namwoo Kim (@iamkimtree) February 18, 2013

10만 시간의 법칙이라는 것이 있지. 그니까 제품이든 서비스든 사람이든 충분히 시간을 들여야 좋은 것이 나온다는 거야. 근데 입장이라는 게, 이걸 만들고, 준비하고, 도전하는 입장에선 당연하다 그러고 쓰면서 누리는 사람은 뚝딱 나오길 바란다는 거야
— Choe, Cheng-Dae (@kiddtm) February 18, 2013

Interesting take on @ronjeffries recent estimation article -- It's Not About Estimation, It's About Risk wp.me/p1wFdW-jh via @az1
— John Goodsen (@jgoodsen) February 18, 2013

Counting number of tests to gauge test coverage is similar to counting lines of product code to gauge software quality (absurd measures)
— Bj Rollison (@TestingMentor) February 18, 2013

베타. 곧 릴리즈될 소프트웨어는 베타테스팅을 거친다. 베타는 라틴어로 "아직 동작하지 않음"을 뜻한다. -작자 미상
— 전산과조교 (@csTA_bot) February 19, 2013

Beta. Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."
— Rick Cable (@MarkLaymoncs) February 20, 2013

bbs2.ruliweb.daum.net/gaia/do/ruliwe… - "크라이텍이 아마 자기 컴퓨터로 게임이 안돌아간다면 오히려 더 좋아하는 팬들을 지닌 유일한 회사일 겁니다. 다른 게임사에서는 이런 일은 없을 겁니다."
— 최재규(Jae-kyu Choi) (@choijaekyu) February 19, 2013

그런 의미에서 테스팅을 통해 밸런스를 잡는다는 방향 보다, 테스팅을 통해 숫자를 믿을 수 있는 '모델'을 설계하고 결과적으로 이를 통해 수치를 잡는 방향은 어떨까 하고 뻘생각 하나 던져 봅니다.
— Kim, Young Soo (@debuggerD) February 19, 2013

테스트 커버리지에 현혹되지 말자 aeternum.egloos.com/1209470 "소수의 핵심 클래스가 70%의 패스 커버리지를 갖는 것이 더 좋은 품질을 보장할 수 있다"기본원리는 똑같군. 주요이슈를 파악해 우선순위를 정해 집중.
— pdaclub (@pdaclub) February 19, 2013

커버러지 분석과 단위 성능 테스트 durl.me/2iessp "Coverage rate를 올리는 것 보다 중요도가 높은 모듈의 Coverage rate만을 관리하는 것이 효율적이라고 생각" 분야,사람이 틀려도 기본원리는 동일한 가 봄
— pdaclub (@pdaclub) February 19, 2013

전에 si쪽 qmo분이 모바일쪽은 테스트커버리지 높일 수 있는 툴 없냐해,단번에 되는게 있음 나도 알고 싶다하고 추상적이라 이해 안되니 예를 들어 달라 요청들어보니 마술 원하는데. 서비스,고객 이해후 우선순위 정해야지 이게 자동으로 되는 툴 있나?
— pdaclub (@pdaclub) February 19, 2013

Do you have a mind-mapping, or idea organizing tool that is your favorite? How about a favorite reference of test ideas? Please share.
— Lanette Creamer (@lanettecream) February 19, 2013

Testing a thing I’ve been working on since Oct. Slowly coming together. Nothing better than playing with freshly built software in a browser
— Simon I'Anson (@simonianson) February 19, 2013

Um, how do you file a bug report against #clojure?
— Brian Marick (@marick) February 19, 2013

Agile Testing책 너무 재밌네^^. 개발자 입장에서의 테스팅과 테스터 입장에서의 테스팅 사이에서 혼란이 오는 개념들을 명확하게 집어준다. 실무에서 고민을 많이 해보신분들께 정말 도움이 되는 책임!!! #정보문화사
— 최영목 (@scroogy_choi) February 19, 2013

데모를 만드는 것과 게임을 만드는 것은 엄연히 다르다. 테트리스 일주일만에 만든다는 사람들은 그냥 데모 수준의 이야기들이 대다수이고, 실제 서비스 가능한 수준의 게임은 개발 기간 산정이 무척 난해하다.
— JinHyun (@HoiPoiPaul) February 20, 2013

Unity3d용 UnitTest도구 SharpUnit github=> github.com/mgants4/SharpU…Wiki=> wiki.unity3d.com/index.php?titl…
— Ted (@booiljoung) February 20, 2013

little eye littleeye.co 안드로이드 앱의 전원,네트웍,메모리 사용량 분석해주는 PC용 앱. 현재 베터서비스이고 정식판 나오면 상용화 한다고 함. twitter.com/pdaclub/status…
— pdaclub (@pdaclub) February 20, 2013

Testing is the name of the game today, I love a bit of software testing.
— JR (@Franc1sJR) February 20, 2013

4th round of Usability testing our installation UX for @infiniosystems today. Cant build good software and sites if unr skipping this!
— Creative | Brian O (@createandrotate) February 20, 2013

Anyone know a good Unit Testing software for 3D applications based on screen dumps? (or some other image based technique). Please RT.
— Marwan Badawi (@LarrxX) February 20, 2013

Why #Agile Development Fails (Sometimes) | Software Testing Blog buff.ly/15sGMpn
— Michael Hulleman (@contact_mike) February 20, 2013

Software testing is like owning a cat. If you see something out of the corner of your eye and don't go look, you'll find a huge mess later.
— Alex Smith (@sparktinker) February 20, 2013

애플/페이스북 직원들이 개발자 사이트(iPhoneDevSDK)에 접속하면서 컴퓨터에 멀웨어가 심어졌는데, 이 사이트 관리자계정 하나가 뚫려 해커가 자바스크립트 악성코드를 심어놨기 때문. feedly.com/k/12OaS7r
— 광파리_IT 이야기 (@kwang82) February 20, 2013

전문 테스터가 아니라서 그런지 아직도 탐색적 테스팅에 대한 감이 오지 않는다. 파괴적인 테스팅과도 다르고 그 자체로는 테스팅 기법이 아니라면 도대체 무엇인가? 구체적 예제가 필요한 시점이다. Cem Kaner가 말한 정의가 아직 이해되지 않는다.
— 최영목 (@scroogy_choi) February 20, 2013

프로그램 테스팅기법에 대한 교육을 받음. 새로운 분야라 재미있게 배웠다. 테스트의 패러다임이 프로젝트 종료 시에서 시작이아니라프로젝트 설계 때 부터 시작하는 것으로 바뀌고 있다.
— Roh munwon (@newtypeno) February 21, 2013

Software Dev teams getting upset at QA for finding a defect is like someone getting upset at their doctor for saying they are fat! #testing
— Mike Lyles (@mikelyles) February 21, 2013

'Doing more with less'는 테스트 매니저라면 즐겨야 하는 고통이다. 하지만 능력없는 테스트 매니저는 그 고통을 고스란히 테스터들에게 전가한다. #누가바
— O (@OEHANs) February 21, 2013

OEHAN (@OEHANs) 2010년 9월부터 누가바닷컴의 필진으로 뛰고 있습니다. ISTQB 실라버스의 단편적인 지식체계를 넘어선 베스트 프랙티스들이 공유되는 장을 만들고 싶습니다. 최근에는 Corner Case에 대한 테스트 아이디어를 효과적으로 도출하는 방법과 최소 비용으로 실사용자 환경 구축하기를 연구하고 있습니다. 전 세계 모든 제품에서 발견되는 버그들을 수집하는데 관심이 많습니다.

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

Tester’s Choice #17 – 해외 아티클 추천

Showstopper — Thu, 21 Feb 2013 11:09:38 +0900

테스터들의 구미를 당기는 테스터스 초이스 17호입니다.
이번 호도 해외 아티클 추천으로 갑니다.
원문을 보시고 싶으신 분께서는 각 글의 제목을 클릭해주세요.

1. Bug Report Attributes Part 2 – Priority

Eric Jacobson 씨는 Priority는 Tester들에 의해 결정돼서는 안 된다고 생각합니다. 대부분의 테스터들은 자신을 고통에 빠진 User들의 구원자쯤으로 여기고 자신이 발견한 버그를 가장 중요하다고 믿는 경우가 많다고 합니다. 하지만 Eric 씨는 자기 자신을 개발팀과 이해관계자들을 위한 정보 수집가쯤으로 생각한다고 하네요.

2. Which Comes First: Functional or Usability Testing?

Peter 씨는 기능성 테스팅과 사용성 테스팅 중 어느 쪽이 더 중요하다는 이야기를 하려고 하는 건 아니라고 합니다. 얼마 전 공유해드린 Nielsen의 포스팅 정도의 의견을 갖고 있는 것 같네요.

3. Testing Email Templates in Rails

4. [ALM-Testing] 10. 부하테스트 이야기, 테스트 데이터 분석 문제 풀어보세요.

5. USING CROWDSOURCING FOR COLLECTING INFORMATION ABOUT SECURITY VULNERABILITIES

Crowdsourcing은 다양한 곳에서 활용되어 성과를 내고 있는데요, 이번에는 '보안 취약성'과 관련하여 생각을 해보자고 하네요. 'Many eyes are better than one pair.'이라는 속담이 있듯이 Crowdsourcing은 보안 취약성에 대한 정보를 모으는 저렴하고 효율적인 방법이라고 합니다.

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

테스터스 초이스 16 - 해외 아티클 추천

Showstopper — Tue, 19 Feb 2013 10:57:02 +0900

테스터들의 입맛에 딱 맞는, 테스터스 초이스 16호입니다.
이번 호는 해외 아티클 추천 편입니다.

원문 보기는 제목을 누르시면 바로 이동합니다.

1. QA & UX

오늘 아침 뉴스레터로 온 따끈따끈한 글입니다. QA와 UX는 다음과 같은 양방향 관계를 가지고 있답니다.

l Most obvious, usability is a quality measure for design. To ensure usability, a good UX thus requires QA thinking.

l Beyond the user interface itself, many other quality issues also impact the total UX .

읽어보면 결국 Early Testing에 관련된 글이네요. 이미 많은 테스터들이 알고 있는 교훈이지만 사용성 테스트 전문가 입장에서 쓴 글이니 참신한 부분도 있네요.

2. Explaining Exploratory Testing Relies On Good Notes..

Note Taking이 중요하다는 글입니다. 좋은 Exploratory Testing을 위해서도 내가 한 Testing에 대해 남에게 잘 설명하기 위해서도. 전자는 잘 하는 사람이 많지만 후자는 잘 하는 사람이 적다는 군요.

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

테스터들의 사고방식 (1) - 제로베이스 사고

Showstopper — Mon, 18 Feb 2013 14:23:58 +0900

제로베이스 사고는 고정관념을 버리고 관점을 바꾸어 다른 각도에서 문제를 바라보는 기법을 뜻합니다.

테스트를 할 때 기존 고정관념의 틀에서 검증 대상을 바라보는 것은 아주 위험합니다. 놓치는 것이 많아지거든요.

실제로 자신이 지난 테스트를 통해 얻은 경험이나 축적된 지식 등을 버리고 완전한 제로 베이스에서 다른 아이디어를 떠올려본다는 것은 쉽지 않은 일입니다. 특히, 특정 시나리오에서 결함을 발견해 본 경험은 그로 하여금 그 시나리오에 편향된 테스트 아이디어만 떠올리게 할 위험이 있습니다.

예를 들어, PC가 최대 절전 모드 상태에 진입했다가 빠져나온 후에 PC와 연결된 디바이스와의 통신에 발생한 문제점을 경험해본 테스터라면 테스트하는 동안 그리고 다음 테스트에서도 'PC 최대 절전 모드 전과 후'라는 조건을 염두에 두고 있을 것입니다. 하지만 PC와 디바이스 간의 통신에 영향을 주는 요소는 이것 뿐일까, 하고 생각해보십시오. 디바이스 단에서 연결이 끊긴 경우, PC 단에서 연결이 끊긴 경우, 디바이스가 재부팅되는 경우, PC가 재부팅되는 경우 등등 다양한 요소들이 떠오를 것입니다.

실제로 유저들이 하루동안 PC를 사용하는 패턴을 보게 되면, (1) 퇴근 후 PC 전원을 껐다가 장시간 방치 후 아침 출근 후 PC 전원을 켜고 난 다음 디바이스와의 통신, (2) 회사에 있는 동안 미팅, 점심 식사 등으로 PC가 화면보호기나 각종 절전모드로 진입한 후 자리로 다시 돌아와 PC를 다시 Wake-up 시켰을 때 디바이스와의 통신 (3) 블루스크린 발생 및 윈도우 업데이트 등으로 인해 PC를 재부팅한 후 디바이스와의 통신 등등 여러가지 상황이 있을 수 있습니다.

여기서 예를 든 것은 제로베이스 사고의 다양한 세부 방법 중 일부에 해당합니다. '제로베이스 사고'에 대해 단편적인 지식만 가지고 계신 분이라면 구글링 한번 해보십시오. 아마, 당신의 테스트 아이디어는 이전보다 훨씬 더 좋아지리라 믿습니다.

<출처 : http://endeavor-online.com/changing-life-with-zero-based-thinking>

다음 시간에는 '프레임워크 사고'에 대해 알아봅시다.

OEHAN (@OEHANs) 어떻게 하면 테스트 아이디어를 효과적으로 도출할 수 있을지와 최소 비용으로 실사용자 환경 구축하기를 연구하고 있습니다.

'▶ 테스팅을 말한다 > 테스팅 일반' 카테고리의 다른 글

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting) (6)	2013/05/06
왜 개발자들이 유닛 테스팅(Unit Testing)을 싫어할까? (1)	2013/03/18
테스터들의 사고방식 (1) - 제로베이스 사고 (1)	2013/02/18
와인 테이스팅(Wine Tasting)과 소프트웨어 테스팅(Software Testing) -#1 (3)	2013/02/11
Google CodePro AnalytiX 소개 - 안드로이드 개발/테스트를 위한 정적분석 도구 (1)	2012/12/10
소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기 (0)	2012/12/03
탐색적 테스팅에서의 세션과 차터 (0)	2012/11/05
Bug Olympics (2)	2012/10/06
서비스의 불균질성 (1)	2012/09/21
버그 리포팅을 도와주는 7가지 팁 (5)	2012/08/16
당신의 버그 리포트에 꼭 들어가야 할 내용들 (3)	2012/08/05

파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지

Showstopper — Fri, 15 Feb 2013 11:34:32 +0900

오늘 제가 잡은 버그들을 소개합니다.

첫번째 버그는 iOS용 Twitter 공식 앱 V5.3.1에서 발견되었습니다.

아래를 보시죠.

이것은,

1. 내가 나 자신에게 멘션을 보낸다.

2. 하단에 [나] 메뉴를 선택하여 내 프로필로 가서 [트윗] 버튼을 클릭한다.

3. 거기서 나 자신에게 보낸 멘션을 삭제한다.

4. 트위터 앱을 종료하고 다시 열어 [친해지기] 메뉴를 본다.

위와 같이 하면 나타나는 버그입니다.

두번째는, Planetary Resources 사의 웹페이지 상에서 발견된 버그입니다.

아래를 보시죠. 일부러 화면을 키웠습니다.

이메일 확인 페이지인 거.. 보이시나요?

하지만 Sign Up 팝업이 뜨면서 이메일 확인 페이지는 비활성화되어 있습니다.

폰트 색깔 때문에 이메일 확인에 관련된 문구가 눈에 잘 안들어올 뿐더러

특히나 저처럼 모바일 사파리를 이용해서 보면 정말 알아보기 힘듭니다.

이것은,

1. http://www.planetaryresources.com에서 회원가입을 한다.

2. 회원가입 시 사용한 이메일로 받은 메일이 있는지 확인한다.

3. 이메일 확인 버튼을 누른다.

위와 같이 화면 해당 웹 페이지로 접속이 되는데 위와 같은 버그가...

움, 이것도 버그라고 할 수 있을 지는 모르겠지만,

굳이 회원 가입을 한 사람에게 또 회원 가입 팝업을 띄울 필요는 없겠죠.

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

[Tester's Choice] #15 - 국내외 소식

Showstopper — Thu, 14 Feb 2013 11:26:27 +0900

1. [SW 강국 진단 – GS인증③] 본말전도 된 ‘GS인증’

기사 제목을 누르면 원문 링크로 넘어갑니다.

'GS(Good Software)인증'을 해주고 있는 한국정보통신기술협회(TTA)의 소프트웨어시험인증단 전영은 단장은 "'GS인증'은 국내에서 개발된 소프트웨어 품질을 증명하는 인증 제도로 국산 SW 제품에 대한 경쟁력을 높이는 게 주목적"이라고 이야기합니다.

하지만 시간이 흐르면서 SW 기업들에게는 공공기관 구매 우선 제도와 가산점 등 공공시장 납품에서 유리한 조건을 받기 위한 제도로 변질되었다고 하네요. 그리고 변별력도 사라졌다는 말도 드립니다.

원문에 링크된 관련기사 '계륵이 되어 버린 'GS인증'과 ''GS인증'은 독소조항?'도 함께 보시기 바랍니다.

2. [이사람]`스피드광` 매킨토시 테스트플랜트 CEO "IT제품 QA 소홀하면 큰 피해"

매킨토시 CEO는 “한국에서 대형 스마트폰 제조사와 소프트웨어 기업, QA아웃소싱 시장을 대상으로 집중적인 마케팅 활동을 펼칠 계획”이라고 밝혔습니다. 아직 매뉴얼테스트 단계에 머물러 있는 한국 IT QA 시장의 패러다임을 바꾸겠다고 하네요.

3. 전직원 자폐증 환자 SW테스트 업체 화제

시카고에 기반을 둔 비영리 법인 'Aspiritech'이 소프트웨어 검증에 '자폐 스펙트럼 장애(ASD)'를 가진 직원들을 고용하여 성공을 거두고 있다는 소식입니다.

2008년에 회사를 설립한 와이츠버그와 모셰 부부는 '고기능 자폐증'의 일종인 '애스퍼거 증후군'을 가진 아들 오란이 4년제 대학을 졸업하고 정상 지능과 숙련된 기능을 갖추었지만 사회적 상호작용에 어려움이 있어 동네 슈퍼마켓에서 카트를 정리하는 일자리조차 유지하기가 어려웠다고 털어놓았는데요, 자신의 아들처럼 자폐 성향을 가진 사람들이 어떤 유형의 일이 좋을 지에 대해 조사를 진행하였다고 하네요.

그러던 중 덴마크 기업(Specialisterne)의 성공 사례를 보고는 섬세한 관찰력과 집중 능력이 필요한 소프트웨어 검증 업무가 '고기능 자폐증'을 가진 사람들에게는 매우 적합하다는 사실을 깨달았다고 하네요.

<출처 : www.aspiriech.org>

4. ‘남부권 SW시험인증센터’ 대구에 들어선다

영남 및 호남지역 소프트웨어 융합 산업 발전의 기폭제가 될 '남부권 SW시험인증센터'가 대구에 들어선다고 합니다. 남부권 SW시험인증센터가 설립되면 현재 한국정보통신기술협회가 맡고 있는 GS인증 발급 업무를 수행하고, SW융합 시험기술 등을 확산시키는 업무를 수행하게 된다고 하네요.

5. 파수닷컴, SW품질에서 시큐어코딩까지 책임지는'스패로우' GS인증 획득

파수닷컴은 국내 유일의 실행의미 기반(시멘틱 기반) 정적 프로그램 분석 솔루션인 스패로우(SPARROW) V4.6에 대한 GS인증을 이번 달 5일에 획득하였다고 합니다.

6. 윈드리버, 올림푸스에 의료장비SW 개발 플랫폼과 테스트 매니지먼트 공급

올림푸스는 수술용 고주파발생기인 `ESG-400'에 윈드리버의 실시간 운영 시스템인 VxWorks 상에서 구동되는 `의료장비 SW 개발용 윈드리버 플랫폼'과 '자동화된 소프트웨어 테스팅 프레임 워크', `윈드리버 테스트 매니지먼트'를 각각 도입했다고 밝혔습니다.

7. Coverity, 소프트웨어 품질 분석.측정 최고 벤더로 선정

IDC가 최근에 발표한 'IDC Market Space: 소프트웨어 품질 분석 및 측정 (SQAM), 2012-2013 벤더 분석 - 품질과 혁신을 높이기 위한 코드 분석 활용'에 따르면 Coverity를 최고 업체로 선정되었다고 합니다.

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

[Tester's Choice] #14 - 해외 아티클 소개

Showstopper — Thu, 14 Feb 2013 10:35:34 +0900

Bug Report Attributes Part 1 – Environment

[원문보기] http://www.testthisblog.com/2013/02/bug-report-attributes-part-1-environment.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29

[요약소개] 버그 리포트에 포함되어야 하는 속성 중 '환경'에 대해 이야기합니다. 보통은 버그가 발견된 환경을 리포팅하지만 버그가 존재하는 최하위 소프트웨어 버전을 적는 것이 더 유용합니다. 또한 숙련된 테스터는 QA 환경에서 발견한 버그가 Production 환경에서도 존재하는지 확인하여 존재한다면 Production 환경을 적습니다.

Software quality assurance testing pros: Act like a journalist

[원문보기] http://searchsoftwarequality.techtarget.com/news/2240178000/Software-quality-assurance-testing-pros-Act-like-a-journalist

[요약소개] 소프트웨어 품질 보증 테스팅 전문가(길다...), 토마스 맥코이 씨는 애플리케이션 품질을 올리는 독특한 방법을 소개합니다. 그는 저널리스트로서 얻은 기술을 소프트웨어 테스팅에 적용하는 것을 선보입니다.

"좋은 저널리스트는 더 좋은 질문을 하기 위해 백그라운드를 조사하고 다양한 뉴스소스와 지속적인 관계를 유지하고 현장 뒤에서 일어나는 일들에 대한 인사이트를 얻기 위해 그 관계를 굳건히 하는데 애를 쓴다."며 "이러한 접근법은 IT 환경에도 효과적이다"라고 말합니다.

맥코이는"견고한 커뮤니케이션 스킬과 프로젝트 이해관계자들과 굳건한 관계를 유지하는 능력은 모든 소프트웨어 QA 프로페셔널들에게 필수다"라고 이야기합니다.

개발자에게 결함에 대해 설명할 때는 시나리오 기반 질문법을, 비지니스 이해관계자들을 Gentle Cajoling Approach(온화한 회유책?)을 사용하면 된다고 합니다. 또, 나쁜 소식을 전할 때는 직접 전하고 문서화된 연구결과와 가능한 해결책을 함께 제시하는 것이 좋다고 합니다. 그리고 이어서 수신처를 최소로 하여 메일을 보내는데 이때 메일의 첫머리는 'As discussed(논의된 대로)'로 시작하는 것이 좋다고 하네요.

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

테스터스 초이스 #19 - 타임라인 뉴스 (0)	2013/02/25
TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29

Tester Risk

Showstopper — Wed, 13 Feb 2013 10:15:29 +0900

Producer Risk와 Customer Risk라는 말이 있다.

Cem Kaner 교수님이 자신의 Testing Computer Software라는 책에서 소프트웨어 테스팅 관점에서 이것들의 의미를 풀이한 것을 보면 (참조 http://noogabar.com/103)

Producer Risk라는 것은, 테스트 오류나 기존 버그와 중복 등의 유형으로 분류되는 버그를 테스터가 보고함으로써 그 버그와 관련된 사람들이 그 버그를 분석하느라 시간이 낭비되는 것을 뜻하고

Customer Risk라는 것은, 어떤 사유로 잠재된 버그를 발견하거나 보고하지 못했는데 이것이 시장에 유입되어 고객들이 경험하게 될 가능성을 뜻한다.

Producer Risk를 위키백과에서 찾아보면 좀 더 광의의 의미까지 볼 수 있지만, 난 Cem Kaner가 테스터를 Producer의 범주에서 제외하고 Producer Risk를 바라봤던 것처럼 Tester가 가지는 Risk는 없을까 생각해본다.

테스터도 주어진 시간 동안 테스트 진행과 별도로 버그 리포트를 상세히 적기 위해 시간을 써야하고 개발자들의 요청에 따라 재현 테스트를 하며 개발자들이 성급히 '문제 아님'으로 State를 돌려버리는 탓에 그것이 명백한 이슈임을 증명하기 위해 또 시간을 배분해야만 한다.

'▶ 테스터의 눈' 카테고리의 다른 글

하이젠버그와 하이젠베르크 (0)	2013/03/13
액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06

테스터스 초이스 13호 - 타임라인 뉴스

Showstopper — Wed, 13 Feb 2013 10:11:59 +0900

트위터 타임라인 뉴스

As a tester, nothing is more funny to me than THIS: tv.msn.com/tv/article.asp… OOPS!
— Lanette Creamer (@lanettecream) February 9, 2013

SW 개발에서 발견되는 이슈나 결함들은 잘 정리된 상자(영역) 내에서 관리하고 이들 간의 관계들이 어떻게 영향을 미치는지를 살펴볼 필요가 있다.
— Elvis Lee (@javauser) February 6, 2013

마이크로소프트에서 IE6~10을 테스트 할 수 있는 가상 머신을 배포하고 있네요. modern.ie/virtualization…
— Hyeonseok Shin (@hyeonseok) February 1, 2013

What makes a great tester? ebaytechblog.com/2013/01/31/bec… Come close to describing you? I'm seeking such a tester here in Arizona.
— Ben Simo (@QualityFrog) February 1, 2013

프로그래머가 QA에게 테스트 제대로 안 하냐고 하는 건 QA가 프로그래머에게 개발 똑바로 안 하냐고 하는 거와 같이 당사자 앞에서는 해서는 안 될 말이라고 생각하는데.. 직급이 깡패지.. 한숨이 나온다. 퇴근이나 하자.
— 다크리스 / Yeonsik Choi (@DarkRiss) January 23, 2013

전달해야 하는 클라이언트 버전을 테스트 하다가 뭔가 문제가 생겨서 야근을 하게 생겼는데 이미 퇴근한 프로그래머가 다시 출근해서는 QA 제대로 안 하냐고 뭐라고 한다. 클라이언트가 문제가 생긴 건 프로그래머가 개발을 개발새발 해서지 QA가 안 되서인가?
— 다크리스 / Yeonsik Choi (@DarkRiss) January 23, 2013

소프트웨어공학센터 <웹진 40호 : 동향 브리핑> SW 자동화 테스팅, 테스트 엔지니어를 대체할 수 있을 것인가software.kr/mbs/swkr/jsp/b…
— Ted (@booiljoung) January 21, 2013

소프트웨어 변경시 영향성 평가는 그 자체가 부정확하고, 난해하기문에 생략하기도. 영향성평가에 담긴 의미는 '오를 수 있는 나무를 쳐다보라는 뜻' 나무의 높이를 주의하자는게 아니라, 나무에 오르고 나서 나무 줄기가 부러지지 않을지 살펴보라는 것.
— Ted (@booiljoung) January 20, 2013

한달 전 모 서비스의 로컬라이징의 범위를 보면서 우려를 했었는 우려가 현실로... 대체 어쩌려고 그렇게 일을 벌였는지... 로컬라이징 수준을 넘어 재창조 수준이 되어 버려 잦은 시스템 장애... 이 정도의 시스템 장애라면 결코 회복 불가능.
— Ted (@booiljoung) January 20, 2013

Utest 정도의 규모는 아닌 것 같은데, 생긴지 얼마 인되서 그러나? 프로필 작성하면 200불 준다기에 우선 작성. 줄려나? testlio.com
— pdaclub (@pdaclub) January 17, 2013

@o_ra_ku_ru @mcalstlr @kichiku100 @teikiss 솔직히 게임회사 다니는 입장에서 보면 그렇게 세팅하는 게 훨씬 더 번거로울 거 같긴 합니다. 확률이 제대로 들어갔는지 각각의 상황에 따라서 다 테스트를 해야 할테니까요..
— 다크리스 / Yeonsik Choi (@DarkRiss) January 15, 2013

@javajigi 테스트를 쉽게 하기위해서는 인젝션 형태가 되어야 하고, 해당 클래스의 책임을 잘 결정해야할 것 같습니다^^. 저는 디자인패턴에서 생성, 구조, 행위로 분류한 것이 책임을 결정하는데 도움을 준다고 생각합니다^^
— 최영목 (@scroogy_choi) January 14, 2013

DateMessageProvider에 대한 정리 및 느낀 점: 잡 생각 때문에 잠이 오지 않아서 뒤척이다가 이 곳에서 코드를 가지고 더 많은 이야기를 했으면 좋겠다는 생각이 들었다. 프로그래머라면 코드... bit.ly/WVjssy
— 박 재 성 (@javajigi) January 14, 2013

삼성 엔지니어들 어쩔... 통신사마다 요구사항이 다르니 수십가지 젤리빈브랜치를 내놔야 할텐데... 브랜치별로 패키징하고 테스트만 해도 헬이라는걸 개발자들은 알텐데... "@atsuhiro6: 삼성의 패기 twitter.com/Atsuhiro6/stat…"
— Ted (@booiljoung) January 10, 2013

구글 회장의 북한 방문 소식에, 다른 국가 사업가들은 '안전' '국보법' '허가'에 관련하여 우리보다 적은 제약으로 북한 관련 사업을 할 수 있겠구나 하는 생각이 드는건 나뿐일까. 북한 자원들이 외국 기업들로 넘어가는 것은 당연 한 수순일듯
— Ted (@booiljoung) January 3, 2013

'구글 탭 암살자' 특허. 사파리도 그렇지만, 크롬은 캐시가 많아서인지 메모리 사용량이 높더라능. 메모리가 부족해지면 일부러 브라우저를 종료하고 다시 재시작 하는데 (보통 1기가 메모리 확보) 자동으로 관리해 주려는 듯.
— Ted (@booiljoung) January 3, 2013

선거관리위원회가 터치스크린전자투표를 계획하고 있나 봅니다. 신뢰성을 위해 어느 기관에서 인증을 받는다는 정보가 전혀 없습니다. 이걸 어떻게 믿죠? 개발자들은 아실겝니다. 조작 코드를 넣는건 무궁무진하다는거... nec.go.kr/nec_new2009/in…
— Ted (@booiljoung) December 27, 2012

소프트웨어 인증은 첫번째 소스 코드를 읽고 분석하고, 동일 방법으로 빌드 하였을때 동일한 바이너리를 얻는것이 첫번쨰 입니다. 두번째는 멍키 테스트로 아무렇게나 조작하는 것입니다. 터치의 경우 매 화면을 뒤지듯이 조합하여 터치를 해보는 거죠.
— Ted (@booiljoung) December 27, 2012

전자투표의 경우 외부 해킹은 인가된 장비만 접속할 수 있도록 하고, 외부 회선을 차단하면 됩니다. 하지만, 이것만으로 개발자들(내부)에 의한 조작을 막을 수 없습니다. 이를 막기 위해서는 공신력 있는 기관들의 인증이 필수입니다.
— Ted (@booiljoung) December 27, 2012

또한 캐쉬영역을 제외한 운영체제와 소프트웨어는 하드웨어에 의한 읽기 전용 영역에 저장되어야 하며, 해당 파일/영역은 해쉬 코드에 의해 인증이 되어야 하고, 감시가 되어야 합니다. (파일 변형 감시는 지원한다고 하네요).
— Ted (@booiljoung) December 27, 2012

'▶ 테스팅 24시 > 테스터스 초이스' 카테고리의 다른 글

TESTER’s CHOICE #18 – 타임라인 뉴스 (2)	2013/02/21
Tester’s Choice #17 – 해외 아티클 추천 (0)	2013/02/21
테스터스 초이스 16 - 해외 아티클 추천 (0)	2013/02/19
[Tester's Choice] #15 - 국내외 소식 (0)	2013/02/14
[Tester's Choice] #14 - 해외 아티클 소개 (0)	2013/02/14
테스터스 초이스 13호 - 타임라인 뉴스 (0)	2013/02/13
테스터스 초이스 12호 (0)	2012/04/05
테스터스 초이스 11호 - 타임라인은 지금 (0)	2012/02/02
누가바 레이더망에 걸려든 전세계 테스트 매거진 목록 (4)	2012/01/12
테스터들을 위한 매거진, [TESTER's CHOICE] 10호 (0)	2011/12/29
테스터들을 위한 매거진, [TESTER'S CHOICE] 9호 (2)	2011/12/27

[번역] 테스터를 위한 디버깅

검은왕자 — Tue, 12 Feb 2013 12:17:02 +0900

앨런 페이지가 쓴 “Debugging For Testers”를 번역했습니다.

테스팅 업계의 큰 화두인 “테스터가 코드에 대해서 얼마나 알아야 하는가?”라는 명제에 대한

앨런 페이지 개인의 답이기도 하면서, 제 개인적으로도 동의하는 의견인지라 흥미있게 읽은

포스트입니다.

실제로 크래시가 발생할 경우 콜스택을 활용해 수정 작업을 진행하고 있어서 제게는 더욱

의미가 있었던 포스트 같습니다.

번역 및 포스트에 대해서는 저자의 허락을 받았습니다.

출처: Tooth of the Weasel - Alan Page's blog

Debugging for Testers

Alan Page

최근 개인적으로 내게 경각심을 불러일으키는 말들을 자주 들을 수 있었다. 내가 들은 이런 말들의 요지는 한 마디로 ‘디버깅은 코더들을 위한 것이고, 테스터들은 단순히 이슈를 찾는 것 뿐’ 이라는 것이다. 이렇게 말하는 이유를 이해할 수 있다(아니면 적어도 최소한 이해한다고 생각한다). 나는 모든 테스터가 코더일 필요는 없다는 말에도 동의한다. 또한 모든 테스터들이 디버깅 마스터가 될 필요도 없다. 하지만 그 어떤 테스터도 디버깅을 두려워해서 이를 멀리해서는 안된다고 생각한다.

사실, 오히려 나는 모든 테스터들이 디버깅에 대해 최소한의 지식은 가지고 있어야 한다고 생각한다. 그들이 끝내주는 프로그래머이거나, 혹은 파트타임으로 일하는 IT 애플리케이션 테스터이던간에 상관없이 말이다.

자, 이제 시작해보자. 좀 짜증이 나면 더 길어질지도 모르지만…

여기부터다.

모든 테스터들이 디버깅에 대해서 알아야만 하는 것들

● 콜스택 – ‘콜스택(Call Stacks)’은 애플리케이션 크래시를 유발하는 일련의 기능들을 일컫는다. 각각의 다른 디버거들이 조금씩 다른 형태로 이를 보여주지만, 일단 대부분의 형태는 다음과 같다.

FunctionThatCrahsed

Function_Three

Function_Two

Function_One

아래부터 위로 읽으면 된다. Function_one 이 Function_Two 를 호출하고, Function_Two 가 Function_Three 를 호출하고, 마지막으로 Function_Three 가 크래시를 유발한 FunctionThatCrashed 를 호출하는 형식이다.

십중팔구 어떤 함수들이 이 목록에 있는지를 살펴보았다면, 그 다음으로 이 함수들의 파라미터에 대해 조사하게 될 것이다. 바로 이 파라미터 값들이 당신에게 문제를 푸는 실마리를 던져줄 것이다. 만약 당신이 개발자와 함께 일하는 환경에서 디버거에서 이런 크래시가 발견되고 콜스택이 남았다면, 이런 콜스택이야말로 당신이 테스트로서 개발자에게 제공할 수 있는 가장 중요한 정황 정보가 될 것이다.

● 크래시 vs. 어서트 – 프로그램이 갑자기 디버거를 띄울 때, 즉 프로그램이 실행을 중단하고 디버거가 갑자기 구동될 때, 이는 해당 프로그램에서 유효하지 않은 메모리를 대상으로 읽기/쓰기 행동을 시도하는 것과 같은 크래시가 발생했거나, 혹은 개발자가 심어놓은 브레이크포인트[1](주로 ‘어서트(assert)[2]’라고 불리우는 매크로)가 구동되었을 경우라고 보면 된다. X86/amd64 플랫폼에서는 디버거 상에서 int 3 혹은 int 2C 라고 표시된다. 어서트 형태로 에러가 표시되는 경우, 가장 주목해야 할 점은 바로 프로그램 실행을 중단시킨 이유가 아주 명백하다는 것이다. 최소한 당신이 코드를 볼 수 있다면 이는 더 명백해 질것이다. 실제로, 어서트는 다음과 같이 활용된다.

bool bSuccess = CreateUserAccount();

//break into the debugger of the call to CUA fails so we can debug

ASSERT(bSuccess == true);

이런 상황에서 프로그램 실행이 중단되었을때, 테스터는 단순히 “로그온 도중에 프로그램에서 크래시가 발생했다”라고 말하는 대신에, “오늘 빌드의 CreateUserAccount 함수에서 오류가 발생해 어서트가 동작했다”라고 말할 수 있을 것이다. 두 문장 모두가 나름대로의 가치를 가지고 있지만, 후자가 좀 더 충실한 정보를 전달하고 있다는 것은 누구나 알 수 있을 것이다. 대부분의 경우 이 정보를 기반으로 당장 문제의 수정에 필요한 행동에 착수할 수 있을 것이다.

● 기본적인 단어들 – 크래시의 기본적인 형태 몇 가지에 대해서는 반드시 알고 있어야 한다. 예를 들어, 접근 오류(AV; Access Violation), 스택 오버플로우(Stack Overflow), 버퍼 오버런(Buffer Overrun) 등의 크래시와 이를 유발하는 원인에 대해 잘 알고 있어야 한다. 즉 잘못된 메모리 주소를 읽어들인다든지, 일반적으로 루프가 잘못 되어 발생하는 너무 많은 함수를 호출하는 경우, 혹은 버퍼에 너무 긴 스트링을 넣는 것들이 크래시를 유발한다는 것을 인지하고 있어야 한다.

당신이 전문가가 될 필요는 없지만, 여기 적어놓은 몇 가지 지식들이야말로 버그를 분석하고 이를 수정하게 되는 길고 긴 여정의 출발점이 되는 것이다.

지금 당장 생각해보면 이 정도면 일단 충분할 것 같다. 하지만 충분히 많은 것을 다룬 것은 아니다. 아직도 배워야 할 것들은 더 많이 남아있고, 지금 이야기한 것들은 프로페셔널 테스터가 되기 위해 알아야 하는 최소한의 것에 지나지 않는다.

더 좋은 아이디어들이 있다면 코멘트에 추가해주길 바란다.

[1] 역자 주: 프로그램에서 디버깅을 목적으로 프로그램의 실행을 내부적으로 멈추게 하는 지점을 의미한다.

위키피디아 ‘breakpoint’ 참조.

[2] 역자 주: Hermet님의 블로그 ‘길고 긴 모험’의 asset문 사용하기 참조.

'▶ 테스팅을 말한다' 카테고리의 다른 글

[번역] 테스터를 위한 디버깅 (1)	2013/02/12
[번역] 소프트웨어 테스팅은 게임이다 (2)	2013/01/08
확률을 어떻게 테스트 할까? (10)	2013/01/06
고객인가 동료인가 - QA가 바라본 게임 개발사와 퍼블리셔의 관계 (1)	2012/11/20
끊이지 않는 버그 (0)	2012/08/05
[번역] 모델 기반 테스팅에 대해 알아야 할 것들 (7)	2012/03/27
[번역] 리그레션 다시 생각해보기 - 파트 5: 테스팅 미션을 결정하라 (0)	2012/03/26
[번역] 리그레션 다시 생각해보기 - 파트 4: 리그레션 테스팅에서 잘못된 점은 무엇인가? (0)	2012/03/26
[번역] 리그레션 다시 생각해보기 - 파트 3: 리스크 완화 전략 (0)	2012/03/05
[번역] 리그레션 다시 생각해보기 - 파트 2: 리그레션이란 무엇인가? (0)	2012/01/09
[번역] 리그레션 다시 생각해보기 - 파트 1: 힘들게 얻은 교훈 (0)	2012/01/09

와인 테이스팅(Wine Tasting)과 소프트웨어 테스팅(Software Testing) -#1

ikooya — Mon, 11 Feb 2013 19:03:35 +0900

와인 테이스팅(Wine tasting)과 소프트웨어 테스팅(Software testing)

저는 요즘 취미 생활로 와인 테이스팅(Wine Tasting)을 즐기고 있습니다.

공교롭게도 저의 직업은 소프트웨어 테스팅(Testing)과 관련이 깊고, 취미 생활은 와인을 테이스팅(Tasting)을 하는 일이네요. 테이스팅과 테스팅, 뜻과 쓰임새는 전혀 다르지만 어떤 부분에서는 많이 비슷하기도 합니다.

와인 테이스팅 방법 중에는 '블라인드 테이스팅' 이라는 것이 있는데요,

말그대로 와인의 레이블을 모두 가려 놓고, 와인에 대한 어떠한 정보도 주어지지 않은 상태에서

와인의 빈티지(포도 수확 년도)나 포도 품종, 숙성 기간 등을 맞춰가는 방법입니다.

와인 테이스팅은 워낙 역사가 깊다 보니, 조금만 찾아보면 관련 자료들을 많이 얻을 수 있습니다.

포도 품종별로 어떤 향이 나는지, 숙성 과정 및 방법에 따라 와인의 향과 마실때의 목넘김이 어떻게 다른지 등등의 것들이지요. 그리고 이런 자료들을 토대로 블라인드 테이스팅을 수행했을때,

그러지 않았을때보다 훨씬 맞추기가 쉽습니다. 좀 더 성공적인 블라인드 테이스팅을 위해서는 이론만으론 한계가 있고 경험적으로 습득한 지식들이 필수적으로 수반되어야 하지만요.

취미로 블라인드 테이스팅을 해보면서,

지금 제가 일하고 있는 소프트웨어에 빗대어서 생각해 보았습니다.

요구사항이나 스펙 등 제품에 대한 어떤 정보를 사용하지 않고서도, 표준적으로 정의된 어떤 잣대를 통해 기본적인 품질을 파악할 수 있다면 얼마나 좋을까 하고요.

(물론 요구사항부터의 검토가 중요하지 않다는 얘기는 아닙니다.)

특히나, 모바일 소프트웨어의 경우 요구사항의 변화가 워낙 빠르고,

우주로켓에 사용되는 소프트웨어 만큼 수준높은 품질이 요구되지 않기 때문에 어느정도 제품이 안정화 되었다면, 마케팅 측면에서의 품질을 고민하는 것이 훨씬 더 중요하다고 생각합니다.

기본적인 품질을 파악하기 위한 잣대를, 체크리스트의 형태로도 만들 수 있을 것 같은데요.

iOS 나 Windows8 의 경우 앱을 스토어에 등록할때 필수적으로 통과해야만 하는 체크리스트가 있지만, 그것만으로는 부족한 느낌이 들더군요.

다르게 생각해보면,

FGI(Focus Group Interview)에 사용되는 설문지 처럼 사용성 관점에서의 체크리스트를 통해 해결할 수 있는 문제를 너무 깊게 고민하는 것은 아닌가 하는 생각도 들고요.

제가 써놓고도 참 애매하네요. ^^;ㅋ

블라인드 테이스팅 말고도 와인을 마시면서 직무와 관련된 여러가지 생각들을 했었는데요,

차근차근 공유하도록 하겠습니다..

번외)

요즘 와인을 집에서 거의 매일 마시다시피 하다보니, 맥주를 마시는 회식자리에서도 맥주잔을 돌려가며 마시는 이상한 버릇이 생겼습니다. ㅜ.ㅜ 혹시 와인 테이스팅에 관심있거나, 와인에 대해 입문하고자 하시는 분은 언제든 연락주세요~!

같이 마시면서 이런저런 얘기 나누는것도 좋고, 취향에 맞는 와인 추천도 해드릴게요.

허접한 포스팅 읽어주셔서 감사합니다. 와인 테이스팅과 소프트웨어 테스팅 1편 -끄-읕-

'▶ 테스팅을 말한다 > 테스팅 일반' 카테고리의 다른 글

소프트웨어 테스팅(Software Testing) 과 와인 테이스팅(Wine Tasting) (6)	2013/05/06
왜 개발자들이 유닛 테스팅(Unit Testing)을 싫어할까? (1)	2013/03/18
테스터들의 사고방식 (1) - 제로베이스 사고 (1)	2013/02/18
와인 테이스팅(Wine Tasting)과 소프트웨어 테스팅(Software Testing) -#1 (3)	2013/02/11
Google CodePro AnalytiX 소개 - 안드로이드 개발/테스트를 위한 정적분석 도구 (1)	2012/12/10
소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기 (0)	2012/12/03
탐색적 테스팅에서의 세션과 차터 (0)	2012/11/05
Bug Olympics (2)	2012/10/06
서비스의 불균질성 (1)	2012/09/21
버그 리포팅을 도와주는 7가지 팁 (5)	2012/08/16
당신의 버그 리포트에 꼭 들어가야 할 내용들 (3)	2012/08/05

[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN

별의카비 — Sat, 09 Feb 2013 21:06:25 +0900

FUN QA? 재미를 테스트 할 수 있는가?

저번 시간에 이어 FUN QA는 그럼 어떤것인가에 대한 고민을 해 보도록 합시다.

1.FUN QA 그건 마치 게임에선 수표 일지도 모른다.

1. FUN QA는 일종의 수표 같은 존재입니다. 하지만 만능에 백지수표까지는 아닙니다.

게임에 있어서의 재미는 흥행을 이야기 하기도 합니다.

게임도 역시 미디어기에 많은 사람이 할 수록 유리합니다.

물론 소수 정예를 이루는 매니악한 게임도 있습니다.

인기 = 이윤! 아니지요.. 사실 인기만으로 이윤으로 이어지지는 않기도 합니다.

재미를 측정하는 일은 상대적인 일입니다.

즉 FUN QA는 이 게임이

게임의 기획요소 및 요구사항에 적합한지

가상의 공간 혹은 세계관이 현실과 조화를 이룰 수 있는지

현실상에서는 시장 조사를 바탕으로 재미가 있을지 분석을 하고

주변에 있는 정보나 기법을 모아서 위험성을 예측 한다.

즉 기획적 능력과 품질적인 능력을 동시에 지녀야 한다는 이야기가 되겠죠.

2. 낚시게임으로 예를 들어보자.

카드나 고스톱을 예를 들면 어떤 부서가 화 내실거 같으니 낚시게임으로 예를 들어 보겠습니다.

낚시게임의 재미 요소는 무엇일까요?

1. 여러사람에서의 경쟁 속에서 내가 더 크고 희귀한 물고기를 잡았다.

2. 어려운 시도 끝에 거대한 물고기를 낚았다.

3. 희귀한 장비를 돈을 모으거나 뽑기를 해서 샀다.

...

뭐 꼽으라면 엄청나게 나옵니다. 이걸 측정 할 수 있을까요? 결국엔 못합니다. 너무 구체적이지 않습니다. 재미를 찾아 나서기 위해서

기획서를 요구하곤 합니다. 게임에 대한 기획 및 요구사항 / 제반 사항 등을 회의나 기획서를 통해서 알아보곤 합니다.

기획 했던 사항이 잘 적용이 되었는지 볼 수 있습니다. 만약에 낚시게임에서A섬에 대한 업데이트에 대한 기획이 있었다고 쳐보도록 하겠습니다.

(한 5분 정도 기획된 겁니다..)

어쩌구 낚시 게임(가칭)

구현 된 사항 : 50랩까지 있음 / 낚시대는 평균 중급 고급 낚시대가 존재함/ 물고기 어종별로 다른 미끼를 먹음/ 프리미엄 물고기가 있음

고급 미끼가 구현되어 있음 / 이벤트 어종이 있음/ 어류를 모으는 도감이 있음 (이벤트 한정 도감 / 일반적인 도감)/10회 이상 물고기

텐션 유지 실패시 도망감. / 릴 조정이 아니라 HIT 방식이다./ 재도전 할 수 있음

A 섬 기획안

물고기 종류 : 25LV 부터 입장 가능/ 거북이는 이벤트 어종이다.

어종:오징어 / 꼴뚜기 / 대구 / 명태 / 거북이 / 연어알 / 물새알 / 인어

먹이: 비실비실한 지렁이 / 싱싱한 지렁이 / 멍한 새우 / 싱싱한 새우 / 금삐까 미끼 / 프리미엄 김중배의 다이아몬드 미끼

난이도

오징어 / 꼴뚜기 / 대구 : 일반어종 : HP 300 27 lv 평균 5lv 낚시대로 약 30hit 및

텐션 유지로 잡을 수 있음 (다이아몬드 미끼 제외 전 미끼) 도감에 들어감. 시간제한 : 40초 도감보상 : 적음

대구 / 명태 : 일반어종 :HP 500 27 lv 중급 5lv 낚시대로 약 36hit 및

텐션유지로 잡을 수 있음(싱싱한 지렁이 / 멍한 새우만 나옴) 도감에 들어감 시간제한 : 40초 도감보상 : 보통

거북이 : 특수어종 HP 660 30lv 중급 5lv 낚시대로 약 42hit 및

텐션유지로 잡을 수 있음 (이벤트 기간엔 멍한새우 이후 금삐까 미끼 및 김중배 다이아몬드 미끼) 한정기간 시간제한 : 40초 도감보상 : 높음(한정적)

연어알 / 물새알 : 특수 어종 : HP 600 27lv 중급 5lv 낚시대로 약 40hit 및

텐션유지로 잡을 수 있음. 도감에 들어감 (금삐까 미끼만 나옴) 시간제한 : 40초 도감보상 : 높음

인어 : 초 레어어종 : HP 1200 27lv 고급 5lv 낚시대로 약 60hit 및

텐션유지로 잡을 수 있음. 도감에 들어감 시간제한 : 45초 도감보상 : 아주 높음

자 이렇게 내놓고 구현을 해 왔습니다. 거북이가 피가 제대로 구현이 안 되었네요. 거북이의 지느러미가 그림에서 삐져나왔습니다!

를 FUN QA가 잡을 필요는 없죠.. 사실은..

뭐 국내 게임회사분들은 힘들게 다 하고 있을 수도 있습니다.. 몇 가지 재미요소를 살펴보자면..

물고기 마다 난이도가 틀려서, 도전을 할 수 있다.

도감이 있어서 어종들을 모을 수 있다. 보상이 난이도에 따라서 틀리다.

일반적인 낚시와 비슷한 HP 게이지이지만 HIT라는 점으로 텐션 조절을 단순화 시켰다.

수시로 이벤트를 하여 유저에게 보상을 준다.

여기서 FUN QA는 보상에 관련된 사항도 고민해야 하지만..그보다 유저가 떨어져 나갈 요소가 몇가지 보입니다.

이런걸 지적해 보고 집중 테스트를 하면 될 듯합니다.

A. 난이도에 대한 궁리를 해봅시다.

일반적으로 10번의 실수를 안하고 45초 동안 60번을 하려면 플래쉬를 불러야 할거 같군요..

시간이 거진 비슷합니다. 대충 봐도 1초에 1번씩은 두들겨야 겨우 잡네요..

이러한 것을 시트프로그램이나 뭐.. 그냥 메모장에 적어서라도 통계를 내어봅시다..

0.78CP 정도 겠죠.. 거진 카메라 셔터 속도입니다. 찰칵!?

도전이 불가능 한 거라면 사람들이 재미가 없어 할 수 있습니다.

그리고 25LV 부터 올 수 있지만.. 실상 27LV 낚시대를 요구하는군요.. 이건 뭐 택도 없습니다.

25LV 유저는 오지 말라는 이야기가 될 수 있겠군요.. 25LV 을 27로 바꾸던가 하는게

좋다는 생각이 듭니다.

"도망가는 시간 과 LV 제한 "이라는 재미 반감요소를 찾았으니..

기획팀에 올려봅시다.. 물론 이는 구체적 통계가 있어야 합니다.

사실 기획팀은 재미 요소를 찾아냅니다.

재미 반감요소에 대한 재심의 시간이 있는 전문적인 팀은 극히 드뭅니다.

심리학자를 준비해 놓은 회사는 몇 없기 때문이죠...

국내에는 아직까지 제가 아는 회사중에는 못 본거 같습니다.

B. 반짝 이벤트에 대한 항목은 아래에도 설명하지만 사실 테스트가 어렵습니다.

위에서 거북이는 사실 재미 요소에 있다고도 아니라고도 할 수 있습니다. 왜냐하면..

거북이를 잡아도 보상은 높지만 연어알 / 물새알에 비하면 메리트가 적다고 할 수 도 있습니다.

난이도는 비슷한데.. 주는건 같다? 그럼 목적이 도감 보상인 사람에게는 반감이 오게 되겠죠.

3.제약요소가 있지는 않을까?

재미란 요소는 상대적인 요소입니다 QA만으로는 잡을 수 없습니다.

재미를 반감시킬 수 있는 요소 중 테스트 불가한 것은 과감하게 측정 불가능 함을 주장 하여야 합니다.

FUN QA가 테스트 불가능한 항목

A. 각각 캐릭터간의 상성 관계 및 통계는 내어 볼 수 있지만, 그 밸런싱을 조절하는건 불가하다.

통계분석은 QA가 한다기보다는 기획적 요구 사항 문제 일 수 있다.

B. 캐쉬에 의해서 조절되는 항목 및 반짝 이벤트에 대한 재미를 사전에 측정하는 것

C. 서버 문제 가 일어나거나 높은 사양 운영적인 요소에 의한 재미 반감 요소도 측정이 불가함.

D. 적절한 업데이트 시기를 놓치거나 폐기가 된 프로젝트에 대한 재미 검토를 하는건 시간 낭비 일 수 있습니다.

보상이 가장 문제다! 하지만 결국 FUN QA가 측정이 가능한 부분은 아니라고 봅니다.

이러한 보상이 게임 내에선 사소할 수도 클 수도 있습니다. 남들과 경쟁을 하는 게임은 주 목적이

과시나 자신이 높은 등급에 있다는 것을 보여주어야 하기 때문입니다.

시각적이나 자신의 게임플레이에 스탯에 영향을 미치는 그런게 없다면 사람의 감성적인면에서의 보상을 유도할 수 있습니다.

하지만 이건 측정이 불가능 합니다. 하지만 한가지는 확실합니다. 사람들은 희소성이 있거나

자신이 관계를 가져야 하는정도는 되어야 한다는 것이지요. 중점적으로 테스트를 하도록 합시다.

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1

별의카비 — Sat, 09 Feb 2013 21:05:00 +0900

FUN QA? 재미를 테스트 할 수 있는가?

국내에 어느샌가 FUN QA라는 직종이 보이기 시작 했다. 재미는 측정이 가능한가?

사실 사람의 심리에 대한 측정을 해보려는 시도는 심리학에서도 엄청나게 많이 나오는 단골 메뉴이기도 합니다.

게임에서의 재미에 대한 내용을 규정 짓는건 무리가 있지만, 아래 4가지 기본 요소라고 할 수 있는 내용을 한번 살펴봅시다.

이는 사실 "보드게임" 에서 유래가 되었습니다. 즉 던전 앤 드래곤 등의 롤북 이나.. 모노폴리 등의 말판 게임을 생각하면 되겠습니다. 사실 비주얼 게임 자체도 시나리오나 책 보드게임등에서 상상의 현실을 일구어 낸 결과물 이라고 할 수 있습니다.

일단 글에 들어가기 전에.. 아래의 목적 목표 경쟁과 몰입을 한번 살펴보시죠.

목적(Goal)

- 결정과 행동을 위한 '큰 틀'을 제공

- 매일매일의 결정을 내리는 데는 큰 도움이 되지 않을 수도 있음.

- 광범위하고 추상적인 개념으로 직접적인 측정이 어려움.

목표(Objective)

- 미래의 어떤 시점에서 이루고자 기대하는 구체적인 결과

- 무엇을 성취하고자 하는가에 대한 진술

- 현실적으로 실행 가능하고 측정 가능한 것을 의미.

목적(Purpose)

- 어떤 것을 하려는 근본적인 이유나 동기

* 어떤 수단이나 행위를 필요로 함.

* 즉, 목적이 있음으로써 그것을 실현하기 위한 운동이 일어나는데, 목적을 운동의 원인이라고 본다.

- 목적은 목표보다 광범위하고 막연하고 추상적일 수 있다.

목표(Objective)

- 행동이 지향하는 최종적인 결과

- 형식상 시간적(단기,장기) 및 공간적으로 설정할 수 있음.

- 결과에 이르기까지 상당한 노력이 따라야 하는 것

- 대체로 현실적이고 실현이나 성패 여부가 분명히 판가름되는 것

예를 들어 인생의 목적이 '행복하게 사는 것'이라면,

목표는 '올해 시험에 합격하기' 등으로 계획적이고 구체적이다.

* 목표: 달성하고자하는 상태
* 목적: 목표를 달성하고자하는 본질적인 이유

목적

- 가고자 하는 방향을 일반적인 수준에서 방향성을 추상적인 수준에서 제시

- 직접 관찰하고 측정할 수 없다.

- 일반적인 방향성이라는 범주 내에서 어느 정도의 개연성과 융통성을 발휘

- 목표보다 불확실한 상황적 변수가 만들어내는 외부 환경변화를 인정하고 수용하면서 여러번의 궤도 수정을 인정

- 하고 싶은 것

- 비전(Vision)

- 불확실성을 내포

- 어느 정도의 感과 직관을 통해 방향성이 맞다고 판단하면 일단 저지르고 보는 스타일. 생각하면서 행동하고, 행동하면서 생각하는 동시 다발적, 동시 병행적(Concurrent) 돌격 스타일. 사전에 예측할 수 없음을 전제하면서 돌발성, 돌출성을 인정하는 창발적(emergent)

목표

- 달성하고자 하는 바를 아주 구체적인 수준에서 설정

- 객관적으로 관찰, 측정 가능하게 진술

- 최적의 합리적인 방법 또는 수단을 동원하여 효율적으로 효과적으로 달성

- 달성되어야 하는 구체적인 지향점

- 해야만 하는 것

- 미션(Mission)

- 확실성의 추구

- 사전에 어떤 일이 일어날 것인지 정확하게 예언할 수 있다는 예측 가능성을 철저하게 신봉, 목표 우선, 행동 나중 주의자. 불확실함을 확실한 그 무엇으로 전환시키지 않고는 심리적으로 불안해서 도저히 참지 못하는 성격의 소유자

경쟁

둘 이상의 사람이나 정당이 무언가를 놓고 겨루는 것을 말한다. 경쟁은 보통 제한된 자원을 가진 환경에 공존하는 생물 사이에서 자연스럽게 일어난다. 짐승들은 물, 먹잇감, 짝짓기 대상 등을, 사람들은 부, 명예, 신임 등을 두고 경쟁한다

몰입

주위의 모든 잡념, 방해물들을 차단하고 원하는 어느 한 곳에 자신의 모든 정신을 집중하는 일이다.

심리학자 칙센트 미하이는 몰입했을 때의 느낌을 '물 흐르는 것처럼 편안한 느낌', '하늘을 날아가는 자유로운 느낌'이라고 하였다. 일단 몰입을 하면 몇 시간이 한순간처럼 짧게 느껴지는 '시간개념의 왜곡' 현상이 일어나고 자신이 몰입하는 대상이 더 자세하고 뚜렷하게 보인다. 몰입대상과 하나가 된듯한 일체감을 가지며 자아에 대한 의식이 사라진다. 몰입현상은 학습과 노력을 통하여 도달할 수 있다. 자신이 몰입하고 있는 대상에 대해서는 단시간에 혹은 빠르게 흡수 할 수 있지만 반대로 관심이 없거나 집중도가 떨어지는 대상에 대해서는 기억조차 못할 수도 있다. 이것이 바로 몰입의 장점이자 단점이 될 수 있다.

아래 표는 기존의 연구에서 나온 자료를 요약하여 간단하게 구성한 표로.. 정말 정확한 자료를 원하신다면.. 국외 게임에서의 통계자료를 찾아보시는게 편할 겁니다.

구분	게임에서의 주요도	관계별 변화	게임에서의 예	재미
목표	필수적	상대적 제안	게임에서의 플레이어 역활 수행 퀘스트 진행 등	?
목적	필수적	절대적 제안	퀘스트 보상 명성치 / 요구치 등
경쟁	선택적	상대적 제안	타임어택 PVE PVP / PK 요소 상업적 경쟁 등
몰입	선택적	상대적 제안	구체화 불가 (구체화 가능하다 는 것이 말도 안됨)

큰 상승 큰 감소 다소 상승 다소 감소상호 보완다름

이론적으로는 분명히 4가지면 될텐데 왜 이런일이 벌어지는 걸까??

그 건 사람마다 재미를 느끼는게 차이가 있기 때문이기도 하고, 이 4가지는 동적인 게임에는 적용이 되지 않습니다.

정적인 게임 즉 룰이 아예 정해져 있는 보드게임엔 가능한 이론이지요.

게임을 크게 보면 매스 미디어 입니다. 그래픽 및 영상 / 음향 / 효과 / 규칙 / 소셜 등..

실체는 나눌 수도 없습니다.

즉 자극적인 문제만 봐도 잔뜩 있기 때문일 겁니다.

[게임을 구성하는 자극요소]

시각적 자극

= 눈으로 느낄 수 있는 자극 / 사람이 기본적으로 느끼는 자극 중 가장 큰 자극 요소 입니다.

이 자극은 광원 / 색 / 형태 / 움직임 등을 감지 할 수 있는데.. 사실 시각적자극이 게임의 요소에

큰 비중을 차지한다는건 틀림 없는 사실입니다.

청각적 자극

= 듣거나 들려지는 자극 / 시각적 자극 외에도 느껴지는 자극 요소로 다른 자극보다 물리적인 자극은 적지만..

다른 자극의 효과를 증폭시키거나 혹은 반감 시키기도 합니다.

촉각적 자극

= 누르거나, 행동시키는 자극 / 게임은 생각하는대로 움직여 지지 않기에, 애석하게도 디바이스가 필요합니다.

즉 뭔가를 누르거나 심지어는 자신이 움직이는걸 감지하기도 합니다. 최근에는 뇌파로 하는 게임에 대한 연구가

있지만.. 아직 이론적으로는 촉각적 자극으로 대부분은 분류 합니다.

감성적 자극

= 심리적인 공감 혹은 소속감 등의 자극 / 즉 게임의 스토리에 공감을 갖는다던지..

혹은 플레이어간의 우정 / 사랑 / 혹은 다툼의 관계에서 이루어지는 자극입니다.

(나쁘게 보면 니 등뒤에 내가 있다... 도 된다는 거죠..)

[그 외에 재미를 느끼는 요소]

지속성

- 지속성에 대한 의문은 많이 있습니다.

1. 이 게임이 얼마나 오래 갈까 ?

부터

2. 내가 이 게임을 해야 하는 이유가 있나?

여기에는 변수가 있습니다.

바로

3. 내가 이 게임을 하는 이유는 사람들끼리 모여서 하기 때문이고 이는 가상의 사회를 이루게 됩니다. ( 친구 / 지인 / 연인 / 가족 / 조금 넘으면 원수지간 등)

지속되는 것이 비단 게임만이 아니기 때문입니다.

그 게임을 하지 않더라도 그 게임을 같이 했었던 인물간의 관계에 따라서 옮겨 갈 수 도 있습니다. 즉 MMO RPG 하던 사람들이 모여서 FPS 게임을 할 수도 있는 겁니다.

사람과의 관계 유지에 있어서의 지속성을 다른 놀이문화와 함께 지니고 있다는 점입니다.

하지만 역시 과하면 독이 되겠죠. 어느정도의 규제는 당연히 필요합니다.

하지만.. 지속성이나 경쟁만이 과몰입으로 이어진다는 단순한 판단 기준은 위험 할 수 있다는 생각이 듭니다.

제가 개인적으로 생각하는 과몰입은..... 아무런 관계도 없이 오로지 목적만을 위해서 움직이는 게 바로 과몰입이 아닌가 합니다. 하지만 이것을 측정을 단순하게 오래한다 안한다 경쟁심을 유발한다 안한다를 5 점 4점 3점 2점 1점의 기준으로는 실효성이 있을지는 모르겠습니다.

보존성

- 아무래도 게임이던 소프트웨어던 저장을 하게 되면 , 자신이 어떠한 일을 해왔는가에 대한 데이터가 남아 있습니다. 물론 저장 기능이 없는 경우도 존재하지만. 최근에는 저장기능이 없는 게임은 없을정도라 봐도 무방합니다.

즉 " 호랑이는 죽어서 가죽을 남긴다 " 라는 거처럼 뭔가 남기는 합니다. 이건 개인마다 보존성에 대한 차이는 있을 수 있습니다. 자신의 게임데이터가 소중한 재산으로 인정 받을 수도 있지만, 반대로 개개인 혹은 문화에 있어서는 이러한 게임이 중요하지 않거나 사회적 암이 될 수도 있기 때문입니다. 보존성도 양날의 칼이 될 수 있습니다.

나아가서 게임이 문화 유산이 되기에는 아직 문화적인 인식의 차이가 있기에, 이건 후세에서 판단 할 거라 생각이 듭니다.

자질 구레한 재미에 대한 내용이나 기획적인 이야기는 이 정도로 하겠습니다.

그럼 FUN QA는 뭐하는 사람인데~? 하는 의문이 남습니다.

이건 다음글에 올리도록 하겠습니다.

'▶ 테스팅을 말한다 > 게임 테스팅' 카테고리의 다른 글

무료로 사용가능한 Testcase를 공유 합니다. (0)	17:49:27
[게임테스팅]서비스 및 게임 장애 유형들에 대한 대략적 분류 - 2 (글리치/그래픽 버그) (0)	2013/05/12
[게임테스팅] 서비스 및 게임 장애 유형들에 대한 대략적 분류 - 1 (1)	2013/03/17
게이머 구분하기 (0)	2013/03/04
[흥미기획] - FUN QA? 재미를 테스트를 할 수 있는가-FIN (0)	2013/02/09
[흥미기획] FUN QA? 재미를 테스트를 할 수 있는가-1 (0)	2013/02/09
비쥬얼드 블리츠를 테스트해보자! (2)	2012/07/03
bug와 glitch의 차이점 (12)	2012/04/13
게임 QA가 게임성에 관여해야 하는가? (2)	2012/03/27
게임 QA에 대해 설명하기 1편 (2)	2012/02/15
클라이언트 최적화 테스트하기 아프다 서비스(A/S) 입니다. (3)	2012/01/10

[번역]Where do Testers come from?

VeЯonica — Tue, 15 Jan 2013 16:49:06 +0900

너무 오래 포스팅을 하지 못해 전전 긍긍하다, 이론적인 내용이 아니어서 가볍게 읽히지만 자신을 한번 돌아보기에 좋은 글 같아 번역으로 옮깁니다.

uTest blog에 있는 글이라 uTest의 입장이 조금씩 뭍어있긴 합니다. 거슬리시면 skip!

원문 : http://blog.utest.com/where-do-testers-come-from/2012/12/ by Mike Brown

테스터들은 어디로부터 오는가?

더글라스 애덤스의 ‘Universe’^(1)역자주 처럼 소프트웨어 테스팅의 세상은 넓다. 정말 넓다. 얼마나 엄청나게, 무지막지하게, 도저히 상상할 수 없게 넓은지 당신은 믿을 수 없을 것이다. 지구 전체를 통틀어 수백 수 천명의 테스터가 문제를 해결하고, 버그를 찾고 셀 수 없이 많은 어플리케이션들의 품질을 개선하기 위해 일하고 있다.

그런데 그들은 어떻게 그 자리에 있게 됐을까? 그들은 어디로부터 온 걸까? 더 중요한 것은 테스터의 다음 세대들은 어디로부터 오게 될 것 인지이다. 꼭 정확히 그 단어가 아니더라도 이런 질문은 컨퍼런스나 기사 그리고 여러 가지 소프트웨어 테스트 블로그에서 거의 항상 들어왔다. 나는 이제 이 질문에 대하여 복잡한 얘기를 하고자 한다.

우리가 uTest에서 하려고 하는 것의 매우 큰 비중을 차지하는 것은 커뮤니티를 구성하는 것이다. 5년이 조금 넘게 지나면서 우리는 가능한 모든 배경과 skill set을 끌어 모았다. 그렇게 함으로써 우리는 테스터가 공통적으로 ‘그들이 거의 공통점이 없다’는 것을 알게 되었다. 즉, 그들은 그들이 테스터가 되기까지의 길이 서로 너무 다르다는 것이다.

그런 생각에 의거해 사람들이 어떻게 이렇게 훌륭한 프로의 자리에 까지 이르게 되었는지 깊이 있게 들여다 보고 싶다. 내가 예전에 말했던 것처럼 – 그리고 또 다시 얘기하게 되겠지만 – 정해진 경로(Path)는 없다. 변호사나 의사가 되는 것과 달리 직업에 필수적인 요구사항인 학력이나 시험 등이 없어도 경력을 밟아 나갈 수 있다. 그러나 소프트웨어 테스트 종사자가 되기 위해 최소한의 공통적인 길이 있긴 하다.

이번 포스트에서 나는 한가지 중요한 것을 짚고 넘어갈 것이다. 그건 바로 당신들의 강점과 약점이다. 그리고 당신에게 테스트 전문가(Expert)로부터 나온 통찰(Insight)를 제공할 것이다. 이것으로 두 그룹의 사람이 도움을 받을 수 있길 바란다.

1. 테스터가 되려고 생각하는 사람들

2. 테스터를 고용하려고 하는 사람들

자, 시작해보자.

인증된 기관 출신

QA종사자 중 꽤 많은 수가 모두에게 잘 알려진 ISTQB이라는 소프트웨어 테스팅 기관 출신이다. 이 같은 조직은 테스터 들이 테스팅 분야에 있어 반드시 필요한 교육(적어도 가장 기초적인 교육)을 받았는지 보증해 주는 것이 목적이다.

그들이 목표한 바를 이루고 있는지 아닌지는 테스팅 분야에서는 논란이 많이 있다. 논쟁이 되는 것에 대해 집요하게 조사하고 알아내려고 하기 보다는 나는 ‘인증’에 대해 찬성과 반대의 두 입장을 전해 보려고 한다. ‘인증된 프로’ 측면에서 우리는 ISTQB의 의장(President)으로 있을 당시의 렉스 블랙의 말을 인용해 보겠다. 이것은 2010년에 ‘테스팅의 한계’라는 인터뷰에서 그가 한 말이다.

"ISTQB 기초와 심화과정 교본(syllabi)을 읽어 보십시오. 그리고 만약 테스터로 살아가고 있는 모든 사람들이 거기 나와 있는 기술, 전략, 개념에 대해 안다면 테스트 세상이 조금 더 나아질 수 있을지 없을지를 스스로에게 물어보십시오. 나는 확실히 그렇다고 생각합니다. 많은 회사와 개인이 지난 10년간 16만 이상의 ISTQB를 발행한 나와 같은 생각일 것입니다."

랙스 블랙의 이 인터뷰 내용이 반드시 진리로 받아들이거나 그가 쓴 것에 전부 동의하라고 말하는 것은 아니다. 하지만, 거기에서 좋은 아이디어를 받아 들일 수는 있을 것이다. 그리고 인증에 대해 반대하는 벤 시모 테스팅 전문가 캠프에서는 비슷한 시기에 이렇게 얘기하였다.

테스팅 인증기관을 비롯한 많은 IT인증기관은 교육보다는 마케팅이다. 이 인증기관들은 기술, 숙련도, 전문성, 자질을 측정하기에 적합하지 않고, 마케팅 측면으로 보아도 마케팅 하고자 하는 영역에 대해서 측정하기에도 좋지 않다. 구직자에 대한 면접을 해본 내 경험상, 테스터 인증은 지원자의 테스트 능력을 나타내지 못하였다.

소프트웨어 테스팅은 풍부하고 다양한 영역이다. 또한 매우 젊은 영역이다. 성숙한 척 하거나, 별것 없는 것처럼 단순화 하기 보다는 그것의 다양성과 아직 신생이라는 것을 받아들여라. 너무 정의하고, 그대로 실행하고, 그것을 표준화 하려고만 하지 말자. 그런 표준은 소프트웨어 품질에 해만 끼칠 뿐, 개선할 수는 없다.

좋든 싫든 소프트웨어 테스터는 인증기관들을 계속 찾아볼 것이고, 회사들은 그들이 각자의 기준에 맞는 테스터를 고용할 것이다. Peter Shih는 찬반 양론을 아래와 같이 요약했다.

인증을 찬성하는 입장

인증은 용어나 프로세트 등, 이 분야의 기본적인 지식의 기본적인 것을 제공한다.
테스트 초보자가 테스트 영역에 발을 들여놓는 것을 돕는다.
기업이 인증된 테스터를 고용하는 것을 더 좋아할 것이라는 것은 확실하다.
인증시험에 합격하는 것은 테스팅을 진지하게 고려하고 있다는 신호이다.
자격증을 가지고 있음으로 당신은 수 많은 소프트웨어 테스터 무리와 차별화 시킬 수 있다.

인증을 반대하는 입장

인증위원회는 당신의 문제 해결 능력과 테스트 하는 방법으로가 아니라 그들이 가진 지식과 시험에 당신의 능력을 끼워 맞추는 것에 자격증을 주면서 엄청난 돈을 벌어들이고 있다.
그런 시험에 통과하는 것은 테스팅 기술의 그 어떤 것도 증명할 수 없고, 단순히 직업을 구하기 위한 수단으로 이용해서는 안 된다.
회사는 그들의 면접 프로세스에 대해 단순히 그냥 안일하게 생각하다 보니 인증된 테스터를 선호하는 것이다. 이력서에 있는 한 줄 들어가 있는 것이나 종이장만 생각하지 말고 지원자의 기술을 봐야 한다.
자격증을 취득했다는 것은 당신이 당신에게 주어진 일을 위해 시간과 돈을 쓰지 못할 이유가 없다라는 것을 보여줄 뿐이다.
인증된 테스터는 너무나 많다. 다른 사람이랑 구별되기 위해 무엇이 필요한가? 더 심화된 자격증? 한계가 있을까?

대학을 졸업하자 마자

나는 아직 소프트웨어 테스팅 정식 학위를 가진 사람을 만난 적이 없다. 그런 학위가 아마 없는 것 같다. 그렇지만 나는 Bing 검색 결과가 그런 것에 대해 불만을 제기할 생각을 없다. 요지는 나는 테스팅 업계의 많은 테스터들이 꼭 소프트웨어 테스팅에 대한 것이 아니더라도 대학학위를 가질 수 있도록 하고 있다는 것이다. 물론 이것은 Cem Kaner의 설명에서 보여지듯 아주 타당한 이유가 있다.

소프트웨어 테스팅 관점에서 대부분의 대학들은 테스팅에 직접적으로 초점을 둔 교육은 매우 적게 제공하고 있고, 대부분의 학교에서 가장 많이 가르치는 것은 제품의 품질에 대한 회의적인 측정 보다는 수학적 개념을 포함한 코드 검증을 조심스럽게 다룰 뿐이다. 이들 대부분은 일반적인 교육과 프로그래밍 기술에 고가의 투자를 한다. 그러나 심화된 테스팅(craft of Testing)에 있어서는 그렇지 못하다.

대학 학부의 교육과정의 목표는 미래에 특별한(특이한) 어떤 직업을 가질 사람들 훈련시키기 위한 것은 아니다. 그들이 몇 번이나 직업을 바꾸고 경력을 바꾸기도 할 10년 후를 준비하기 위한 것이다. 대학 학부 교육은 기술적인 스킬 보다는 ‘배우는 방법’을 가르치는 곳이고 그들의 전공 분야 외의 바깥 영역으로 진출 하고자 할 때 어느 방향으로 갈지를 한정 지어서는 안 된다. 이것은 “일반적인 교육”이냐 “학생의 선택에 따른, 현장에서 바로 쓰이는 기술에 초점을 맞춘 교육”이냐 라는 두 가지의 뭐라 말하기 힘든 문제를 가져온다.

그렇다면 어떤 종류의 학위가 그들이 미래에 테스팅 경력을 가지는데 도움이 될까? 명백히 그것은 전산이다. 그러나 위에 언급한 기준을 보면 대부분의 어떤 전공에서도 논란의 여지가 있다.

사실, 많은 회사들은 소프트웨어 테스터 역할에 IT학과가 아닌 졸업자들의 영입을 늘이고 있다. 이 신기술 종사자들의 더 넓은 배경지식이 더 유용하고 그 직종에 필요한 역량이 더 늘어나고 있다, 최종 사용자 관점에서 제품을 보는 능력까지 포함해서 말이다.

[Jeff Findlay, a senior solution architect at Micro Focus with an architecture degree]에 의하면 보통의 일반 교양 학위를 가지고 있는 것은 테스터가 테스트를 할 때 좀 더 넓은 사고방식에 따라 테스트 할 수 있도록 한다고 한다. 그런가 하면, 왜 이런 버그나 나타나게 되었는지 생각하고 이것을 해결하기 위한 가장 좋은 해결책은 무엇인지 고민하기 보다는 그저 전적으로 테스트 활동에만 초점을 둘 수도 있다.

…

Morces의 CEO인 Derek Ang는 모바일 앱과 같이 모든 사람에게 사용될 정도로 소프트웨어가 진화한 오늘날, “비IT 졸업생은 좋은 소프트웨어 테스터가 될 수 없다는 것은 말이 되지 않는다.” 그리고 Ang에 따르면 이상적인 소프트웨어 테스트 팀은 IT와 비 IT사람들이 함께 구성되어야 한다. IT사람들은 기술적인 측면을 테스트 하는 반면, 비IT사람들은 사람과 컴퓨터의 상호작용(HCI)나 흐름등과 같은 그 외의 부분을 테스트 한다.

테스터가 회사에 고용될 때, 대학의 학위보다는 교육(훈련)받은 것과 그들의 진입차선이 더 높은 우선순위를 갖게 된다. 물론, 그 외의 꼬집어 말할 수 없는 것들이 그들의 성공을 돕는다. Scott Barber은 테스터를 고용하는 것에 있어서 자신의 생각에 대해 이렇게 기술 한 바 있다.

나는 기술과 새로운 프로그래밍 언어를 어떻게 가르쳐야 하는지 알고 있고, 버그를 보고하는 방법이나 프로세스를 문서화 하는 방법 그리고 가지고 있는 정보를 어떻게 테스트 아이디어로 만들어 내야 하는지도 가르칠 수 있다. 하지만, 사람들에게 호기심을 갖게 만들거나, 그 호기심을 가지고 뭔가를 찾아내고자 하고 싶게 만들거나, 조사한 것이 좀 이상한 것 같다는 느낌이 드는 것을 가지고 흥분되도록 하는 것은 내가 가르칠 수 있는 것이 아니다.”

1000명의 임의의 테스터를 대상으로 현업의 경험 없이 대학을 졸업하고 바로 QA로 직업을 구한 경우가 얼마나 되는지를 설문조사 해 본다고 해보자. 내 생각에 그 수는 극히 일부에 불과할 듯 하다. 내가 틀린 수도 있긴 하다. 하지만, 대부분은 경우 테스팅 경력은 우리를 다음 지점으로 데려다 주는 그 어떤 다른 곳에서 시작한다.

다른 부서로부터

테스팅 업계에서 내가 아는 대부분의 우수한 사람들은 다른 분야의 많은 경험을 가진 사람이다. 테스팅에서 프로그래밍, writing(Document팀 등?)혹은 마케팅으로 옮겼다가 다시 돌아오는 것은 일반적인 일이고, 그것을 통해 테스터는 개발, 마케팅, 제품 지원에 잘 부합하는 보다 제품 중심적인 풍부한 관점을 가지게 된다.

일반적으로 다른 직종에서 테스팅 분야로 이직하는 것을 생각할 때 다른 직종은 프로그래머와 소프트웨어 엔지니어를 주로 생각한다. Brian Marick는 프로그래머로 성공하지 못하여 테스터로 지원하는 것이 가장 최악의 경우가 될 것이라고 이점을 꼬집었다.

“우수한 프로그래머는 아니지만, 우수한 테스터인 사람이 너무나 많다. 그러나 우수하지 못한 프로그래머는 테스터가 됨에 있어서도 똑같이 안 좋은 버릇을 갖게 마련이다. 예를 들면, 버그를 양산하는 사람은 세세한 부분을 부주의하게 다루기 때문에 같은 이유로 많은 버그를 놓치게 될 것이다.”

어쨌든, 테스터들은 조직내의 여러 다른 부서에서 올 수 있고, 또 그렇게 한다. 이것은 검증된 테스터를 찾기 위해 예전 방식(모집하여, 기존 테스터를 면접하여 뽑고하는)으로 고군분투하고 있는 회사에게는 좋은 소식이다. 이것은 현재 자신의 role이 마음에 들지 않아 경력을 변경하고자 하는 사람들에게는 더할 나위 없이 좋은 소식이다.

고난과 역경을 극복 (독학)

제임스 바흐는 이 접근법을 “해적^(2)역자주 학위”라고 부를는지도 모르겠다. 기본적으로 심화적인 테스팅을 배우기로 자청한 사람들은 그들만의 길을 개척해 낸다.

이 접근방법의 이점은 확실해야 한다는 것이다. 무엇을 위해 공부하는 것인지 불 분명한 시험도 없다. 참석하기엔 비싼 세미나도 없다. 단, 자신의 페이스와 처한 상황에 맞춰서 테스팅에 필요한 것과 테스팅으로 도출되는 것을 배울 수 있다. 그리고 그에 따라 보수를 받을 수도 있다. 만약 당신이 이 방법에 관심이 있다면 ‘uTest는 당신을 위한 곳이다.’

많은 회사들이 이 접근법에 대해 눈살을 찌푸리거나 진지하게 생각하지 않는다. 그리고 그런 회사들은 자기 혼자만 인정해 주는 것 말고 그 이상의 것을 요구한다. 주제에 좀 벗어난 얘기지만, 만약 그런 경우라면 당신은 그들과 별로 일하고 싶지 않을 것이다.

********

나는 테스터의 훈련과 경력개발을 중요한 문제로 다루고 싶다. 물론 내가 놓친 것이 많을 것이고 문제는 다시 원점이다.

당신을 위해 comment section을 열어 놓을 것이다. 특히 아래 내용에 대해 질문이나 당신의 생각을 듣고 싶다.

· 소프트웨어 테스터가 되려면 어떻게 해야 하는가?

· 당신이 테스터를 고용한다면 인증에서 당신은 무엇을 기대할 수 있는가?

· 마지막으로 테스터의 교육의 질을 개선하기 위해 당신이 할 수 있는 것은 무엇인가?

이 외에도 이 주제에 대한 다른 글들은 아래의 블로그 포스트 링크를 통해 볼 수 있다.

(1) 엄청 길게, 작가가 죽을때까지 완결을 하지 못하고 죽어버린 연재소설입니다. 시스콤으로도 제작되었죠. 시트콤이 먼저였고 그 인기로 소설이 나온것인지 반대인지 아리까리 하네요.

(2) 해적 : 여기서 해적은 바이킹과 같은 새롭고 험란한 길을 개척하는 ‘해적’의 의미. 현재 우리나라 언론에서 자주 쓰이는 것과 같이 ‘해적폰’과 같은 단어에서 뜻하는 ‘해적’의 의미가 아닌것 같죠?

'▶ 테스터의 눈' 카테고리의 다른 글

액션러닝과 테스팅 (0)	2013/02/27
피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06
리스크 기반 테스팅이 어려운 이유는... (0)	2012/10/31

Design for All? Quality for All!

Showstopper — Thu, 10 Jan 2013 13:00:10 +0900

매일같이 쏟아져 나오는 신제품들은 대부분 불특정 다수의 니즈를 파악하고 예상하여 만들어진 경우가 대부분이다. 그래서 시장 출시 후, 외면 받기도 하고 사랑 받기도 한다.

불특정 다수를 카테고리화 하면 상당히 다양한 유형의 구매자 및 사용자가 있음을 알게 되는데 과연 우리 테스터들은 이들의 관점에서 제품을 검증하는 일이 가능할까?

어떤 사용성 이슈를 제기하고 개발자가 그것에 동의하지 않을 때 우리는 '유저 관점에서 보면...'이라는 말을 하며 자신의 의견을 피력하게 된다. 이때의 '유저 관점에서 보면'이라는 말은 아마도 '여러 유형의 유저가 보편적으로 동의할 수 있는 수준에서 보면'이라는 말과 일맥상통하지 않을까, 감히 추측해본다.

그렇다면 여러 유형의 유저가 보편적으로 동의할 수 있는 수준은 무엇일까?

나는 얼마 전에 '유니버셜 디자인'이라는 개념을 이제서야 접하면서 그것에 대해 생각해보게 되었다. 유니버셜 디자인이라는 것은 'Universal design refers to broad-spectrum ideas meant to produce buildings, products and environments that are inherently accessible to both people without disabilities and people with disabilities.'이라고 위키백과에 소개되어 있다. 즉, 장애가 있든 없든 남녀노소 관계없이 모두가 제품(실제로는 환경, 서비스 등으로도 확장. 여기서는 제품에 한정.)을 사용하는데 편하고 무리가 없게끔 하는 디자인을 뜻한다.

유니버셜 디자인의 7대 원칙을 보면,

1. 공평한 사용 (equitable use)

2. 사용상의 융통성 (flexibility in use)

3. 간단하고 직관적인 사용 (simple and intuitive)

4. 정보 이용의 용이 (perceptive information)

5. 오류에 대한 포용력 (tolerance for error)

6. 적은 물리적 노력 (low physical effort)

7. 접근과 사용을 위한 충분한 공간 (size and space for approach and use)

위와 같은데 소프트웨어 제품군에도 당연히 일맥상통한다. (모두 위키백과에서 인용.)

물론 이러한 수준의 고민이 소프트웨어 분야에 없는 것은 아니다. UX에 대한 고민이 많아지며 훨씬 더 훌륭한 이론과 방법론들이 많이 나오고 있다. 또 유니버셜 디자인의 예로서 구글을 들기도 한다.

그렇다면 나는 왜 이 이야기를 하고 있을까? 뒷북치고자 하는 것이 아니라 앞서 이야기했듯이 보편적으로 수긍할 수준의 유니버셜 품질을 우리 테스터들이 어떤 관점을 지니면 될까, 하는 것을 고민하고 있는 것이다.

물론 여기에서 악의적인 유저는 배제되어 있다. 제품을 다른 용도로 사용하거나, 제품의 보안적 취약점을 공격해 부당한 이득을 얻으려는 경우에 대해서는 따로 생각해야 할 것이다.

앞으로 이 추상적인 개념에 대해 좀 더 구체화해보고자 한다.

그럼, 다음 포스팅까지 아래 유니버셜 디자인의 예들을 살펴보자.

제일 많이 회자되는 것이 맨 첫그림... 스칸디나비아 항공사 주전자. 근데 아래 그림은 아마 최초의 디자인은 아니고 많이 발전된?

손잡이 위치를 바퀴 무게 중심으로 옮겨 주전자를 기울일 때 팔에 무리가 안감. 그리고 손잡이 각도, 스프링이 장착된 가재들 모두 관절염 환자나 노약자들에게 최적화...

<출처 : http://www.design.co.kr/section/news_detail.html?info_id=46808&category=000000060003 및 구글 웹이미지 검색>

'▶ 테스터의 눈' 카테고리의 다른 글

피닉스 체크리스트와 테스팅 (1)	2013/02/26
고객경험지도와 테스팅 (2)	2013/02/26
파브르 버그기 #1 - iOS용 트위터 공식 앱과 플래너터리리소시스 웹페이지 (0)	2013/02/15
Tester Risk (0)	2013/02/13
[번역]Where do Testers come from? (3)	2013/01/15
Design for All? Quality for All! (2)	2013/01/10
어느 테스터의 육아일기 (1)	2012/12/10
완벽한 테스팅은 불가능하다고? (3)	2012/11/15
[번역] 소프트웨어 개발 게임(The Software Development Game) (0)	2012/11/06
리스크 기반 테스팅이 어려운 이유는... (0)	2012/10/31
트위터 한국 트렌드 서비스의 문제 (0)	2012/10/24

[번역] 소프트웨어 테스팅은 게임이다

검은왕자 — Tue, 08 Jan 2013 20:14:23 +0900

지난해 11월에 번역해 포스팅한 조나단 콜의 ‘The Software Development Game’에 이어, ‘Software Testing is a Game’을 번역해 올립니다.

게임과 게이미피케이션이라는 관점에서 소프트웨어 개발에 접근했던 전작과 마찬가지로, 이번에는 소프트웨어 테스팅이라는 영역을 어떻게 게임이라는 관점에서 파악하고 접근할 수 있는지는 보여주고 있습니다. 소프트웨어 테스팅에 대한 색다른 접근법이기도 하지만, 게임QA라면 또한 누구나 한 번쯤은 생각해 보았을만한 주제인지라 쉽게 공감하실 수 있으리라 생각됩니다.

번역 및 포스팅에 대해서는 저자의 승인을 받았습니다.

원글 출처: http://www.kohl.ca/2012/software-testing-is-a-game/

Software Testing is a Game

Jonathan Kohl

데이빗(David McFadzean)과 나는 “Better Software” 9/10월호에 “소프트웨어 개발 게임(The Software Development Game)”이라는 글을 발표했다. 우리는 이 글을 통해 어떻게 소프트웨어 개발 과정에 게임과 유사한 기법을 적용하는 지에 대해 설명했다. 이 일이 있고난 후, 소프트웨어 테스팅에 관련해서도 게임과 유사한 기법을 적용할 수 있는지에 대해 글을 써달라는 요청을 여러번 받게 되었다. 이 글을 통해 그 방법을 자세하게 알아보기로 하겠다.

자, 내가 생각하는 바는 이렇다.

어떻게 소프트웨어 테스팅이 게임과 같을 수 있을까? 소프트웨어 개발 자체를 게임과 같다고 간주하거나, 혹은 서로 다른 사람들이 서로 다른 동기와 목표를 가지고 협동하거나 경쟁하는 상황이라고 생각한다면, 소프트웨어 테스팅은 확장된 소프트웨어 개발 게임(SDG; Software Development Game)이라는 범주 안에 속하며 따라서 게임과 같다고 생각할 수 있을 것이다. SDG가 정책과 사례, 그리고 프로세스와 툴, 기술적인 면을 이상적으로 혼합하는 방법에 초점을 두고 있다면, 소프트웨어 테스팅은 게임이라는 큰 전제 하에서 크게 두 가지의 형태가 앞서거니 뒤서거니 하는 형태를 띄게 된다. 이 두 가지 서로 다른 게임 스타일은 바로 스크립트 테스팅과 탐색적 테스팅이다.

스크립트 테스팅 게임에서는 테스트 계획과 테스트 케이스 관리 시스템이 가장 많은 영향을 미친다. 우리는 이러한 관리 시스템을 통해 테스트 스크립트를 반복하고 그 결과를 패스 혹은 패일로 처리함으로써 보상을 받게된다. 또한 우리는 테스트 케이스 관리 시스템에 저장되어 있는 테스트의 커버리지를 통해 정량화될 수 있다. 테스트 케이스 관리 시스템에 미리 설정되어 있는 테스트 커버리지에 얼마나 가깝게 테스트를 수행했느냐는 모든 사람들에게 중요한 문제 중의 하나다. 이는 늘상 반복되는 일임과 동시에, 환경의 제약을 많이 받는 일중의 하나다. 테스트 케이스 관리 시스템 상에서 높은 커버리지를 달성해야 한다는 목표와 어긋나는 일들은 종종 무시되거나 아예 시도조차 되지 못하기도 한다. 이런 경우, 시스템 상의 수치가 가장 중요한 목표가 되어버리고 아무리 더 나은 테스팅이라고 하더라도 이 목표에 어긋나는 것이라면 무시당하기 일쑤가 되어버린다. “당신같은 테스터들은 얼마나 많이 시스템에 있는 테스트 케이스를 수행했는지, 그리고 그 결과에 따라 패스나 패일을 표시했는지에 따라 보상을 받게될 것이다. 그러니 이런 일을 다 한 다음에도 시간이 남으면, 그때에나 다음에 뭘할까 생각해봐라.”

탐색적 테스팅 게임에서는 테스터가 어느 정도 자기 일에 대한 결정 권한을 가진다. 사실 가장 최근의 정의는 오히려 이 부분을 강조하고 있다. “개인의 자유와 책임을 강조하는 소프트웨어 테스팅 스타일. 프로젝트 전체를 통해 테스트와 관련된 학습, 테스트 디자인, 테스트 실행 그리고 테스트 결과 분석을 상호 보완적으로 수행함으로써 작업의 품질을 지속적으로 향상시킬 수 있게 한다”라고 정의하고 있는 것이다.

탐색적 테스팅을 수행하는 게임 플레이어는 그들이 수행한 작업의 품질과 접근법, 그리고 그들이 제공하는 정보의 품질에 따라 보상을 받는다. 탐색적 테스팅은 스크립트 테스팅에 비해 유연하고 상대적이며, 질적인 정보를 중시하는 경향으로 인해 숫자[1]를 중요하게 보는 생각들은 때때로 폄하되고는 한다. 만약 테스터가 업무를 수행하는 도중에, 어떤 합리적인 이유로 일의 방향을 바꾸고 이것이 합당한 조치였다는 것을 논리적으로 입증할 수 있다면, 이러한 변경에 대해 충분한 보상을 받을 수 있을 것이다. 이러한 변경이 제품 자체에도 도움이 되고 자신이 보유한 테스트 기법을 향상시키는 데에도 도움이 되기 때문이다. 커버리지는 테스팅에서 무엇보다 중요한 요소 중의 하나이다. 테스터는 탐색적 테스팅을 사용함으로써 기존의 리그레션 테스트를 얼마나 많이 반복적으로 수행했느냐를 통해 커버리지를 측정하는 방법을 벗어나, 커버리지를 확보하는 다양한 기법을 사용해 볼 기회를 가지게 되며 때로는 중요한 기법들을 새로 발견할 수도 있다.

탐색적 테스팅을 생각할 때마다, 룰을 변경하는 것이 의미있는 턴으로 간주되는 게임인 노믹(Nomic)[2]을 떠올리곤 한다. 노믹처럼 여러 명이 무언가를 변경하는 대신 테스터들은 그들 스스로 그들의 코스를 자유롭게 변경시킬 수 있다. 이를 통해 탁월한 업무 성과를 창출함으로써, 팀 전체의 성과와 기법을 향상시키는데도 도움을 주어야 한다. “테스터들은 훌륭한 테스팅과 중요한 문제를 찾아내고 보고하는 스킬과 능력으로 보상을 받는다. 우리는 테스터들이 정보를 얻기 위해 한 번의 테스트를 수행하던, 혹은 수 천번의 테스트를 수행하든 상관하지 않는다. 당신들이 제공하는 정보로 인해 제품의 품질과 가치가 얼마나 향상될 수 있느냐가 의미있는 것이다”. 탐색적 테스터들은 팀 전체가 제품을 통해 어떤 가치를 창조할 수 있도록 그들이 처한 상황을 개선하고 필요한 정보를 제공해 주어야 한다. 또한 대부분의 경우 동료들로부터 지지와 존경을 얻어내는 것도 필수적이다.

자 이제 게임 플레이를 생각해보자. 스크립트 테스팅과 탐색적 테스팅은 모두 어느 정도 반복적인 작업을 포함하고 있다. ‘게이미피케이션’이라는 개념을 활용해 이러한 행위를 연구함으로써, 어떻게 게임이라는 컨셉을 적용해 우리가 수행하는 작업을 더 발전시킬 수 있는지에 대해 답을 얻을 수 있다. 우리가 연구해 볼 대상 중의 하나는 바로 비디오 게임이다. 우리가 MMORPG 게임을 플레이하고 있다고 가정해보자. 어떤 플레이어들은 개인의 퀘스트 혹은 파티가 공유하는 퀘스트와 상관없이 반복적인 작업을 수행하는 것을 좋아할 것이다. 그들의 캐릭터에 맞는 새로운 의상이나 액세서리를 얻기 위해 단순하고 반복적인 사냥을 좋아하는 플레이어들도 있다.

또 어떤 플레이어들은 퀘스트를 달성하는 것에 집중한다. 그들은 개인에게 주어진 미션을 달성해 포인트를 획득하는 것과, 특정 퀘스트를 완료해 보상을 얻고 이 과정에서 동료들과 협동하는 것을 배워 좀 더 많은 것을 달성하려고 한다. 어떤 플레이어 유형은 반복되는 개별 업무를 통해 보상을 받으려하고, 또 다른 사람들은 성과를 만들어내거나 혹은 스스로나 다른 사람들의 가치를 탐구하는 것에서 보상을 받으려 한다. 이 두 가지 타입이 혼재되면, 거의 모든 플레이어들이 그렇듯이 캐릭터의 외양을 변경하는 서브미션을 수행하면서 동시에 더 어려운 퀘스트를 수행하거나 다른 업적 달성을 위해 장비를 강화하고 골드를 모으는 것이다. 상대적으로 덜 도전적인 사람들과 캐릭터의 외양에 집착하는 사람들 모두 이러한 퀘스트에 참여할 수 있게 되는 것이다.

만약 당신이 이런 게임을 하면서 협력 플레이를 하려고 한다면, 당신과 다른 시각을 가지고 있는 사람들도 많다는 사실을 알게 될 것이다. 만약 팀 구성원이 팀 전체의 업무에 도움을 주는 것보다 그가 가진 캐릭터의 능력치를 올리는 것에만 관심을 보인다면 이는 실망스러운 일이 아닐 수 없다. 예를 들어, 만약 당신이 레이드에 참가하고 있을 때, 한 명 혹은 그 이상의 레이드 구성원들이 자신의 체력을 채우거나 떨어진 금화를 줍기 위해 계속 멈춘다면, 레이드의 속도가 느려질 뿐만 아니라 어떤 경우는 다시 레이드를 구성해야 하는 일도 생길 것이다. 게임에서 눈에 보이는 가치와 보상 구조가 조화롭지 않게 설계되었기 때문에 함께 레이드를 진행하기가 힘든 것이다. 개인적인 스탯과 장비에 집착하는 사람들이 있는 반면, 자신이 보유한 캐릭터의 속성과는 관계없이 동료들과 레이드 전체의 목적을 우선시 하는 사람들도 있는 것이다.

소프트웨어 테스팅 게임에서, 엄격하고 제한적이며 스크립트 기반의 게임을 하는 테스터들에게 보상을 주는 시스템에서라면 탐색적 테스팅 게임을 수행하기 힘들 것이다. 정반대로, 테스트 케이스 관리 시스템에서 요구하는 커버리지를 얼마나 달성했느냐로 보상을 받는데 익숙한 테스터들에게, 그들이 제공한 정보와 테스팅 스킬의 품질로 보상을 받게 한다면 거의 어떤 보상도 받지 못할 것이다. 테스팅에 대한 전통적인 개념과 일반적인 사례들은 테스팅을 단순히 테스트 케이스 관리 시스템이 중심이 되는 게임의 한 종류로 보는 경향이 있다. 이런 부류의 사람들이 깨닫지 못한 것은 테스팅이라는 게임을 플레이 하는 데에는 단 한 가지가 아닌 여러가지 다양한 방법이 존재한다는 것이다. 나는 게이밍이라는 렌즈를 통해 다른 방법들을 좀 더 자세하게 살펴보았으면 하는 바램이 있다.

테스터와 테스트 매니저들은 스크립트 테스팅과 테스트 케이스 관리 도구 외에도 더 많은 것들이 세상에 존재한다는 것을 알 필요가 있다. 스크립트 테스팅과 테스트 케이스 관리 도구는 모바일과 웹을 비롯한 새로운 분야가 성장하면서 야기된 새로운 기술과 방법론 앞에서 다시 전면에 나서려고 노력하는 고전적인 게임(최소한 1970년대부터 이어져온)의 일부일 뿐이다. 현대적인 테스터들은 우리를 둘러싼 세상에 걸맞는 게임을 플레이하려고 노력한다. 팀원들이 시대에 걸맞는 게임을 플레이하고 있는지, 아니면 지금까지 가장 익숙했던 게임을 플레이 하고 있는지를 관찰하고 그에 따른 보상을 주고 있는가? 비디오 게임의 주인공이 스탯을 높이고 액세서리를 모으는 것처럼, 당신은 다른 팀원들의 목표를 방해하면서까지 이에 집착하고 있는 것은 아닌가? 아니면 적합한 측정과 보상을 통해 전체 소프트웨어 개발 팀이 더 나은 제품을 만들 수 있도록 도와주고 있는가?

추후에 게이미피케이션과 게임 이론, 그리고 게임이라는 관점을 더 깊이 분석해서 소프트웨어 테스팅을 탐색할 것이다. 지켜봐주시길 바란다.

[1] 역자 주: Metrics. 앞서 말한 스크립트 기반 테스팅에서 중요시되는 얼마나 많은 테스트 케이스를 수행했는지, 얼마나 많은 테스트 케이스의 결과가 패스와 패일로 구분되었는지를 의미한다.

[2] http://en.wikipedia.org/wiki/Nomic

'▶ 테스팅을 말한다' 카테고리의 다른 글

[번역] 테스터를 위한 디버깅 (1)	2013/02/12
[번역] 소프트웨어 테스팅은 게임이다 (2)	2013/01/08
확률을 어떻게 테스트 할까? (10)	2013/01/06
고객인가 동료인가 - QA가 바라본 게임 개발사와 퍼블리셔의 관계 (1)	2012/11/20
끊이지 않는 버그 (0)	2012/08/05
[번역] 모델 기반 테스팅에 대해 알아야 할 것들 (7)	2012/03/27
[번역] 리그레션 다시 생각해보기 - 파트 5: 테스팅 미션을 결정하라 (0)	2012/03/26
[번역] 리그레션 다시 생각해보기 - 파트 4: 리그레션 테스팅에서 잘못된 점은 무엇인가? (0)	2012/03/26
[번역] 리그레션 다시 생각해보기 - 파트 3: 리스크 완화 전략 (0)	2012/03/05
[번역] 리그레션 다시 생각해보기 - 파트 2: 리그레션이란 무엇인가? (0)	2012/01/09
[번역] 리그레션 다시 생각해보기 - 파트 1: 힘들게 얻은 교훈 (0)	2012/01/09