메뉴

컨텍스트 기반 테스트 : 7 가지 기본 원칙 (예제 포함)

context driven testing

문제를 제거하기 위해 도구를 사용해보십시오

예제를 통한 상황 기반 테스트의 7 가지 기본 원칙 :

.swf를 실행하는 방법

나는 공항까지 운전할 때 일반적으로 최소한의 시간에 도착하고 통행료를 피할 수있는 고속도로를 이용합니다. 하지만 그날 나는 통행료가있는 더 긴 지방 도로를 택했습니다. 가족과 함께 주말을 보내기 위해 아주 먼 거리를 여행 한 친구와 몇 분 더 운전하고 싶었 기 때문입니다. 이 경우 정상적인 최악의 선택이 최선의 선택으로 판명되었습니다.

그러나 이것을 고려하십시오.

가스가 부족하면 어떻게합니까?

현금이 부족하면 어떻게합니까?

나는 다른 옵션을 선택할 것입니다. 왜? 문맥.

컨텍스트 기반 테스트 란?

(영상 신용 )

다음을 기반으로 결정을 내릴 때 상황에 따라 결정됩니다.

  • 관련된 사람들
  • 상황
  • 목표
  • 사용 가능한 옵션
  • 감정 등

그렇다면 컨텍스트 기반 테스트 란 무엇입니까?

컨텍스트 기반 테스트는 Cem Kaner, James Bach 및 Bret Pettichord가 개발 한 사고 방식 전환 (또는 테스트 학교)입니다. 이에 대한 자세한 내용은 유명한 책에서 찾을 수 있습니다. 소프트웨어 테스팅에서 배운 교훈 .

7 가지 기본 원칙이 있습니다. 다음은 책에서 직접 선택되었습니다.

#1) 모든 관행의 가치는 상황에 따라 다릅니다.

#두) 상황에 맞는 모범 사례가 있지만 모범 사례는 없습니다.

#삼) 함께 일하는 사람은 모든 프로젝트의 맥락에서 가장 중요한 부분입니다.

# 4) 프로젝트는 종종 예측할 수없는 방식으로 시간이 지남에 따라 전개됩니다.

# 5) 제품은 해결책입니다. 문제가 해결되지 않으면 제품이 작동하지 않습니다.

# 6) 좋은 소프트웨어 테스트는 어려운 지적 프로세스입니다.

# 7) 프로젝트 전체에 걸쳐 협력 적으로 실행되는 판단과 기술을 통해서만 적시에 올바른 작업을 수행하여 제품을 효과적으로 테스트 할 수 있습니다.

나는 그들 각각을 설명하지 않을 것입니다. 여기 전문가 자신 .

컨텍스트 기반 테스트에 대한 설명을 바탕으로 시나리오를 작성하겠습니다.

컨텍스트 기반 테스트의 예 :

웹 기반 애플리케이션에 대한 종단 간 테스트를 포함하는 테스트 프로젝트 인 프로젝트 A를 시작한다고 가정 해 보겠습니다.

내 전략은 무엇입니까?

표준 프로세스에 따르면 다음과 같은 일련의 이벤트가 있습니다.

  • 요구 사항 수집 및 응용 프로그램 이해
  • 테스트 계획 만들기
  • 테스트 문서 생성-테스트 시나리오, 테스트 사례, 추적 성 매트릭스 등
  • 모든 문서를 검토하고 승인하십시오.
  • QA 환경 및 테스트 데이터 설정
  • 테스트 실행 수행
  • 버그 보고서 작성
  • 테스트 실행 상태 보고서 생성 및 공유 등

내가 스스로에게 '내가해야 할 일이라고 어떻게 결정 했는가?'라는 질문을하면 내 대답은 모범 사례, QA 표준, 업계 지침, 과거 경험 기준 등이 될 것입니다. 맞습니까?

나는 내가하도록 배운 것과 다른 사람들이하는 것을 본 것을 반복하고있다.

자, 거기에 문제가 있습니까? 전혀. 이 접근 방식에 대해 일정한 반복성과 시간 테스트를 거쳤기 때문에이 역시 작동 할 수 있습니다. 그러나 최적의 결과를위한 길을 열었습니까?

불안한. 왜?

모든 프로젝트에서 서로 다른 상황을 다루게되기 때문입니다.

  • 문서화 된 요구 사항과 문서화되지 않은 요구 사항
  • 밀접하게 작업하는 팀과 지리적으로 분산 된 팀
  • 같은 회사에 속한 개발 및 테스트 팀 vs. 경쟁
  • 충분한 시간 vs. 빡빡한 일정
  • 팀 구성 – 신규 이민자 대 경험있는 사람. 훈련 된 것과 훈련되지 않은 것.
  • 도구 가용성-수동 및 테스트 관리 도구 사용
  • 프로젝트 유형-규칙 (FDA 또는 은행)에 대한 엄격한 준수와 실험적 (소셜 미디어 등) 준수 필요
  • 프로젝트의 기술.예를 들면 :웹과 Windows 앱을 같은 방식으로 테스트하지 않을 것입니다.
  • 클라이언트의 요구 사항 (일부는 일일 상세 보고서를 원하고 일부는 하이라이트 만 원함)
  • 후속 프로세스 (Agile vs. Traditional, 스크립트 vs. 탐색 적 테스트)

이 목록은 완전하지 않으며 각 프로젝트에 많은 변수가 있다는 것을 알고 있습니다.

컨텍스트 기반 테스트는 이러한 상황이 업계에서 인식하는 표준이 아닌 테스트 관행, 기술 및 정의까지 결정하도록하는 것입니다. 모범 사례' .

이제 프로젝트 A를 위해 작업중인 세부 정보는 다음과 같습니다.

  • 저는 5 ~ 4 명의 신규 이민자와 1 명의 숙련 된 테스터로 구성된 팀과 함께 일하고 있습니다.
  • 문서화 된 요구 사항이 없습니다.
  • 우리 팀은 인도에 있고 개발 팀은 미국에 있으므로 반대 시간대에 근무합니다.
  • 고객은 일일 상세 상태 보고서를 원합니다.
  • 우리는 Mantis 또는 Bugzilla와 같은 웹 기반 버그 추적 도구를 사용합니다.
  • 테스트 문서화를 위해 3 일 동안 10 일 동안 2 차 테스트를해야합니다.

다음은 대략적인 계획입니다.

1) 많은 신규 사용자가 팀에 있기 때문에 많은 동료 검토가 필요합니다.

두) 또한 BA 및 Dev 팀과 최소 2 회의 요구 사항 토론 회의가 필요합니다. 팀이 다른 곳에 위치해 있고 질문을 던질 여지가 거의 없기 때문에 이것은 공식적이어야합니다.

삼) 문서화를위한 공격적인 테스트 타임 라인입니다. 더 많은 문서를 작성할수록 더 많은 리뷰가 필요하며 이는 더 많은 시간을 의미합니다. 따라서 최소한의 문서를 유지해야합니다. 우리는 단지 메인 종단 간 TC 나머지는 탐구 적으로 테스트 .

4) 테스트 실행 중 일일 상태 보고서가 생성되어 매일 EOD로 전송됩니다.

5) 대부분의 테스트는 탐색 적이므로 실행되는 모든 테스트에 대한 간략한 개요를 작성하도록 시간을 조언하십시오. 이렇게하면 무엇이 테스트되고 무엇이 아닌지 알 수 있습니다.

6) 결함은 Mantis에 실시간으로보고됩니다. 팀이 다른 시간대에서 작업하고 있으므로 설명이 필요한 경우 QA 팀의 답변을 듣기 전에 하루 종일 기다려야 할 수 있습니다. 따라서 QA 팀이 버그 재현을 시연하는 편리한 팀에서 매일 통화를 설정하십시오. 이렇게하면 기다리거나 후속 조치를 취할 필요가 없습니다.

등등.

전반적인 전략이 수립되면 이러한 사항을 설명하는 기본 테스트 계획을 작성하십시오. 이제 신중하게 고려하고 성공을위한 전략을 맞춤화 한 후 테스트 프로젝트에 들어갈 준비가되었습니다.

wav 변환기 무료 다운로드에 유튜브

요약하자면:

이것은 컨텍스트 기반 테스트; 표준이 아닌 환경을 테스트 전략에 대한 주요 입력 및 영향 요인으로 만듭니다. 그것은 우리가 주변을 둘러보고 주변의 모든 것을 고려하도록 촉구합니다.

개인적으로 저는이 개념을 좋아합니다. 너무 자주 테스트 관행이 엄격하고 모방에 기반한 것으로 인식되기 때문입니다. 누군가 해냈고 성공 했으니 나도 해보겠다. 이것은 사람들이 시험 경력을 쌓기 위해 노력하고 머무르는 것을 두려워하는 종류의 이미지입니다.

그러나 창의적 사고, 분석 기술 및 의사 결정에는 많은 범위가 있습니다. 자세한 내용은 위에 제공된 링크에서 주제를 읽으십시오.

행복한 컨텍스트 기반 테스트

추천 도서

^