본문 바로가기

분류 전체보기

 (130)
동등분할(등가분할)기법에 대한 몇 가지 단상 렉스 블랙이 쓴 책에서 동등분할(혹은 등가분할)에 관한 부분을 읽으면서 느낀 몇 가지를 적어보면 다음과 같다. 이 양반이 글은 좀 어렵게 쓰는 경향이 있지만 그래도 경력이 경력인지라 생각할 거리를 꽤 많이 던져준다. 1. 명세 기반 테스트는 요구사항에 기반하고 있다(Specification-based tests are requirement-based). : 명세 기반 기법, 그리고 블랙박스 기법 중의 대표적인 기법이 동등분할이다 보니 그 얘기하면서 다시 리뉴얼해주는 부분임. 명세는 요구사항을 반영하고 있어야 한다. 당연한 이야기. 2. 등가분할을 통해 나누어진 각 클래스 간에는 교집합 영역이 없어야 한다. : 등가분할은 동일한 메타 태그 아래 동일한 성격을 가지는 데이터(무엇에 관한 것이라도 상관없다)로..
리스크 기반 테스팅에 대한 몇 가지 단상 1. 사용성 측정을 어떻게 할 것인가? o 메트릭을 정해놓고 1부터 5까지의 점수를 줘서 평균내는 방법 o QA나 개발자가 평가하는 것은 의미가 없다 o UX(User eXperience) 팀과 같은 전문가가 있어야 한다(특히 게임과 같은 Customer Target 도메인에서) 2. 테스트 계획 단계에서 리스크 분석이 수행되고 그 결과는 프로젝트의 이해당사자들에게 공유 및 승인되어야 한다. 3. 잔존 리스크(Residual Risk): 테스트 종료 시점에서 아직 해결되지 않은 버그들 역시 잔존 리스크로 봐야한다. -> These should be reported through test result report! 4. Severity Integrity Level(안전 무결성 수준) 5. 위험에 대한 추적..
개발자에 대처하는 우리의 자세 CBT가 코앞으로 다가오면서 바빠지고 있다. 중요한 마일스톤을 넘어갈 때마다, QA가 해야할 일이 별로 없다면 얼마나 행복한 상황인가. 하지만 역시 현실은 시궁창. 늘 그렇듯이 크리티컬한 이슈는 하루가 멀다하고 터지고 심지어는 가장 기본적인 컴포넌트에서조차 빵구가 나기 시작한다. 덕분에 마무리 작업은 순조롭지 못하다. 빌드가 매일매일 릴리즈되고 테스트도 거의 매일 수행된다. 그저께도 밤늦게까지 테스트를 수행했지만 결과는 그리 신통하지 못했다. 나쁜 일이 만성이 되는 것처럼 무서운 일이 있을까. 아무렇지도 않게 시험 실패 보고서를 날리고 피곤한 몸을 이끌고 자정이 다되어서야 집으로 들어갔다. 다음날 아침, 출근해보니 몇몇 핵심 개발자들이 이미 출근해 있었다. 보고서를 날리기 전에 크리티컬 이슈가 터질 때마..
헤센 2차 CBT 찔끔 리뷰 - F키 하나로도 충분히 신선하다! 10월 28일 헤센(Hessian) 2차 CBT가 시작되었다. 3인칭 밀리터리 슈팅 게임인 헤센은 이프(IF)라는 신생 개발사를 단숨에 게임 업계의 떠오르는 이단아로 만들어 준 게임이라고 할 수 있겠다. 소리 소문 없이 나타난 신생 게임 개발사가 언리얼 3 엔진을 기반으로 새로운 TPS를 개발한다는 기사를 읽을 때만 해도 “에효, 그 흔한 엔진에 또 고만고만한 게임 하나 나오겠구나…”라고 생각했었는데, 직접 플레이 해 본 소감은… “어, 이거 봐라?”... 라고나 할까? 근 미래인 2016년을 배경으로 민간군사조직(PMC)이 주인공으로 등장한다. 게임을 조금이라도 하는 사람이라면 당연히 TPS의 원조이며 대표작이라고 여기고 있는 게임이 있다. 그 이름도 거룩한 “기어즈 오브 워(Gears of war)”..
오토 마우스 - 게임 테스팅 자동화의 대안이 될 것인가 최근 소프트웨어 테스팅 업계에서는 단연 자동화(Automation)가 핫이슈다. 몇년 전 미국의 휴대폰 관련 테스팅 업체에서 일하고 있는 지인에게서 현지의 자동화 테스팅이 어느 정도 수준인지 들을 기회가 있었다. 그분이 재직하고 있는 회사는 휴대폰 임베디드 소프트웨어를 만드는데, 테스트 팀에서 사용자 시나리오를 간편하게 스크립트로 작성하면 이를 직접 하드웨어를 통해 구현해주는, 즉 휴대폰의 키패드를 시나리오에 따라 하나하나 누를 수 있는 로봇(!)을 활용해 수 천 번 동일한 사용자 시나리오를 반복하는 테스트를 수행한다고 얘기했었다. 소프트웨어의 사용성 뿐만 아니라, 소프트웨어가 구현되어 있는 하드웨어의 내구성과 신뢰성을 같이 테스트하게 되는 것이다. 당시에도 물론이거니와, 지금도 과연 우리나라에서 이 정..
[TIG 카툰]KGC2009 - 버그의 비중에 따른 개발자의 반응 개인적으로 팬인 원사운드 님이 이번 KGC2009를 주제로 그린 TIG 웹툰에 소프트웨어 테스트와 관련된 내용이 나와 소개하고자 한다. 웹툰의 내용 중에 버그에 대한 개발자의 6 가지 반응이 나온다. 자, 그 다음 직접 웹툰을 보고 오자. (http://www.thisisgame.com/board/view.php?id=302087&category=106&subcategory=2) 개발자의 6가지 반응 중, 그래서는 안된다고 생각하는 “1~5번을 고르신 분들은 훌륭한 개발자입니다” ...라는 이토 마코토의 대사만 보고 ‘이거뭐병!!!’이라는 생각을 했다가 이어지는 내용들을 보고 나서는 “음…”이라고 할 수 있었다. 테스터가 버그를 보고할 때에도, 그 중요도(Severity)와 우선순위(Priority)에 ..
탐색적 테스팅에 관한 짧은 고찰 - Exploratory Testing Explained 요즘 QA를 하는 사람치고 탐색적 테스팅(Exploratory Testing)이라는 말을 처음 들어본 사람은 없을 것이다. 그만큼 소프트웨어 테스트 업계에서 쉽게 찾아볼 수 있는 범용적인 테스트 프로세스로 자리잡았으며, 아울러 최신의 트렌드인 애자일(Agile) 프로세스와의 궁합으로 인해 더더욱 이를 선호하는 사람들이 늘어나고 있다. 해외에서는 제임스 바흐(James Bach)가 탐색적 테스팅을 주창하면서 테스트 업계에 이를 전도하고 주창하는 역할을 맡아오고 있다. 제임스 바흐는 지난해 10월 STEN에서 초대해 국내에서도 세미나를 가진 적이 있었다. 그 만큼 국내에서도 탐색적 테스팅에 관한 지적 혹은 실무적인 요구가 충분하다 할 것이다. 그러나 높은 비용을 지불하고 이런 세미나에 참석할 만한 여유가 있..
드래곤 네스트 2차 CBT 찔끔 리뷰 10월 1일 2009년 하반기 기대작 빅3 중 하나로 꼽히는 "드래곤 네스트"의 2차 CBT가 종료되었다. 지난 1차 CBT에도 테스터로 신청을 했으나 아쉽게도 당첨되지 못했고, 이번에는 개인적인 친분을 십분 활용해 테스트 계정을 획득했다. 따라서 1차에 비해 얼마나 많은 발전과 변화가 있었는지는 비교할 근거가 없었다. 그러나 비록 1차 CBT의 경험이 없더라도, "드래곤 네스트"는 첫 인상부터가 무척 호감을 가질 만 하다. SD 캐릭터로 표현되는 월드임에도 불구하고 이전의 SD 장르, 혹은 다른 MMORPG 게임들에 비하더라도 깊은 색감과 디테일한 그래픽 요소들을 제공함으로써 시각적인 측면에서는 확실히 다른 게임들과 차별화될 만 했다. 거기에 최신의 트렌드를 따라가는 오소독소한 게임 내 컨텐츠들과 여기..

티스토리툴바