메인 프로덕트
테스트 계획
시나리오 작성 및 테스트 수행
테스트 결과에 따른 릴리즈 노트 작성 및 공유
오류 및 개선 의견 등록
제품 교육, 매뉴얼 작성 및 배포 등
프로젝트
범위: 메인 프로덕트 + 커스터마이징
보증 범위: 기능 변경에 따른 기본 흐름 및 추가 요구사항에 대한 품질 보증 테스트
고객 요구시: 프로젝트 프로세스 품질 보증 활동 수행( 예: CMMI 등)
STEN의 QA Role에 대한 견해 중 몇가지를 옮겨본다.
정용태님
... 중략 ....저희 회사의 채용시 사용하는 role은 아래와 같습니다.
=============================================================
QA
- Develop Test Plan and Strategy
- Develop Test Cases / Procedure and other specification
- Cause analysis / Priority,Ugency,Severity analysis
- Configuration Management
- Release Maintenance
- Maintain Test Metrics
- SRS / UC / Mapped UC review
- Build Management
- Process audit
- Bug tracking tool
Test
- Test Automation
- Build Test Environment
- Execute Black Box, White Box, Ad hoc Testing
- Regression/ confirmation Testing
- Review
- Test data Management
David 님
=====================================================
QA & QE 라는 Part 가 또 나눠지게 되는데요..
QA 는 사용자의 관점에서 중점적으로 Test 진행이 되고요
QE 는 개발자와의 상호협력적 중심으로 일이 진행이 됩니다.
QA 와 다르게 QE는 엔지니어적인 면이 강합니다. 그래서 일부
모호한 감성적인 버그 및 에러 같은 경우는 대체로 잘 다루지 않습니다.
반면에 QA에서는 이런 감성적인 부분까지도 Issue로 다루게 됩니다.
이는, 엔지니어적인 측면이기 보단 사용자의 관점을 좀더 치우쳐 있기 때문이죠
QA 는 그렇기때문에 아무래도 개발자들과의 의견다툼이나
이견이 많겠지요. ^^
QC : 과학적 원리를 응용하여 제품품질의 유지·향상을 기하기 위한 관리
넓은 뜻으로는 가장 시장성이 높은 제품을 가장 경제적으로 생산하기 위한 일련의 체계적 조치를 가리키나, 일반적으로는 앞의 좁은 뜻의 해석이 통용된다.
초기의 QC는 전제품에 대해 치수·중량·체적이나 재료의 화학적 성분 등을 측정하고, 그것을 미리 정해 놓은 품질표준과 비교하여 적부를 판정하는 방법이 취해졌다. 이 경우 그 측정은 과학성이 낮으며 또 전품검사(全品檢査)이기 때문에 비용에서도 부담이 컸다. 이 같은 결점을 극복하고자 1920년대에 벨전화연구소의 W.A.슈하트 등이 통계학을 큐시(QC)에 응용하였다. 이로써 근대적 QC로서 통계적 품질관리의 성립을 보게 되었는데, 그것이 SQC(statistical quality control)이다.
현재의 품질관리는 품질수준의 유지·향상을 도모하는 SQC만으로는 불충분하므로, 넓은 뜻의 개념으로서 앞에 밝힌 바와 같은 활동까지도 QC 속에 포함시켜야 한다는 주장이 있어, 그 경우를 SQC에 비교해 종합적 품질관리 또는 TQC(total quality control)라고 한다. QC는 품질표준의 설정, 품질의 검사 및 보정(補整)으로 구성된다.
품질표준의 설정에서 기본적으로 중요한 것은 첫째, 품질의 최종판정자는 소비자이므로 품질표준에 소비자의 동향을 투영하는 일이다. 제품이 소비자의 요구를 만족시키기에 족한 성능을 지니고 있는지의 여부에서 본 품질가치와 그것을 달성하는 데 소요되는 비용, 즉 품질비용(불량품비용·평가비용·예방비용)의 면에서 볼 때 균형이 잡힌 것인가, 아닌가 하는 것이 문제이다.
둘째, 검사에는 전품검사와 발취검사(拔取檢査)가 있는데 SQC에서는 관리도를 사용하는 발취검사에 의존한다. 관리도란, 품질에 관한 측정치를 시계열적(時系列的)으로 상한과 하한의 관리한계선으로 나타낸 것으로, 한계 안에 있으면 품질은 정상이다. 보정활동은 품질보고를 바탕으로 하여 불량원인을 찾아내고 이에 대하여 발견과 시정조치를 취하는 것을 말한다.
또한 QC에서는 소정의 품질수준을 유지하여 신뢰받는 제품을 생산하기 위해서는 어느 단계에, 즉 하자를 예방하고 계획하는 단계에 역점을 둘 것인가, 또는 공정검사의 단계에 중점을 둘 것인가, 아니면 애프터서비스의 단계에 주력할 것인가 등을 경험적으로 인식하는 것도 중요하다.
QA
테스팅의 목적
- SW 개발 과정 중 실수와 오류를 범할 가능성은 매우 높다.
- 테스팅은 개발자, 사용자 모두 자신의 불완전함과 실수를 [가정] 하는데서 출발한다.
- 테스트는 인간의 불완전성을 극복하고 높은 품질의 제품을 만들기 위한 노력이다.
- 모든 가능한 데이터를 사용하여 모든 경우의 수에 대한 철저한 시험은 일반적으로 가능하지 않다.
- 결국 선택된 데이터를 기초로 시험이 이루어지며 높은 확률로 버그를 찾아낼 수 있도록 좋은 테스트 케이스를 만들어야 한다.
- SW 시험의 목적은 "품질향상을 위해 결함을 발견하는 것" 이다.
주요 이유
- 잔존 결함 발견
- 명세 충족 확인
- 사용자 및 비즈니스 요구 충족 확인
- 비즈니스 리스크 감소위한 Well-informed 조언 제공
- (발견된 결함 기반의 수치적 데이터 제공)
기타 이유
- 개발 시스템 / SW 에 대한 자신감 부여
- 개발 프로세스 점검, 이슈제기
- 논리적 설계의 구현 검증(Validate)
- 시스템 / SW가 적절히 동작함을 확인
주의 사항
- 완벽한 테스트는 불가능하다
- 테스트는 오류가 없음을 보여주는 것이 아니다.
- 주어진 시간과 인력 및 리소스로 오류 발견 확율이 높은 테스트 케이스를 찾아 실행해야 한다.
- 한계를 인정해야 한다.
모든 입력값을 테스트 할 수 없음, 모든 경로(Path)를 테스트 할 수 없음, 모든 타이밍을 테스트 할 수 없음. )
테스팅이란?
- 테스트 계획
- 통제
- 테스트 조건의 선택
- 테스트 케이스 디자인
- 결과의 원인확인과 완료특성(criteria) 평가
- 테스트 프로세스와 테스트 시스템에 대한 보고
- 최종 승인(테스트 phase가 완수된 후의) 종료작업
- 문서 리뷰(소스코드 포함)
- 정적 분석
목적
- 결함발견
- 품질 수준에 대한 확신을 얻고 정보를 제공하는 것
- 결함의 예방
유형별 목적
- 개발테스팅(Development Testing)
컴포넌트 테스팅, 통합 테스팅, 시스템 테스팅의 주된 목적은 실패의 원인이 될 수 있는 결함을 가능한한 많이 확인하고 고치는 것.
- 승인테스트(Acceptance Test)
시스템이 예상되는대로 작동하는 것을 테스트하고 시스템이 요구사항을 만족한다는 확신을 얻는 것.
- 유지보수 테스팅(Maintenance Testing)
변경에 기인한 새로운 에러들이 없음을 알려주는 테스트를 포함함.
- 운영 테스팅(Operational Testing)
신뢰성(reliaability) , 가용성(availability) 과 같은 시스템 특성 평가
- SW 품질 평가 테스트
결함을 고치려는 의도가 아닌 품질 평가가 목적이 되기도 한다.
이해 당사자는 품질 평가 결과로 계획된 시간에 시스템 릴리즈 되는 것이 위험하다는 것을 알 수 있다.
디버깅(Debugging) & 테스팅(Testing)
테스팅은 결함(Defect)에 의한 실패(Failures)를 보여줄 수 있다.
디버깅은 결점의 원인 확인 > 코드 수정 > 바르게 고쳐졌는가를 확인하는 [개발 활동]이다.
테스터에 의한 확정 테스팅(Confirmation Testing) 은 실패가 실제로 고쳐졌음을 보증한다.
각각의 활동에 대한 책임은 매우 다르다. 예를 들어,
테스터는 테스트에 대한 책임이 있고, 개발자는 디버깅에 대한 책임이 있다.
테스팅 필요성?
1.1.1 SW 시스템 환경
SW 이상 동작은 비용, 시간, 기업이미지(사업 평판) 을 포함한 문제를 야기하거나
상해, 사망 원인이 될 수도 있다.
인간은 문서, 시스템, SW, 코드 내에 결함을 생성하는 실수를 할 수 있다.
1.1.2 SW 결함 원인
[결함(Defects)]
인간이 오류에 빠지기 쉽고, 시간의 압박, 복잡한 코드, 하부 구조의 복잡성, 기술의 변경
그리고 또는 많은 시스템들의 상호 작용에 의해 생긴다.
[실패(Failures)]
환경적 조건이 원인이 될 수 있다.
발열, 자기장, 전기장, 오염은 펌웨어의 결점 원인이 될 수 있으며 H/W 조건 변경은 S/W 동작엥 영향을 줄 수 있다.
1.1.2 SW 개발, 유지, 운영에 있어 테스팅의 역할
결함들이 운영을 위해 릴리즈 되기전에 고쳐진다면, 시스템과 문서에 대한 엄격한 테스팅은 운영환경 내에서
발생하는 위험을 줄이는데 도움을 줄 수 있으며 SW품질에도 도움을 줌.
1.1.4 테스팅과 품질
SW 기능적, 비기능적 요구사항과 특성(Software Product Quality'(ISO 9126))들을 만족시키는 것에 대한
SW 품질 측정하는 것. 적절하게 설계된 테스트를 통과하는 것은 Risk 를 낮추고 품질을 높여준다.
[테스팅이란...?]
시스템에서 결함을 찾는것
결함 발견 및 버그 수정(때때로 예방까지)
테스트는 실제 수행하는 하나하나의 실체이다.
주로 결함 발견(Defect Dectection - QC) 메커니즘을 의미하지만, 결함 예방(Defect Prevention - QA) 과 조화를 이뤄야 함.
Test Case를 만들어 실행하는 것 뿐 아니라 테스팅 전략 수립과 계획, 설계, 결함 수정과 도구의 사용 등 포괄적인 의미이다.
IEEE 정의
SW테스트는 수동, 자동으로 시스템을 시험 작동 시키고 평가하는 작업으로
명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과와의 차이를 인식하기 위한 목적을 가진다
