Career Skills_P3 - Ch28. 테스트와 QA 기초

대부분의 개발자가 실제로 어떻게 테스트가 이루어지는지 아예 모른다라는 사실과
테스터 업무 경험은 소프트웨어 개발자로 일하는 데에도 큰 도움이 된다는 사실을 깨달았다.
테스트의 기초를 모르면 '의도한 대로 바르게 작동한다'는 말이 정확히 어떤 뜻인지 제대로 이해하기 어렵다.

 

| 테스트의 핵심 목표 |

테스트의 핵심 목표는 위험 부담을 줄이는 것이다. 소프트웨어를 사용할 고객에게 가장 큰 영향을 미칠 문제를 사전에 찾아 제거함으로써 위험을 감소 시키는 것이 테스트의 목표다. 의도대로 작동하지 않는 일이 얼마나 자주 발생하는지, 혹은 그 문제가 얼마나 심각한 수준으로 발생하는지가 고객에게 영향을 미친다.

버그와 결함을 전부 찾아내거나 모든 입력 테스트해보는 건 불가능하다.

소프트웨어 테스트가 집중하는 핵심적인 목표는 소프트웨어를 사용하는 고객에게 크고 부정적인 영향을 미칠 만한 위험 요소를 감소시키는 것이다.

 

 

| 일반적인 테스트 유형 |

테스트와 QA(Quality Assurance)의 세계는 엄청나게 넓고 다양한 방법이 있으며 끊임없이 변화한다. 

 

블랙박스 테스트(Black-Box Test)

소프트웨어 내부가 보이지 않는 검은 상자라고 생각하고 진행하는 테스트이다. 입력과 출력만 신경쓰면 된다. 편견이 개입할 여지가 적다는 장점 때문에 대부분의 테스트가 차용하는 방식이다. 

 

화이트박스 테스트(White-Box Tet)

시스템의 내부 구조를 이해하고 소스 코드에 접근할 권한이 있어야만 제대로 해볼 수 있다.

 

인수 테스트(Acceptance Test)

소프트웨어가 고객의 요구사항이나 기대에 맞게 제작되었는지 확인하는 테스트, 시스템을 전체적으로 점검하는 테스트다.

 

자동 테스트

저자는 테스트 실행이나 결과 검증이 자동으로 이루어지는 모든 테스트를 자동 테스트라고 본다.

 

회귀 테스트(Regression Test)

시스템이 과거에 작동했던 방식 그대로 작동하고 있는지 확인하는 테스트다

 

기능 테스트(Functional Test)

시스템의 기능을 대상으로 진행하는 테스트를 폭넓게 아우르는 용어의 의미도 있다. 시스템이 기능적 측면에서 해야 할 일을 잘하고 있는지에 초점을 맞추어 진행하는 테스트다.

 

 탐색적 테스트(Exploratory Test)

저자는 탐색적 테스트가 합리적인 테스트 케이스로는 알아내기 어려웠을 버그를 찾아낸다는 장점은 인정하지만 선호하지는 않는다고 한다.

 

그외 테스트 유형

부하 테스트(Load Test) : 과부하 상태에서 애플리케이션 이 어떤 성능을 보이는지 확인

성능 테스트(Perfomance Test) : 특정 시나리오에서 애플리케이션의 성능을 확인

회복 테스트(Recovery Test) : 에러가 나거나 하드웨어에 문제가 생겼을 때 어떻게 회복하는지 확인 

보안 테스트(Security Test) : 시스템 보안

스트레스 테스트(Stress Test)

사용성 테스트(Usablility Test)

 

| 테스트 절차 |

테스트는 보통 테스트 계획을 셍는 것으로 시작한다.

• 어떤 방식으로 테스트할 것인가?
• 테스트 전략은 무엇인가?
• 어떤 유형의 테스트를 할 것인가?
• 어떤 기능을 테스트할 것인가?
• 일정은 어떻게 되는가?

위의 질문에 대한 답이 테스트 계획서에 있어야 한다.

그 다음은 시스템의 요구사항 혹은 기능을 기반으로 테스트를 설계하는 단계다. 실행 가능한 테스트 케이스 목록, 텟스트 싫행 조건의 유형, 그러한 테스트 실행에 필요한 사항을 정리한다. 테스트를 만들고 실행하는 건 다음 단계다.

테스트 실행 결과는 녹화하고 평가하며, 버그나 결함은 보통 버그 추적 시스템에 기록된다. 버그는 우선순위를 매겨서 개발자에게 보내 수정하게 한다. 수정된 버그는 다시 테스트한다. 소프트웨어가 배포용 코드의 품질 기준에 부합하는 수준에 이를 때까지 이 과정은 반복된다.

 

| 애자일 팀의 테스트 방식 |

표준 테스트 절차를 애자일 소프트웨어 개발 생명주기에 맞게 변형해서 쓸 생각을 못하고 표준 테스트 절차를 엄격하게 지키려고 애쓰다가 아예 포기하는 팀이 너무 많다. 두 방법 다 문제가 있다. 코드를 작성하기 전에 테스트 케이스와 테스트 시나리오부터 개발하고 애자일 방식으로 소프트웨어 개발할 때처럼 테스트 절차를 더 작은 단계로 나누어서 줄여야 한다. 테스트 단계를  더 잘게 나누어서 피드백을 더 자주 받아야 한다는 뜻이다.  각 기능을 미니 프로젝트라고 생각하고 코드 작성 전부터 미니어처 버전의 테스트를 실행하라.

 

| 테스트, 당신 그리고 개발자 |

개발자라면 자신이 만든 코드의 품질에 그 누구보다 신경을 써야 한다. 자신의 버그는 자신이 직접 찾아서 고치겠다는 책임감을 지녀야 한다.  이유는 간단하다. 버그가 늦게 발견될 수록 고치는데 더 많은 비용이 들기 때문이다.

이렇게 생각해보자. 개발자가 자신이 만든 코드를 QA에게 넘기기 전에 직접 테스트해서 찾아낸 버그는 한 시간 정도만 들이면 수정할 수 있다. 하지만 그 버그를 스스로 찾아서 고치지 않을 경우 다음과 같은 절차를 거친다.

• 테스터는 버그를 찾기 위해 테스트를 실행한 후 발견한 버그가 유효한지 확인하기 위해 테스트를 재실행한다.
• 확인된 버그는 버그 추적 소프트웨어에 저장한다.
• 개발팀 관리자는 해당 버그가 수정해야 할 정도로 심각한 것인지 확인한 후 개발자에게 할당한다.
• 개발자는 버그를 재현해본다. 하지만 자신의 컴퓨터에서는 이상 없이 작동한다.
• 테스터가 버그를 재현해서 버그 보고서에 더 자세한 내용을 기술한다.
• 개발자는 드디어 버그 재현에 성공해서 버그를 수정한다.
• 개발자는 버그 보고서에 수정한 내용을 업데이트한다.
• 테스터는 버그가 제대로 고쳐졌는지 다시 확인하고 그 버그가 해결되었다고 표시한다.

얼마나 많은 사람이 긴 시간을 들여야 하는지 보이는가? 코드를 체크인하기 전에 10분 정도 시간을 내서 코드를 테스트해보는 게 좋다는 말이다. 그렇게 한다고 모든 버그를 찾을 수 있는 건 아니다. 하지만 10%만 찾아낸다고 해도 꽤 많은 시간이 절약된다.