메뉴

소프트웨어 테스팅의 탐색 적 테스팅이란 무엇입니까 (전체 가이드)

  • 메인
  • 다른
  • 소프트웨어 테스팅의 탐색 적 테스팅이란 무엇입니까 (전체 가이드)

what is exploratory testing software testing

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

탐색 적 테스트 란 무엇입니까?

'탐색 테스트'– 이름에서 알 수 있듯이 동시 학습, 테스트 설계 및 테스트 실행 프로세스입니다. 이 테스트에서 테스트 계획, 분석, 설계 및 테스트 실행이 모두 함께 즉시 수행된다고 말할 수 있습니다.

이 테스트는 시스템을 탐색하고 테스터의 실시간 및 실제 사고를 장려하는 것입니다.

이 시리즈에서는 다음 튜토리얼을 다뤘습니다.:

튜토리얼 # 1 : 소프트웨어 테스팅에서 탐색 적 테스팅이란? (이 튜토리얼)
튜토리얼 # 2 : 둘러보기를 사용하여 완전한 탐색 테스트 보장
튜토리얼 # 3 : 탐색 적 테스트와 스크립팅 된 테스트
튜토리얼 # 4 : HP Sprinter를 사용한 탐색 적 테스트
튜토리얼 # 5 : 상위 17 개 탐색 테스트 도구

************************************
탐색 적 테스트

학습 내용 :

개요

평범한 용어로 탐색 적 테스트에는 동시 테스트 케이스 설계 및 테스트중인 애플리케이션 또는 시스템의 테스트 실행이 포함됩니다. 테스터는 테스트 아이디어를 작성하거나 작성하여 방향을 제시하고 테스트하는 동안 시스템을 탐색하여 애플리케이션의 성공적인 테스트를위한 중요하고 실용적이며 유용한 테스트를 추가로 만듭니다.

이를 위해서는 최소한의 계획이 필요합니다. 테스터는 다음 조치 단계에 대해 지속적으로 결정을 내립니다. 테스터의 사고 과정에 전적으로 달려 있습니다.

때로는이 테스트가 공식 테스트 방식보다 더 유용 할 수 있습니다. 미묘한 결함 찾기 공식 테스트에서 누락됩니다.

의식적으로 또는 무의식적으로 모든 테스터는 경력의 어느 시점에서 탐색 테스트를 수행했을 것입니다.

우리 모두 알다시피, 학습자는 이론을 익히기보다는 실습 경험을 통해 더 잘 배울 것입니다.

마찬가지로 테스터는 자체적으로 제공하는 모든 기능을 탐색하고 학습하는 동안에 만 애플리케이션을 더 잘 알 수 있습니다. 애플리케이션의 성공적인 테스트를 보장하기 위해 테스트하는 동안 고객 및 비즈니스 관점을 갖는 것이 항상 좋습니다.

예를 들어, 쇼핑 웹 사이트를 열면이 쇼핑 웹 사이트에서 원하는 제품을 선택한 다음 동일한 비용을 지불하여 쇼핑 할 수 있다는 일반적인 생각을 갖게됩니다.

이 과정에서 웹 사이트가 제품 선택 과정에서 도움이되는 가상의 사람과 비슷한 모습을 제공한다는 사실을 알게 될 것입니다. 또한 홈 트라이얼을 위해 여러 제품을 주문할 수 있거나 일부 은행 등의 리워드 포인트를 통해 결제 할 수 있음을 발견했습니다.

테스터는 시스템이 예상대로 작동하는지 확인해야 할뿐만 아니라 해당 시스템이 예상치 못한 방식으로 작동하지 않는지도 확인해야합니다.

이 테스트를 수행하는 동안 기억해야 할 몇 가지 사항 :

  • 당신의 임무는 분명해야합니다.
  • 메모를 작성하고 수행중인 작업과 잠재적 인 버그 일 수있는 시스템 작동 방식에 대해보고하십시오.
  • 새로운 테스트 사례를 배우고 관찰 한 다음 생각해보십시오.

권장 탐색 테스트 서비스

# 1) Digivante Direct

Digivante Direct 로고

Digivante Direct 전문 테스터의 글로벌 네트워크를 사용하여 탐색 적 테스트를 수행하므로 다른 테스트 공급 업체 나 사내 팀이 달성 할 수없는 일정에 모든 주요 장치에 대한 테스트를 수행 할 수 있습니다.

더 빠르고 안전하게 출시하고 디지털 플랫폼에서 더 높은 고객 만족도와 온라인 수익을 제공 할 수 있습니다.

풍모:

  • 24 시간 만에 24 일 테스트 또는 72 시간에 90 일 (근무일 기준), 다른 방법으로는 달성 할 수없는 독보적이고 포괄적 인 테스트 수준.
  • 저렴한 비용 , 숨겨진 추가 사항이없는 이해하기 쉬운 가격 패키지.
  • 셀프 서비스 지속적인 약정이 필요하지 않은 온라인 포털.
  • 실제 장치에서 테스트하는 실제 사람 – 더 빠른 처리 시간 내에 사내에서 달성 할 수있는 것보다 훨씬 더 많은 장치 및 브라우저 적용 범위.
  • 전체 탐색 테스트 범위 – 위험을 줄이고 최종 사용자 만족도와 전환율을 개선하여 비용을 줄이면서 수익을 증가시킵니다.
=> Digivante Direct 웹 사이트 방문

탐색 적 테스트 예

예 1 :

다음 구성 요소가 포함 된 홈 케어 서비스 제공 업체 웹 사이트 :

  • 로그인
  • 서비스
  • 카트
  • 지불
  • 주문 내역
  • 기술자 할당

시작하기위한 일반적인 아이디어 탐구적인 테스트는 로그인하거나 서비스를 예약하는 것입니다.

테스트 케이스를 다루는 방법?

탐색 적 테스트 테스트 케이스

미국의 무료 이메일 제공 업체 목록

위에서 예, 아이디어는 지식을 기반으로 한 기능으로 시작하는 것입니다. 애플리케이션에 대해 더 많이 배우고 관찰하면 다음 테스트 케이스 세트를 관리 할 수 ​​있습니다.

예 # 2 :

나는 한때 신청서에 새로운 뮤추얼 펀드를 추가하는 작은 프로젝트에 포함되었습니다. 내 임무는 애플리케이션을 테스트하여 사용자가 새로운 뮤추얼 펀드를 구매할 수 있는지 확인하고 관련 평가가 올바른지 확인하는 것이 었습니다. 테스트를 완료하는 데 2 ​​일 밖에 걸리지 않았습니다.

테스트의 촉박 한 기한과 엄격함을 감안하여 테스트의 탐색 적 접근 방식을 사용했습니다. 내 목표는 새로운 기능을 테스트하고 호환성 요구 사항 위반을 찾는 것이 었습니다.

위에서 언급 한 목표가이 테스트 세션에 대한 나의 헌장이되었습니다.

이 테스트 중에 다음 테스트 사례가 발전했습니다.

  • 새로운 뮤추얼 펀드가 애플리케이션에 추가되었는지 테스트합니다.
  • 새 MF가 성공적으로 구입되었습니다.
  • 새로운 MF의 평가가 정확합니다.
  • 기존 포트폴리오를 위해 새로운 MF를 구입하려고했습니다.
  • 모든 포트폴리오에 새로운 MF를 추가 할 수 있습니까?
  • 기존 밸류에이션에 대한 New MF의 영향.
  • 그래서 다른 테스트 케이스에서 진화했습니다.

나는 내 관찰을 BA 및 관련된 고객과 논의하기 위해 테스트 중에 메모와 보고서를 준비했습니다.

탐색 적 테스트의 기본 전략은 공격 계획을 세우는 것입니다. 아이디어로 테스트를 시작하고 지식과 관찰을 기반으로 새로운 테스트 케이스를 즉석에서 수정하십시오.

예제 # 3 :

IRCTC 웹 사이트의 탐색 적 테스트

=> IRCTC 웹 사이트의 탐색 적 테스트 샘플 테스트 사례를 다운로드하려면 여기를 클릭하십시오.

테스트 접근법

  • 경험적 방법을 사용하여 테스트를 안내하십시오.
  • 테스트 케이스 실행과 테스트 케이스 생성은 함께 진행됩니다.
  • 테스트 사례는 테스터 관찰 및 학습을 기반으로 계속 진화합니다.
  • 다음과 같은 다양한 테스트 기술 경계 값 분석 , 동등성 테스트 등을 ET에 적용 할 수 있습니다.
  • 세션 기반 ET를 사용하여보다 체계적이고 집중적으로 만들 수 있습니다.
  • 테스터는 아이디어를 나눌 수 있지만 임무에서 벗어나지 않습니다.
  • ET 테스트는 스크립트를 사용하지 않고 테스터의 직감, 기술 및 경험에 따라 달라집니다.

혜택

이 테스트의 이점은 다음과 같습니다.

  • 실시간 사고를 촉진하고 더 많은 결함을 발견하는 데 도움이됩니다.
  • 사용 사례 및 시나리오 기반 테스트를 홍보합니다.
  • 최소한의 문서화, 최대 테스트.
  • 테스터의 학습 및 확장에 더 중점을 둡니다.
  • 중복 작업을 피하십시오.
  • 다른 테스터의 작업을 감사 할 때 유용합니다.

단점

단점은 다음과 같습니다.

  • 테스트는 테스터의 경험, 기술 및 지식에 따라 달라집니다.
  • 응용 프로그램을 배우는 데 시간이 필요합니다. 테스터는 응용 프로그램에 대해 잘 모르면 놓칠 가능성이 높습니다.
  • 실행 시간이 긴 프로젝트에는 적합하지 않습니다.

세션 기반 탐색 테스트

탐색 적 테스트를 수행하는 동안 테스터가 테스트 한 내용과 기준에 대해 말로 표현하는 것은 매우 어렵습니다.

기본적으로 작업과 소요 시간을 정량화하는 것은 어렵습니다. 그러나 모든 프로젝트에서 우리는 팀 리더와 관리자에게 메트릭, 추정 및 진행 보고서를 제공해야합니다. 속담처럼 '정량화 할 수 없으면 관리 할 수 ​​없다'.

세션 기반 테스트는 관리 및 추적에 도움이되는이 테스트를 수행하는 시간 기반 접근 방식입니다. 이메일, 전화, 메시지 등의 중단없이 전용 타임 박스 테스트 세션이 포함됩니다.

접근하다:

테스트 작업은 세션으로 나뉩니다.

다음은 세션 기반 테스트 (SBT)의 구성 요소입니다.

  • 사명: Mission은 세션의 목적을 외치고 테스터에게 초점을 제공합니다. 세션 시간도 포함됩니다.
  • 전세: 테스트 범위를 포함합니다. 기본적으로 세션 중에 완료해야하는 목표를 자세히 설명하는 의제입니다.

홈 케어 서비스 웹 사이트의 로그인 기능에 대한 테스트 헌장의 예 :

로그인 기능에 대한 테스트 헌장의 예

  • 세션: 중단없이 사전 정의 된 타임 박스 테스트 세션. 각 세션은 다음 기간을 가질 수 있습니다.
    • '짧은'(60 분)
    • '보통'(90 분)
    • 'Long'(120 분)
  • 세션 보고서 : 리더와 관리자에게 메트릭을 제공하는 메모와 간단한 보고서를 포함합니다. 남아 있거나 완료된 차터 세션, 세션 설정 시간, 테스트 된 시나리오, 테스트 프로세스에 대한 세부 정보, 버그 및 발견 된 문제 목록 및 메트릭에 대한 기타 정보를 제공합니다.
  • 세션 요약 : 테스트 세션 결과를 검토하기 위해 테스터와 테스트 리드 / 관리자 간의 짧은 회의 또는 스탠드 업.

관리자는 세션 보고서를 기반으로 다음 측정 항목을 실습 할 수 있습니다.

  • 완료되고 남은 세션 수입니다.
  • 보고 된 버그 수입니다.
  • 세션 설정에 소요 된 시간입니다.
  • 테스트에 소요 된 시간.
  • 문제 또는 문제를 분석하는 데 소요 된 시간.
  • 다루는 기능.

위의 내용을 요약하면 다음과 같습니다.

SBT는 책임을 허용하는 탐색 적 테스트이며 테스트에 소요되는 시간을 더 잘 관리합니다. 또한 생산성을 높이고 버그 감지를 더 잘 파악할 수 있습니다. 팀장과 관리자에게 프로젝트 진행 상황을 확인할 수있는 메트릭을 제공하는 좋은 방법입니다.

쌍 기반 탐색 테스트

쌍 테스트는 두 사람이 PC를 공유하여 응용 프로그램의 동일한 항목 / 기능을 동시에 테스트하는 접근 방식입니다. 그들은 지속적으로 자신의 생각과 아이디어를 공유합니다. 이 테스트 동안 한 사람이 키보드를 담당하고 다른 사람이 테스트 사례를 제안하고 기록합니다.

파트너들 사이에 좋은 의사 소통을하는 것이 항상 도움이되므로 두 사람이 무엇을하고 있고 그 이유를 알 수 있습니다. 테스터의 강점이 서로 약점을 보완하는 쌍을 강 그룹으로 간주합니다.

이러한 페어링은 당사자 모두에게 이익이되며 각자 파트너로부터 무언가를 배울 수 있습니다. 또한 경험이 풍부한 리소스와 결합하여 새로운 리소스를 교육하는 좋은 방법입니다.

쌍 테스트의 이점

  • 테스터가 당면한 작업에 집중할 수 있도록 도와줍니다.
  • 파트너 간의 상호 신뢰와 존중을 장려합니다.
  • 일반적으로 짝을 이룬 테스터 간의 브레인 스토밍은보다 건설적인 아이디어로 이어집니다.
  • 터널 비전을 피하십시오.
  • 다른 사람들이 방해 할 가능성이 적습니다.

탐색 적 테스트 기법

투어 : 테스터가 자신의 상상력을 사용하고 자신이 방문하는 도시를 탐험하는 관광객으로 생각할 수있는 간단한 기술입니다. 여기서 테스트 할 애플리케이션은 도시이고 테스터는 관광객입니다. 손에 많은 시간과 돈이 없으면 도시 전체를 탐험하기가 매우 어렵 기 때문에 관광객은 특정 목표를 염두에두고 계획을 세워야합니다.

관광객은 다음과 같은 투어를 할 수 있습니다.

  • 가이드 북 투어 – 응용 프로그램의 강조된 기능을 테스트합니다. 사용자 기반 시나리오를 사용합니다.
  • 도시의 역사 탐험 – 응용 프로그램의 이전 기능을 테스트합니다.
  • 머니 투어, 즉, 고객 또는 클라이언트와 관련된 모든 중요한 기능이 테스트되고 성공적으로 작동하는지 확인합니다.
  • 범죄 행위 여행 – 잘못된 입력을 입력하고 부정적인 시나리오를 테스트합니다.
  • 뒷골목 투어 – 응용 프로그램에서 가장 적게 사용되는 기능을 테스트합니다.
  • 지루한 투어 – 응용 프로그램의 각 화면에서 최소 시간을 보내고 최소 필드를 채우고 최단 경로를 선택하십시오. 이는 기본값 및 유효성 검사 테스트에 도움이됩니다.

투어를하는 동안 항상 어떤 경로를 선택할 수 있습니다. 소프트웨어를 탐색하고 기능을 테스트하기위한 고유 한 경로를 찾을 수 있습니다.

다음은 ET에서 사용할 수있는 몇 가지 팁 / 트릭입니다.

  • 응용 프로그램을 모듈로 나누고 모듈을 여러 페이지로 나눕니다. 페이지에서 ET를 시작하십시오. 이것은 올바른 보장을 제공 할 것입니다.
  • 모든 기능의 체크리스트를 작성하고 해당 기능이 적용되면 확인 표시를하십시오.
  • 기본 시나리오로 시작한 다음 점차적으로 개선하여 더 많은 기능을 추가하여 테스트합니다.
  • 모든 입력 필드를 테스트하십시오.
  • 오류 메시지 테스트
  • 모든 부정적인 시나리오를 테스트하십시오.
  • 표준에 대해 GUI를 확인하십시오.
  • 응용 프로그램과 다른 외부 응용 프로그램의 통합을 확인하십시오.
  • 복잡한 비즈니스 로직을 확인하십시오.
  • 응용 프로그램의 윤리적 해킹을 시도하십시오.

ET에 영향을 미치는 요인은 다음과 같습니다.

  • 프로젝트의 목적
  • 테스트 전략
  • 특정 단계의 테스트 목표
  • 사용 가능한 도구 및 시설
  • 테스터 역할 및 기술
  • 이용 가능한 시간
  • 경영 지원
  • 동료 지원
  • 사용 가능한 리소스 (학습 자료, 테스트 조건 등)
  • 고객의 관심
  • 제품의 이해도.
  • 응용 프로그램의 UI
  • 응용 프로그램의 기능
  • 이전 테스트 결과
  • 응용 프로그램과 관련된 위험
  • 이전 결함
  • 최근 변경
  • 테스트에 사용할 데이터 유형
  • 사용할 사용자 유형

테스터에게 무엇을 실행해야하는지 묻는 대신 테스터의 판단에 맡겨서 테스트 할 내용과 테스트 방법을 결정합니다.

탐색 적 테스트와 임시 테스트의 차이점

ET를 혼동하지 마십시오. 임시 테스트 .

  • 임시 테스트는 스크립팅되지 않고 계획되지 않은 즉석에서 결함을 검색하는 프로세스를 의미하는 반면 탐색 테스트는 임시 테스트에 대한 사려 깊은 방법입니다.
  • 애드혹 테스트는 버그를 찾는 히트 앤 트라이얼 방법이지만 ET는 그렇지 않습니다. ET 접근 방식에서 테스터는 획득 한 지식을 사용하여 테스트를 탐색하고 궁극적으로 발전시키면서 시스템에 대해 학습합니다.
  • 임시 테스트는 구조화되지 않은 활동이지만 ET는 다소 구조화 된 활동입니다.

탐색 적 자동 테스트 (EAT)

Exploratory Automated Testing은 테스터가 버그보고 및 복제, 스냅 샷 수집을 간소화하고 향후 회귀 소송을 준비하는 데 도움이되는 방법입니다. 자동화 테스트와 탐색 테스트를 결합하는 프로세스입니다.

EAT 접근 방식에는 두 가지 유형이 있습니다.

  • 패시브 EAT
  • 활성 EAT

패시브 EAT

패시브 EAT는 단일 테스터 또는 쌍으로 수행 할 수 있습니다. 이 방법론에서 일반적으로 테스트 리소스가 수행하는 모든 단일 활동을 캡처하고 기록하고 리소스의 PC에 설치되는 도구입니다.

수동 EAT는 캡처 된 세션을 기반으로 테스트 결과를 작성하는 것 외에 테스트가 실행되는 방식에 변화가 없기 때문에 수동으로 수행되는 ET와 유사합니다. 이러한 테스트 결과는 나중에 기록 된 작업을보고하고 재현하는 데 사용할 수 있습니다.

설치된 비디오 도구는 테스트 케이스 기록 및 결함보고를 통해 테스터를 지원합니다.

또한 다음과 같은 몇 가지 다른 이점도 있습니다.

  • 버그를 재현하기위한 명확한 단계를 제공합니다.
  • 결함 리포터가없는 경우에도 결함 재현이 더 쉽습니다.
  • 간헐적 인 버그가보고 될 때 테스트 팀과 개발 팀 간의 충돌을 없애십시오.
  • 특정 시점에서 시스템 응답 시간을 확보하여 성능 테스트를 지원합니다.

Passive EAT 이전에 고려해야 할 몇 가지 다른 사항은 다음과 같습니다.

  • 도구를 자동화 된 EAT에 완전히 적용하기 전에 파일럿 테스트를 수행하는 것이 좋습니다. 이는 테스트 세션 중에 생성 된 테스트 로그를 재 설계하는 데 필요한 시간이 테스트 실행보다 길지 않도록하기위한 것입니다. 그렇다면 팀은 다음에 대해 상호 결정을 내려야합니다.
    • 특정 프로젝트에 대해 테스트 자동화가 필요한 경우.
    • 사용중인 도구를 변경해야하는 경우.
    • 사용중인 도구의 성능을 최적화 할 수 있습니다.
  • 자동화 된 EAT를 수행하는 데 사용되는 도구는 테스트와 관련된 모든 테스트 리소스에 설치되어야합니다. 개발자에게 VPN을 제공하거나 테스트 머신에 대한 원격 액세스를 제공하거나 개발 환경에 도구를 설치하여 달성 할 수있는 개발자를 참여시키는 것도 좋은 생각입니다.
  • 테스트 도구에 응용 프로그램의 GUI 개체를 구성하여 버그 나 문제를 분석 할 때 의미있는 이름으로 인해 개체를 인식 할 수 있도록하는 것이 항상 좋은 생각입니다.
  • AUT에서 사용되는 GUI 개체에 의미있는 이름을 지정하고 나중에 사용할 수 있도록 구성하는 것이 좋습니다.

이제 두 번째 접근 방식으로 넘어가겠습니다.

활성 EAT

쌍 테스트와 함께 Active EAT를 수행하는 것이 좋습니다. 이 접근 방식에서는 키워드 기반 테스트가 세션 테스트와 동기화되어 사용됩니다. 한 테스터는 자동화 된 테스트 스크립트를 만들고 두 번째 테스터는 첫 번째 테스터가 만든 테스트 스크립트를 실행합니다.

이 접근 방식에서 자동화 테스트 스크립트를 생성하려면 기존 테스트와는 다른 경로가 필요합니다. 자동화 된 테스트 스크립트는 테스트 중에 만들어지며 이전 테스트에서 발견 된 내용이 디자인을 결정합니다.

종료 단계는 테스트 세션이 끝날 때 실행됩니다. 그리고 다음 작업이 있어야합니다.

  • 관련 테스터는 테스트 스크립트를 만든 테스트 리소스가 스크립트를 다시 실행하여 생성 된 제품군의 안정성과 견고성을 확인할 수 있도록 역할을 바꿔야합니다.
  • 모든 자동화 된 테스트 스크립트에 대해 몇 가지 식별 특성과 함께 간략한 설명을 제공해야합니다.
  • 회귀 테스트에 사용할 수있는 자동화 된 테스트 스크립트를 식별하려면 기준을 정의해야합니다.

EAT의 이점

  • 각 세션이 시작될 때 이미 생성 된 자동 테스트 스크립트가 실행되므로 매번 테스트 범위가 향상됩니다.
  • 결함 재현을위한 더 나은 버그보고 및 문서화.
  • EAT는 이해 관계자가 진행 상황을 볼 수 있도록 충분한 증거와 문서를 제공합니다.

탐색 적 테스트의 유형

다음은 몇 가지 유형의 ET입니다.

1) 자유형 및 :

애드혹 스타일의 애플리케이션 탐색.

이 유형의 ET에는 규칙이나 적용 범위에 대한 설명 등이 없습니다. 그러나 이러한 유형의 테스트는 응용 프로그램에 빠르게 익숙해 져야 할 때, 다른 테스터의 작업을 확인하고 싶을 때 유용합니다. 결함을 조사하거나 빠른 연기 테스트를 원합니다.

2) 시나리오 기반 ET :

이름 자체에서 알 수 있듯이 테스트는 시나리오 기반입니다. 실제 사용자의 시나리오, 종단 간 시나리오 또는 테스트 시나리오로 시작합니다. 초기 테스트 후 테스터는 학습 및 관찰에 따라 변형을 주입 할 수 있습니다.

시나리오는 ET 동안 수행 할 작업에 대한 일반적인 가이드와 같습니다. 테스터는 시나리오를 실행하는 동안 가능한 여러 경로를 탐색하여 기능 작업에 대한 가능한 모든 경로를 확인하는 것이 좋습니다. 테스터는 또한 다양한 카테고리에서 가능한 한 많은 시나리오를 수집해야합니다.

3) 전략기반 ET :

탐색 적 테스트와 결합 된 경계 값 분석, 동등성 기술 및 위험 기반 기술과 같은 알려진 테스트 기술. 이러한 유형의 테스트에는 응용 프로그램에 익숙한 숙련 된 테스터 또는 테스터가 지정됩니다.

애자일 탐색 테스트

애자일 환경에서 일한 적이 없더라도 인기가 높아지고 있기 때문에 읽거나 들었을 것입니다. 애자일 방법론에는 짧은 스프린트와 촉박 한 기한이있어 팀이 계획, 추정, 개발, 코딩, 테스트 및 릴리스를 완료하는 데 몇 주가 걸립니다.

이 테스트 접근 방식에서는 빠르고 유용한 결과에 중점을두기 때문에 탐색 테스트는 이러한 촉박 한 기한에 유용합니다. 요구 사항을 이해하면 경험과 지식을 바탕으로 테스트를 시작할 수 있습니다.

애플리케이션 기능 및 동작에 익숙해지면 더 많은 테스트 케이스를 설계하여 애플리케이션 기능을 검증하고 계획되지 않은 버그를 감지 할 수 있습니다. 프리 스타일 테스트 방식이므로 모든 것을 문서화해야합니다. 그러나 테스트 한 내용, 발견 된 버그 및 문제 등에 대한 메모와 간략한 보고서를 유지해야합니다.

애자일 탐색의 장점

  • 개발자에게 최대한 빨리 피드백을 제공합니다.
  • 다양한 결함이 발견됩니다.
  • 개발자, 테스터, BA, 디자이너와 같은 다양한 리소스 그룹은 스크립팅 된 테스트 케이스가없고 각각 다른 관점을 제공하므로 ET를 수행 할 수 있습니다.
  • ET에서 수행되는 스카우트는 새로운 영역을 탐색하고 중요한 버그를 노출하는 데 도움이됩니다.
  • 애플리케이션의 반복적 코딩의 경우 ET는 새로운 기능 테스트에 집중할 수 있으며 자동화는 회귀 및 이전 버전과의 호환성 테스트를 수행합니다.
  • 불안정한 요구 사항의 경우 ET는 제한된 시간 내에 새로운 요구 사항을 테스트하는 데 도움을 줄 수 있습니다.

기억해야 할 사항 :

1. 다른 기술이 필요합니다. ET를 수행하는 테스터는 듣기, 읽기, 사고 및보고 능력이 우수해야합니다. 스크립트 및 테스트 케이스가 없으므로 도메인 경험이 필요합니다.

2. 때때로 어렵습니다 버그보고 : ET 흐름에있는 동안 결함이 발생할 수 있지만 재현하지 못할 수 있습니다. 이는 테스트 단계를 추적하지 않고 문제를 재현하는 정확한 단계를 잊어 버릴 수 있기 때문입니다.

3. 레크리에이션 활동으로 수행 할 수 있습니다. 정기적 인 테스트 실행주기에서 휴식을 원할 때 개인적으로 ET를 수행합니다. 그러나 많은 팀은 테스트주기의 별도 단계로 ET를 사용합니다.

4. 모든 테스트 단계에 대해 수행 할 수 있습니다. 테스트 단계가 시작되기 전에 ET를 구현할 수 있습니다. 기능 테스트 단계 이전에도 ET를 수행 할 수 있습니다.

5. 신속한 피드백 : ET는 문제 및 발생한 모든 이상에 대한 신속한 피드백을 필요로합니다.

6. 비판적 사고 다양한 아이디어 : 이 테스트에는 비판적 사고가 필요합니다. 테스터는 자신의 아이디어를 논리적으로 재현, 검토 및 표현할 수 있어야합니다. 테스터는 작업 한 다양한 기술과 도메인에서 자신의 경험을 구현할 수 있습니다.

탐색 적 테스트에서 전통적인 테스트 경계를 넘어서 생각하는 방법

“제품에 대한 귀하의 관심에 감사 드리며 최종 사용자의 관점을 이해하는 데 도움을주었습니다. 매우 도움이 될 것입니다. 수고 해주셔서 감사합니다.

이것은 우리 고객이 보낸 21 개의 이메일이 포함 된 이메일 체인의 마지막 이메일이었습니다. 자정이었고 우리가 발견 한 심각한 버그로 인해 제품 출시가 지연되었습니다. 새로운 것이 무엇인지 생각할 수 있습니다. 여러 번 발생할 수 있습니다. 그러나 우리가보고 한 중요한 버그가 문서화 된 테스트 케이스의 결과가 아니기 때문에 이것은 정말 달랐습니다.

완료 후 회귀 테스트 그날 저녁 마지막으로 제품을 가지고 놀았습니다. 그게 무슨 뜻입니까? 하지 말아야 할 일을 자유롭게 할 수 있습니다. 내 경험과 프로젝트 지식을 바탕으로 일반적인 테스트 저장소와 별도로 제품을 테스트하는 방법에 대한 아이디어를 얻었습니다. 전화 탐색 적 테스트 .

탐색 테스트를 통해 예기치 않은 작업을 수행하는 동안 서버 중단 문제와 관련된 심각한 버그가 발견되었습니다.

탐색 적 테스트의 팬이기 때문에 다양한 방식으로 제품을 탐색하는 것을 좋아합니다. 저에게 소프트웨어의 정의는 다음과 같습니다.

'해야 할 일을해야하고해서는 안되는 일을해서는 안됩니다.'

탐색 적 테스트 프로세스

작동해야하는 제품이 작동하는지 확인하기 위해 테스트 경계를 제한하면 불완전한 테스터가됩니다. 실제로 테스터의 수명은 문서화 된 회귀 테스트가 종료되고 결과가 업데이트 될 때 시작됩니다. 서로 다른 관점에서 제품을보고 서로 다른 시나리오에서 최종 사용자 요구 사항을 이해하면 큰 차이가 있습니다. 그래서 오늘은 어떻게 그 차이를 만들 수 있는지 함께 이해합시다.

다른 관점에서 제품을 보는 방법?

탐색 적 테스트

#1. 고객 / 최종 사용자 이해

소프트웨어 테스트는 고객 만족 측면에서 제품의 품질을 확인하는 것입니다. 고객의 관점을 어떻게 아십니까? 답은 간단합니다. 고객이되어야합니다. 좋습니다. 수정하겠습니다. 고객이되는 것만으로는 충분하지 않습니다. 고객이 제품을 어떻게 취급하고 싶어하는지 이해해야합니다. 동일한 원료를 구입 한 두 고객은 동일한 레시피를 준비하지 않습니다. 네, 우리가 개발 / 제공하는 제품은 고객 비즈니스의 원재료이며 사용하는 동안 다른 사고 방식을 가지고 있습니다.

소프트웨어 테스터로서 우리는 제품의 목적이나 측면이 아닌 제품의 목적을 확인해야합니다.

실제 실제 사례를 몇 가지 알려 드리겠습니다.

  • 가위는 종이를 자르는 데 국한되지 않았습니다. 절단은 목적이지 종이 (대상)가 아닙니다.
  • 휴대 전화는 통화에만 국한된 것이 아니라 '통화 가능'이 항상 기본 목적이었습니다.
  • 보관함에는 보관함이 사용되지만 보관 된 자재의 안전은 보관만큼 중요합니다.

이해 관계자와 그들의 다양한 기대치를 이해하는 것이 탐색 적 테스트의 기준이되어야합니다.

# 2. 사고 방식

취업 광고를 찾는 동안 (예를 들어) 굵은 글꼴로 된 페이지 사이에 잭팟이 보이나요? 우리 대부분은 그렇지 않습니다 (저를 믿으세요, 사실입니다). 우리의 마음에 무엇이 유용한 지 확인하거나 확인하도록 지시했기 때문입니다. 다른 것은 쓸모가 없으므로 마음은 우리가 그것을 인식하는 것을 거부합니다.

마음을 열고 제품 탐색을 시작할 때 기대치를 설정하지 마십시오. . 항상 기억하세요. 제품이해야 할 일을하고 있다면 괜찮지 않습니다. 해서는 안되는 일을하지 않는 것도 중요합니다.

한 가지 고전적인 예를 기억합니다.

Linux에서는 'cat'명령을 사용하여 파일 내용을 확인하고 'ls'명령을 사용하여 디렉토리 내용을 확인합니다. Linux로 작업하고 5 년 동안 소프트웨어 테스트를하면서 마음이 정해 졌기 때문에 고양이를 할 생각은 없었습니다. dir 콘텐츠가 필요하면‘ls’를 사용해야합니다. 그것은 효과가 있었지만 기대의 반대면은 제품이 예상하지 못한 방식으로 작동해서는 안된다는 것입니다. Linux를 잘 모르는 고객 중 한 명이 실수로 cat을했고 시스템이 충돌했습니다. 우리는이 사고 방식에 대해 지불했습니다.

최종 사용자가 할 일이기 때문에 항상 소프트웨어로 실수 할 준비가되어 있어야합니다. 소프트웨어를 테스트하기 위해 교육을 받았지만 최종 사용자는 교육을받지 못합니다. 그렇지 않으면 그 / 그녀는 당신만큼 기술 전문가가 아닐 것입니다. 또한 문제가 발생하면 소프트웨어로 무엇이든 할 것입니다.

이러한 시나리오에 대해 생각하고 테스트 피드백을 제공하십시오. 소프트웨어와 당신의 (테스터로서)의 삶은 흔들릴 것입니다.

#삼. 경쟁사 파악

클라이언트 용 소프트웨어 응용 프로그램을 테스트하는 동안 동일한 목적을 가진 다른 소프트웨어를 알고 이해하려고 시도한 적이 있습니까? 경쟁사의 제품에서 관찰 한 유용한 기능을 제안한 적이 있습니까? 그것은 우리의 직업 설명에 포함되지 않고 전형적인 대답입니다. 하지만 그렇게하는 것의 이점을 알고 있습니까?

Windows 10 용 시스템 모니터링 도구

요점을 이해하는 데 도움이되는 실제 사례는 다음과 같습니다.

  • 드레스를 꿰맬뿐만 아니라 액세서리 매칭에 대한 의견을 가장 많이 제공하는 디자이너가 마음에 들지 않습니까?
  • 훌륭한 피자를 만들뿐만 아니라 집에서 가장 정시에 배달하는 피자 브랜드가 마음에 들지 않습니까?
  • 좋은 사진을 찍을뿐만 아니라 다른 종류의 프레임을 제안하는 사진가가 마음에 들지 않습니까?

모든 사람들은 자신이 지불하는 것에 대해 추가로 무언가를 원합니다. 경쟁 소프트웨어에 대한 분석은 우리에게도 동일한 방식으로 작동 할 수 있습니다. 고객은 항상 가치있는 제안을 듣고 싶어합니다. 주로 제품을 더 유용하거나 시장성있게 만들기위한 비교 제안입니다.

또한 동일한 범위의 제품에 대한 이러한 종류의 비교 및 ​​분석은 분석을 더욱 강력하게 만들어 결국에는 언제든지 돌아가 유용한 것을 찾을 수있는 보물을 만듭니다.

결론

Exploratory는 기존의 테스트 방식이 아닌 매우 강력한 테스트 방식입니다.

테스터에 대한 즉각적인 생각을 이끌어 내고 결함을 찾기위한 실제 및 실시간 테스트 사례를 제시하도록 권장합니다. 자유형 특성은 다른 테스트 유형보다 우위를 제공하며 Agile 또는 폭포를 사용하는 프로젝트 또는 최소한의 문서화가 필요한 기타 프로젝트 등 어디서나 수행 할 수 있습니다.

탐색 적 테스트의 성공 여부는 테스터의 기술, 효과적인 테스트 케이스를 생성하는 능력, 경험, 직감을 따르는 요령과 같은 수많은 무형 자산에 달려 있습니다.

ET는 예측이 아닌 적응 형 프로세스이며 탐색 적 테스트와 스크립팅 된 테스트 또는 정기적 인 테스트간에 건전한 균형을 유지하는 것이 필수적이라는 점을 기억하는 것이 중요합니다.

일반적인 탐색 테스트 경험이있는 테스터입니까? 여러분의 의견을 기다리고 있습니다. 아래 댓글 섹션에서 자유롭게 공유하십시오.

다음 튜토리얼 # 2: 둘러보기를 사용하여 완전한 탐색 테스트를 보장하는 방법

추천 도서

^