2024-11-10

소프트웨어 테스트의 주요 목적

1. 결함을 조기에 발견하여 제품의 품질을 향상시키는 것
2. 품질 평가 및 의사 결정을 지원하는 것
3. 개발 프로세스를 개선하는 데 기여하는 것
4. 제품의 요구사항을 충족하고 정해진 표준을 준수 하는지 검증

Q 소프트웨어 개발 과정에서 '오류', '결함', '장애'의 차이점은 무엇인가요?

A.
오류, 결함, 장애는 각각 소프트웨어 품질에 영향을 미치는 중요한 개념이지만, 의미와 원인이 다릅니다.

• 오류는 사람의 실수로 인해 발생하며, 주로 요구사항 분석, 설계, 코딩 등에서 발생하는 실수들을 말합니다. 예를 들어, 요구사항을 제대로 파악하지 못하거나, 설계 과정에서 특정 요구사항을 빠뜨리는 등의 문제가 포함됩니다.
• 결함은 오류로 인해 소프트웨어 내에 잘못된 로직이나 잘못된 구현이 발생한 상태를 뜻합니다. 결함은 시스템이 원하는 기능을 제대로 수행하지 못하게 만드는 원인이 되며, 누락되거나 부정확하게 구현된 기능 등으로 인해 장애를 일으킬 가능성이 있습니다.
• 장애는 소프트웨어가 실제 실행 중에 요구사항과 다르게 작동하는 현상을 뜻합니다. 결함이 존재해도 모든 결함이 장애로 이어지는 것은 아니지만, 특정 결함은 사용 시 문제를 발생시켜 정상적인 기능 수행을 방해할 수 있습니다.

Q 개발 단계에서 발생하는 오류를 방지하기 위한 방법에는 어떤 것이 있나요?

A.
개발 단계에서 오류를 방지하기 위해 다음과 같은 방법을 활용할 수 있습니다.
첫째, 명확한 요구사항 정의입니다. 사용자의 요구사항을 정확히 이해하고, 요구사항 문서를 상세하게 작성함으로써 설계 단계에서의 오류를 줄일 수 있습니다.
둘째, 의사소통 강화입니다. 특히 개발자와 요구사항 분석가, 고객 간의 원활한 의사소통을 통해 요구사항의 누락이나 오해를 방지할 수 있습니다.
셋째, 코딩 표준 준수 및 코드 리뷰입니다. 정해진 코딩 표준을 준수하고 동료와의 코드 리뷰를 통해 사소한 타이핑 오류나 설계 반영 실수를 줄일 수 있습니다.
마지막으로, 충분한 테스트 프로세스를 갖추는 것입니다. 기능 테스트와 더불어 다양한 경로에서 테스트를 수행함으로써 잠재적 오류를 조기에 발견할 수 있습니다.

Q. 오류가 결함이나 장애로 이어지는 것을 줄이기 위한 QA 활동에는 어떤 것들이 있나요?

A.
오류가 결함이나 장애로 이어지는 것을 줄이기 위해서는 여러 가지 QA 활동이 필요합니다.
첫째, 정기적인 코드 리뷰와 정적 분석을 통해 코드 작성 단계에서 발생할 수 있는 오류를 미리 확인합니다. 코드 리뷰를 통해 동료들이 작성한 코드의 논리적 오류나 누락 사항을 발견할 수 있습니다.
둘째, 테스트 케이스 설계입니다. 다양한 시나리오와 경로를 고려한 테스트 케이스를 작성하여 결함이 다양한 조건에서 발견될 수 있도록 준비합니다.
셋째, 회귀 테스트입니다. 결함 수정 후 전체 시스템이 예상대로 작동하는지 재확인함으로써, 수정 과정에서 추가 결함이 발생하지 않도록 합니다.
마지막으로, 품질 관리 프로세스 개선을 위해 발생한 결함과 오류의 데이터를 분석하여 개선 지점을 도출하고, 프로세스를 지속적으로 최적화하는 것도 중요한 활동입니다.

Q. 소프트웨어 품질 속성 중 '신뢰성'이란 무엇이며, 이를 보장하기 위한 테스트 방법에는 어떤 것이 있나요?

A.
'신뢰성'은 소프트웨어가 규정된 조건에서 규정된 기간 동안 오동작 없이 의도된 기능을 수행하는 능력을 말합니다. 이는 사용자 입장에서 소프트웨어가 예측 가능한 방식으로 일관되게 작동하는지를 의미하며, 특히 안정성과 가용성이 중요한 시스템에서 필수적인 품질 속성입니다.
신뢰성을 보장하기 위해 내구성 테스트나 스트레스 테스트를 수행할 수 있습니다. 내구성 테스트는 소프트웨어를 오랜 시간 실행하여 장기적으로 오류가 발생하지 않는지 확인하는 것이고, 스트레스 테스트는 높은 부하나 비정상적인 환경에서 시스템이 어떻게 반응하는지를 평가하여 예기치 못한 상황에서도 안정적으로 운영되는지를 확인합니다.

 

Q. 호환성과 이식성의 차이점은 무엇인가요?

A.
호환성과 이식성은 모두 소프트웨어가 다양한 환경에서 원활하게 작동할 수 있는 능력을 평가하지만, 적용되는 환경의 범위와 조건에 차이가 있습니다.

• 호환성은 소프트웨어가 다른 시스템이나 소프트웨어와 상호 연동되어 문제없이 작동할 수 있는 능력을 말합니다. 예를 들어, 특정 웹 애플리케이션이 여러 웹 브라우저와 호환되도록 개발하는 것이 호환성을 고려한 작업입니다.
• 이식성은 소프트웨어가 다양한 플랫폼에서 실행될 수 있는 능력을 의미합니다. 이식성 높은 소프트웨어는 서로 다른 운영체제나 하드웨어 환경에서 재개발 없이 그대로 작동할 수 있습니다. 예를 들어, 윈도우와 리눅스 환경에서 모두 작동하도록 설계된 소프트웨어는 이식성이 높은 소프트웨어라 할 수 있습니다.

Q. 소프트웨어 보안성을 평가할 때 중점적으로 확인해야 할 사항은 무엇인가요?

A.
소프트웨어 보안성을 평가할 때는 정보와 데이터가 보호되는지에 중점을 두고 다음 사항들을 확인합니다.
첫째, 접근 제어로, 시스템이 권한이 없는 사용자의 접근을 차단하는지 확인합니다.
둘째, 데이터 무결성으로, 데이터가 손상되거나 불법적으로 수정되지 않도록 보호하는지 평가합니다.
셋째, 암호화로, 데이터 전송 과정에서의 보안을 보장하기 위해 민감한 정보를 암호화하여 전송하는지 확인합니다.
마지막으로, 침입 탐지 및 대응입니다. 외부 공격에 대한 대응 능력을 갖추고 있는지, 시스템에 침입 시도를 감지하고 알림 및 차단 기능이 있는지 평가합니다. 이를 통해 소프트웨어가 데이터 유출 및 무단 접근으로부터 안전하게 보호될 수 있도록 보안성을 확인할 수 있습니다.

Q. 테스트 설계 기법에는 어떤 것이 있으며, 각각의 특징은 무엇인가요?

A.
테스트 설계 기법은 테스트 목적과 방법에 따라 정적 테스트와 동적 테스트로 나뉩니다.

• 정적 테스트는 코드 실행 없이 리뷰나 정적 분석을 통해 결함을 발견하는 기법으로, 코드 리뷰와 같은 문서 검토와 코드의 정적 분석 도구를 사용하여 코드 내 논리적 오류나 잠재적 문제를 확인할 수 있습니다.
• 동적 테스트는 소프트웨어를 실제로 실행하여 결함을 발견하는 기법으로, 실행 중에 소프트웨어의 동작을 관찰합니다. 여기에는 요구사항을 기준으로 테스트하는 명세 기반 테스트, 소프트웨어 구조를 기반으로 테스트하는 구조 기반 테스트, 그리고 과거 경험을 활용하는 경험 기반 테스트가 포함됩니다. 각 기법은 테스트 상황에 맞춰 사용되며, 결함을 효과적으로 검출하기 위해 복합적으로 활용될 수 있습니다.

Q. 시스템 테스트와 인수 테스트는 어떻게 다른가요?

A.
시스템 테스트와 인수 테스트는 모두 소프트웨어의 전체 기능을 평가하지만, 목적과 관점이 다릅니다.

• 시스템 테스트는 전체 시스템이 통합되어 요구사항에 맞게 작동하는지를 확인하는 단계입니다. 이 단계에서는 기능적 요구사항뿐만 아니라 성능, 보안, 호환성 등 비기능적 요구사항도 테스트하여 시스템의 전반적인 품질을 평가합니다.
• 인수 테스트는 최종 사용자가 시스템이 실제 요구사항을 충족하는지 확인하는 최종 단계로, 소프트웨어의 비즈니스 요구사항 충족 여부를 중점적으로 평가합니다. 인수 테스트는 실제 사용자나 고객의 입장에서 시스템을 평가하는 것이 특징이며, 테스트 결과에 따라 시스템의 승인 여부가 결정됩니다.

Q. 컴포넌트/단위 테스트에 적용되는 FIRST 원칙에 대해 설명해 주세요.

A.
컴포넌트/단위 테스트에서는 FIRST 원칙을 따라 테스트의 효율성을 높입니다. FIRST는 Fast, Isolated, Repeatable, Self-Validating, Timely의 약자로, 각각의 의미는 다음과 같습니다.

• Fast: 테스트는 빠르게 실행되어야 합니다. 테스트가 빠르면 코드 변경 시마다 자주 실행하여 결함을 빠르게 발견할 수 있습니다.
• Isolated: 각 테스트는 독립적으로 실행되어야 합니다. 이는 테스트 간에 의존성을 없애, 다른 테스트의 결과에 영향을 받지 않도록 합니다.
• Repeatable: 테스트는 여러 환경에서도 일관된 결과를 반환해야 합니다. 동일한 입력에 대해 항상 동일한 결과가 나오는 것이 중요합니다.
• Self-Validating: 테스트는 스스로 검증할 수 있어야 하며, 통과/실패 여부를 명확하게 보여주어야 합니다.
• Timely: 테스트는 코드 작성 직후에 바로 실행할 수 있도록 작성되어야 합니다. 이를 통해 개발 주기 내에서 테스트가 즉시 실행되어 결함을 빠르게 파악할 수 있습니다.

이 원칙들은 컴포넌트/단위 테스트의 신뢰성 및 유지보수성을 높이고, 테스트의 가치를 극대화하기 위한 기본 원칙입니다.

통합 테스트에서 점진적 통합 방식에는 어떤 방법들이 있으며, 각 방식의 장단점은 무엇인가요?

A4.
통합 테스트의 점진적 통합 방식에는 상향식 통합과 하향식 통합이 있습니다.

• 상향식 통합: 하위 모듈부터 테스트하여 상위 모듈과 통합해 나가는 방식입니다. 이 방식의 장점은 하위 모듈이 충분히 테스트된 상태에서 상위 모듈과의 통합을 진행할 수 있어 하위 모듈에 대한 신뢰도가 높다는 점입니다. 또한, 테스트 스텁을 제공할 비용이 들지 않습니다. 반면, 최상위 모듈의 결함을 발견하는 데 시간이 걸릴 수 있습니다.
• 하향식 통합: 최상위 모듈부터 하위 모듈을 순차적으로 통합해 나가는 방식입니다. 최상위 모듈부터 테스트하기 때문에 전반적인 아키텍처와 주요 기능을 초기에 검증할 수 있는 장점이 있습니다. 그러나 테스트 스텁이 필요하며, 리그레션 테스트가 요구됩니다.
• 샌드위치 통합: 상향식과 하향식을 혼합하여, 중간 레벨에서 상위와 하위 모듈을 동시에 통합하는 방식입니다. 상위와 하위 모듈의 동시 통합이 가능해 테스트 기간을 단축할 수 있지만, 관리가 복잡할 수 있습니다.

Q. 마이어스 원칙에서 '개발자와 무관한 그룹이 테스트를 수행해야 한다'고 하는 이유는 무엇인가요?

A.
마이어스 원칙에서 '개발자와 무관한 그룹이 테스트를 수행해야 한다'고 하는 이유는 테스트의 객관성과 공정성을 확보하기 위해서입니다. 개발자는 본인이 만든 코드에 대한 선입견이나 친숙함으로 인해 일부 결함을 놓칠 수 있습니다. 반면, 개발과 무관한 그룹이 테스트를 진행하면 보다 중립적인 시각에서 결함을 찾을 가능성이 높아지고, 품질 관리의 독립성이 보장되어 소프트웨어의 신뢰성을 높일 수 있습니다. 이를 통해 보다 철저하고 효과적인 결함 검출이 가능해집니다.

Q. 마이어스 원칙에서 '결함이 발견되지 않으리라는 가정을 하지 말라'는 원칙은 왜 중요할까요?

A.
'결함이 발견되지 않으리라는 가정을 하지 말라'는 원칙은 테스트 계획을 수립할 때 리스크 관리의 중요성을 강조합니다. 결함이 없을 것이라는 가정하에 테스트를 진행하면 실제 결함이 있을 경우 쉽게 간과될 수 있으며, 이로 인해 심각한 오류가 남아 있을 위험이 큽니다. 따라서 오류 가능성을 고려하여 철저히 테스트하고, 예상하지 못한 결함까지 검출할 수 있는 테스트 케이스를 마련해야만 시스템의 안정성과 신뢰성을 확보할 수 있습니다.

Q. '어떤 부분에 결함이 남을 확률은 그 부분에서 이미 발견된 결함의 수와 비례한다'는 원칙은 어떤 테스트 방법론에 기초하나요?

A.
이 원칙은 **파레토 법칙(80/20 법칙)**에 기초합니다. 이는 전체 결함의 약 80%가 특정 20%의 코드나 기능에서 발생한다는 개념으로, 문제 발생 빈도가 높은 영역에 집중 테스트를 진행하는 것이 효과적이라는 뜻입니다. 따라서 이미 결함이 많이 발견된 부분을 더욱 면밀히 검사하여 추가적인 오류를 방지하고, 효율적으로 품질을 개선할 수 있습니다.

Q. 에자일 모델에서 테스트는 어떻게 수행되나요?

A.
에자일 모델에서는 반복적이고 점진적인 개발을 강조합니다. 개발과 테스트는 짧은 주기의 스프린트(Sprint)마다 반복적으로 수행됩니다. 각 스프린트가 끝날 때마다 개발된 기능을 테스트하고, 필요시 수정하며 점진적으로 개선해 나가는 방식입니다. 이 모델에서는 테스트가 개발과 동시에 병행되며, 변경사항에 맞춰 지속적으로 테스트를 진행하여 고객의 요구사항에 맞는 소프트웨어 품질을 빠르게 확보하는 데 중점을 둡니다.