소프트웨어 테스팅에 대한 간략한 가이드 - 표준 및 프로세스

"모든 코드는 무죄로 테스트될 때까지 유죄입니다." - 알려지지 않은 기술 괴짜.

엄격한 테스트를 거치지 않고는 좋은 소프트웨어를 가질 수 없습니다. 이 기사에서는 더 나은 결과를 제공하기 위해 따라야 하는 소프트웨어 테스트 표준 및 프로세스에 대해 자세히 알아볼 것입니다.

소프트웨어 테스팅이란?

간단히 말해서, 소프트웨어 테스팅은 소프트웨어를 더 좋게 만듭니다. 개발된 소프트웨어의 정확성, 완전성 및 품질을 식별하는 프로세스입니다. 테스트는 클라이언트에게 전달되기 전에 결함/버그를 찾아내고 소프트웨어 품질을 보장하기 때문에 중요합니다. 소프트웨어를 보다 안정적으로 사용할 수 있습니다.

소프트웨어 테스트 단계

위에 나열된 소프트웨어 테스트 단계를 살펴보겠습니다.

요구 사항 분석:

요구 사항 분석은 구축/수정할 소프트웨어 애플리케이션에 대한 최종 사용자의 기대치를 정의합니다. 따라서 요구 사항 분석은 소프트웨어 또는 시스템 요구 사항을 분석, 보고, 문서화, 검증 및 관리하는 것을 의미합니다.

테스트 엔지니어는 요구 사항 분석을 완료하기 위해 다음 작업을 수행해야 합니다.

• 각 요구 사항을 읽고 완전성, 명확성, 모호성이 있는지 확인하십시오.
• 요구 사항 분석 단계에서 가능한 모든 시나리오가 고려되었는지 확인하고 발견되지 않은 모든 사례 또는 격차를 식별하십시오.
• 요구 사항 분석에서 발생하는 질문이나 의심에 대한 토론은 팀이 같은 페이지에 있어야 한다고 매일 호출합니다.
• 테스트 중인 소프트웨어의 완전한 요구 사항 범위를 보장하려면 요구 사항 추적성 매트릭스를 사용해야 합니다.

아래는 RTM(Requirements Traceability Matrix) 샘플 템플릿입니다.

크레딧: Opencodez

테스트 계획:

테스트 계획은 소프트웨어 응용 프로그램에서 소프트웨어 테스트를 수행하는 데 필요한 테스트 목표, 일정, 추정, 결과물 및 리소스를 설명하는 문서입니다. 테스트 계획은 테스트 중인 애플리케이션의 품질을 검증하는 데 필요한 노력을 이해하고 결정하는 데 도움이 됩니다. 다음은 샘플 애자일 테스트 계획입니다.

크레딧: zenq

테스트 디자인:

테스트 설계는 테스트에 필요한 사용 사례를 설계하는 단계입니다. 테스트 설계는 테스트 계획에 따라 수행됩니다. 설계된 테스트 케이스는 소프트웨어 응용 프로그램의 모든 요구 사항을 충족하는지 확인합니다. 모든 요구 사항 격차를 커버하기 위해 추적 가능성 매트릭스를 사용한 테스트 사례 매핑도 필요한 것으로 간주됩니다.

테스트 시나리오/테스트 케이스는 해피 패스 및 네거티브 시나리오 테스트에 대한 완전한 테스트 커버리지를 보장하기 위해 아래 테스트 설계 기술을 기반으로 설계되었습니다.

• 경계 값 분석(BVA)
• 등가 분할(EP)
• 사용 사례 테스트
• 충격 기반 테스트

아래는 샘플 테스트 디자인 템플릿입니다.

크레딧: https://www.softwaretestingclass.com/

테스트 환경 설정:

테스트 환경은 소프트웨어 애플리케이션에서 테스트 케이스를 구현하고 실행하기 위해 구축된 플랫폼입니다. 테스트를 위한 환경은 필요한 네트워크 구성 및 필요한 설정과 함께 필요한 하드웨어 및 소프트웨어의 통합으로 생성됩니다. 테스트를 시작하기 전에 항상 테스트 환경의 실행 가능성을 확인하기 위해 테스트 환경에서 스모크 테스트를 수행하는 것이 중요합니다.

테스트 실행:

테스트 실행은 설계된 테스트 케이스를 실행하고 예상 결과와 실제 결과를 문서화하고 비교하는 프로세스입니다. 위험성을 고려하여 테스트 실행을 위해 다음과 같은 요소를 고려합니다. 이 주기에 대해 실행할 테스트 스위트의 하위 집합을 선택하고 해당 테스터/품질 분석가에게 할당합니다.

• 테스트 실행은 테스트 계획에 따라 설계된 테스트 케이스 / 테스트 시나리오를 기반으로 수행됩니다.
• 관찰 - 테스트 실행 중 발생한 각 JIRA 티켓에 문서화
• 각 JIRA 티켓의 테스트 증명 문서는 다음으로 구성됩니다.

◦ 테스트 상태: PASS / FAIL - JIRA 티켓의 테스트 상태를 나타냅니다.

◦ 테스트 URL: 특정 요구 사항을 테스트하는 데 사용되는 테스트 데이터로 구성

◦ 테스트 시나리오 및 해당 스크린샷

• 온전성 및 회귀 - Pre UAT 테스트 조치의 일부로 모든 스프린트 끝에서 정기적으로 상위 환경(STG)에서 온전성 및 회귀 테스트를 수행합니다.

테스트 마감:

스프린트 테스트 종료 체크리스트는 여러 스프린트 간의 원활한 전환을 위해 모든 스프린트가 끝날 때 다음 활동이 수행되는지 확인합니다.

• 완전한 적용 범위로 타임 라인에 따라 기능 테스트 완료
• 팀이 기록하고 처리한 모든 관찰
• 결함으로 기록되고 해당 티켓 소유자에게 할당된 유효한 관찰
• 각 티켓에 대해 해당 수동 테스트 및 장치 테스트 결과로 업데이트된 테스트 증명 문서
• 코드가 상위 환경에 병합되기 전에 테스트 환경에서 수행된 회귀 테스트. 이 경우 Dev에서 STG로

기기 테스트/크로스 브라우저 테스트:

장치/크로스 브라우저 테스트는 장치/브라우저가 개발된 요구 사항을 얼마나 잘 충족하는지 확인하기 위해 품질을 테스트하는 프로세스입니다. 기기/교차 브라우저 테스트는 고객이 확인한 아래 기기/브라우저 목록에 포함됩니다. 장치 테스트를 위한 플랫폼으로 사용되는 브라우저 스택.

다양한 유형의 소프트웨어 테스트

단위 테스트:

단위 테스트는 테스트 전략의 속도를 높이고 원치 않는 테스트 주기를 줄이기 위해 정보를 조기에 전달하기 위해 작은 코드 단위를 확인합니다. 단위 테스트는 일반적으로 코드가 소프트웨어 테스트 팀에 전달되기 전에 개발자가 수행합니다.

연기 테스트:

Smoke Testing은 배포된 소프트웨어가 안정적인지 여부를 결정하는 소프트웨어 테스트 절차입니다. 연기 테스트는 테스트 팀이 추가 소프트웨어 테스트를 진행하기 위한 확인입니다. 소프트웨어 기능을 테스트하기 위해 각 빌드에서 실행할 최소 테스트 세트로 구성됩니다.

통합 테스트:

통합 테스트는 시스템의 동작을 확인하기 위해 통합된 하드웨어 및 소프트웨어 환경에서 수행되는 테스트 유형으로 정의됩니다. 소프트웨어/하드웨어 구성 요소는 완성된 시스템이 테스트될 때까지 통합되고 점진적으로 테스트됩니다.

시스템 테스트:

완전히 통합된 소프트웨어 제품의 시스템 테스트. 납품된 제품이 요구사항 문서에 언급된 요구사항 사양을 충족하는지 확인하기 위한 최종 테스트입니다. 기능적 요구사항과 비기능적 요구사항 모두가 범위에서 고려되어야 합니다.

회귀 테스트:

회귀는 최근 코드 변경이 이미 존재하는 기능을 변경하거나 파괴하지 않는지 확인합니다. 회귀 테스트에는 하위 집합/전체 회귀가 모두 포함되며 둘 다 수동 또는 자동 테스트 시나리오로 다룰 수 있습니다.

사용자 수락 테스트(UAT):

사용자 승인 테스팅은 소프트웨어 테스팅 라이프 사이클의 마지막 단계 중 하나로 소프트웨어가 철저하게 테스팅된 후 클라이언트에 의해 수행됩니다. UAT는 프로덕션 릴리스의 승인 및 배포를 위해 제품의 최종 사용자가 수행합니다.