메뉴

임시 테스트 : 공식 테스트 프로세스없이 결함을 찾는 방법

ad hoc testing how find defects without formal testing process

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

임시 용어는 구조가 없거나 체계적이지 않은 것을 의미합니다. 당신이 말할 때 임시 테스트 , 그것은 블랙 박스 또는 공식적인 프로세스없이 수행 된 행동 테스트.

여기서 공식적인 프로세스는 요구 사항 문서, 테스트 계획, 테스트 사례 및 수행 된 테스트의 일정 및 순서와 관련하여 적절한 테스트 계획과 같은 문서를 갖는 것을 의미합니다. 또한 테스트 중에 수행 된 모든 작업은 일반적으로 문서화되지 않습니다.

임시 테스트

이것은 주로 테스트주기 동안 따르는 전통적 또는 공식적인 프로세스를 통해 포착 할 수없는 결함이나 결함을 발견하려는 목적으로 수행됩니다.

이미 이해했듯이이 테스트의 본질은 공식적이거나 구조화 된 테스트 방법이 없다는 데 있습니다. 이러한 종류의 무작위 테스트 기술을 수행하면 테스터는 시스템을 중단하려는 목적으로 특별한 사용 사례를 염두에 두지 않고이를 수행합니다.

따라서 이러한 직관적이거나 창의적인 테스트 방법에는 테스터는 매우 숙련되고 능력이 있으며 시스템에 대한 심층적 노하우를 가지고 있습니다. 임시 테스트는 수행 된 테스트가 완료되었는지 확인하고 특히 테스트 버킷의 효율성을 결정하는 데 매우 유용합니다.

추천 도서=> 탐색 적 테스트 – 기존의 테스트 경계를 넘어서 생각하는 방법?

학습 내용 :

임시 테스트 예제로 시작하겠습니다.

다음은 UI 마법사와 관련하여이 테스트를 수행 할 수있는 방법의 예입니다.

이 UI 마법사를 사용하여 수행 할 일종의 작업에 대한 계획이나 템플릿을 만들어야한다고 가정 해 보겠습니다. 마법사는 이름, 설명 등과 같은 사용자 입력이있는 일련의 창입니다.

마법사가 진행됨에 따라 창 중 하나에 사용자 데이터를 입력하면 UI 마법사가 마법사를 완료하고 마법사를 배포 / 활성화하기 위해 관련 데이터를 추가하는 컨텍스트 팝업 상자가 표시됩니다.

이 테스터를 테스트하기 위해 다음과 같은 정규 테스트를 수행합니다.

테스트 계획 샘플 작성 방법
  • 모든 유효한 데이터를 사용하여 마법사를 성공적으로 완료하고 계획을 만듭니다.
  • 마법사를 중간에 취소합니다.
  • 마법사를 통해 생성 된 계획을 편집합니다.
  • 생성 된 계획을 삭제하고 잔여 물이 없는지 확인하십시오.
  • 마법사에 음수 값을 입력하고 적절한 오류 메시지가 표시되는지 확인합니다.

이제 위의 예에서 다음은 임시 테스트에 대한 몇 가지 테스트 사례입니다. 수행 할 수있는 가능한 한 많은 결함을 발견하려면 :

  • 부정적인 데이터를 추가하는 동안 제한되지 않은 특정 특수 문자를 추가하여 제대로 처리되는지 확인하십시오. 예를 들어, 때때로 마법사는 {또는 (중괄호를 제한하지 않지만 특정 상황에서는 작성된 언어에 기반한 코드와 충돌하여 매우 불안정한 동작을 유발할 수 있습니다.
  • 또 다른 테스트는 팝업과 관련된 것입니다. 사용자는 팝업을 시작한 다음 키보드의 백 스페이스 버튼을 눌러 볼 수 있습니다. 그렇게하면 백그라운드 마법사가 완전히 사라지고 팝업이 시작될 때까지 입력 한 전체 사용자 데이터가 손실되는 것을 여러 번 관찰했습니다!

임시 테스트의 특성 :

위의 시나리오를 살펴보면 이러한 유형의 테스트에서 매우 뚜렷한 특징을 볼 수 있습니다.

그들은:

  • 그들은 항상 테스트 목표와 일치합니다. 그러나 그들은 시스템을 깨기 위해 수행되는 특정 과감한 테스트입니다.
  • 테스터는 테스트중인 시스템에 대한 완전한 지식과 인식이 있어야합니다. 이 테스트의 결과는 테스트 프로세스의 허점을 강조하려는 버그를 찾습니다.
  • 또한 위의 두 테스트를 살펴보면 이에 대한 자연스러운 반응은 다음과 같습니다. 이러한 종류의 테스트는 관련된 결함이없는 한 재 테스트가 불가능하므로 한 번만 수행 할 수 있습니다.

애드혹 테스트는 언제 수행합니까?

정말 백만 달러짜리 질문!

대부분의 테스트 팀은 제한된 시간 내에 테스트 할 수있는 기능이 너무 많아 항상 부담이됩니다. 제한된 시간 동안에도 완료해야하는 공식 프로세스에서 파생 된 테스트 활동이 많이 있습니다. 이러한 상황에서 임시 테스트는 테스트에 들어가는 방법을 찾기가 쉽지 않습니다.

그러나 내 경험에 비추어 볼 때 한 번의 임시 테스트는 제품 품질에 대한 놀라운 일을 할 수 있고 많은 디자인 질문을 제기 할 수 있습니다.

임시 테스트는 구조화 할 필요가없는 '야생'테스트 기술에 가깝기 때문에 현재 테스트 버킷을 실행 한 후에 수행해야하는 것이 일반적입니다. 또 다른 관점은 시간이 짧아 세부 테스트를 수행 할 수 없을 때이를 수행 할 수 있다는 것입니다.

내 견해로는 임시 테스트는 거의 모든 시간에 수행 할 수 있습니다. 처음부터 중간, 끝까지! 주어진 시간에 그 자리를 찾습니다. 그러나 최대 가치를 얻기 위해 임시 테스트를 수행해야하는 경우 테스트중인 시스템에 대한 심층적 인 지식을 가진 숙련 된 테스터가 가장 잘 판단합니다.

언제 실행하지 않습니까?

이전 질문이 백만 달러의 가치가 있었다면 이것은 10 억의 가치가있을 것입니다!

우리는 임시 테스트가 얼마나 효과적이고 유익한지를 확인했지만, 숙련되고 유능한 테스터로서 이러한 유형의 테스트에 투자하지 않을 때도 해독해야합니다. 테스터의 재량이지만 여기에 필요하지 않을 수있는 몇 가지 권장 사항 / 예.

  • 결함이있는 테스트 케이스가있는 경우이 테스트를 피하십시오. 이러한 상황에서는 테스트 케이스 실패 지점을 문서화 한 다음 결함이 수정되면 확인 / 다시 테스트해야합니다. 따라서 여기에서는 적용 할 수 없습니다.
  • 고객 또는 클라이언트가 초대 될 수있는 특정 시나리오가있을 수도 있습니다. 소프트웨어의 베타 버전 테스트 . 이러한 경우이 테스트를 수행해서는 안됩니다.
  • 또 다른 시나리오는 추가 된 매우 간단한 UI 화면이있는 경우입니다. 기존의 양성 및 음성 테스트만으로도 최대 결함을 파악할 수 있습니다.

임시 테스트 유형

임시 테스트는 아래 세 가지 범주로 분류 할 수 있습니다.

# 1) 버디 테스트

이 형식의 테스트에서는 동일한 모듈에서 작업하도록 선택 될 테스트 멤버와 개발 멤버가 있습니다. 직후 개발자가 단위 테스트를 완료합니다. , 테스터와 개발자가 함께 앉아 모듈에서 작업합니다. 이러한 종류의 테스트를 통해 두 당사자 모두에 대해 더 넓은 범위에서 기능을 볼 수 있습니다.

개발자는 테스터가 실행하는 모든 다른 테스트에 대한 관점을 얻고 테스터는 잘못된 시나리오를 설계하는 것을 방지하여 잘못된 결함을 방지하는 데 도움이되는 고유 한 디자인의 관점을 얻게됩니다. 한 사람이 다른 사람을 생각하는 것처럼 생각하는 데 도움이됩니다.

# 2) 쌍 테스트

이 테스트에서는 두 명의 테스터가 동일한 테스트 설정을 공유하는 모듈에서 함께 작업합니다. 두 테스터가 아이디어와 방법을 브레인 스토밍하여 여러 결함을 갖도록하는이 테스트 형식의 아이디어입니다. 둘 다 테스트 작업을 공유하고 모든 관찰에 필요한 문서를 만들 수 있습니다.

# 3) 원숭이 테스트

이 테스트는 주로 단위 테스트 수준에서 수행됩니다. 테스터는 시스템이 충돌을 견딜 수 있는지 확인하기 위해 완전히 임의의 방식으로 데이터를 구문 분석하거나 테스트합니다. 이 테스트는 두 가지 범주로 더 분류 될 수 있습니다.

임시 테스트 이점

테스트는 테스터가 필요한만큼 창의적이되도록 많은 힘을 보증합니다.

이렇게하면 아래와 같이 테스트 품질과 효율성이 향상됩니다.

  • 눈에 띄는 가장 큰 장점은 테스터가 소프트웨어 테스트에 적용 할 수있는 다양한 혁신적인 방법으로 인해 기존 테스트보다 결함 수를 찾을 수 있다는 것입니다.
  • 이 형식의 테스트는 SDLC의 어느 곳에서나 적용 할 수 있습니다. 테스트 팀에만 국한된 것이 아닙니다. 개발자는 또한이 테스트를 수행하여 코딩을 개선하고 발생할 수있는 문제를 예측할 수 있습니다.
  • 정기적 인 테스트에 필요한 시간을 단축 할 수있는 최상의 결과를 얻기 위해 다른 테스트와 결합 할 수 있습니다. 이를 통해 더 나은 품질의 테스트 케이스를 생성하고 전체적으로 제품의 품질을 높일 수 있습니다.
  • 테스터의 추가 부담을 방지하는 문서를 작성하도록 요구하지 않습니다. 테스터는 기본 아키텍처를 실제로 이해하는 데 집중할 수 있습니다.
  • 테스트 할 시간이 많지 않은 경우 테스트 범위 및 품질 측면에서 매우 유용 할 수 있습니다.

임시 테스트 단점

임시 테스트에도 몇 가지 단점이 있습니다. 몇 가지를 살펴 보겠습니다. 뚜렷한 단점 :

매우 체계적이지 않고 필수 문서가 없기 때문에 가장 분명한 문제는 테스터가 임시 시나리오의 모든 세부 정보를 기억하고 기억해야한다는 것입니다. 이는 특히 서로 다른 구성 요소간에 많은 상호 작용이있는 시나리오에서 훨씬 더 어려울 수 있습니다.

  • 첫 번째 요점부터 이어지면 정보를 요청하면 후속 시도에서 결함을 재현 할 수 없게됩니다.
  • 이것이 밝혀내는 또 다른 매우 중요한 질문은 노력의 책임입니다. 이것은 계획 / 구조화되지 않았기 때문에 이러한 종류의 테스트에 투자 된 시간과 노력을 설명 할 방법이 없습니다.
  • 임시 테스트는 잠재적 인 결함 발생 영역을 예측하는 측면에서 사전 예방적이고 직관적이어야하므로 팀에서 매우 지식이 풍부하고 숙련 된 테스터 만 수행해야합니다.

이 테스트를보다 효과적으로 만들기위한 모범 사례

우리는이 테스트와 관련된 강점과 약점을 길게 논의했습니다.

이상적으로는 임시 테스트가 SDLC에서 그 자리를 찾아야하지만 적절한 방식으로 접근하지 않으면 비용이 많이 들고 귀중한 테스트 시간이 낭비 될 수 있습니다. 따라서 다음은 임시 테스트를 효과적으로 수행하기위한 몇 가지 지침입니다.

# 1) 결함이 발생하기 쉬운 영역 식별 :

특정 소프트웨어를 테스트하는 것을 잘 지키면 다른 것보다 오류가 발생하기 쉬운 특정 기능이 있다는 데 동의하게됩니다. 시스템을 처음 사용하는 경우 계속해서 기능 대 결함을 확인하십시오.

특정 기능의 결함 수는 해당 기능이 민감하다는 것을 보여 주며 임시 테스트를 수행 할 해당 영역을 정확하게 선택해야합니다. 이것은 심각한 결함을 노출하는 매우 시간 효율적인 방법임이 입증되었습니다.

# 2) 전문성 구축 :

YouTube를 mp3 무료로 안전하게 변환

의심 할 여지없이 경험이 많은 테스터는 경험이 많지 않은 사람에 비해 더 직관적이며 오류가 어디에 있는지 추측 할 수 있습니다. 경험이 있든 없든, 테스트 대상 시스템에 뛰어 들고 전문성을 구축하는 것은 개인의 몫입니다.

예, 숙련 된 테스터는 수년 동안 축적 된 기술이 유용하기 때문에 우위를 가지고 있지만, 새로운 테스터는이를 플랫폼으로 사용하여 더 나은 임시 시나리오를 설계하기 위해 가능한 한 많은 지식을 얻어야합니다.

# 3) 테스트 카테고리 만들기 :

테스트 할 기능 목록을 알고 있으면 이러한 기능을 분류하고 테스트하는 방법을 결정하는 데 몇 분을 할애하십시오. 예를 들어, 소프트웨어의 성공에 중요해 보일 수 있으므로 사용자가 가장 잘 보이고 가장 일반적으로 사용하는 기능을 먼저 테스트해야합니다.

그런 다음 기능 / 우선 순위를 분류하고 세그먼트별로 테스트 할 수 있습니다.

이것이 특히 매우 중요한 또 다른 예는 구성 요소 또는 모듈 간의 통합이있는 경우입니다. 이러한 경우 발생할 수있는 많은 이상이있을 수 있습니다. 분류를 사용하면 이러한 종류의 테스트를 적어도 한 두 번 다루는 데 도움이됩니다.

# 4) 대략적인 계획을 세우십시오.

예, 예,이 점은 애드혹 테스트를 계획이나 문서가 없어야하는 테스트로 설명 했으므로 약간 혼란 스러울 수 있습니다. 여기서 아이디어는 임시 테스트의 본질을 고수하지만 테스트 계획에 대한 대략적인 지침을 적어 두는 것입니다.

매우 기본적인 예는 때때로 수행하려는 모든 테스트를 기억하지 못할 수도 있다는 것입니다. 따라서 적어두면 어떤 것도 놓치는 일이 없습니다.

# 5) 도구 :

우리 모두가 매우 일반적으로 직면하는 예를 들어 보겠습니다. 관찰하면 많은 경우 기능 자체의 테스트가 성공하며 동작에 불일치가보고되지 않습니다. 그러나이면의 로그는 어떤 식 으로든 테스트 목표를 방해하지 않기 때문에 테스터가 놓칠 수있는 몇 가지 예외를보고 할 수 있습니다.

심각도가 높을 수도 있습니다. 따라서이를 즉시 파악하는 데 도움이되는 학습 도구와 도구가 매우 중요합니다.

# 6) 더 많은 결함에 대한 문서 :

다시 말하지만, 이것이 다시 눈썹을 올릴 수 있음을 이해합니다. 문서를 자세히 설명 할 필요는 없지만 다루는 모든 다양한 시나리오, 관련된 단계의 편차, 특정 테스트 기능 범주에 대한 결함 기록을 직접 참조 할 수있는 작은 메모입니다.

이는 전체 테스트 버킷을 개선하는 데 도움이 될뿐만 아니라 기존 테스트 케이스를 즉석에서 수정하거나 필요한 경우 추가하는 방법을 결정할 수 있습니다.

결론

애드혹 테스트 기법 (강점, 약점, 유익한 상황과 그렇지 않은 상황)에 대해 자세히 논의했습니다.

이것은 테스터의 창의성을 최대한으로 충족시키고 만족시킬 수있는 하나의 테스트 기술입니다. 내 전체에서 테스트 경력 , 혁신에 제한이없고 지식이 더 많아지기 때문에 임시 테스트에서 최고의 만족을 얻습니다.

하지만 위의 모든 정보에서 되돌려 야 할 가장 중요한 것은 임시 테스트 강점을 활용하고 전체 테스트 프로세스 및 제품 품질에 가치를 더하는 방법을 결정합니다.

저자 정보 : 이것은 Sneha Nadig의 게스트 기사입니다. 그녀는 수동 및 자동화 테스트 프로젝트에서 7 년 이상의 경험을 가진 테스트 리드로 일하고 있습니다.

프로젝트에서 임시 테스트를 수행합니까? 임시 테스트를 성공적으로 수행하기위한 제안 사항은 무엇입니까?

추천 도서

^