소프트웨어를 테스트하는 동안 준수해야 할 테스팅 가이드라인
● 개발 팀은 소프트웨어 테스트를 피해야 한다.
소프트웨어를 테스트하는 것은 개발 팀이 피해야 하는데, 테스트는 항상 테스팅 팀에 의해 수행되어야 한다. 개발 팀은 소프트웨어를 직접 테스트해서는 안 된다. 이는 개발자가 소프트웨어를 구축하는 데 몇 시간을 투자한 후, 무의식적으로 소프트웨어에 대해 잘 알고 있다 생각되어 시스템의 결함을 간과할 수 있기 때문이다. 테스터는 제품에 대해 파괴적인 접근을 가져야 한다. 개발자는 단위 테스트와 통합 테스트를 수행할 수 있지만, 소프트웨어 테스트는 테스팅 팀에 의해 수행되어야 한다.
● 소프트웨어에 버그가 100% 없을 수는 없다.
테스트를 통해 소프트웨어에 버그가 100% 없다는 것을 증명할 수는 없다. 다시 말해, 수많은 테스트 케이스를 만들어도 소프트웨어에 오류가 없다는 것을 증명할 방법이 없다.
● 가능한 한 빨리 시작한다.
테스트는 항상 요구사항 분석 프로세스와 병행하여 시작해야 한다. 이는 결함 이관 문제를 방지하기 위해 매우 중요하다. 가능한 한 빨리 테스트 대상과 범위를 결정하는 것이 중요하다.
● 우선 순위를 지정한다.
만약 특정한 중요한 부분이 있다면, 이러한 부분들이 가능한 한 빠르고 최우선으로 테스트되어야 한다.
● 테스트 가능한 시간을 제한한다.
소프트웨어의 테스트 시간은 제한되어 있다. 테스트 가능한 시간이 무한정이 아니라는 사실을 명심해야 하며, 테스트 과정을 시작하기 전에 효과적인 테스트 계획이 매우 중요하다. 테스트 프로세스를 종료할 때 어떤 기준을 두어야 하는지를 결정하기 위해 몇 가지 기준이 필요하다. 이러한 기준은 미리 결정되어야 한다. 예를 들어, 시스템이 수용 가능한 수준의 위험을 가지고 남아있거나 일정이나 예산 제약 조건에 따라 테스트 프로세스를 종료하는 것이 그 예이다.
● 예상치 못한 부정적인 입력값을 사용하여 테스트를 수행해야 한다.
테스트는 올바른 데이터와 테스트 케이스뿐만 아니라 결함이 있는 테스트 케이스도 수행되어야 하며, 이를 통해 시스템이 누수 없음을 확인해야 한다. 향후 테스트 재사용을 위해 테스트 케이스들을 문서화되어야 한다. 이는 테스트에 입력과 해당되는 예상 출력의 적절한 정의와 설명을 포함하여 명확하게 관리되어야 함을 의미한다. 테스트는 소프트웨어 제품의 기능적 요구사항뿐만 아니라 비기능적 요구사항에 대해서도 수행되어야 한다.
● 테스트 결과를 올바르게 검사한다.
테스트와 그 결과는 정량적으로 평가해야 한다. 테스트 케이스의 결과를 검증할 때 문서를 적절하게 참고하여 올바른 테스트를 수행해야 한다. 가능한 한 자동화된 도구와 기술을 사용하여 테스트를 수행해야 한다. 시스템이 수행해야 할 작업을 정확하게 수행하는 것 뿐만 아니라, 시스템이 수행해서는 안 될 작업을 수행하지 않도록 테스터들은 확인해야 한다.
● 가정을 정확하게 검증 한다.
테스트 케이스는 가정이나 가설에 기반하여 개발되어서는 안 된다. 항상 정확하게 검증되어야 한다. 예를 들어, 테스트 케이스를 설계할 때 소프트웨어 제품이 버그가 없다는 가정을 하면 매우 약한 테스트 케이스가 만들어질 수 있다.
● 테스트는 소프트웨어 품질을 향상해야 한다.
테스팅 팀은 소프트웨어 요구 사항 문서(SRS)를 기반으로 애플리케이션의 테스트에 집중해야 한다. 또한 소프트웨어의 성능, 확장성 및 신뢰성에 중점을 두며 소프트웨어의 개선을 고려해야 한다.
● 테스트하는 동안 소프트웨어 개발 모델을 따라야 한다.
테스트 팀은 워터폴 모델과 같은 소프트웨어 개발 모델을 따라야 한다. 테스트를 수행하는 동안에는 효과적인 테스트를 위해 요구사항 단계가 포함되어야 한다.
● 사용자 인수 테스트 시행.
사용자 인수 테스트는 주로 소프트웨어 개발의 최종 단계에서 수행된다. 사용자 인수 테스트에는 규정 인수 테스트, 알파 및 베타 테스트, 블랙박스 테스트 및 생산 준비 테스트등이 있다. 이를 통해 소프트웨어가 프로덕션 준비 상태를 확인할 수 있다.
테스트는 소프트웨어 공학의 필수적인 부분이며 소프트웨어가 요구 사항을 충족하고 고품질임을 확인하는 데 활용된다.
소프트웨어 공학의 테스트를 위한 일반적인 지침은 다음과 같다.
1. 명확하고 측정 가능한 테스트 목표 정의: 테스트해야 할 항목과 각 테스트의 합격 또는 불합격을 구성하는 항목을 정의한다.
2. 포괄적인 테스트 케이스 작성: 에지 테스트 케이스 및 네거티브 테스트 케이스를 포함하여 가능한 모든 시나리오를 다루는 테스트 케이스 세트를 개발한다.
3. 테스트 데이터 생성: 소프트웨어가 정상 작동 중에 발생할 예상 데이터와 예상치 못한 데이터를 나타내는 테스트 데이터를 생성한다.
4. 테스트 자동화: 가능한 한 많은 테스트를 자동화하여 효율성을 높이고 인적 오류를 줄인다.
5. 다양한 테스트 기법 사용: 단위 테스트, 통합 테스트, 시스템 테스트 및 인수 테스트와 같은 다양한 테스트 기술을 조합하여 사용하여 포괄적인 테스트 범위를 제공한다.
6. 테스트 기반 개발(TDD) 사용: 이 방법은 메인 코드 생선 전에 테스트를 작성하는 방법으로, 코드가 요구 사항을 충족하는지 확인하는 데 도움이 되며 코드 리팩터링에도 도움이 된다.
7. 테스트 프로세스를 문서화: 테스트 케이스, 테스트 데이터, 테스트 결과를 포함한 테스트 프로세스에 대한 상세 기록을 보관한다. 소프트웨어를 디버깅하고 유지 관리하는 데 도움이 될 수 있다.
8. 지속적인 테스트 및 모니터링: 개발 중 및 릴리스 후 소프트웨어를 지속적으로 테스트하고 모니터링하여 소프트웨어가 예상대로 작동하는지 확인한다.
9. 최종 사용자 참여: 최종 사용자를 테스트에 참여시켜 소프트웨어가 요구 사항을 충족하고 사용하기 쉽도록 보장한다.
10. 테스트 프레임워크 사용: 테스트 프레임워크를 사용하여 테스트 프로세스를 구성하고 자동화할 수 있다.
'Software Engineering > Testing & Debugging' 카테고리의 다른 글
경계값 분석(Boundary value analysis) (3) | 2024.04.26 |
---|---|
Debugging (0) | 2023.04.23 |
화이트 박스 테스트 (0) | 2023.04.22 |
블랙박스 테스트 (0) | 2023.04.20 |
소프트웨어 테스트의 7가지 원칙 (0) | 2023.04.15 |
댓글