소프트웨어 테스팅의 주요 단어에 대한 정의

소프트웨어 테스팅에 입문하거나 학교에서 배우는 과정에서 필요한 기본 용어나 개념에 대해서 언급해 보았다. 다만, ISTQB 등에서 정의하고 있는 용어와는 다를 수 있을 것이다. 에러/결점/실패의 용어 정의가 그것인데, 이러한 분류도 가능하다는 분류의 기준을 오히려 이해하고 있는 편이 용어의 정의만 단순 암기하는 것보다는 나을 것이다. ^^ (이미 ISTQB의 용어 정의는 많이 알려져 있기도 하다.)

-----------------------------------------------------------------------------------------------------

소프트웨어 테스팅의 목적은?

소프트웨어 테스팅은 개발된 컴퓨터 소프트웨어의 품질, 보안성, 완전성, 정확성을 확인하는데 사용되는 프로세스이다.

소프트웨어 테스팅은 에러를 찾으려는 의도를 가지고 시스템이나 프로그램을 동작시키는 프로세스이다.

QA와 테스팅의 차이점은?

테스팅은 제어 가능한 조건들 하에서 어플리케이션이나 시스템을 동작시키고, 그 결과를 평가하며, '발견'을 지향한다.

소프트웨어 QA는 전체 소프트웨어 개발 프로세스에 참여한다. 즉, 프로세스의 개선과 모니터링, 합의된 표준이나 프로시저의 준수 여부 확인, 문제를 찾아내고 처리하는 것을 확실하게 하며, '예방'을 지향한다.

검증과 확인간의 차이를 기술하라.

확인(Verification)은 문서, 정책, 코드, 요구사항, 명세를 확인하기 위한 빈번한 미팅과 평가에 의해 이루어진다. 이것은 체크리스트, 웍쓰루, 인스펙션 미팅을 통해 가능하다.

검증(Validation)은 실제 테스팅 과정에 이루어지는 것으로, 모든 확인 과정이 완료된 이후에 발생한다.

소프트웨어 개발 라이프싸이클을 기술하라.

초기 컨셉, 요구사항 분석, 기능 디자인, 내부 디자인, 문서화 계획, 테스트 계획, 코딩, 문서 준비, 통합, 테스팅, 유지보수, 업데이트, 재테스팅, 단계 마감, 나머지 다른 일들과 같은 측면들이 포함된다.

충분히 테스트 했음을 어떻게 결정하나?

테스팅을 중단하는 결정에 대한 일반적인 고려 요소는 다음과 같다.

• 데드라인 (릴리즈 데드라인, 테스팅 데드라인 등)
• 특정 퍼센트의 pass를 달성한 테스트 케이스 전체의 완료
• 테스트 예산의 고갈
• 코드/기능성/요구사항의 커버리지가 특정 지점에 다다른 경우
• 특정 레벨 이하로 버그율이 떨어지는 경우
• 알파나 베타 테스팅 기간이 종료하는 경우

어떤 소프트웨어 테스팅 유형이 있나?

블랙 박스 테스팅: 이 유형의 테스팅은 내부 디자인이나 코딩에 대한 지식이 필요치 않다. 이러한 테스트는 요구사항이나 기능성을 근거로 한다.

화이트 박스 테스팅: 이 유형의 테스팅은 특정 어플리케이션 코드의 내부 로직에 대한 지식을 근거로 한다. 이 테스팅은 코드 구문, 경로, 조건들의 커버리지에 근거해 완료된다.

유닛 테스팅: '세부' 범위의 테스팅으로, 주로 특정 기능이나 코드 모듈을 테스트하는데 사용된다. 일반적으로 프로그래머에 의해 수행되며 테스터에 의해서는 수행되지 않는다.

스모크 테스팅: 이 유형의 테스팅은 새로운 소프트웨어  버전이 상강한 테스팅 활동을 수행할 수 있을 정도인지를 결정하가 위해 초기에 이루어지는 것이다. 예를 들어, 새로운 소프트웨어가 매 5분마다 시스템을 크래쉬시키거나 데이터베이스를 망가뜨린다면, 소프트웨어 현재 상태에서는 테스팅을 더 진전시키기 적합한 상태가 아닌 것이다.

기능적인 테스팅: 일반적으로 이것은 어플리케이션의 기능적인 요구사항을 체크하기 위해 블랙 박스 테스팅을 사용한다. 이 유형의 테스팅은 테스터에 의해서 이루어져야 한다.

통합 테스팅: 이 테스팅은 기능이 서로 어울려 동작하는지 확인하기 위해 어플리케이션의 여러 "파트" 들을 통합하는 것이다. "파트"는 코드 모듈이나, 개별 어플리케이션, 네트워크 상의 클라이언트나 서버 어플리케이션이 될 수 있다. 특히 이 유형의 테스팅은 분산 시스템이나 클라이언트/서버에 적합하다.

점진적 통합 테스팅: 이것은 새로운 기능성이 기존 것에 덧붙여지면서 지속적으로 어플리케이션을 테스팅하는 것이다. 또한 프로그램의 모든 파트가 완성되기 전에 개별적으로 동작여부를 확인함으로써 어플리케이션의 기능성을 체크하기도 한다. 또 이 유형의 테스팅은 테스트 드라이버가 있는지 없는지를 체크하게 될 것이며, 이것은 테스터나 프로그래머에 의해서 수행될 수 있다.

회귀 테스팅: 이것은 수정이나 변경이 이루어진 후 전체 어플리케이션을 다시 테스팅하는 것이다. 대개 SDLC의 마지막에 가서야 완료된다. 또한 대부분의 자동화된 테스팅은 이 유형의 테스팅에 사용된다.

시스템 테스팅: 이 유형의 블랙 박스 테스팅은 전체 요구 명세에 기반을 두며, 시스템 모든 결합된 부분들을 커버한다.

엔드 투 엔드 테스팅: 이것은 시스템 테스팅과 유사하나, 데이터베이스와의 연동, 네트워크 연결 사용, 다른 하드웨어/SW와의 연결 등의 전체 어플리케이션 환경에 대한 테스팅이 포함된다.

유저 승인 테스팅: 이 것은 최종 단계에서 발생하며, 주로 최종사용자나 고객에 의해서 수행된다.

사용성 테스팅: 이 테스팅은 어플리케이션의 "유저 친화력"을 점검한다. 이것은 목표 최종사용자나 고객에 따라 달라진다. 유저 인터뷰, 서베이, 유저 세션의 비디오 녹화, 그외 기법들이 사용된다. 프로그래머나 테스터는 대개 사용성 테스터로서는 적합하지 않다.

호환성 테스팅: 소프트웨어가 특정 하드웨어, 소프트웨어, 운영쳬제, 네트워크 등에서 얼마나 잘 동작하는지 테스팅한다.

비교 테스팅: 이것은 다른 경쟁 제품과 소프트웨어의 강점과 약점을 비교하는 것이다.

뮤테이션 테스팅: 이것은 테스트 데이터나 테스트 케이스의 집합이 유용한지를 판단하는 또 다른 방법으로, 의도적으로 다양한 코드를 변경하거나 버그를 심어두고 "버그"를 발견하는지 못하는지 원래 테스트 데이터나 케이스를 가지고 재테스팅한다.

왜 소프트웨어는 버그를 내재하게 되나?

잘못된 의사소통 또는 의사 소통이 없음 - 어플리케이션이 어떠해야 하는지 또는 어떻게 하면 안되는지에 대한 상세 내용

프로그래머 에러 - 대 부분의 경우 프로그래머들도 실수를 한다.

요구사항 변경 - 최종 사용자는 변경이 미치는 영향력을 이해하지 못한채로 변경요구한다. 또는 이해하고 있더라도 재디자인, 엔지니어 스케줄 조정, 다른 프로젝트에 영향을 미치기 위해 요구하며, 이 때 이미 완성된 것들은 재작성되거나 버려진다.

시간 강제 - 소프트웨어 프로젝트의 준비는 아무리 잘해봐야 어려운 것으로, 종종 많은 수의 추정을 요구한다. 데드라인이 다가오거나 위기가 닥쳐오면 실수는 만들어 진다.

소프트웨어 개발 프로세스의 전형적인 문제점들은 무엇인가?

고객으로 부터 오는 부적절한 요구사항 - 고객에서 오는 요구사항이 명확하지 않거나, 완성된 것이 아니며, 테스터블 하지 않다면, 문제는 발생한다.

비현실적인 스케줄 - 때때로 과도한 작업이 개발자에게 할당되며 짧은 기간 안에 완성하도록 요구된다. 그러면 문제는 피할 수 없다.

부족한 테스팅 - 개발된 소프트웨어가 적절하게 테스트되지 않은 경우 문제는 발생한다.

기존 프로세스 하에서 또 다른 작업이 주어질 때 - 상위 관리층에서 또 다른 프로젝트를 작업하라는 요구를 하거나 업무가 발생하면 팀으로서 테스트되는 프로젝트일 때 문제가 발생한다.

의사 소통 오류 - 일부 경우 개발자는 고객의 요구사항과 기대치를 인지하지 못한다. 따라서, 이탈(잘못 구현)이 발생할 수 있다.

소프트웨어 개발과 관련한 문제의 기본적인 해결책은 무엇인가?

기본 요구사항 - 명확하고, 상세하며, 완전하고, 달성할 수 있으며, 테스트 가능한 요구사항이 개발되어야 한다. 프로토타잎을 사용하면 요구사항을 고정하는데 도움이 된다. 급변하는 환경에서는 고객/최종 사용자와의 지속적이고 긴밀한 협력이 필요하다.

스케줄은 현실적이어야 한다 - 주어진 스케줄 안에 계획, 디자인, 테스트, 버그 수정, 재테스트, 변경, 문서화를 할 수 있는 충분한 시간이어야 함.

적절한 테스팅 - 테스팅은 초기부터 시작되어야 하며, 버그 수정이나 변경이 발생한 직후 재테스트 되어야 한다. 테스팅과 버그 수정에 충분한 시간이 사용되어야 한다.

초기 요구사항에 대한 적절한 연구 - 개발이 시작되고 난 이후 변경이 될 때마다 살펴야 하며, 다른 이들에게 변경을 설명할 수 있어야 한다. 고객과 최종 사용자의 기대치를 관리하기 위해 그들과 긴밀하게 작업해야 한다. 이것은 이후 단계에서의 과도한 변경을 방지한다.

의사소통 - 적절한 기간 동안 빈번한 인스펙션과 웍쓰루를 시행한다. 가능한 한 전자적인 형태로 문서와 정보를 최신으로 유지하도록 하며, 팀워크를 고취시키고 팀 내부의 협업을 증진한다. 프로토타잎과 최종 사용자와의 적절한 의사소통은 그들의 의심과 기대를 명확하게 해준다.

UAT 테스팅은 무엇이며 언제 이루어지나?

UAT 테스팅 - UAT는 "유저 승인 테스팅"을 나타낸다. 이 테스팅은 유저의 관점에서 수행되며, 대개 릴리즈 이전에 완료된다.

재테스트와 회귀 테스트는 무엇인가?

재테스트 - 재테스팅은 어플리케이션의 특정 파트만 테스팅하는 것으로 그것이 전체 어플리케이션에서 또는 다른 파트에 어떤 영향을 미치는지는 고려하지 않는다.

회귀 테스팅 - 모듈 또는 어플리케이션의 파트의 변경 이후에 어플리케이션을 테스팅 하는 것으로, 코드 변경이 어플리케이션의 나머지 영역에 미치는 영향에 대한 테스팅이다.

구조적(structural), 기능적(functional) 테스팅의 차이점은?

구조적 테스팅은 "화이트 박스" 테스팅으로 알고리즘과 코드에 근거한다.

기능적 테스팅은 "블랙 박스" (행동적인) 테스팅으로 테스터는 기능적인 명세를 확인한다.

회귀 테스팅에서 상향식, 하향식 접근법을 기술하라.

상향식 접근법: 이 접근법의 테스팅은 하부 모듈에서 메인 모듈로 수행한다. 메인 모듈이 드라이버라고 불리는 임시 프로그램으로 개발되지 않은 경우 메인 모듈을 시뮬레이트하는 방법이 사용된다.

하향식 접근법: 이 접근법의 테스팅은 메인 모듈에서 하부 모듈로 수행한다. 하부 모듈이 스텁이라 불리는 임시 프로그램으로 개발되지 않은 경우 하부모듈을 시뮬레이트하는 방법이 사용된다.

임의(ad-hoc) 테스팅이란?

임의 테스팅은 어떤 규칙이나 테스트 케이스를 따르지 않는 어플리케이션 테스팅과 관계가 있다.

임의 테스팅에서 누군가는 어플리케이션에 대해서 많은 지식을 가지고 있어야 한다.

SDLC와 STLC는 무엇인가? 이 서로 다른 단계를 설명하라.

SDLC

요구사항 단계(Requirement phase)
디자인 단계(Designing phase (HLD, DLD (Program spec))
코딩(Coding)
테스팅(Testing)
릴리즈(Release)
유지보수(Maintenance)

STLC

시스템 연구(System Study)
테스트 계획(Test planning)
테스트나 스크립트 작성(Writing Test case or scripts)
테스트 케이스 리뷰(Review the test case)
테스트 케이스 수행(Executing test case)
버그 추적(Bug tracking)
버그 리포트(Report the defect)

또는

Software Development/ Product Life Cycle
------------ --------- --------- ---------
Requirement Analysis
Detailed Specification
High Level Design (HLL)
Low Level Design (LLL)
Coding
Unit Testing
Integration Testing
Operational Testing (optional)
Product Delivery

Software Testing Life Cycle
------------ --------- ------
Requirement Analysis
Test Strategy/Estimate/ Plan/Bed
Test Cases Identification/ Review/Updation/ Execution
Bug Reporting
Regression Testing
Test Summary/Report
User Acceptance Testing

부하, 성능, 스트레스 테스팅을 예를 들어 설명하라.

부하 테스팅과 성능 테스팅은 일반적으로 긍정적인 테스팅으로 불린다. 반면에, 스트레스 테스팅은 부정적인 테스팅으로 불린다.

한 번에 25명의 유저의 동시 로그인을 처리할 수 있는 어플리케이션이 있다고 가정하면, 부하 테스팅에서는 25명의 유저에 대해서 어플리케이션을 테스트 하며, 이 단계에서 어플리케이션이 어떻게 동작하는지 체크할 것이다. 성능 테스팅에서는 그 동작을 수행하는데 걸리는 시간에 집중할 것이다. 반면에 스트레스 테스팅에서는 25명 이상의 경우를 테스트하며, 시스템이 문제가 생기는 숫자가 될 때까지 테스트를 계속할 것이다.

부정적인 테스팅은?

부정적인 테스팅 - 부정적인 데이터를 가지고 시스템을 테스팅하는 것을 부정적인 테스팅이라 한다. 예를 들어, 최소 8캐릭터가 필요한 암호를 테스팅하는데, 6캐릭터만 가지고 테스팅하는 것이 부정적인 테스팅이다.

테스트 베트와 테스트 데이터는 무엇인가?

테스트 베드는 소프트웨어 테스팅을 위해 구성된 실행 환경이다. 이것은 특정한 하드웨어, 네트워크 위상, 운영 체계, 테스트를 위한 제품의 구성, 시스템 소프트웨어와 또 다른 어플리케이션으로 구성된다. 프로젝트의 테스트 계획은 사용될 테스트 베드에서 개발되어야 한다.

테스트 데이터는 소프트웨어를 테스트하기 위해 컴퓨터 프로그램에 들어간다. 테스트 데이터는 소프트웨어가 효과적인 제어 기능을 수행하는지 테스트하기 위해 사용된다.

버그, 에러, 결점의 차이는?

에러: 실제와 기대 값의 가치
버그: 제품이 해당 고객에게 인도되기 전에 개발 환경에서 발견된 것
결점: 해당 고객에게 인도된 이후에 제품 그 자체에서 발견된 것

에러 추정과 에러 시딩(seeding)은 무엇인가?

에러 추정은 테스터가 어떤 결점이 출현할지 추정하고, 그것을 드러내기 위해 테스트를 디자인하는 기법이다.

에러 시딩은 결점의 발견과 제거의 비율을 모니터링하려는 목적으로 의도적으로 프로그램에 알려진 결점을 추가하고, 프로그램에 남아 있을 것으로 예상되는 결점수를 추정하는 것이다.

버그 라이프사이클은?

버그 라이프 사이클은 그것이 발견되고 리포트된 이후에 버그가 겪는 다양한 단계를 말한다.

생성(New or Opened)
할당(Assigned)
수정(Fixed)
테스트 완료(Tested)
종료(Closed)

효과적인 버그 리포트의 내용은 무엇인가?

프로젝트, 주제, 기술문, 요약, 발견자 (테스터의 이름), 할당자(버그의 처리 개발자의 이름), 테스트 리드 (이름), 발견 버전, 종료 버전, 발견 날짜, 종료 예상일, 실제 종료일, 중요도 (중간, 낮음, 높은, 긴급), 심각도 (1부터 5까지 범위), 상태, 버그 ID, 첨부, 실패한 테스트 케이스(해당 버그를 찾지 못한 테스트 케이스 번호)

결점 유출이란?

결점 누출은 어플리케이션 인수이후에 고객이나 최종 사용자 단에서 발생하는 것이다. 어플리케이션이 고객에게 전달된 이후에 고객이 어플리케이션을 사용함으로써 어떤 종류의 결함이라도 만났다면, 결점 유출이라고 부르는 것이다. 이러한 결점 유출은 버그 유출이라고도 부른다.

{끝}