문성준의 단단해지기

안녕하세요!!

이번에는 Pairwise Testing 에는 어떤 Tool 이 있는지 알아보고

대표적인 Tool 소개와 Tool을 다운받을 수 있는 링크를 첨부하였습니다.

https://www.pairwise.org/tools.asp

에서 이와같은 페이지를 찾아볼 수 있고 다운로드 받을 수 있습니다.

안녕하세요

오랜만의 포스팅이네요..

오늘은 Pairwise Testing 에 대해서 글을 써보려고 합니다.

일단 이번글은 Pairwise Testing 의 정의에 대해서 알아보겠습니다.

 "테스트 프로세스의 기초"에 대해 이야기 해보려고 한다. 

 테스트 프로세스 주요활동 에는 아래와 같이 5개로 구분할 수 있다.

<<테스트 프로세스 주요활동>>

 

1. 계획과 제어(Planning and Control)

 

2. 분석과 설계(Analysis and Design)

 

3. 구현과 실행(Implementation and Execution)

 

4. 완료 조건의 평가와 보고 (Evaluating exit criteria and Reporting)

 

5. 테스트 마감 활동(Test Closure activities)

테스트 프로세스는 순차적이지만, 프로세스 내의 활동들은 중복되거나 동시에 발생할 수 있다.

1.     테스트 계획과 제어

-계획 : 테스팅의 미션과 목표를 정의하고 이를 만족 시키기 위한 테스트 활동을 수립하는 과정 , 모니터링 및 통제 활동의 피드백에 따라 조치를 할 수 있도록 수립되어야 한다.

 

-제어 : 실제 진행 상황과 계획을 비교하고 보고하는 활동 ,프로젝트의 미션과 목표를 위해 조치가 이루어 질 수 있다.

이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어야 한다.

2.     테스트 분석과 설계 

 

-테스팅 목적에 부합하는 테스트 상황과 테스트 케이스를 생성한다.

 

-자료 리뷰( 요구사항 ,디자인 등) , 테스트 케이스 설계와 우선 순위를 선정한다.

 

-테스트 상황과 테스트 케이스에 필요한 데이터 식별 및 환경과 도구를 확보한다.

 

3.     테스트 구현과 실행 

 

-테스트의 조건들을 테스트 케이스로 전환하고 이를 위한 환경을 갖추는 일련의 활동을 말한다.

 

-계획된 절차에 따라 테스트 케이스를 직접 또는 자동화 툴을 사용하여 수행한다.

 

-테스트 실행 결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전 등 테스트 기록을 남긴다.

 

-실제 결과와 기대 결과를 비교 후 불일치 시에 원인을 기록하거나 원인을 모르겠다면 발생 되기 까지의 프로세스를 남긴다.(반복적 , 간헐적인지 기록)

 

4.     테스트 완료 조건의 평가와 보고 

 

-테스트 수행 결과를 목적과 비교하여 평가한다.

 

-이해관계자들을 위한 테스트 요약 보고 작성한다.

 

5.     테스트 마감 활동 

 

-모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합하기 위해 모든 데이터를 수집하고 완료한다.

이론적으로 이러한 프로세스를 바탕으로 테스트를 진행하게 된다.

그러나 이론과 실무에는 크다고하면 크고 작다고하면 작은 차이가 있으니

기본에 중점을 두고 테스팅하면 결함을 발견하는데 도움이 될 것이다.

테스팅과 디버깅의 차이는 무엇일까?

다른 활동이지만 서로 의존하는 관계라고도 볼 수 있다.

 테스팅 : 결함을 발견하기 위한 활동

-테스트는 공정상의 결함을 발견할 수 있다.

-시스템이 정지되는 결함과 정지가 되지 않는 결함이 모두 포함된다.

 

 디버깅 : 결함의 원인을 찾고, 코드를 수정하는 개발활동

-디버깅 후 테스터에 의해 확인 테스팅을 수행하여 결함이 제대로 고쳐졌는지 확인이 필요하다.

"결국 테스팅과 디버깅을 반복해야 최종적으로 결함을 수정 및 해결 할 수 있다고 생각된다."

테스팅의 필요성과 품질에 관한 이야기를 저번에 했는데

테스트 품질관련 이야기를하면서 소프트웨어의 요구사항 (기능적, 비기능적) 에 대해서 다음에 포스팅 한다고 했다.

개인공부를 하던 중 기능적, 비기능적 뿐만아니라 도메인 요구사항도 있길래 몇글자 적어보려 한다.

기본적으로 소프트웨어 요구사항과 특성에는 뭐가 있을까?

총 5가지 이다. 사용성, 효율성, 신뢰성, 이식성 , 유지보수성 이다.

사용자가 소프트웨어를 얼마나 쉽게 사용할수 있는지 또 소프트웨어의 효율은 어떠한지, 특정 기능에 대해 실패 확률은 얼

마인지, 이 소프트웨어가 다양한 환경에서도 동작하는지, 이 소프트웨어를 얼마나 오래 쓸건지에 대해 특성을 정리해 보았

다.

<<소프트웨어 요구사항과 특성>>

 

1.     사용성(usability)- 사용자가 소프트웨어를 어떻게 쉽게 사용할 수 있을지가 기술되는 요구 사항

 

2.     효율성(efficiency)- 소프트웨어는 빠를수록, 메모리를 적게 사용할수록 좋다. 이에 대한 제약 사항을 정의

 

3.     신뢰성(reliability) –특정한 기능을 실행할 때 실패할 가능성

 

4.     이식성(portability)- 소프트웨어가 다양한 플랫폼에서 작동

 

5.     유지 보수성(maintainability)- 소프트웨어의 수정, 개선을 용이하게 하는 능력

소프트웨어 시스템의 요구사항은 크게 기능적(functional), 비기능적(non-functional) 또는 도메인 (domain) 요구사항으로 분류될 수 있다.

      << 기능적 요구사항(Functional requirements)>>

 

- 시스템이 제공하는 기능 또는 서비스에 대한 기술

 

- 기능적 사용자 요구사항은 시스템 동작사항에 대한 추상적 기술이지만, 기능적 시스템 요구사항은 시스템 서비스에 대한 상세한 

기술이어야한다.

 

- 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술

 

- 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술 ( 시스템이 하지 말아야할 것 에 대해 기술하는 경우도 있음)

 

- 소프트웨어 종류, 예상되는 사용자, 소프트웨어가 사용되는 시스템의 종류에 좌우

   <<비기능적 요구사항 (Non-functional requirements)>>

 

-       시스템 속성이나 시스템에 의해 제공되는 서비스나 기능에 대한 제약사항에 대해 정의 한다.

 

-       신뢰도, 반응 시간, 저장소 요구사항 등 대부분 개별적 기능이 아닌 전체적 모습에 관한 요구 ( 프로세스 요구사항이 있을 수도 있다.)

   <<도메인 요구사항 ( Domain requirements)>>

 

-       응용 도메인 으로부터 생기는 요구사항으로 특정 도메인의 용어나 개념이 반영되어 시스템의 특성에 영향을 준다.

 

-       새로운 기능적 요구사항 또는 기존의 요구사항에 대한 제약사항이 되거나 특별한 계산식을 정의하는 것 등이 될 수 잇다.

 

-       도메인의 요구사항이 만족되지 않으면 시스템이 쓸모 없게 된다.

 

-       문제점 : 해당 응용 도메인의 언어로 표현되기 때문에 시스템을 개발하는 소프트웨어 공학자가 이해하기 어렵다. 도메인 전문가에게는 분명한 부분이기 때문에 생략해버린 정보를 개발자가 알 수 없다.

도메인 요구사항은 글을 작성하고 있는 나도 학교에서 배운 기억이 없는것 같다.( 내가 수업시간에 졸았나?)

정리하자면, 기능적 요구사항은 단어의 뜻대로 사용자가 원하는 기능을 말한다. 사용자는 그 기능을 시스템을 통해 제공받기를 원하며, 시스

템은 사용자에게 필요한 기능을 제공해줘야 한다.

기능적 요구사항이 소프트웨어가 제공하는 기능이라면, 비기능적 요구 사항은 수행 가능한 환경, 품질 , 제약 사항이다.

*피드백 환영 합니다* 

테스팅을 하다보면 오류가 발생하게 된다.

오류의 원인으로는 무엇이 있을까?

1.     인간의 실수 – 소프트웨어 또는 시스템 코드에 결함을 야기

2.     주변 환경에 의한 결함 – 전자파, 자석 , 공해 , 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어에 영향을 주어 오류 발생

위와 같이 오류도 상황에 따라 다양한 이유로 발생하기 때문에 이를 분류해 줄 수 있는 용어가 필요하다.

<<테스팅 용어>>

-       오류 (error) : 잘못된 결과를 만드는 사람의 행위(사람의 실수에 의한 에러)

-       결함 (Defect, Bug,Fault) : 에러에 의해 발생한 것 , 에러가 실제로 코드에 구현된 것 , 소프트웨어 상의 Error 를 일으킬 수 있는 징후 ,요구 기능의 부정확한 처리 , Failure 의 원인

-       장애 (Failure) : 예상과 다르게 동작하는 소프트웨어의 의도하지 않은 결과, 결함을 가진 SW 실행 시 발생 ( 단, 모든 결함이 장애로 가지는 않는다)

이러한 이유로 소프트웨어가 올바르게 작동 되지 않는 경우 이로 인한 피해가 크다.

피해로는 아래와 같은 이유가 있다.

1. 금전적 손실

2. 시간 낭비

3. 비지니스의 이미지 손상

4. 부상 or 사망

테스트 후의 결과는 곧 신뢰성과 밀접한 연관관계를 가지고 있다.

아니 거의 동일하다고 본다. 

추가적으로 이건 내 경험이지만, 같은 팀이여도 못믿는 경우가 생긴다.

QA 팀이지만 본인부터 실수가 많아버리면 제품이나 고객사에게도 큰 영향을 주기때문에 

내가 직접 보고 경험한 것 만으로 보고를 해야한다고 생각된다.

*피드백 환영입니다.*

<<테스팅의 일반적인 원리>>

1.     테스팅은 결함이 존재함을 밝히는 활동이다. 

 – 결함이 없다는 것은 증명할 수 없다.

2.     완벽한 테스팅(Exhaustive) 은 불가능 하다. 

 – 무한 경로, 무한 입력 값, 무한 타이핑, 리스크 분석과 결정된 우선 순위에 대한 테스팅을 집중

3.     테스팅을 개발 초기에 시작한다. 

 – 개발 시작과 동시에 테스트를 계획, 전략적으로 접근, Test case 를 도출하면서 문서상의 결함 발견

4.     결함 집중(Defect Clustering) 

 – 적은 수의 모듈에서 대다수의 결함 발견 ( 결함과 장애가 집중)

5.     살충제 패러독스(Pesticide Paradox) – 동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듦, 경험 기반 기법을 통해 테스트 방법을 다양화

 – 해당 기법을 다른 모듈 또는 시각에서 재적용시켜 테스트 케이스를 업데이트하는 노력

– 탐색적 테스팅(Exploratory testing), JIT 테스팅(Just-in-time-testing)등의 경험 기반 접근법을 통해 새로운 테스트 케이스를 추가하는 것이 필요

6.     테스팅은 정황(Context)에 의존적이다. (일의 사정과 상황)

 – 효율적, 효과적 테스트 팀 조직, 독립적 테스트 환경

7.     오류 – 부재의 궤변 (Absence – of – errors fallacy)

 – 사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미, 결함을 모두 발견했다고 해도 품질이 높다고 할 수 없다.

*피드백 환영입니다*

QA는 무엇이고 , QC는 무엇일까? 

오늘은 미묘하게 다른 QA, QC 에대해 몇글자 적어보려고 한다.

QA는 Quality Assurance로 품질 보증을 말하고, 품질 요구 사항을 만족시키고 고객에게 신뢰감을 주기위함을 목적으로 한다.

일정한 효율과 품질이 보장되어야 하는 활동 또는 제품에 대하여 보증을 부여하기 위하여 필요한 증거를 제공하는 것을 이른다.  

QC는 Quality Control 로 품질 관리를 말한다. 기업이 생산과 관련된 모든 요소의 품질을 검토하는 프로세스를 말한다.

품질관리(QC)는 품질 보증 프로세스 내에서 품질 평가 활동을 모니터링하고 요구 사항을 충족하는지 관찰하는 업무를 수행하게 된다.

결함 발견을 위한 활동이므로 테스팅(Testing), 리뷰(Review), 검사(Inspection)를 수행한다.

즉, QA 는 좀 더 고객에 중점을 두고 있고, 그에 비해 QC는 제품에 많은 비중을 두고 있다고 볼 수 있다.

품질보증(QA)은 고품질(High-Quality)을 위해 품질관리(QC)보다 넓은 활동을 수행한다고 볼 수 있다.  

4차산업혁명 시대에 품질 보증(QA)은 IT 분야에서 더욱 더 다양하게 수행되어진다. 

실제  IT 업계의 대다수 기업에서는 소프트웨어의 결함을 예방하기 위해 품질 보증 프로세스를 확립하고 지속적으로 관리하고 있다.

*피드백 환영합니다*