KoonHous

What is the difference between QA QC ?  QA(Quality Assurance - 품질보증)과 QC(Quality Control - 품질관리)는 다른 정의를 갖고 있고, 두 용어는 산업분야 혹은 상황에 따라서 여러 가지 해석과 용도로 사용되고 있다. 품질은 여러 산업분야에서 제품의 내구성, 용도에 대한 적합성, 선호도에 대한 정의로 용어를 사용하기 시작했다. 이 용어는 아주 예전부터 사용했지만 품질에 관한 정의와 연구는 지금까지도 계속되고 있다.  QA의 정의 중 하나는 '품질 프로세스를 통해 제품이 요구 사항에 준수하고 품질에 대한 확신을 갖기 위한 모든 활동'이다. 그리고 QC의 정의 중 하나는 '품질 요구 사항을 충족시키기 위한 모든 가능한 기법과 활동'이다. 얼핏 보면 동일한 의미 같지만 지금부터 설명하는 걸 잘 보면 다른 의미를 갖는다는 것을 알 수 있다. 품질 관리란?  QA QC 차이를 알기 위해서는 먼저 QC 용어를 알아야 한다. QC라는 말은 1920년쯤 산업혁명과 함께 많은 제품이 쏟아져 나오면서 시작되었다.  산업 초기에는 제품의 수요는 많고 공급이 부족했지만 산업화가 급격하게 진행되면서 공급이 많아져 기업들 간에 경쟁이 생겼다. 그 시점에 기업이 제품의 품질에 대해서 고민하게 되고 QC라는 용어가 처음 시작되어 제품 품질을 관리하기 시작했다. 이때만 해도 QC는 단순히 제품이 생산되는 부품들을 검사하고 완제품을 검사하는 정도에 지나지 않았다.  QA 용어는 1950년쯤에 품질 분야에 품질 보증과 품질 사후 서비스를 독립적인 조직으로 운영하면서 사용하기 시작되었다. QA라는 용어는 제품에 대해서 불량이 없는지 보증한다는 개념에서 사용했고 또한 고객이 불편을 겪은 부분에 대해 처리하는 업무 즉 사후 관리 개념이었다.  1980년쯤부터 TQM(Total Quality Management - 전사적 품질 경영)라는 용어를 사용 했는데, 산업 분야

What is ISTQB? ISTQB 란 International Software Testing Qualification Board의 약자로 국제 소프트웨어 테스팅 자격 협회 라고 하는데, 2002년 11월 에든버러에서 공식 출범하여 벨기에에 등록한 비영리 단체이다. 2005년 초에 한국 지부인 KTB(Korean Testing Board)가 도입되었고, 그밖에 50여 개 나라에서 지역 멤버 위원회(Board)로 구성되어 자격시험 체계와 교육 인증과 같은 프로세스 규정을 하고 있다. QA자격증인 ISTQB는 소프트웨어의 품질을 보증하는 테스터들이 갖춰야 하는 지식과 기술을 다루는데, 시험 범위와 수준에 따라 Foundation, Advanced, Expert로 나뉜다. (출처:STEN)  소프트웨어 다양성과 활용도가 높아지면서 수요가 늘어나고, 테스팅의 중요성에 대한 인식이 점점 높아지고 있고 소프트웨어가 많아지고 의존도가 높아질수록 당연히 품질의 중요성도 높아지고 있다. 테스팅이 전문 인력이 주도하는 전문 공학 분야로 인식되면서 QA자격증을 취득한 소프트웨어 테스팅 전문 인력을 양성하고 테스트 체계를 구축하기 위한 기업의 투자가 늘고 있다.  ISTQB가입 국가(ISTQB 시험 진행 국가포함) 108개국 이상으로 2010년부터 지속적으로 ISTQB를 취득한 사람들이 증가하고 있는 상황이며, 2015년 12월 기준 ISTQB 총회 발표 자료에 따르면 자격증 취득자는 약 450,000명, 분기당 약 13,000명씩 취득하고 있다. 다양한 분야의 기업에서 지원자격요건 또는 우대사항에 QA자격증을 보유한 지원자를 선호하고 있다. 게임, PC, 애플리케이션, 모바일 단말기, 임베디드 등 세부적인 분야로 언급하자면 더욱 다양하며 범위가 넓다. ISTQB 자격증을 취득을 위해서는? ISTQB Foundation 자격증 이미지(개인정보 모자이크)  필자가 ISTQB Foundation이라는 자격증을 알게 된 때는 2009년에 단말 검증 부서에서

TMMI Test Environment phase 아래는 TMMi에서 테스트 환경 단계의 프로세스를 수립하기 위한 가이드라인이다. Test Environment 테스트 환경의 목적은 적절한 환경을 설정하고 유지한다, 테스트 데이터를 포함한 그것은 관리와 반복적인 방법으로 테스트를 실행할 수 있다. 프로세스 영역과 테스트 환경의 요구 사항을 지정하고 구현하며 테스트 환경을 제어 하는 모든 범위를 해결합니다. 테스트 환경설정의 관리 및 제어 부분의 측면을 포함한 형상관리를 이용이 가능하다. 테스트 환경 프로세스 영역 범위는 물리적 테스트 환경 및 모든 테스트 데이터를 포함한다. 1 테스트 환경의 요구 사항을 개발 이해관계자 요구의 기대와 제한적으로 수집한 테스트 환경 요구 사항으로 번역된다. 1.1 테스트 환경 요구 사항을 도출한다 이해관계자의 요구의 기대와 제약 수집 및 테스트 환경 요구 사항으로부터 의미된다. 1.1.1 주요 산출물 • 테스트 환경의 필요사항 1.1.2 세부사항 1.1.2.1 테스트 환경 의미에 대한 테스트 방법 및 테스트 계획을 연구 1.1.2.2 일반적인 테스트 데이터, 기대와 제약 조건을 포함하여 테스트 환경 요구 사항의 도출을 위한 담당자를, 테스트 참여 테스트 환경 요구 사항의 예 : - 네트워크 구성 요소 - 소프트웨어 구성 요소, 예를 들어, 운영 체제, 펌웨어 - 가상, 스텁 및 드라이버 - 증빙 서류, 예를 들어, 사용자 안내서, 기술 안내서 및 설치 설명서 - 인터페이스 구성 요소 또는 제품 - 도구 스텁과 드라이버를 개발 - 테스트 장비 - 복합 테스트 환경을 위한 요구 사항 - 일반 테스트 데이터베이스 - 테스트 데이터 생성기 - 테스트 데이터 스토리지 요구 - 테스트 데이터 보관 및 복원 시설 1.1.2.3 테스트 환경 요구 사항을 문서, 일반적인 테스트 데이터, 기대와 제약 조건을 포함 1.2 테스트 환경 요구 사항을 개발 테스트 환경 요구 사

TMMI Test Monitoring and Control 아래는 TMMi에서 테스트 모니터링 및 제어 단계의 프로세스를 수립하기 위한 가이드 라인이다. 1 테스트 계획에 대한 감시 테스팅의 성과와 실제 과정을 테스트 계획에 맞춰 모니터링 한다. 1.1 테스트 계획 매개변수를 모니터 테스트 계획에 대한 테스트 계획 매개 변수의 실제 값을 모니터링 한다 1.1.1 주요 산출물 • 테스트 성과 기록 • 계획과 중요한 차이 기록 1.1.2 세부 실행 1.1.2.1 테스트 일정에 대한 테스트 진행 상황을 모니터링 한다. • 주기적으로 테스트 작업의 실제 완료시점을 측정, 제품 테스트 및 테스트 이정표 • 테스트 계획에서 설명하는 테스트 일정에 대한 테스트 작업과 제품 테스트 및 테스트 이정표의 실제 완료를 비교 • 테스트 일정에서 상당한 편차를 확인하는 테스트 계획을 예상 1.1.2.2 테스트 비용과 소비된 테스트 활동을 모니터링 한다. • 주기적으로 실제 테스트 비용과 소비된 인력을 측정 • 테스트 계획에서 설명된 예상과 실제 테스트 비용, 인력을 비교 • 테스트 계획 테스트 비용, 인력에서 큰 편차를 확인 1.1.2.3 테스트 산출물 및 테스트 작업의 속성을 모니터링 한다. • 주기적으로 테스트 작업 제품과 테스트 작업의 크기나 복잡성과 같은 실제 특성을 측정 • 테스트 계획에서 설명된 예상과 테스트 작업 제품 과 테스트 작업의 실제 특성을 비교 • 테스트 계획에 대한 견적에서 큰 편차를 확인 1.1.2.4 테스트 인력의 지식과 스킬을 모니터링 한다. • 주기적으로 테스트 직원이 획득한 지식과 기술을 측정 • 실제 교육으로 얻은 것과 테스트 계획에서 설명하는 것을 비교 • 테스트 계획의 예상에서 큰 편차를 확인 1.1.2.5 테스트 계획 매개 변수에서 중요한 차이를 문서화 1.2 제공/사용되는 테스트 환경 자원들을 모니터링 한다 제공/사용 되는 테스트 환경 자원들을 계획에 비교해 모니터링 한다. 1.

TMMI Test Design and Execution 아래는 TMMi에서 테스트 설계 및 실행 단계의 프로세스를 수립하기 위한 가이드라인이다. 1 테스트 분석 수행 및 테스트 설계 기법 도출 테스트 분석과 설계 중, 테스트 설계 기법을 사용하면서, 테스트 접근법이 분명히 실재하는 테스트 상태와 테스트 케이스로 옮겨진다. 1.1 테스트 상태를 식별하고 우선순위를 정한다 테스트 베이시스에 명시된 테스트 아이템의 분석을 기반으로 한 테스트 설계 기법을 사용하여 테스트 상태를 식별하고 우선순위를 정한다. 1.1.1 주요 산출물 • 테스트 베이시스(Basis) 이슈 로그 • 테스트 조건 (Conditions) • 테스트 설계 명세서 1.1.2 세부 실행 1.1.2.1 테스트 basis(요구 사항, 디자인과 인터페이스 명세서)를 연구하고 분석한다. 1.1.2.2 문서작성자와 테스트 베이시스에 관련된 이슈를 논의한다. 1.1.2.3 문서화된 테스트 접근법과 함께 가장 적절한 테스트 설계 기법을 선택한다. [Black Box] - 동등 분할(Equivalence rtitioning) - 경계 값 분석 (Boundary Value Analysis) - 결정 테이블 (Decision Tables (Cause/Effect Graphing) - 상태 전이 테스팅 (State Transition Testing) [White Box] - 구문 테스트 - 결정 테스트 - 상태 테스트 1.1.2.4 테스트 설계 기법을 사용한 테스트 베이시스로부터 테스트 조건을 얻어낸다. 1.1.2.5 식별된 제품 리스크를 기반으로 한 테스트 조건의 우선순위를 결정한다. 1.1.2.6 테스트 설계 명세서 표준을 기반으로 한 테스트 설계 명세서에 테스트 상태를 문서화한다. - 테스트 설계 명세서의 우선순위 - 테스트하려는 항목/특징 - 접근법 개선 - 테스트 조건 - Pass/Fail 조건 1.1.2.7 이해관계자와 테스트 설계 명세서를 리뷰한

  QA 가 전문적인 분야로 인식되어 가면서 QA 전문가와 테스터 에 대한 개념과 업무에 대한 이론이 더욱 자리 잡아가고 있다. 단순히 테스트만 하는 테스터와 QA 전문가를 분류하는 기준은 명확하게 말할 수 있다. "QA가 무엇인가?" 이 물음에 답할 수 있느냐이다. 소프트웨어 테스트라는 업무를 진행하면서 단순히 테스트만 진행했다면 대답하기 어려울 것이다. 단순히 테스트만 한 테스터가 있다면 아래의 테스팅 노하우를 읽어보는 것을 권하고 싶다. 그리고 한번쯤은 왜라는 의문점을 스스로 가져보길 바란다. 이 포스트를 주의 깊게 읽어보면 테스트 활동을 실천하고 적용해 볼 수 있다. 이후에 경험을 통해 모든 사례를 배울 수 있고 실패하는 사례도 경험의 과정이고 배움이라는 것을 인지해야 한다. 경험을 통해 배운 20가지 최선의 소프트웨어 테스트 업무 노하우 1) 소프트웨어 요구 사항과 설계 단계에서 테스트팀의 권한을 확보해야 한다.  이 방법으로 테스트팀이 애플리케이션 의존도에 대해 아는 것이 상세한 테스트 커버리지를 달성 시킬 수 있다. 만약 테스트팀이 개발 수명 주기에서 이런 부분을 요청받지 못했다면 관리자나 담당자에게 모든 프로세스 결정이나 관련 회의에 대해 테스트팀을 포함시켜 달라고 요청해야 한다. 2) 사용자 요구 사항 문서에 대한 이의 제기를 생략한다.  사용자가 어플에 필요하지 않거나 요구하지 않으려고 했던 것을 명시하지는 않는다. 3) 테스트 결과를 철저히 분석해서 인지한다.  테스트 결과만 보고 지나치면 안 된다. 마지막 테스트 결과는 ‘Pass’ 이거나 ‘Fail’일수 있다. ‘Fail’의 근본적인 원인을 해결하려는 것이 문제의 해결책으로 당신을 안내할 것이다. 테스터가 단순히 결함을 보고하는 것이 아닌 해결책을 제시한다면 인정받을 것이다. 4) 테스트 대상이 되는 소프트웨어의 테스트 범위를 항상 최대로 잡아서 노하우를 터득한다.   100% 테스트 범위를 충족하는 것은 불가능하지만 항상 근접하게 시도할

How to find issues when software testing?  버그(Bug)를 찾는 것과 이슈 관리는 소프트웨어 테스트에서 매우 중요한 부분이다. 테스터나 QA 엔지니어라면 업무를 진행하는 매 순간마다 소프트웨어에서 이슈를 어떻게 찾을지 생각해야 하고 반드시 찾아야만 한다. 테스터들은 시스템 충돌 같은 심각한 이슈를 발견한 것에 대해 보람을 느끼기도 한다. 그 부분도 중요하지만 우리는 가장 찾아 내기 어렵고 복잡한 이슈를 찾아 내려는 노력을 해야 한다. 일반적으로 시장에서 사용자에게 어려움을 주는 것은 그런 이슈들이다.  한가지 경험을 예로 들면, 로그파일을 처리하거나 데이터베이스를 업데이트하기 위해 특정 시간과 상황에서 자동화 스크립트를 수행하는 툴이 있었는데, 전체 데이터가 동기화 되도록 로그 파일과 데이터베이스를 구동하는 역할을 했다. 두 개의 툴이 얼마의 시간 간격을 두고 하나의 테이블에서 구동이 되었지만, 몇몇 데이터의 불일치가 일어나면서 다른 툴에 의해 테이블에 중복된 칼럼이 생겼다. 방대한 데이터 베이스 프로세스들과 각각 다른 툴들 때문에 그 문제를 해결하기 위해 많은 시간을 소요해야 했다.  이 경험을 이야기하는 요점은 어떤 특정한 조건이나 상황에서 발생하거나 시스템에 심각한 영향을 일으키는 숨겨진 버그를 찾기 위해 노력해야 한다는 것이다. 그리고 이렇게 발견된 버그들은 체계적인 이슈 관리 시스템에 의해 처리되어야 하고 지속적으로 모니터링해야 한다. 프로젝트의 승패가 좌우된다고 해도 과언이 아닐 정도로 중요한 부분임을 인지해야 한다.  아래는 위에서 언급한 이슈 관리 경험들을 통해 배운 노하우이다. 1) 소프트웨어 테스트를 진행하기 전에 전체적인 애플리케이션 또는 모듈에 대한 상세히 이해해야 한다. 요구 사항, 사양 설명서 등 테스트 활동에 필요한 문서를 분석하고 개발자나 관련 이해관계자들과의 소통을 통해 정확하게 이해해야 한다. 2) 테스트 진행에 앞서 좋은 테스트 케이스를 준비한다. 프로젝트의 속성

Software automation tool Top10  우리는 모든곳에 자동화기기가 있는 시대에 살고 있다. 즉, 업무를 쉽고 효율적으로 끝낼수 있는 어플리케이션이 공존하는 시대에 접어 들었다. 우리는 다양한 툴의 도움으로 우리의 업무를 줄인다고 생각한다. 어플리케이션을 줄이려는 노력의 순환은 아래 산업을 빠르게 마무리 지을 것이다. • 어플리케이션 개발 • 소프트웨어 테스팅 • VOIPs • 인력관리 자동화 • 병원 • 철도   자동화의 늘어나는 수요는 우리 소프트웨어 테스팅 산업의 경향이다. 소프트웨어나 어플리케이션 테스팅 커뮤니티(uTest, Quora 등)를 찾아 보면 데스크탑 테스팅, 웹 테스팅, 브라우저 테스팅, 회기 테스팅, 웹 서비스 그리고 API 테스트 등 테스트 활동에 유용한 다양한 툴을 촉구하는 소프트웨어 테스터들을 찾을 수 있다. 이 중 최근 가장 선호되고 있는 소프트웨어 테스팅 자동화 툴 을 간단하게 소개한다. 소프트웨어 테스팅 자동화 툴 Top 10 1. Selenium  셀레니움은 윈도우, Mac, 리눅스와 같은 플렛폼이나 다양한 브라우저의 웹어플리케이션 테스팅을 수행하는 테스팅 프레임워크이다. 셀레니움은 테스터가 Java, PHP, C#, Python, Groovy, Ruby, Perl과 같은 다양한 프로그래밍 언어에서 테스트 작성을 돕는다. 셀레니움은 셀레니움 IDE를 배우지 않아도 테스트를 작성하기 위해 녹화와 재생 기능을 제공한다. 유명한 브라우저 공급자들이 브라우저에 셀레니움을 탑재하여 릴리즈하도록 공급하고 있다. 일반적으로 셀레니움은 대부분의 다른 소프트웨어 테스팅 툴의 확실한 기반된다. Learn more about Selenium 2. TestingWhiz  테스팅 위즈는CMMi Level3 IT 솔루션 공급업체인 Cygnet Infotech의해 개발된 코드없이 스크립팅하는 테스트 자동화 툴이다. 테스팅위즈 기업용 버전은 웹 테스팅, 소프트웨어 테스팅, 데이터베이스 테스팅,

테스트 케이스 개선 방법  소프트웨어 개발 분야에서 유능한 소프트웨어 개발자는 코딩의 효율과 품질을 개선하는 코딩 단계 전에 기능 요구 사항을 기반으로 항상 유닛 테스트 케이스를 작성한다. 이와 같이 소프트웨어 테스터는 소프트웨어 개발 수명주기(Software life Cycle)의 초기 단계에 테스트 케이스를 작성해야 하는데 소프트웨어 요구 사항 취합 단계에 작성하는 것을 권장한다. 테스트 매니저 또는 품질보증 매니저는 아래 목록에 따라 가능한 문서를 준비하고 취합해야 한다. 1 테스트 케이스 작성을 위한 문서 취합 1.1 사용자 요구 사항 (User Requirements)  유저 요구 사항 문서는 비즈니스 절차, 사용자 프로파일, 사용자 환경, 다른 시스템과 호환성, 존재하는 시스템과의 교체 및 대체성, 기능 요구 사항, 비기능 요구 사항, 성능 요구 사항, 요구 사항의 권한 제약, 보안 요구 사항, 사용성 등을 말한다. 1.2 비즈니스 사용 사례 (Business Use Case)  비즈니스 사용 사례 문서는 소프트웨어 적용 업무 관점에서 기능 요구 사항의 사용 사례 시나리오를 자세히 기술한 문서를 말한다. 이 문서는 요구 사항의 범위 내에서 적용 업무 관점의 사용자 동작이나 시스템 동작, 목표, 사전 조건, 사후 조건, 기본 동작 흐름, 대체 동작 흐름, 선택 사항, 시스템적인 업무 흐름에 대한 모든 예외사항을 포함한다. 1.3 기능 요구 사항 (Functional Requirements)  요구 사항 범위 내에서 시스템의 각각의 특징에 대한 기능 요구 사항을 자세히 기술한 문서를 말한다. 일반적으로, 기능 요구 사항 문서는 개발팀이나 테스트팀에게 공통 백과사전과도 같은 정보로, 고객을 포함한 프로젝트 의사결정자에게는 공식적인 요구 사항으로 어떤 소프트웨어 개발사항보다 가장 중요한 정보를 제공한다. 1.4 소프트웨어 프로젝트 계획서 (선택사항)  소프트웨어 프로젝트 계획 문서는 프로젝트, 목적, 우선순위, 주요 단

TMMI Test Policy and Strategy 아래는 TMMi에서 테스트 정책과 전략 단계의 프로세스를 구축하기 위한 가이드 라인이다. 1. 테스트 정책을 설립하라 비즈니스 정책(품질)에 관련된 테스트 정책이 설립되고, 이해관계자의 동의를 받아야 한다. 1.1. 테스트 목적 정의하라 비즈니스 요구와 목적 기반으로 테스트 목표를 정의하고, 준수하라 1.1.1 주요 산출물 • 테스트 목표 1.1.2 세부 실행 1.1.2.1 비즈니스 요구와 목적을 연구한다 • 강령(사훈) • 제품에 관련된 비즈니스와 사용자 요구 • 비즈니스 추진 요인 • 품질 프로그램의 주요 목표 • 비즈니스(품질) 정책 • 사업의 형태, 개발되는 제품의 위험 등급 1.1.2.2 명확한 비즈니스 요구사항을 위한 Feedback과 필수적인 목적을 제공하라 1.1.2.3 비즈니스의 요구와 목적을 추적할 수 있는 테스트 목표를 정의하라 • ‘fit-for-use(쓰기 알맞음)’에 대해 제품을 입증하라 • 동작 중 발생하는 결함을 막아라 • 외부 표준에 준수함을 입증하라 • 제품 품질에 관련된 가시성을 제공하라 • 테스트 실행 소요 시간을 단축하라 1.1.2.4 이해관계자와 테스트 목표를 리뷰하라 1.1.2.5 테스트 목적을 적당한 때(예:매년) 다시 논의하고, 개정하라 1.2. 테스트 정책을 정의하라 테스트 목적을 기반으로 테스트 정책이 정의되고, 이해관계자에게 동의를 받아야 한다. 1.2.1 주요 산출물 • 테스트 정책 1.2.2 세부 실행 1.2.2.1 정의된 테스트 목적을 기반으로 테스트 정책을 정의하라 • 테스팅의 정의 • 디버깅의 정의 (오류 위치와 수리) • 테스팅 진행자와 테스팅에 대한 기본적인 관점 • 테스팅의 목표와 추가된 가치 • 달성되기 위한 품질 등급 • 테스트 조직 독립성의 정도 • 상위 등급 테스트 프로세스 정의 • 테스팅에 주요 책무 • 조직의 접근법과 테스트 프로세스 개선의 목표 1.3

TMMI Test Planning  아래는 TMMi에서 테스트 계획 단계의 프로세스를 구축하기 위한 가이드 라인이다. 1 제품 리스크 평가를 수행하라  테스팅을 위해 치명적인 영역을 식별하기 위해 제품 리스크 평가를 수행한다. 1.1 제품 리스크 카테고리와 매개변수를 정의하라.  제품 리스크 평가하는 동안 사용될 제품 리스크 카테고리와 매개변수가 정의되어야 한다. 1.1.1 주요 산출물 • 제품 리스크 카테고리 리스트 • 제품 리스크 평가와 우선순위 기준 1.1.2세부 실행 1.1.2.1 제품 리스크 카테고리를 확정한다.  제품 리스크 카테고리를 식별하는 이유는 테스트 계획의 테스트 타입별 테스트 업무에 유망한 통합을 돕기 위함이다. 1.1.2.2 제품 리스크 가능성과 영향력 등급을 평가하고, 입증하기 위한 일관된 기준을 정의한다. 1.1.2.3 각각 제품 리스크 등급을 위한 한계점을 정의한다. 1.2 제품 리스크를 식별하라  제품 리스크는 식별되고 문서화된다. 1.2.1 주요 산출물 • 식별된 제품 리스크 1.2.2 세부 실행 1.2.2.1 리스크 평가에 기여할 필요가 있는 이해관계자를 식별하고 확인한다. 1.2.2.2 요구 사항 문서와 이해관계자로부터 입력되어 사용된 제품 리스크를 식별한다. • 위험 작업장 • 브레인스토밍 • 전문가의 인터뷰 • 체크리스트 • 교육 이수 1.2.2.3 리스크의 배경과 잠재적 중요도를 문서화한다. 1.2.2.4 각 리스크에 연관된 이해관계자를 식별한다. 1.2.2.5 테스트 임무에 맞게 식별된 제품 리스크를 리뷰한다. 1.3 제품 리스크를 분석한다  사전 정의된 제품 리스크 카테고리와 매개변수를 사용하여, 제품 리스크가 평가되고, 배열되고, 우선순위가 정해진다. 1.3.1 주요 산출물 • 각각 리스크에 할당된 카테고리와 우선순위가 입력된 제품 리스크 목록 1.3.2 세부 실행 1.3.2.1 사전 정의된 매개변수, 발생 가능성. 미치는 영향 정도를 사용하여

How to create the test case for the software? 1 소프트웨어 테스트 케이스란?  소프트웨어 테스트 케이스는 테스트 대상에 오류가 있는지, 사용자 요구 사항과 같이 동작하는지 확인하는 순차적인 절차를 테스터에게 가이드 한다. 소프트웨어 테스트 케이스를 어떻게 작성하는지 배우는 것은 기본적인 작성 기술과 테스트 대상(Application Under Test - AUT)에 대해 충분한 이해력이 요구된다. 2 효과적인 테스트 케이스 전달  설명이 잘되고 가독성이 좋은 테스트 케이스가 테스터에게 전달되어 수행되어야 한다. 테스트 케이스 작성을 할때 사용자의 관점에서 모든 필수 세부사항을 포함하는 것이 중요하다. 선행 절차에서 좋은 테스트 케이스를 위한 많은 노력을 하는 것은 차후에 시간과 노력을 절약한다. 특히 많은 테스트 케이스를 한꺼번에 작성하는 것이 많은 시간이 소요되는 데, 이 포스트는 높은 수준의 테스트케이스를 쉽게 작성하고 정리하는 방법을 알려줄 것이다. 해당 포스트 끝부분에 샘플 테스트 케이스와 함께 어떻게 테스트 케이스를 작성하는지 약간의 노하우 설명한다. 3 소프트웨어 테스트 케이스 어떻게 작성하나? • 핵심적인 제목을 사용하라  테스트 케이스 작성방법 중 가장 중요한 부분은 핵심적인 제목으로 선정하는 것이다. 좋은 사례로는, 테스트하는 모듈 테스트 케이스 이름을 기입한다. 예를 들어 만약 Login Page를 테스트하고 있다면 테스트 케이스 제목에 "Login Page"를 포함시킨다. • 핵심적인 설명을 포함해라  설명은 테스터가 무엇을 테스트해야 하는지와 다른 관련된 정보를 말해줘야 한다. 테스트 환경, 테스트 데이터 그리고 사전 조건 등과 같은 정보가 포함되어야 한다. • 사전 조건을 포함해라  테스트가 진행되기 전에 충족되어야 하는 테스트와 사전 조건에 적용되는 어떤 상황들을 포함해야 한다. 이 정보는 사용자가 어떤 상황에서 테스트를 시작하는지, 테스트 환경에 의존되는

TMMI Overview and Definition TMMI(Test Matrity Model Integration)란 세계적인 테스팅 전문가들이 다양한 산업분야의 소프트웨어 테스트 베스트 프랙티스를 근간으로 만든 테스트 프로세스 진단 및 심사모델로, 소프트웨어 테스트 프로세스 등급 척도 모델로 소프트웨어 테스트 조직이 갖추고 있는 성숙도를 평가하고 프로세스를 개선하기 위한 모델이다. 과거 수십 동안, 소프트웨어 산업은 소프트웨어 상품들의 품질을 개선하기 위한 상당한 노력을 기울여왔다. 이것은 어려운 과제로 남아있다. 고객과 사용자의 요구가 더욱 많아지면서 소프트웨어의 규모와 복잡성이 급격하게 증가했고, 이것은 어려운 과제로 남아있다. 다양한 품질 개선 접근법의 고무적인 결과에도 불구하고, 소프트 산업에 무결점은 아직 멀다. 제품품질을 개선하기 위해, 소프트웨어 산업은 종종 소프트웨어 개발 프로세스에 관점을 둬왔다. 개발 프로세스를 개선하기 위해 광범위하게 쓰인 가이드라인은 CMM(Capabilty Maturity Model)이다. CMM과 CMMI(Capability Maturity Model Intergration)은 종종 소프트웨어 프로세스 개선을 위한 산업표준으로 여겨진다. 테스팅이 전체 비용의 적어도 30~40%를 차지하는 점에도 불구하고, CMM, CMMI와 같은 다양한 소프트웨어 프로세스 모델이 갖춰진 테스팅은 많은 주목을 받지 못했다. 그 해답으로 테스트 전문가들은 TMMI라는 개선 모델을 만들었으며, TMMI의 테스트 프로세스 개선을 위한 모델은 CMMi와 상호 보완적으로 배치하게 한다. 현재 TMMI 외에 TPI, TIM과 같은 테스트 프로세스 모델이 있으며, 이러한 테스트 프로세스 모델은 CMMI, SPICE와 같은 범용적인 프로세스 모델이 제공하지 못한 상세화된 테스트 지침을 제시하여 조직의 테스트 프로세스를 체계적으로 구축하기 위해 적용되고 있다. 그러나 이러한 개선 활동이 항상 효과가 있는 것은 아니다. 예를 들어 CMM