The life is REAL

렉스 블랙이 쓴 책에서 동등분할(혹은 등가분할)에 관한 부분을 읽으면서 느낀 몇 가지를 적어보면 다음과 같다. 이 양반이 글은 좀 어렵게 쓰는 경향이 있지만 그래도 경력이 경력인지라 생각할 거리를 꽤 많이 던져준다. 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가 해야할 일이 별로 없다면 얼마나 행복한 상황인가. 하지만 역시 현실은 시궁창. 늘 그렇듯이 크리티컬한 이슈는 하루가 멀다하고 터지고 심지어는 가장 기본적인 컴포넌트에서조차 빵구가 나기 시작한다. 덕분에 마무리 작업은 순조롭지 못하다. 빌드가 매일매일 릴리즈되고 테스트도 거의 매일 수행된다. 그저께도 밤늦게까지 테스트를 수행했지만 결과는 그리 신통하지 못했다. 나쁜 일이 만성이 되는 것처럼 무서운 일이 있을까. 아무렇지도 않게 시험 실패 보고서를 날리고 피곤한 몸을 이끌고 자정이 다되어서야 집으로 들어갔다. 다음날 아침, 출근해보니 몇몇 핵심 개발자들이 이미 출근해 있었다. 보고서를 날리기 전에 크리티컬 이슈가 터질 때마..

10월 28일 헤센(Hessian) 2차 CBT가 시작되었다. 3인칭 밀리터리 슈팅 게임인 헤센은 이프(IF)라는 신생 개발사를 단숨에 게임 업계의 떠오르는 이단아로 만들어 준 게임이라고 할 수 있겠다. 소리 소문 없이 나타난 신생 게임 개발사가 언리얼 3 엔진을 기반으로 새로운 TPS를 개발한다는 기사를 읽을 때만 해도 “에효, 그 흔한 엔진에 또 고만고만한 게임 하나 나오겠구나…”라고 생각했었는데, 직접 플레이 해 본 소감은… “어, 이거 봐라?”... 라고나 할까? 근 미래인 2016년을 배경으로 민간군사조직(PMC)이 주인공으로 등장한다. 게임을 조금이라도 하는 사람이라면 당연히 TPS의 원조이며 대표작이라고 여기고 있는 게임이 있다. 그 이름도 거룩한 “기어즈 오브 워(Gears of war)”..

최근 소프트웨어 테스팅 업계에서는 단연 자동화(Automation)가 핫이슈다. 몇년 전 미국의 휴대폰 관련 테스팅 업체에서 일하고 있는 지인에게서 현지의 자동화 테스팅이 어느 정도 수준인지 들을 기회가 있었다. 그분이 재직하고 있는 회사는 휴대폰 임베디드 소프트웨어를 만드는데, 테스트 팀에서 사용자 시나리오를 간편하게 스크립트로 작성하면 이를 직접 하드웨어를 통해 구현해주는, 즉 휴대폰의 키패드를 시나리오에 따라 하나하나 누를 수 있는 로봇(!)을 활용해 수 천 번 동일한 사용자 시나리오를 반복하는 테스트를 수행한다고 얘기했었다. 소프트웨어의 사용성 뿐만 아니라, 소프트웨어가 구현되어 있는 하드웨어의 내구성과 신뢰성을 같이 테스트하게 되는 것이다. 당시에도 물론이거니와, 지금도 과연 우리나라에서 이 정..