https://m.blog.naver.com/PostView.nhn?blogId=muchine98&logNo=220262491992&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

'QA > Theory' 카테고리의 다른 글

Canary Release  (0) 2018.12.12
version naming  (0) 2016.08.23
Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29

Component Versioning

version

  • Major Version : 
    • 하위 호환성 없음 (인터페이스 변경, 삭제되는 경우)
  • Minor Version : 
    • 하위 호환성 보장함 (인터페이스는 변화 없음. 내부 로직이 변경된 경우)
  • Patch Version : Bug Fix
    • 내부 로직 오류 수정해야 하는 경우
  • SNAPSHOT : 항상 변경될 수 있는 floating version
    • 개발용
  • RELEASE : 더 이상 변경이 일어나지 않는 version 
    • 외부 배포용 - SNAPSHOT 제거

Product Versioning

  • Major Version : 
    • Major Change (UX changes, file format changes, etc.)
  • Minor Version : 
    • Minor Change (Minor features, major bug fixes, etc.)
  • Patch Version : Bug Fix
    • Minor bugs, spelling mistakes, etc.

참고

Qualifier

  • Alpha: not feature complete
  • Beta: contains critical bugs
  • RC: release candidate, not fully tested
  • RELEASE or Final: final version, release 버젼
  • SNAPSHOT : 그냥 라이브 버젼. Floating version, not an actual identification. Should allways be used for code under development.


'QA > Theory' 카테고리의 다른 글

Canary Release  (0) 2018.12.12
version naming  (0) 2016.08.23
Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29

Introduction

Code coverage analysis is the process of:

Finding areas of a program not exercised by a set of test cases,
Creating additional test cases to increase coverage, and
Determining a quantitative measure of code coverage, which is an indirect measure of quality.
An optional aspect of code coverage analysis is:

Identifying redundant test cases that do not increase coverage.
A code coverage analyzer automates this process.

You use coverage analysis to assure quality of your set of tests, not the quality of the actual product. You do not generally use a coverage analyzer when running your set of tests through your release candidate. Coverage analysis requires access to test program source code and often requires recompiling it with a special command.

This paper discusses the details you should consider when planning to add coverage analysis to your test plan. Coverage analysis has certain strengths and weaknesses. You must choose from a range of measurement methods. You should establish a minimum percentage of coverage, to determine when to stop analyzing coverage. Coverage analysis is one of many testing techniques; you should not rely on it alone.

Code coverage analysis is sometimes called test coverage analysis. The two terms are synonymous. The academic world more often uses the term "test coverage" while practitioners more often use "code coverage". Likewise, a coverage analyzer is sometimes called a coverage monitor. I prefer the practitioner terms.

'QA > Theory' 카테고리의 다른 글

Canary Release  (0) 2018.12.12
version naming  (0) 2016.08.23
Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29

탐색적 테스팅 접근법(Exploratory testing approach)

  • 테스트케이스 작성의 시간을 최소화하면서 테스트 엔지니어의 발견적인(Heuristic) 지적 능력을 최대한 활용하여 테스트를 수행하는 것
  • 테스트 설계, 테스트 수행, 테스트 계획, 테스트 기록 및 학습을 동시에 진행하는 휴리스틱한(Heuristic, 발견적인) 테스팅 접근법
  • 테스트 케이스를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서, 익숙해지는 것과 동시에 테스트를 설계하고 테스트를 계획한다.
  • 60~120분 동안에 몰입하여 수행할 수 있는 정도의 테스트 목적을 담고 있는 테스트 차터(Test Charter)를 기반으로 “제한된 시간(Time-Boxing)” 내에 테스팅의 “목적”을 정한 후, “몰입”하여 최소한의 설명 가능한 기록(Note)를 남기면서 테스트를 수행하고, 수행 후 “요약보고(Debriefing)”하는 것을 강조한다.
  • 테스트 케이스 기반의 공식적인 테스팅과 반대되는 개념의 “테스팅 접근법”
  • 최소한의 문서화를 통해 테스트를 실행하면서 분석/설계하고 계획을 세우는 것으 공식적인 테스팅 방법론보다 더 효율적이고 결함을 발견할 확률이 높아질 수 있다고 보는 테스팅 접근법
  • 공식적 테스팅이 문서화된 테스트 케이스를 기반으로 수행하는 것임에 반해, 탐색적 테스팅은 테스트 케이스를 문서화하는데 소요되는 시간을 최소화하여 테스트를 ”실행”하는 것에 집중한다.
  • 여러 테스팅 기법과 방법론을 훈련된 테스트 엔지니어가 많은 생각과 지적인 활동을 통해 창조적으로 테스팅하는 것을 강조
  • 탐색적 테스팅이 포함하는 내용
    • 제품 탐색(Product Exploration)
    • 테스트 설계(Test Design)
    • 테스트 실행(Test Execution)
    • 휴리스틱스(Heuristics)
    • 검토 가능한 결과물(Reviewable Results)
  • 탐색적 테스팅의 테스트 절차
    • 제품의 목적 식별(Identify the purpose of the product)
    • 기능 식별(Identify functions)
    • 잠재적으로 불안정한 부분 식별(Identify areas of potential instability)
    • 각각의 기능 테스트 및 문제점 기록(Test each function and record problem)
    • 일관성 검증 테스트 설계 및 기록(Design and record a consistency verification test)

탐색적 테스팅의 구성요소

  • 테스트 차터(Charter)와 시간 제한(Time Box)
    • 테스트 차터 : 무엇이 어떻게 테스트되어야 하고, 무슨 문제를 살펴야 하는지를 제안하는 내용
    • 테스트 차터를 정할 때에는 먼저 수행될 각 세션당 시간을 정해 놓는다.(Time box)
    • 테스터는 정해진 시간 내에 테스트 차터를 수행해야 하며, 몰입하여 테스트하는 것을 원칙으로 한다.
    • 테스터가 정해진 시간 안에 수행해야 할 것
      1. 정확한 리포팅(Accurate reporting)
      2. 유연성 있는 일정관리(Flexible scheduling)
      3. 테스트 방향 정정(Course correction)
      4. 견고한 테스팅(Solid testing done)
      5. 효율적인 요약 보고(Efficient debriefings)
    • 테스트 차터를 효율적/효과적으로 만들기 위해서는 제품 리스크 기반하여 만들어야 한다. 즉 리스크 분석 결과 제품의 리스크가 높은 기능에는 테스트 차터가 많이 생성하고, 리스크 낮은 기능에는 적게 생성하여 테스트를 수행하는 것이다.

예제) Test charters are used in ________ testing ( A )

a)      Exploratory testing

b)     Usability testing

c)      Component testing

d)     Maintainability testing

  • 테스트 노트(Test note)와 요약 보고(Debriefing)
    • 테스트 엔지니어는 테스트 실행과 동시에 머리 속에 계획, 설계하고 테스트 케이스를 작성하며, 이러한 사고활동을 간단하게 노트에 기록한다.
    • 작성한 테스트 노트는 테스트 케이스의 역할을 대처함과 동시에, 검토 가능한 결과물로써 활용된다.
    • 탐색적 테스팅의 한 세션이 종료된 후에는 팀원끼리 요약보고(Debriefing)하는 시간을 갖는다. 요약 보고 중에는 테스트 중 발견했던 결함과 이슈사항에 대해 보고하고, 어떤 식으로 테스트를 수행했는지에 관한 경험을 팀원 모두가 공유한다. 이러한 토론 과정을 통해 경험이 적은 테스터는 경험이 많고 뛰어난 테스터의 지도와 조언으로 스스로를 훈련시킬 수 있다.
    • 테스트 노트에 포함되어야 할 내용
      1. 테스트한 제품에 대한 노트 및 기록
      2. 발견된 결함과 장애에 대한 노트 및 기록
      3. 어떻게 테스트되었는지를 기술하는 요약된 문서
  • 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교
    • 테스트 케이스 기반 테스팅과 탐색적 테스팅의 가장 큰 차이점은 테스트 기반 테스팅은 모든 테스트 케이스의 작성을 마친 후 그것을 절차적으로 실행하지만, 탐색적 테스팅은 테스트 대상을 알게 되면서 동시에 테스트를 설계하고 실행하는 것이다.
    • 두 가지의 테스팅 방식이 발견하는 결함의 종류도 서로 다르다. 테스트 케이스 작성이 완료된 상태에서 테스트를 실행하게 되면 테스터 주체에 상관없이 같은 결함을 발견하지만, 탐색적으로 테스트할 경우 테스터의 성향(파괴적 테스터, 스크립트적 테스터, 사용성 테스터, 남/여 등)에 따라 서로 다른 결과를 산출하게 된다.
    • 탐색적 테스팅은 “자유로운 방식”에서 시작하여 스크립트 정도와 탐색적 정도에 따라 테스트 케이스 기반 방식으로 확장할 수 있다.

테스트 케이스 기반 테스팅

탐색적 테스팅

테스트가 먼저 설계되고 기록된다. 나중에 (때에 따라 다른 테스터가 이를 수행한다.)

테스트 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다.

[비유]준비된 연설과 같다. 테스트는 미리 착안된 생각에 따라 수행된다.

대화를 하는 것과 같다. 테스트는 아이디어를 반영하고, 생각을 발전시키는 방향으로 수행된다.

테스트의 실행을 관리하는 것이다.

(Controlling test execution.)

테스트 설계를 계속 향상 시키는 것이다.

(Improving test design.)

테스트 실행을 시작하기 전에 테스트 케이스를 작성한다.

프로젝트 기간 내내 테스트 계획/설계와 실행을 반복한다.

테스트 문서 작성, 검토에 많은 에너지를 소비함으로써, 생성될 테스트의 전체 수를 줄이는 경향이 있다.

테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복잡한 테스트에 상대적으로 많은 노력 투자가 가능하다.

테스트 간의 (특성, 능력) 차이를 제거하려는 능력

테스트 간의 (특성, 능력) 차이를 십분 활용하려는 노력

테스터가 아닐 수 있는 테스트 설계자가 테스트를 설계한다.

테스트 설계자일 수 있는 테스터가 테스트를 설계한다.

완벽하게 한번에 테스팅을 수행한다.

점진적이고 주기적으로 테스팅을 수행한다.

    • 리스크가 가장 높은 곳에는 테스팅 경험이 가장 많고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행해야 하고, 반대로 리스크가 가장 낮은 곳에는 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행해야 한다.
  • 성공적인 탐색적 테스팅의 효과
    • 경험적으로 테스팅을 하는 것을 체계화 시킬 수 있다.
    • 테스트 케이스를 작성하는 시간을 줄여 보다 많은 테스트를 실행할 수 있다.
    • 테스터 또는 테스트 엔지니어의 역량을 월등히 향상시킬 수 있다.
    • 적은 테스트 인력으로 많은 테스트를 수행할 수 있다.
    • 명세가 거의 없고 시간이 부족한 경우 테스트를 효과적/효율적으로 수행할 수 있다.

'QA > Theory' 카테고리의 다른 글

version naming  (0) 2016.08.23
Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29

 

Selenium

도구 명Selenium 
구매 여부
    • 오픈 소스 (Apache License 2.0)
도구 설명(특징)
    • 웹 어플리케이션 테스트 프레임워크
적용 장점
    • 다양한 프로그래밍 언어 지원 (Python, Ruby, .Net, Perl, Java, PHP)
    • 현재 사용되고 있는 대부분의 Browser에서 실행 가능 (IE, FireFox, Opera, Safari, Chrome)

    • 다양한 운영 체제에서 동작 가능 (Windows, Linux, Macintosh)

    • 웹페이지 객체에 대해 다양한 접근 가능 (Id, Name, Identifier, XPath, Dom, CSS, Link 등)

    • Flash, SilverLight, Ajax 지원 가능 (추가 설치 필요)

    • 다양한 테스트 프레임워크와 연동 가능 (Bromine, JUnit, NUnit, TestNG, FitNesse)

    • 언어를 자바로 선택했을 경우, 이클립스 사용 가능하고 이클립스 플러그인 사용가능

    • JUnit과 결합할 경우 개발자 Unit 테스트와 유사한 형태 (CI서버, Clover 등 연동 가능)

적용 범위
    • 서비스에 대한 브라우저 호환성 체크, 서비스 테스트 자동화 등
제약 사항
    • FireFox에서 가장 잘 수행되며, IE 등 다른 브라우저에서는 버그가 존재함(Cross Domain등)
    • Flash 테스트는 외부에 노출된 External Interface에 한해서만 가능
사용 팁 
    • 코드 작성시 Selenium IDE(레코딩 기능), XPath Checker, FireBug 툴을 사용하면 코드 작성이 용이함
    • 코드 작성 이후 기존 Unit Test 하는 방법과 유사하게 진행됨.
    • 다양한 이클립스 플러그인 사용하면 좀 더 쾌적한 환경을 구성할 수 있음
필요한 기술
    • JAVA를 베이스로 사용할 경우: JAVA, HTML, JAVA SCRIPT, 이클립스 사용법
관련 자료 다운로드

AutoIt

도구 명AutoIT
구매 여부
    • 오픈 소스
도구 설명(특징)
    • 윈도우 GUI와 범용적인 동작들을 테스트 자동화 하기 위한 도구로 윈도우 기반의 웹, 어플리케이션에 대해 손쉬운 스크립트 작성 가능
적용 장점
    • Web Browser 뿐만 아니라, Windows Application에 대한 제어도 가능함
    • 이미지 비교를 통해서 웹이나 어플리케이션에 대한 UI 테스트가 가능함
    • Recording 기능 및 명령어 자동완성 기능을 통해 손쉽게 테스트 케이스를 만들 수 있음
    • 외부 API, DLL 사용이 가능함
    • ImageSearch.DLL을 이용하여 UI 테스트가 가능
    • 국내/해외 사용자가 많아, 관련 문서나 Example을 찾기 쉬움(커뮤니티 활성화)
    • SWAT과 연동 활용 가능함
    • Compile 후 별도의 Framework 설치 필요 없이 독립적으로 실행 가능
    • Random, For, IF 문 등의 사용이 가능하므로 복잡하고 다양한 테스트 시나리오 작성이 가능함
적용 범위
    • Flash를 제외한 모든 웹/윈도우 어플리케이션에서 제약 없이 테스트 자동화 가능
    • 웹과 어플리케이션을 병행하는 서비스에 대해서 효율적인 결과를 도출할 수 있음
    • 이미지 비교(ImageSearch.DLL)을 통해서 UI 테스트 자동화 가능
제약 사항
    • Flash는 테스트 불가능 (ImageSearch.DLL을 이용해 이미지 비교 후 해당 좌표에 대한 Action은 가능함)
    • Recording이 가능하나, Recording 시 객체에 대한 확인 보다는 Low Recording으로 좌표에 대한 Action으로 Recording (Recording 효율성이 낮음)
    • Low Level Action에 대해 Recording을 하게 되므로, UI 변경 시 Recording된 Script에 대한 효율성이 낮음
    • 테스트 결과에 대한 View가 제공되지 않아, 별도의 Test Result를 볼 수 있도록 결과 페이지를 작성 해야 함
    • 기본적인 스크립트를 작성하기 위해서는 기초적인 Language Skill이 요구되므로 지식이 없는 사용자가 사용하기에 진입장벽이 존재함
사용 팁 
    • 결과에 대한 Result View가 존재하지 않으므로, 별도의 Result를 볼 수 있도록 Log나 Html, XML 형식으로 결과를 Write
    • Object의 Name, ID가 존재하지 않을 경우에는 ImageSearch.DLL함수를 이용하여 해당 Object의 Position을 받아와 Action 수행
    • 자주 사용되는 기능이나, 모듈에 대해서는 재사용성이 용이하도록 Function 또는 Module 화
    • SWAT과 연동이 가능하므로 기본적인 웹 기능에 대해서는 SWAT을 이용하고, SWAT으로 Cover 하기 어려운 부분은 AutoIT을 이용
필요한 기술
    • WEB Object(HTML)와 COM 객체에 대한 개념
    • AutoIT의 기본적인 개념 및 기본적인 Script Language 습득
관련 자료 다운로드

SWAT

도구 명SWAT (Simple Web Automation Toolkit)
구매 여부
    • 오픈 소스
도구 설명(특징)
    • HTML 기반의 웹 어플리케이션 테스트 자동화 도구로 End-User 관점에서 다양한 브라우저를 이용하여 손쉽게 테스트 케이스 작성이 가능
적용 장점
    • 스크립트 구조가 간단하여 다른 자동화 도구에 비해 익히기 쉬움
    • 다양한 브라우저 지원 (Internet Explorer 6.0이상 8.0지원, Firefox, Safari)
    • Recording 기능 및 명령어 자동완성 기능을 통해 손쉽게 테스트 케이스를 만들 수 있음.
    • FitNesse와 연동 가능
    • Hudson CI서버와 연동하여 Regression Test 자동화 가능
    • 테스트의 성공/실패에 따라 선택적으로 그 결과를 스크린샷으로 확인 가능
    • RunScript 명령어를 이용하여 JavaScript 를 직접 실행 가능
    • SWAT4NHN 20091111이후 버전부터 AutoIT 연동기능 제공
    • Random, For, IF 문 등의 사용이 가능하므로 복잡하고 다양한 테스트 시나리오 작성이 가능함
적용 범위
    • 기본적으로 HTML과 JavaScript만으로 이루어진 웹 어플리케이션은 제약 없이 자동화 가능
    • 간단한 Ajax와 ActiveX(예, 파일 업/다운로드 컴포넌트)가 사용된 경우도 가능
제약 사항
    • ActiveX / Flash는 테스트가 불가능 (단, AutoIt과 연동 기능을 제공하므로 비교적 단순한 테스트는 자동화가 가능함)
    • Ajax를 지원하지만 제약사항이 존재함 (단순한 구조만 가능)
    • 일부 Recording이 잘 되지 않는 경우가 존재함
    • 테스트 케이스 실행 시 런타임 시점에 테스트 결과에 따라 실행 순서를 변경하거나 특정 테스트를 반복하는 등의 flow control 기능이 없음
      (단, Command Modifier를 지원하여 간단한 컨트롤은 가능함)
    • 명령어가 단순하므로 복잡한 로직을 포함하는 테스트 케이스는 작성이 불가능
    • 현재 FireFox의 JSSH 플러그인 문제로 인해 한글 입력이 잘 되지 않음
사용 팁 
    • SWAT Editor의 Recording 기능을 활용하여 기본적인 스크립트를 완성하고, Play해서 recording이 잘 되지 않는 부분은 명령어를 직접 typing하여 완성
    • 검증 하고자 하는 값(check point)을 정하고 다양한 Assert 명령어를 추가하여 테스트의 성공/실패를 확인할 수 있도록 함
    • 이렇게 작성된 스크립트를 FitNesse 위키 페이지에 옮겨서 저장하고 테스트를 수행
    • FitNesse와 연동할 경우 관련 있는 테스트 케이스를 페이지 별로 구조화 시키고 다른 페이지 내에서 include와 variable를 통해 재사용 가능하도록 만들 수 있으므로 테스트 케이스 작성 및 유지보수성을 높일 수 있음
    • 특히, 관련 있는 테스트는 FitNesse에서 제공하는 Suite기능을 통해 테스트가 작성된 모든 페이지들을 한번에 테스트 가능
    • FitNesse와 연동 시 Hudson CI서버와도 연동이 가능하므로 주기적인 테스트 및 이전 테스트 결과를 비교 참조할 수 있음
필요한 기술
    • SWAT 개념 및 명령어 작성법
    • Hudson 연동을 위한 STAF 커맨드 사용법 
관련 자료 다운로드

QTP

도구 명QTP (Quick Test Professional)
구매 여부
도구 설명(특징)
    • 기능 테스트 자동화 솔루션으로 MS Windows GUI 어플리케이션에 대한 기능 테스트 및 회귀 테스트 자동화가 가능함
적용 장점
    • 오브젝트 자동 인식 및 등록: 어플리케이션 스크린 구성 요소들을 한번의 마우스 클릭으로 Shared Object Repository에 등록함으로써 작업 그룹간에 협업 지원
    • Keyword View를 통해 Coding 작업 없는 스크립트 작성 지원
    • Auto-documentation: 테스트 단계 작성과 동시에 자동 설명 등록
    • Integrated Data Table (간단한 테스트 데이터 등록 및 실행)
    • 테스트 결과 검증이 용이
적용 범위
    • Web/Windows 서비스 모두 테스트 가능
제약 사항
    • 스크립트 오동작으로 오브젝트 인식이 안 되는 경우가 있음
사용 팁 
필요한 기술
    • SWAT 개념 및 명령어 작성법
    • Hudson 연동을 위한 STAF 커맨드 사용법 
관련 자료 다운로드

WebDriver

도구 명WebDriver
구매 여부
도구 설명(특징)
    • Web UI 테스트 자동화 라이브러리로 다양한 드라이버를 통한 다중 브라우저 테스트 가능
    • 개발자 관점의 웹 테스트 자동화 지원 도구 (only API)
적용 장점
    • 다양한 브라우저(Internet Explorer, Firefox, Safari, Chrome)에 대한 직접적인 컨트롤을 통한 네이티브한 테스트 지원
    • HtmlUnit 드라이버 지원을 통한 플랫폼 독립적인 테스트 및 테스트 결과의 빠른 피드백 가능
    • Support 라이브러리를 사용한 Java Object와 Web Page간 Binding
    • 자바스크립트(Javascript) 지원
    • 쿠키(Cookie)와 관련된 다양한 기능 지원
    • Maven을 통한 Maven 프로젝트에의 손쉬운 테스트 케이스 추가 가능
    • 다양한 키보드 제어 기능 지원
적용 범위
    • HtmlUnit이 지원하는 범위 내의 웹UI 테스트를 지원하며, 동일한 테스트케이스에 대해 여러 웹 브라우저에 대한 반복 테스트가 필요할 경우 사용 가능
제약 사항
사용 팁 
관련 자료 다운로드

WebAii

도구 명WebAii
구매 여부
    • 상용 도구이나 테스트 엔진 자체는 무료로 제공되므로 무료 사용 가능
도구 설명(특징)
    • 웹 어플리케이션 테스트 자동화 도구로 End-User 관점에서 다양한 브라우저를 이용하여 손쉽게 테스트 케이스 작성이 가능
    • Browser와 연계된 Win32 Native 이벤트 제어를 광범위하게 지원함으로써, 기존의 테스트 도구로 테스트하기 힘든 복잡한 어플리케이션도 테스트할 수 있음
    • Test Recoder는 상용으로 제공되나, 테스트 엔진 자체는 무료로 제공됨
적용 장점
    • 타 테스트 도구에 비해 많은 API 셋을 제공함으로써, 테스트 코드가 간단함
    • 다양한 브라우저 지원 (Internet Explorer 6.0이상 8.0지원, Firefox, Safari)
    • SilverLight App에 대한 직접 지원(External API 필요 없음).
      Flash에 대한 Window Native Event를 사용한 처리 지원
    • 다양한 .NET 기반 Unit Test 프레임웍 지원 (MbUnit / MSTest / NUnit 등)
    • Recording 기능을 통해 자동으로 테스트 케이스를 만들 수 있음 (단, 상용 버전 구매 필요)
적용 범위
    • 지나치게 복잡하여 다른 도구로 테스트하기에 힘든 Ajax Web Application
    • Silverlight / Flash 를 많이 사용한 Web Application 테스트
    • Web Game Launcher등 Windows Native App 테스트와 연계가 필요한 경우 
      (또 다른 Native App 테스트 환경인 White(http://www.codeplex.com/white)와 자연스럽게 연계 가능)
제약 사항
    • NET 지원 언어 습득 필요. Window 환경에서만 동작
    • Visual Studio 구매 또는 Open Source. NET IDE인 SharpDevelop 사용 필요
    • 한글 FireFox에 대한 JavaScript 다이얼로그 처리 기능 일부 미숙. 패치 필요
    • API가 약간 직관적이지 않아 학습이 필요함스크립트 오동작으로 오브젝트 인식이 안 되는 경우가 있음
사용 팁 
필요한 기술
    • .NET 지원 언어 사용법.
    • .NET Unit Test Framework 사용법
관련 자료 다운로드


 

'QA > Theory' 카테고리의 다른 글

Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29
ISTQB Agile Test Extension  (0) 2016.02.03

페어와이즈 조합 테스팅(Pairwise testing)

  • 커버해야 할 기능적 범위에 비해 상대적으로 적은 량의 테스트 세트를 구성하여 소프트웨어의 결함을 찾고 테스트에 대한 자신감(Confidence)을 얻을 수 있는 방법 중 한 가지
  • 관찰 결과 대부분의 결함이 2개의 요소의 상호작용(Interactions of two factors)에 기인한다는 것에 착안하여 2개 요소의 모든 조합을 다룬다.
  • 페어와이즈 조합의 의미는 테스트를 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한번씩은 조합을 이룬다는 의미
  • 모든 조합을 고려해 테스팅했을 때 발견할 수 있는 결함을 모두 발견하는 것은 아니지만, 테스팅한 결과에 결함이 없다는 것까지는 보장성을 제공해준다.
  • 경험적으로 의미 있고 결함을 발견할 가능성이 높다고 판단되는 조합을 추가하여 관리 가능한 선에서 조합을 늘이는 것은 조합 테스팅의 효과성을 높이는데 도움이 된다.(물론 늘어난 조합을 감안하여 도출한 테스트 케이스가 보장하는 범위는 페어와이즈 조합 테스팅 기법이 보장하는 범위까지이다.)

'QA > Theory' 카테고리의 다른 글

탐험적 테스팅(Exploratory Testing)  (0) 2016.03.29
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29
ISTQB Agile Test Extension  (0) 2016.02.03
ISO/IEC 25010 품질특성과 품질 부특성  (0) 2016.02.03

Reference :  Fit_소개.pptx

Introduction to Fit

  • Great software requires collaboration and communication.
  • During development, how can customers know that their programmers are producing the right thing? 
  • How can programmers know what the customers really want? 
  • How can testers know what's right and what's wrong? 
  • Getting these groups to communicate effectively and precisely should be a goal for teams creating great software.
  • Fit is a tool for enhancing communication and collaboration. 
  • Fit creates a feedback loop between customers and programmers. 
  • Fit allows customers and testers to use tools like Microsoft Office to give examples of how a program should behave--without being programmers themselves. 
  • Fit automatically checks those examples against the actual program, thus building a simple and powerful bridge between the business and software engineering worlds.

FitNess

  • Requirement are written with example tables.

  • The tables are really tests.

  • Writing test as a table is an interesting paradigm

  • Some tests naturally fit into tables

  • Some tests require thought to put them in the form of a table


 

'QA > Theory' 카테고리의 다른 글

Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29
ISTQB Agile Test Extension  (0) 2016.02.03
ISO/IEC 25010 품질특성과 품질 부특성  (0) 2016.02.03
탐험적 테스팅(EXPLORE IT)  (0) 2016.02.03

ISTQB Agile Test Extension

Syllabus : 

ISTQB CTFL_AT_v.2014_Kr1.0_201504_KSTQB.pdf



소프트웨어(SW) 테스팅 국제자격의 표준 및 대표주자인 ISTQB (비영리 국제SW테스팅자격협회)에서
2014년부터 실시하고 있는
ISTQB Agile Tester(ISTQB FL_AT) 국제 자격증은 자격증 소지자가
애자일 프로젝트에서 필수적인 테스팅 기본지식과 기술을 보유하고 있음을 인증합니다.

시작한지 채 반년이 되지 않아 이미 미국/유럽 쪽에서는 350여명 이상의 취득자(2015년 3월 기준)를 배출했으며,
아시아 국가들에서도 그 유효성이 확대되고 있는 테스팅 국제 자격증입니다.

Agile Tester 실라버스에서는 아래와 같은 학습목표 (Learning Objectives) 를 제공합니다.

  애자일 프로젝트 기획, 보편적으로 적용되는 애자일 개발 프랙티스, 애자일과 기존 접근방식 간의 차이점 이해
  애자일 환경에서 탁월한 성과를 얻기 위해 필요한 애자일 테스팅 원리/사례/프로세스 및 기술 학습
    (애자일 조직 내 테스터의 최적의 포지셔닝법 습득 포함)
  애자일 프로젝트에서의 테스팅 추정과 구성법, 리스크기반 테스팅 적용과 응용
  에자일 프로젝트에 주로 사용되는 테스트 도구에 대한 기본적인 이해 습득

※ ISTQB Agile Tester 실라버스 및 샘플문제 다운로드 : www.kstqb.org | www.istqb.org




STEN에서는 이번 2015년 6월 13일(토) 국내 처음으로 진행되는 ISTQB Agile Tester 국제자격
시험을 자격증 출시기념 특별가로 제공합니다.
(시험시간, 교육일정 등의 상세한 안내는 곧 STEN사이트에 공지 될 예정입니다.)
ISTQB Agile Tester 시험료 특별시험 할인 : 143,000원 → 99,000원 (VAT포함)




-  40문제 객관식 사지선다 형식, 26문항(65%) 이상을 맞추면 합격
-  ISTQB CTFL(Certified Tester Foundation Level) 자격증 보유
-  테스트 설계, 프로세스 및 용어에 대한 기본적인 이해를 가지고 있어야 유리




-  애자일 환경 및 원리와 프랙티스를 숙지하고, 테스팅의 지식체계를 정리하고 내재화 할 수 있다.
-  애자일 관련 테스트 방법론과 기법 등의 실무 적용으로 애자일 팀의 테스트 관련 활동을 지원 할 수 있다.
-  기존의 테스트 경험, 지식 및 모범사례를 애자일 프로젝트에 적용해 애자일 팀과 애자일 환경에서
    효율적인 작업이 가능하다.
-  비즈니스 이해관계자가 이해하기 쉽고 검증도 가능한 사용자 스토리/인수기준을 정의할 수 있도록 지원한다.
-  애자일 테스팅에 대한 역량 검증을 통해 취업, 이직, 승진 시 우위를 선점 할 수 있다.
-  국내에서 애자일한 테스팅을 이끌 수 있는 선도자임을 증명 할 수 있다.
 




-  애자일 프로젝트에 참여하고 있는 테스트 엔지니어, 테스트 매니저, 개발자, PM 등
-  SW 테스팅과 애자일 테스팅의 원리와 프랙티스를 익혀 조직내 프로젝트에서
   눈에 띄는 성과를 올리고 싶은 개발자, 엔지니어 등
-  애자일 테스팅에 관련된 직업에 관심이 있거나 이직을 고려 중인 직장인이나 취업 준비생



 

'QA > Theory' 카테고리의 다른 글

Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29
ISTQB Agile Test Extension  (0) 2016.02.03
ISO/IEC 25010 품질특성과 품질 부특성  (0) 2016.02.03
탐험적 테스팅(EXPLORE IT)  (0) 2016.02.03
애자일 테스팅(Agile Testing)  (0) 2014.10.21

ISO/IEC 25010 품질특성과 품질 부특성


소프트웨어의 품질은 IEEE에서는 컴포넌트, 시스템 또는 프로세스가 명시된 요구사항과 사용자/고객의 필요와 기대를 충족시키는 정도를 말하며, ISO/IEC 25010에서는 명시적이거나 묵시적인 필요를 만족시키는 능력과 관련된 소프트웨어 제품의 특성, 특징으로 정의한다.

이러한 품질은 품질 목표 수립, 기능 명세 및 기능, 비기능 요구사항 보완, 테스트 설계 및 테스트 케이스 도출 등에 사용된다.

국제 표준인 ISO/IEC 25010 품질모델에서는 소프트웨어 품질 특성을 8가지의 주 특성으로 정의한다.


품질특성 내용 부특성 내용
기능성 요구되는 기능을 만족 시키는 능력 기능성숙도

명시된 요구사항 구현 정도




기능정확도

정의된 정밀도에 따라 정확하게 결과를 제공하는 정도




기능타당성

사용자의 목적 달성에 소프트웨어가 도움을 주는 정도


사용성

사용자가 이해하고 배우기 쉬운 정도

타당성 식별력

사용자의 요구에 적절한 기능인지 식별할 수 있는 정도




학습성

사용자가 소프트웨어의 사용법을 배워 명시된 목적을 달성할 수 있는 정도




운용성

제품 혹은 시스템이 작동 및 제어를 쉽게 할 수 있는 정도




사용자 오류 보호

소프트웨어가 발생한 오류로부터 사용자를 보호하는 정도




사용자 인터페이스 미학

사용자 인터페이스가 사용자에게 만족스러운 정도




접근성

연령과 장애에 관계없이 사용될 수 있는 정도


효율성

적절한 자원의 사용 및 적정한 반응시간 정도

시간 반응성

기능 수행 시 응답, 처리시간과 처리율이 요구사항을 충족시키는 정도




요소 활용

기능 수행시, 사용되는 자원의 유형 및 양이 요구사항을 만족시키는 정도




기억 용량

제품 혹은 시스템 파라미터(최근 사용자 수, 통신 대역폭, 데이터베이스가 저장할 수 있는 데이터 양등)의 최대 한계가 요구사항을 만족시키는 정도


신뢰성 규정된 환경에서 결함 없이 의도된 기능 및 작업을 수행하는 능력 성숙성

소프트웨어 구성요소가 표준적 환경에서 신뢰도 요구를 충족시키는 정도




가용성

사용자가 원하는 시간에 사용 및 접근이 가능한 정도




결점완화

시스템, 제품 및 구성요소가 하드웨어 혹은 소프트웨어에 결함이 존재하더라도 이를 극복하고 의도한대로 작동해야 함




회복 가능성

중단 및 실패 발생시, 제품 혹은 시스템이 데이터를 복구할 수 있는 정도


이식성 지원하는 다양한 환경에서 운영될 수 있는 능력 적용성

제품 혹은 시스템이 다른 하드웨어, 소프트웨어 혹은 기타 사용 환경에 효과적이고 효율적으로 적용될 수 있는 정도




설치성

제품 또는 시스템이 성공적으로 설치 및 제거 될 수 있는 정도




대치성

제품이 동일한 환경에서 동일한 목적을 위해 다른 지정 소프트웨어 제품으로 대체 될 수 있는 정도


유지보수성 소프트웨어의 수정 및 변경의 용이성 모듈성

최소의 영향을 가진 개별 구성요소로 구성된 정도




재사용성

자산이 하나 이상의 시스템에서 사용될 수 있고, 기타 자산을 구축할 수 있는 정도




분석성

시스템 변화에 대해 어떠한 영향을 받는지 평가 할 수 있는 보고서를 제공하는 정도




수정가능성

제품 혹은 시스템이 장애 없이 효과적이고 효율적으로 수정될 수 있는 정도




시험가능성

제품 사용 전, 사용에 필요한 검증 기능 제공 여부


상호운용성 다른 시스템과의 상호 연동 능력 공존성

다른 소프트웨어에 유해한 영향을 주지 않고 환경 및 자원을 공유하면서 요구된 기능을 효과적으로 수행하는 정도




상호운용성

 혹은 그 이상의 시스템, 제품 혹은 구성요소가 정보를 교환하거나 교환된 정보를 이상 없이 사용할 수 있는 정도


보안성 정보 및 데이터를 보호하는 능력 기밀성

제품 혹은 시스템은 반드시 권한이 있는 데이터에만 접근 가능하도록 해야 함




무결성

시스템, 제품 혹은 구성요소가 컴퓨터 프로그램 혹은 데이터에 대해 무단으로 접근 혹은 변경되는 것을 방지하는 정도




부인 방지

사건 및 행위 후에 부인하지 못하도록 행동 및 사건에 대해 입증되는 정도




책심성

시스템 내의 각 개인을 유일하게 식별하여 언제 어떠한 행동을 하였는지 기록하여 필요 시 그 행위자를 추적할 수 있는 능력




진본성(인증성)

사전 및 행동에 대해 행위자임을 증명할 수 있는 능력


 

'QA > Theory' 카테고리의 다른 글

Fit & FirNeses  (0) 2016.03.29
ISTQB Agile Test Extension  (0) 2016.02.03
ISO/IEC 25010 품질특성과 품질 부특성  (0) 2016.02.03
탐험적 테스팅(EXPLORE IT)  (0) 2016.02.03
애자일 테스팅(Agile Testing)  (0) 2014.10.21
Scrum(스크럼)  (0) 2014.08.20

탐험적 테스팅 :  배우고 통찰하며 개선하는 소프트웨어 테스트, 엘리자베스 핸드릭슨 지음. 오광신 옮김. 인사이트

1장. 테스팅과 탐험에 대해서

  • 테스트케이스에는 두 가지 핵심 질문에 대답할 수 있는 테스트 전략이 필요하다.
    • 소프트웨어가 주어진 환경과 조건에서, 의도한 대로 동작하는가?
    • 다른 위험 요소들이 있는가?
  • 탐험적 테스팅은 그물망이 아무리 촘촘하게 만들어도 잡아내지 못하는 부분들을 조사하는 것을 포함하고 있다. 실제 소프트웨어를 직접 사용해보면서, 테스트를 위한 작은 실험들을 설계해서 실행해보고, 그 결과를 반영해서 다음 실험을 설계하고 실행하는 연속적인 작업을 신속하게, 그리고 계속 진행해야 한다.
  • 그저 반복만 하는 것은 절대 도움이 안되지만, 변화를 주면서 반복하게 되면 무엇인가 놀랄만한 새로운 것들을 얻을 수 있다.
  • 테스트 완료 =  확인하기 (모든 기능의 동작 확인하기) + 탐험하기 (모든 위험 요소 탐험하고 돌아오기)
  • 탐험적 테스팅은 학습, 테스트 설계, 테스트 실행, 이 세가지가 동시에 일어나는 테스팅 방법이다 - 제임스 바크(Exploratory Testing Explained, 2003)
  • 탐험적 소프트웨어 테스팅은, (1) 테스트를 통해 얻게 되는 학습, (2) 테스트 설계, (3) 테스트 수행, (4) 테스트 결과 해결, 이 네가지 모두를 상호간에 도움을 주면서 동시에 실행 될 수 있는 활동들로 간주하고, 가치 있는 테스트 결과를 가장 효과적으로 끊임없이 얻기 위해 테스터 개개인의 자유 의지와 책임감을 강조하는 소프트웨어 테스팅의 한 방법이다. - 켐가너
  • 저자 : 시스템을 완벽하기 테스트하기 위해 테스트 도중에 지난 테스트로부터 배운 것들을 다음 테스트를 위해 사용하면서 테스트 설계와 테스트 수행을 동시에 진행하는 테스트 방법이다.
  • 탐험적 테스팅을 다른 테스팅 방법과 쉽게 구분할 수 있도록 해주는 것이 탐험적 테스팅에서는 바로바로 실행에 옮긴다는 사실이다.
  • 찾아야할 가장 중요한 정보에 집중하면서 동시에 방향을 전환하는 것은 탐험적 테스팅의 전문가가 지녀야할 핵심 기술 중 하나이다.
  • 목적도 없이 해매다가 시간만 투자하고 유용한 정보를 하나도 얻지 못하고 끝나는 경우도 있기 때문에 존바크와 제임스 바크는 이런 경우에 대한 해결택으로 세션 기반 테스트 관리 즉, 주어진 시간을 시간이 정해져 있는 세션들로 나눠 구성하는 것을 제안했다. 각 세션을 진행하면서 무엇을 탐험했고, 어떤 정보를 찾았는지 꼼꼼하게 메모를 하되, 이런 메모는 개인적인 용도임을 잊지말자. 그리고 세션 마지막에 다른 사람들에게 전달해야 하는 정보들을 정리한다.

2장. 탐험을 위한 차터 작성

  • 소프트웨어 탐험의 궁극적인 목표는 이해관계자들이 관심을 가지고 있고 그들에게 가치가 있는 정보를 찾아내는 것이다. 
    • 목표 : 어느 곳을 탐험해야 할까? 어떤 기능이나 요구 사항일 수도 있고, 관련된 특정 모듈일 수도 있다.
    • 자원 : 어떤 자원들을 가지고 갈 것인가? 도움을 주는 도구, 데이터, 새로운 기술, 환경 설정 또는 상호 의존적인 다른 기능들도 자원이 될 수 있다.
    • 정보 :  어떤 종류의 정보를 찾고 싶은가? 보안, 성능, 신뢰성, 가용성, 사용성 또는 시스템의 특정 측면에 우선 순위를 두고 찾고 있는가? 설계의 일관성이나 표준을 위반하는 부분들을 찾고 있는가?
  • 차터를 실행해 옮길 때, 주어진 상황에 따라 여러 단계의 변화가 필요하다는 것을 인지하고, 고려해야 한다. 탐험을 진행할 때, 특정한 정보나 위험 요소에 더욱 더 집중할 수 있게 도와주는 것이 차터이고, 이것이 바로 우리가 차터를 만들어야 하는 이유이다.
  • 차터 양식이 모든 상황에 완벽하게 적합할 수 없기 때문에 단지 가이드 역할을 해준다는 사실을 기억해야 한다. (모든 차터를 양식에 무리하게 끼워 맞추지는 말아야 한다.) 차터를 만드는 것에 익숙하지 않을 때는 양식을 사용하는 것이 좋지만 경험이 많이 쌓여 익숙해지면, 그저 차터 양식의 빈자리를 채우기보다는 현재 작성하고 있는 차터가 이번 탐험의 목적과 이유를 더욱 더 잘 반영하도록 해야 한다.
  • 좋은 차터란 테스트 순서 하나하나를 일일이 구체적으로 명시하지 않으면서도 테스트가 나아가야 할 방향을 알려주는 차터이다. 훌륭한 차터는 아주 명확한 행동 지침이나 결과물에 대한 언급 없이도 영감의 원천이 되는 힌트여야 한다.

3장. 세심하게 관찰하기

4장. 눈여겨볼 변수 찾아내기

5장. 결과를 가지고 판단하기

6장. 순서와 상호 작용 다양하게 바꿔보기

7장. 개체와 개체들 사이의 관계 탐험하기

8장. 상태와 전이 발견하기

9장. 소프트웨어 생태계 탐험하기

10장. 사용자 화면이 없는 곳 탐험하기

11장. 기전 시스템 탐험하기

12장. 요구 사항 탐험하기

13장. 처음부터 끝까지 탐험 적용하기

부록1. 탐험적 테스팅 기법 면접하기

부록2. 테스트 휴리스틱 치트 시트

 

'QA > Theory' 카테고리의 다른 글

ISTQB Agile Test Extension  (0) 2016.02.03
ISO/IEC 25010 품질특성과 품질 부특성  (0) 2016.02.03
탐험적 테스팅(EXPLORE IT)  (0) 2016.02.03
애자일 테스팅(Agile Testing)  (0) 2014.10.21
Scrum(스크럼)  (0) 2014.08.20
소프트웨어 테스팅의 기초-4  (0) 2010.04.07

+ Recent posts