소프트웨어 테스팅 방법론: QA 모델
편집 팀
⚡ 스마트 요약
소프트웨어 테스트 방법론은 애플리케이션이 고객의 기대치를 충족하는지 확인하기 위해 사용되는 전략과 테스트 유형을 정의합니다. 워터폴, 반복형, 애자일, 익스트림 프로그래밍은 각각 테스트 시작 시점과 피드백 제공 방식을 결정합니다.
소프트웨어 테스팅 방법론이란 무엇입니까?
소프트웨어 테스팅 방법론은 테스트 중인 응용 프로그램이 클라이언트 기대치를 충족하는지 확인하는 데 사용되는 전략 및 테스트 유형으로 정의됩니다. 테스트 방법론에는 AUT를 검증하기 위한 기능 및 비기능 테스트가 포함됩니다. 테스트 방법론의 예는 다음과 같습니다. 단위 테스트, 통합 테스팅, 시스템 테스트, 성능 시험 등. 각 테스트 방법론에는 정의된 테스트 목표, 테스트 전략 및 결과물이 있습니다.
주의 사항: 소프트웨어 테스팅은 모든 개발 방법론의 필수적인 부분이므로 많은 회사에서는 개발 방법론 및 테스트 방법론이라는 용어를 구어체로 사용합니다. 따라서 테스트 방법론은 위의 테스트 방법론 정의와 비교하여 Waterfall, Agile 및 기타 QA 모델을 참조할 수도 있습니다. 다양한 테스트 유형에 대한 논의는 독자에게 가치를 더하지 않습니다. 따라서 우리는 다양한 개발 모델에 대해 논의할 것입니다.
테스트 방법론 vs 테스트 유형 vs 테스트 전략
위의 내용은 업계에 실제로 존재하는 모호성을 시사합니다. 세 가지 용어가 일상 대화에서는 혼용되지만 프로젝트 문서에서는 서로 다른 의미를 가지며, 이를 혼동하면 잘못된 질문에 대한 답을 제시하는 테스트 계획이 만들어지게 됩니다.
| 기간 | 질문에 대한 답변 | 결정됨 | 예 |
|---|---|---|---|
| 테스트 방법 | 개발 주기에서 테스트는 언제, 어떻게 이루어져야 할까요? | 사용 중인 개발 모델 | 폭포식, 반복식, 애자일, 익스트림 프로그래밍 |
| 테스트 유형 | 제품의 어떤 부분을 검증하는 것입니까? | 위험 및 요구사항 범위 | 단위, 통합, 시스템, 성능, 보안 |
| 테스트 수준 | 소프트웨어는 어느 정도 수준까지 검사됩니까? | 빌드 계층 구조에서의 위치 | 구성 요소, 통합, 시스템, 승인 |
| 테스트 전략 | 우리 조직의 품질 관리 접근 방식은 무엇인가요? | QA 리더십은 프로젝트 전반에 걸쳐 적용됩니다. | 위험 기반 접근, 자동화 우선, 시프트 레프트 |
| 테스트 계획 | 이 프로젝트는 정확히 무엇을, 언제, 누가 테스트할 예정인가요? | 프로젝트별 테스트 관리자 | 범위, 일정, 자원, 진입 및 종료 기준 |
유용한 경험 법칙: 방법론이 리듬을 정하고, 유형이 목표를 정한다. 테스트 계획 이 기록은 약속을 담고 있습니다. 아래 섹션에서는 방법론을 살펴봅니다.
폭포 모델
그것은 무엇인가?
. 폭포 모델, 요구사항 분석, 설계 등 다양한 단계를 통한 소프트웨어 개발 진행 – 순차적으로.
이 모델에서는 이전 단계가 완료되어야 다음 단계가 시작됩니다.
테스트 접근 방식이란 무엇입니까?
폭포 모델의 첫 번째 단계는 테스트를 시작하기 전에 모든 프로젝트 요구 사항이 완전히 정의되는 요구 사항 단계입니다. 이 단계에서 테스트 팀은 테스트 범위, 테스트 전략을 브레인스토밍하고 자세한 테스트 계획 초안을 작성합니다.
소프트웨어 설계가 완료된 후에만 팀은 개발된 소프트웨어가 예상대로 작동하는지 확인하기 위해 테스트 사례를 실행합니다.
이 방법론에서는 테스트 팀은 이전 단계가 완료되어야만 다음 단계로 진행합니다.
| 장점 | 단점 |
|---|---|
| 이 소프트웨어 엔지니어링 모델은 계획 및 관리가 매우 간단합니다. 따라서 요구사항이 사전에 명확하게 정의되고 명시된 프로젝트는 폭포수 모델을 사용하여 쉽게 테스트할 수 있습니다. | 폭포수 모델에서는 이전 단계가 완료되어야 다음 단계를 시작할 수 있습니다. 따라서 이 모델은 계획되지 않은 사건과 불확실성을 수용할 수 없습니다. |
| 이 방법론은 요구 사항이 자주 변경되는 프로젝트에는 적합하지 않습니다. |
반복 개발
그것은 무엇인가?
이 모델에서는 큰 프로젝트를 작은 부분으로 나누고, 각 부분은 폭포수 모델의 반복 과정을 여러 번 거칩니다. 각 반복이 끝나면 새로운 모듈이 개발되거나 기존 모듈이 개선됩니다. 이 모듈은 소프트웨어 아키텍처에 통합되고 전체 시스템이 동시에 테스트됩니다.
테스트 접근 방식은 무엇입니까?
반복이 완료되자마자 전체 시스템이 테스트됩니다. 테스트를 통한 피드백은 즉시 이용 가능하며 다음 주기에 반영됩니다. 과거 반복에서 얻은 경험을 바탕으로 연속 반복에 필요한 테스트 시간을 줄일 수 있습니다.
| 장점 | 단점 |
|---|---|
| 반복 개발의 가장 큰 장점은 각 주기가 끝날 때마다 테스트 피드백을 즉시 사용할 수 있다는 것입니다. | 이 모델은 각 주기가 끝날 때 결과물, 노력 등에 대한 피드백을 제공해야 하기 때문에 통신 오버헤드를 크게 증가시킵니다. |
민첩한 방법론
그것은 무엇인가?
전통적인 소프트웨어 개발 방법론은 소프트웨어 요구 사항이 프로젝트 내내 일정하게 유지된다는 전제 하에 작동합니다. 그러나 복잡성이 증가함에 따라 요구 사항은 수많은 변화를 겪고 지속적으로 진화합니다. 때때로 고객 자신도 자신이 원하는 것이 무엇인지 확신하지 못합니다. 반복적 모델은 이 문제를 해결하지만 여전히 폭포수 모델을 기반으로 합니다.
Agile 방법론에서는 소프트웨어가 점진적이고 빠른 주기로 개발됩니다. 프로세스와 도구보다는 고객, 개발자, 클라이언트 간의 상호 작용이 강조됩니다. 민첩한 방법론은 광범위한 계획보다는 변화에 대한 대응에 중점을 둡니다.
테스트 접근 방식이란 무엇입니까?
증분 테스트는 민첩한 개발 방법에 사용되므로 프로젝트의 모든 릴리스는 철저하게 테스트됩니다. 이렇게 하면 다음 릴리스 이전에 시스템의 모든 버그가 수정됩니다.
| 장점 | 단점 |
|---|---|
| 요구 사항을 준수하기 위해 언제든지 프로젝트를 변경할 수 있습니다. | 지속적인 클라이언트 상호 작용은 클라이언트 자신, 소프트웨어 개발 및 테스트 팀을 포함한 모든 이해 관계자에게 시간 압박이 가중된다는 것을 의미합니다. |
| 이 증분 테스트는 위험을 최소화합니다. |
익스트림 프로그래밍
그것은 무엇인가?
익스트림 프로그래밍은 짧은 개발 주기를 믿는 민첩한 방법론의 한 유형입니다. 프로젝트는 간단한 엔지니어링 작업으로 구분됩니다. 프로그래머는 간단한 소프트웨어를 코딩하고 고객에게 피드백을 요청합니다. Rev고객이 주신 포인트를 반영하여 개발자가 다음 작업을 진행합니다.
익스트림 프로그래밍 개발자는 대개 쌍으로 작업합니다.
익스트림 프로그래밍 고객 요구 사항이 지속적으로 변화하는 장소에서 사용됩니다.
테스트 접근 방식이란 무엇입니까?
익스트림 프로그래밍은 다음과 같이 설명되는 테스트 중심 개발을 따릅니다.
- 추가 할 테스트 케이스 아직 개발되지 않은 새로운 기능을 검증하기 위해 테스트 스위트에 추가합니다.
- 모든 테스트를 실행하면 기능이 아직 코딩되지 않았기 때문에 추가된 새 테스트 사례는 분명히 실패해야 합니다.
- 기능을 구현하는 코드를 작성하세요.
- 테스트 스위트를 다시 실행하십시오. 이번에는 기능적으로 코딩되었으므로 새 테스트 사례가 통과되어야 합니다.
| 장점 | 단점 |
|---|---|
| 소프트웨어 설계에 대한 구체적인 구상이 없는 고객은 익스트림 프로그래밍을 활용할 수 있습니다. | 소프트웨어 개발 팀과 고객 간의 회의로 인해 시간 요구 사항이 추가됩니다. |
| 지속적인 테스트와 소규모 릴리스의 지속적인 통합을 통해 소프트웨어 코드의 고품질 전달이 보장됩니다. |
V-모델과 나선형 모델
대부분의 프로젝트에서 두 가지 추가 모델이 등장하여 전체적인 그림을 완성하는데, 각 모델은 폭포수 모델의 약점을 서로 다른 방식으로 보완하기 때문입니다.
V 모델. 검증 및 유효성 검사라고도 불리는 V 모델은 모든 개발 단계를 해당 테스트 단계와 짝지어 V자의 두 팔처럼 표현합니다. 요구사항은 인수 테스트와, 고수준 설계는 시스템 테스트와, 저수준 설계는 통합 테스트와, 코딩은 단위 테스트와 연결됩니다. 이 모델의 장점은 테스트 설계가 코딩 이후가 아니라 각 개발 단계와 동시에 시작된다는 점입니다. 따라서 모호한 요구사항은 결함이 발생하기 몇 달 전에 인수 테스트를 작성하는 사람이 발견할 수 있습니다. 하지만 폭포수 모델에서 물려받은 약점은 요구사항이 안정적이라고 가정한다는 점입니다.
나선형 모델. 나선형 방식은 명확한 위험 분석을 중심으로 반복적인 개발 과정을 설계합니다. 각 반복 단계는 목표 설정, 위험 식별 및 해결, 개발 및 테스트, 그리고 다음 반복 단계 계획이라는 네 가지 활동으로 구성됩니다. 따라서 테스트는 위험이 가장 높은 곳에 집중되며, 위험 요소에 고르게 분산되지 않습니다. 이 방식은 항공우주 산업이나 은행 핵심 시스템과 같이 대규모의 고비용 장기 프로젝트, 즉 위험 발견 시 발생하는 손실이 막대한 프로젝트에 적합합니다. 하지만 소규모 웹 프로젝트의 경우, 매 반복 단계마다 공식적인 위험 분석을 수행하는 것은 비용 대비 효과가 크지 않을 수 있습니다.
두 모델 모두 워터폴 방식의 규율과 애자일 방식의 반응성 사이에 위치합니다. 릴리스 빈도가 두 방식보다 더 중요한 경우에 적합합니다. DevOps (개발 운영) 파이프라인은 테스트를 지속적 통합에 통합하여 모든 커밋이 자동으로 검증되도록 합니다.
어떤 소프트웨어 방법론을 선택해야 합니까?
소프트웨어 개발 및 해당 테스트에 사용할 수 있는 방법론은 엄청나게 많습니다. 각 테스트 기술과 방법론은 특정 목적을 위해 설계되었으며 상대적인 장점과 단점이 있습니다.
특정 방법론의 선택은 프로젝트의 성격, 고객 요구 사항, 프로젝트 일정 등과 같은 여러 요소에 따라 달라집니다.
테스트 관점에서 일부 방법론은 개발 수명 주기 초기에 입력 테스트를 추진하는 반면 다른 방법론은 시스템의 작동 모델이 준비될 때까지 기다립니다.
소프트웨어 테스트 방법론을 설정하는 방법은 무엇입니까?
소프트웨어 테스트 방법론은 소프트웨어 코드 테스트만을 위해 설정되어서는 안 됩니다. 큰 그림을 고려해야 하며, 테스트 방법론은 프로젝트의 주요 목표를 만족시켜야 합니다. 이 평판 좋은 목록을 참조하십시오 소프트웨어 테스트 서비스 제공업체 프로젝트 목표에 맞는 효과적인 테스트 전략을 수립하는 데 도움을 줄 수 있는 사람입니다.
예약
현실적인 일정 계획은 성공적인 테스트 방법론 구현의 핵심이며 일정은 팀의 모든 구성원의 요구 사항을 충족해야 합니다.
정의된 결과물
팀의 모든 구성원이 동일한 내용을 공유하려면 잘 정의된 결과물이 제공되어야 합니다. 결과물에는 모호함 없이 직접적인 내용이 포함되어야 합니다.
테스트 접근법
일정이 완료되고 정의된 결과물이 제공되면 테스트 팀은 올바른 테스트 접근 방식을 공식화할 수 있어야 합니다. 정의 문서와 개발자 회의는 프로젝트에 사용할 수 있는 최상의 테스트 접근 방식에 대해 팀에 알려야 합니다.
통계 보고서
투명한 보고는 달성하기 매우 어렵지만 이 단계는 프로젝트에 사용되는 테스트 접근 방식의 효율성을 결정합니다.
