SW Test 쉽게 이야기하기

출처: Elf-Moondance of Pixabay

 

 소프트웨어를 만들고 나서 소프트웨어가 잘 돌아가는지 테스트가 필요합니다.

사용자에겐 최고 상태의 SW를 전달할 수 있어야하기 때문이죠.

 

Q. 테스트 어떤 걸까요?

 

 프로그램에 있는 결함을 찾아내거나 이 프로그램이 요구사항을 만족시키는지 그리고 동작은 잘하는지 확인을 해보는 것입니다.

테스트를 하기 전에 뭐 어떤 걸 테스트할 건지 유형을 분류해두는 것도 중요합니다.

 

Q. 테스트를 하면 뭐가 좋을까?

 

 프로그램 실행 전에 미리 오류를 조기에 발견해서 대응할 수 있고 제품이 잘 동작한다는 신뢰를 얻음으로서 신뢰도 역시 올라갑니다. 그리고 비용이랑 노력을 최소화할 수 있습니다.

 

Q. 테스트의 기본 원리는 어떻게 되는 건가요?

 

- 결합집중: 소프트웨어를 테스트해보니 결함이 나는 곳에서 계속 결함이 나더라라는 것입니다. 고질병처럼 아픈 곳에서 늘 아픈 거죠. 이걸 파레토 법칙(Pareto Principle)이라고 하기도 합니다.

 

- 정황 의존:소프트웨어 특징, 테스트의 할 때의 환경, 테스터의 역량과 같은 테스트 정황에 의존합니다.

 

- 오류-부재의 궤변: 테스트를 해보니 오류 없이 완벽하게 동작한다고 해도 사용자 요구사항을 만족하지 못하면 품질이 좋다고 말할 수 없습니다.

 

- 살충제 패러독스: 동일한 테스트 케이스를 반복적으로 수행하면 새로운 결함을 찾을 수 없어 테스트 케이스를 정기적으로 리뷰하거나 개선해야 합니다.

 

- 불완전: 모든 케이스를 테스트할 수는 없습니다.

 

- 결함 발견을 위한 활동: 소프트웨어 결함이 발견되지 않는다고 하더라도 결함이 완전히 없어졌다고 할 수 없습니다.

 

Q. 테스트 방법도 분류하나요?

 

 테스트의 방법도 분류합니다. 우선 정적 테스트와 동적 테스트로 나눌 수 있습니다.

이름만 들어도 알 수 있듯이 정적 테스트는 가만히 있는 것을 이야기합니다. 프로그램을 실행하지 않고 테스트하는 것이죠.

그럼 어떻게 테스트를 한다는 걸까? 

그동안 작성해온 명세서, 소스코드를 가지고 분석하겠다는 것입니다.

아무래도 프로그램을 직접 실행시키지는 않으니 동적 테스트보다는 훨씬 저렴한 편이긴 합니다.

 

 동적 테스트는 프로그램을 실제로 실행해서 오류를 찾는 테스트를 말합니다. 그리고 이 테스트는 소프트웨어 개발 전체 단계에서 수행하게 되죠.

 

 테스트 시각에 따라도 분류할 수 있는 데 검증 테스트와 확인 테스트로 나눌 수 있습니다.

검증 테스트란 이거 요구사항에 맞게 잘 만들어진 거야?라는 관점으로 테스트하는 것이고

확인 테스트란 사용자의 입장에서 아 이게 잘 만들어졌다! 아니다! 를 테스트하는 것입니다.

 

 테스트 목적에 따라 분류 역시 가능합니다. 

테스트의 초점을 뭐로 맞춰서 하겠냐?라는 것입니다.

회복, 안전, 강도, 성능, 구조, 회귀, 병행이 있으며

 

회복은 일부로 결함을 만든 다음에 제대로 복구하나? 확인하는 것입니다.

 

안전은 외부에서 불법으로 침입하려고 할 때 얼마나 잘 막냐?라는 것을 확인하는 것입니다.

 

강도는 정보량이나 빈도를 과부하해서 과부하 시에도 소프트웨어가 정상적으로 잘 돌아가나 보는 것입니다.

 

성능은 소프트웨어의 성능과 효율성을 확인하고

 

구조란 내부 소스 코드가 얼마나 잘 짜여있나를 확인합니다.

 

회귀란 소프트웨어를 변경했을 때 수정코드에 결함이 있나 없나를 확인합니다.

 

병행이란 변경된 소프트웨어와 기존의 소프트웨어에 동일한 데이터를 입력해서 비교해보는 것을 말합니다.

 

Q. 그럼 테스트를 도대체 어떤 상황에 맞춰서 해야 할까요?

 

 사용자의 요구사항에 대해 명세를 빠짐없이 테스트를 구현하고 있는지 확인할 수 있는 명세 기반 테스트 방법이 있습니다.

 소프트웨어 내부의 논리적인 흐름에 따라서 테스트 케이스를 작성해보는 구조 기반 테스트 방법이 있고 테스터의 경험을 정말 중시하는 경험 기반 테스트 방법도 있습니다.  상황에 맞춰 3가지 방법 중 선택해서 하는 것이 좋다고 합니다.

 

Q. 테스트의 절차는 어떻게 되나요?

 

 테스트는 우선 개발 결과 나온 것을 보고 테스트를 분석 및 디자인을 하게 됩니다. 그 후에 테스트 케이스 및 시나리오를 작성하고 작성된 시나리오에 맞춰 테스트를 수행합니다. 그리고 수행된 결과를 평가하고 리포팅하는 순서대로 진행됩니다.

 

 테스트 분석 및 디자인 단계에서 테스트의 목적 및 원칙을 검토하고 요구사항을 분석하게 되며 테스트를 할 수 있는 환경을 만들어 주게 됩니다.

 

 테스트 케이스 및 시나리오 작성 단계에서는 테스트 케이스를 작성하게 되는 데 이 테스트 케이스는 설계부터 작성이 이루어지기 때문에 굉장히 중요한 일입니다.

 

 테스트 수행 단계에서는 초기 데이터를 로딩하고 테스트를 수행하게 됩니다.

 

 테스트 결과 평가 단계에서는 결과를 정리하고 프로세스 리뷰를 합니다. 그리고 그에 따른 리포팅을 하게 되죠.

 

Q. 테스트 케이스란 뭔가요?

 

 구현된 소프트웨어가 사용자의 요구대로 잘 작성되었는가? 이것을 확인하기 위해서 설계된 입력값, 실행결과, 기대 결과 등으로 이루어진 테스트 항목의 명세서를 테스트 케이스라고 합니다.

 

 테스트 시나리오는 테스트 수행을 위한 여러 테스트 케이스의 집합, 동작 순서를 명세화한 문서이며 설계 단계에서 중요시되던 요구사항이나 사전 조건과 같은 구체적인 항목을 빠짐없이 테스트할 수 있습니다.

 이런 테스트 시나리오를 작성할 때는 시스템별, 모듈별, 항목별 시나리오를 분리하여 작성해야 하며, 고객의 요구사항과 설계 문서 등을 토대로 작성할 수 있어야 합니다.

 테스트 항목으로는 식별자 번호, 순서 번호, 테스터 데이터, 테스트 케이스, 예상 결과, 확인 등의 항목이 들어갑니다.

 

Q. 테스트는 다 수동으로 사람이 직접 하는 걸까요?

 

 테스트는 반복적으로 동일한 내용을 확인해서 에러가 나는지 확인하기 위함으로 자동화 도구가 있습니다.

실제로 테스트를 진행할 때에는 휴먼 에러 즉, 사람이기에 생기는 에러가 생겨 정확한 결과가 나오지 않을 수도 있습니다. 이 문제를 보완하고자 자동으로 진행합니다.

 

 테스트 자동화 도구는 반복적으로 진행되는 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용하니 보다 쉽고 효율적으로 테스트를 수행할 수 있더라~!라는 것입니다.

하지만 이 자동화 도구도 모든 과정을 전부 자동화할 수는 없고 용도에 맞춰 적절한 도구를 사용해야 합니다.

또한, 테스트 초기에 엔지니어가 투입되어야 하는데 그 이유는 늦어지면 늦어질수록 이 제품에 대한 이해도가 떨어져 제대로 된 테스트를 할 수 없기 때문입니다.

 

Q. 결함을 찾으려고 테스트하는 건데 결함이라는 게 뭘까요?

 

 결함이란 에러가 났다? 그러면 결함입니다.

조금 더 설명하면 제품을 만들 때 동작하지 않는 원인이라던가 개발자가 만든 것과 다른 결과가 나오는 경우 이런 것들을 결함이라고 합니다.

 

 결함에도 종류가 있는 데 시스템 결함, 기능 결함, GUI 오류, 문서 결함 이렇게 4가지입니다.

 

시스템 결함이란 시스템이 다운되거나 동작하다가 멈추는 시스템적인 문제를 이야기합니다.

 

기능 결함이란 사용자의 요구사항이 제대로 반영되지 않은 경우를 이야기합니다.

 

GUI 오류란 표시 방법이라던가 메시지, 이상한 모양의 버튼과 같은 GUI적인 문제를 이야기합니다.

 

문서 결함이란 매뉴얼과 실제품이 다른 경우 개발자와 사용자의 의사소통 및 명세 목록이 일치하지 않는 경우를 이야기합니다.