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

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

개인적으로 팬인 원사운드 님이 이번 KGC2009를 주제로 그린 TIG 웹툰에 소프트웨어 테스트와 관련된 내용이 나와 소개하고자 한다. 웹툰의 내용 중에 버그에 대한 개발자의 6 가지 반응이 나온다. 자, 그 다음 직접 웹툰을 보고 오자. (http://www.thisisgame.com/board/view.php?id=302087&category=106&subcategory=2) 개발자의 6가지 반응 중, 그래서는 안된다고 생각하는 “1~5번을 고르신 분들은 훌륭한 개발자입니다” ...라는 이토 마코토의 대사만 보고 ‘이거뭐병!!!’이라는 생각을 했다가 이어지는 내용들을 보고 나서는 “음…”이라고 할 수 있었다. 테스터가 버그를 보고할 때에도, 그 중요도(Severity)와 우선순위(Priority)에 ..