티스토리 뷰
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. 위험에 대한 추적성(Tracebilty for risk)
6. 프로젝트 리스크와 요구사항 자체의 결함(일반적으로 명확하게 제시되지 않으므로...)
7. 항상 모든 항목의 매핑이 중요!!!
'QA' 카테고리의 다른 글
만약 당신이 새로 부임한 QA 매니저라면 (0) | 2010.01.08 |
---|---|
동등분할(등가분할)기법에 대한 몇 가지 단상 (2) | 2009.12.07 |
개발자에 대처하는 우리의 자세 (0) | 2009.11.13 |
오토 마우스 - 게임 테스팅 자동화의 대안이 될 것인가 (0) | 2009.10.21 |
[TIG 카툰]KGC2009 - 버그의 비중에 따른 개발자의 반응 (2) | 2009.10.17 |
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- BasketBall
- How Google Tests Software
- 구글 테스트
- 구글
- 게임QA
- 리그레션 테스트
- 테스팅
- 테스트
- 게임 테스팅
- Test
- Game Testing All in one
- 테스터
- 바이오웨어
- Software Testing
- Regression Testing
- 농구
- Game Testing
- basketball diary
- 누가바닷컴
- 구글 테스팅 블로그
- testing
- 구글 테스팅
- Bug
- 제임스 휘태커
- 리스크 기반 테스팅
- Iain McCowatt
- 버그
- QA
- 소프트웨어 테스트
- software tester
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
글 보관함