소프트웨어 테스트 기초

소프트웨어 테스트는 다양한 분야와 산업에서 이루어집니다. 프로젝트마다 새로운 과제가 생깁니다. 테스트를 시작하기 전에 고객의 관점과 해당 분야를 이해해야 합니다. 프로젝트에 따라 다른 테스트 방법이 필요할 수도 있습니다. 따라서 기초를 제대로 이해하는 것이 좋은 결과를 얻기 위한 첫 조건입니다.

소프트웨어 테스트는 왜 필요한가요?

개발자는 의도하지 않게 오류, 결함 또는 버그를 만들 수 있습니다. 현대의 소프트웨어는 복잡하기 때문에 잘못 이해한 부분이 논리나 코드의 오류로 이어질 수 있습니다.

테스트는 문제를 찾아 수정할 수 있게 하고 소프트웨어 품질을 높입니다. 목표는 버그가 없는 애플리케이션을 개발해 제공하는 것입니다. 회사가 고객을 위해 소프트웨어를 개발하기로 하면 법률, 계약, 산업별 요구 사항이 작업에 영향을 줍니다. 품질을 중시하는 회사는 테스트를 모범 실무로 삼습니다.

어느 정도의 테스트가 충분한지 판단하기는 어렵습니다. 꼼꼼하게 계획하고 테스트 케이스를 잘 설계하면 높은 품질로 납품할 수 있습니다.

누가 소프트웨어를 테스트하나요?

누가 테스트를 해야 할까요? 개발자는 코드를 넘기기 전에 여러 번 확인하는 경우가 많습니다. 그래도 자기 실수를 알아보기는 어렵기 때문에 결함이 남을 수 있습니다.

테스트 담당자는 고객의 관점에서 편견 없이 제품을 바라보고 명세와 요구 사항에 집중합니다. 이를 통해 개발자가 놓친 부분을 발견할 수 있습니다. 따라서 테스트는 항상 개발과 독립적인 담당자가 수행하는 것이 바람직합니다.

개발팀과 테스트팀을 분리하는 데에는 단점도 있습니다. 의사소통에 문제가 생길 수 있습니다. 개발자가 품질을 테스트팀의 책임으로만 생각하면 코드 검토를 소홀히 할 수 있고, 그 결과 테스트팀의 업무가 늘어납니다.

개발자가 서로의 작업을 테스트하기도 합니다. 이를 동료 테스트 또는 버디 테스팅이라고 합니다. 모든 개발팀에는 테스트 전담 인력이 있어야 하며, 프로젝트에는 보통 한 개 이상의 전담 테스트팀이 있습니다. 어떤 회사는 사용성, 성능, 보안 등 테스트 유형에 따라 별도 팀을 둡니다. 다른 회사는 전문 업체, 독립 테스트 담당자 또는 컨설턴트에게 테스트를 맡깁니다.

실제로 무엇을 테스트해야 하나요?

프로젝트의 요구 사항과 소프트웨어가 실제로 쓰이는 환경을 이해하세요. 그래야 무엇을 테스트할지 정하고 적절한 테스트 전략을 세울 수 있습니다.

전체 크기 도표 열기 ↗

실제로 무엇을 테스트해야 하나요?

소프트웨어 테스트는 언제 하나요?

테스트를 일찍 시작하면 개발자가 기한을 지키는 데 도움이 되고 시간, 비용, 노력을 아낄 수 있습니다. 개발 후반에 발견한 결함은 수정 비용이 많이 들 수 있습니다. 개발을 단계로 나누고 다음 단계로 넘어가기 전에 각 단계의 결과를 테스트하세요. 이는 제때 납품하고 더 좋은 결과를 얻는 데 도움이 됩니다. 각 모듈을 명세에 따라 미리 독립적으로 테스트하면 통합도 쉬워집니다.

얼마나 자주 테스트해야 하나요?

개발과 함께 테스트를 진행하고 초기 단계에서 가능한 한 많은 결함을 찾아보세요. 테스트 빈도는 필요한 품질 수준에 따라 달라집니다. 문제를 일찍 발견하면 변경하기 쉽고 비용이 적게 들 때 설계를 조정할 수 있습니다. 후반에는 큰 변경이 어렵고 비용도 많이 듭니다.

전체 크기 도표 열기 ↗

얼마나 자주 테스트해야 하나요?

소프트웨어 테스트 표준이란 무엇인가요?

테스트 표준은 고객과 소프트웨어를 만드는 기업 모두에게 중요합니다. 고객은 비용을 들이는 만큼 소프트웨어의 품질이 구매할 만한 수준인지 확신하고 싶어 합니다.

평판이 좋은 회사는 공개적으로 인정된 표준을 바탕으로 제품 품질을 관리합니다. 표준을 준수하면 제품과 예상 동작에 대한 신뢰가 높아집니다. 고객은 필요한 품질 기준에 맞는 소프트웨어를 구매한다는 확신을 얻을 수 있습니다.

소프트웨어를 만드는 쪽에서는 표준이 최종 제품을 개선하는 데 도움이 됩니다. 회사가 표준을 한 번 선택하면 이후 프로젝트에서 처음부터 다시 시작할 필요 없이 이를 토대로 삼을 수 있습니다. 많은 테스트 표준이 품질 평가와 테스트 효과 개선에 도움이 됩니다. 다만 어떤 한 표준도 소프트웨어 테스트의 모든 측면을 다루지는 않습니다.

더 넓은 요구 사항의 일부로 테스트를 다루는 표준과 테스트에 특화된 표준은 모두 실무 지침으로 활용할 수 있습니다.

소프트웨어의 테스트 가능성이란 무엇인가요?

테스트 가능성은 소프트웨어 시스템을 얼마나 쉽게 테스트할 수 있는지를 나타냅니다. 일찍 평가해 테스트에 필요한 자원을 추정하세요. 테스트는 결함을 드러냅니다. 테스트 가능성을 평가하면 결함이 발견되지 않고 남을 수 있는 부분을 찾는 데 도움이 됩니다. 테스트 가능성이 높으면 테스트하기 쉽고, 낮으면 더 많은 노력이 필요합니다. 다음 요소를 살펴보세요.

1. 제어 가능성이 있으면 테스트 과정을 제어하고 최적화할 수 있습니다.
2. 관찰 가능성을 확보하려면 동작과 결과에 영향을 미치는 요소가 보여야 테스트할 수 있습니다.
3. 가용성은 테스트를 위해 시스템에 접근할 수 있다는 뜻입니다.
4. 일관된 설계, 이해하기 쉬운 기능, 간단한 코딩 방식은 테스트의 복잡성을 낮춥니다. 복잡한 소프트웨어일수록 테스트가 어렵습니다.
5. 안정성이 있으면 테스트하기 쉽습니다. 설계가 자주 바뀌면 테스트에 지장이 생길 수 있습니다.
6. 테스트 효율은 소프트웨어에 대해 확보한 정보에 크게 좌우됩니다.

테스트 가능성과 결함 사이의 관계를 기억하세요.

1. 테스트 가능성이 높을수록 더 나은 테스트를 수행하고 결함을 줄이는 데 도움이 됩니다.
2. 테스트 가능성이 낮으면 테스트 품질이 떨어지고 시스템에 더 많은 결함이 남을 수 있습니다.

소프트웨어 검증과 타당성 확인

검증과 타당성 확인은 서로 다른 분석입니다. 타당성 확인은 올바른 시스템을 만들고 있는지 묻습니다. 고객의 요구 사항을 충족합니까?

검증은 시스템을 올바른 방식으로 만들고 있는지 묻습니다. 기술적 품질과 필요한 표준의 준수에 초점을 맞춥니다.

타당성 확인은 명세가 고객의 필요에 맞는지 살핍니다. 검증은 개발 작업이 조직의 소프트웨어 품질 표준과 엔지니어링 관행을 따르는지 확인합니다.

전체 크기 도표 열기 ↗

소프트웨어 검증과 타당성 확인

검증을 모든 개발 단계에서 하고 타당성 확인을 처음과 끝, 즉 요구 사항 분석과 인수 테스트에 집중하는 접근 방식도 있습니다. 그러나 실제로 따르기는 어렵습니다. 시작할 때 고객의 모든 요구 사항을 파악하기 어렵고, 개발이 시작된 뒤에도 요구가 자주 바뀝니다. 개발팀 자체가 변경을 요청하기도 합니다. 따라서 개발 전 과정에서 검증과 타당성 확인을 모두 실시하세요.

테스트 담당자는 검증과 타당성 확인(V&V)으로 소프트웨어 품질의 여러 측면을 살핍니다.

소프트웨어 테스트와 디버깅

테스트와 디버깅은 목적이 다릅니다. 테스트는 결함을 찾아냅니다. 디버깅은 결함을 발견한 후에 진행하며 그 원인을 제거합니다.

테스트 담당자가 결함을 보고하면 개발자는 근본 원인을 조사합니다. 관련 모듈을 살펴보고 코드에서 문제를 찾아 수정합니다. 디버깅은 원인을 단계적으로 파악하고 해결하는 과정입니다.

수정하기 전에 결함이 생겼을 가능성이 있는 원인을 파악하세요. 정보가 부족한 채 디버깅하면 연결된 모듈에 또 다른 결함이 생길 수 있습니다. 계획 없이 이것저것 바꾸는 일은 피하세요. 수정 후에는 모듈을 테스트 담당자에게 돌려보내 철저히 테스트하도록 합니다.

1. 테스트는 결함을 드러냅니다. 디버깅은 그 원인을 찾아 바로잡습니다.
2. 테스트는 개발의 중요한 부분입니다. 디버깅은 테스트에서 발견된 결함에 대응합니다.
3. 테스트는 개발 초기부터 시작합니다. 디버깅은 결함이 보고되면 시작합니다.
4. 테스트에는 검증과 타당성 확인(V&V)이 포함됩니다. 디버깅은 결함의 원인을 조사하고 바로잡습니다.

결함이란 무엇인가요?

결함은 소프트웨어 요구 사항 명세에서 벗어난 상태입니다. 코드나 설계에 결함이 생길 수 있으며, 프로그램 실행 중 잘못된 출력으로 이어질 수 있습니다.

1. 결함이 많은 코드를 흔히 버그가 많은 코드라고 합니다.
2. 버그 보고서는 결함의 성격을 설명합니다.
3. 버그 추적 도구는 시스템의 결함을 추적하는 데 쓰입니다.
4. 한 테스트 기법은 코드에 의도적으로 결함을 넣습니다. 결과를 관찰해 시스템이 해당 문제에 예상대로 반응하는지 확인합니다.

전체 크기 도표 열기 ↗

결함이란 무엇인가요?

심각도와 우선순위는 무엇인가요?

심각도는 결함이 시스템에 미치는 영향을 나타냅니다. 이 영향은 다음과 같이 분류합니다.

1. 치명적 결함은 시스템 장애나 데이터 손상으로 애플리케이션이 정상적으로 동작하지 못하게 합니다. 사용자는 더 진행할 수 없습니다.
2. 중대한 결함은 시스템 장애를 일으킬 수 있지만, 사용자가 추가 교육 없이 다른 방법으로 원하는 결과를 얻을 수 있습니다. 치명적 결함보다는 영향이 작습니다.
3. 중간 정도의 결함이 있으면 시스템은 계속 동작하지만 잘못되거나 서로 모순된 결과를 냅니다.
4. 경미한 결함은 시스템 장애를 일으키거나 사용성에 영향을 주지 않으며 쉽게 수정할 수 있습니다.
5. 외관상 결함은 시스템의 모양에 영향을 줍니다.

결함 보고서에는 심각도와 함께 우선순위를 기록합니다. 우선순위는 개발자가 어떤 순서로 결함을 해결할지 알려 줍니다.

1. 우선순위가 낮은 결함은 더 높은 우선순위의 결함을 처리한 뒤 해결합니다. 즉각적인 대응은 필요하지 않습니다.
2. 우선순위가 중간인 결함은 더 높은 우선순위의 결함을 처리한 뒤 신속히 해결합니다.
3. 우선순위가 높은 결함은 즉시 살펴보고 가능한 한 빨리 해결합니다.

보고된 심각도와 우선순위를 함께 고려해 얼마나 긴급하게 대응할지 판단하세요.

전체 크기 도표 열기 ↗

심각도와 우선순위는 무엇인가요?

1. 우선순위와 심각도가 모두 높으면 기본 기능의 문제로 사용자가 시스템을 쓰지 못합니다. 즉시 해결하세요.
2. 우선순위가 높고 심각도가 낮은 예는 회사 이름의 오타나 로고 문제입니다. 기능에 미치는 영향은 작아도 즉시 수정해야 합니다.
3. 심각도가 높고 우선순위가 낮은 경우는 사용자가 당장 필요로 하지 않는 모듈에 중대한 결함이 있는 상황입니다. 수정을 미룰 수 있습니다.
4. 우선순위와 심각도가 모두 낮은 경우로는 기능에 영향을 주지 않는 외관상 결함이 있습니다. 일반적으로 이런 결함을 가장 나중에 수정합니다.