40 개 이상의 인기 테스트 QA 분석가 인터뷰 질문 및 답변 (2021 목록)

40 popular test qa analyst interview questions

가장 자주 묻는 테스트 / 품질 보증 분석가 인터뷰 질문 및 답변 :

자신이되고 싶은 커리어를 결정할 때 결정적인 요소는 일하는 것을 즐길 수 있다고 생각하는 사람 만이 아닙니다.

그러나 그 범주에 속하기 위해서는 많은 기술이 필요하며 선택한 직업에 필요한 직무뿐만 아니라 책임을 이해해야합니다. QA 분석가로 경력을 선택하는 경우에도 마찬가지입니다. 그것은 당신이 좋은 테스터, 빠른 학습자, 비범 한 사고력을 요구할뿐만 아니라 복잡한 문제 해결사도 요구합니다.

위에서 언급 한 자질이 즉시 달성되는 것은 아니지만 분명히 경험과 노력이 필요합니다.

이 기사에서는 QA 분석가가되기 위해 지식이 필수 인 모든 측면을 다룹니다. 여기에 포함 된 가장 자주 묻는 QA 테스트 분석가 인터뷰 질문과 답변은 인터뷰 준비에 대한 명확한 아이디어를 제공합니다.

인기있는 QA 테스트 분석가 인터뷰 질문

Q # 1) QA 분석가의 책임은 무엇입니까?

대답: QA 분석가는 소프트웨어 솔루션의 각 기능을 기능 및 기술적으로 테스트하기 위해 가능한 모든 조치를 취했는지 확인하는 사람입니다.

QA Analyst의 주요 책임은 다음과 같이 등록 할 수 있습니다.

• 테스트 계획의 목표를 충족하기 위해 모든 활동을 실행하고 관리합니다.
• 제품 개발을 위해 고품질 프로세스를 선택하십시오.
• 요구 사항을 분석하고 절차를 문서화 할 수 있어야합니다.
• 모든 결함을 문서화하고 다시 확인합니다. 결함의 우선 순위와 심각도를 설정합니다.
• 테스트 케이스를 작성, 문서화 및 유지할 수 있어야합니다.
• 테스트 결과 분석.

Q # 2) 테스트 계획에 대해 어떻게 이해하고 있습니까?

대답: 무엇을, 언제, 어떻게, 누구에게 분명하게 알면 일이 더 쉬워집니다. 소프트웨어 테스트의 경우도 마찬가지입니다. 여기서 테스트 계획은 테스트 프로젝트의 범위, 접근 방식, 리소스 및 개요와 프로젝트 진행 상황을 추적하기위한 활동으로 구성된 문서입니다.

테스트 계획은 다음을 포함하는 프로세스의 기록입니다.

• 테스트 작업
• 테스트 환경
• 디자인 기술
• 입장 및 퇴장 기준
• 모든 위험 등

Q # 3) 제품 개발에서 QA 팀이 정의한 테스트 작업의 우선 순위를 입력합니다.

대답: 테스트 작업의 우선 순위는 다음과 같이 정의됩니다.

• 테스트 프로젝트의 개요와 범위로 구성된 테스트 계획이 준비됩니다.
• 테스트 케이스는 테스트에 필요한 데이터와 함께 모든 주요 기능과 작은 기능을 포함하도록 준비되어 있습니다.
• 테스트주기에서 테스트 프로젝트의 향후 빌드로 구현되는 기능에 따라 테스트 케이스 실행.
• 재확인 및 진행 상황 추적을 통한 결함보고.
• 테스트 실행 보고서 요약을 준비합니다.

Q # 4) 소프트웨어 테스팅을 수행하는 동안 직면 한 몇 가지 주요 과제를 입력하십시오.

대답: 완전한 테스트는 결코 달성 할 수 없다고 말했듯이 여기에는 몇 가지 문제가 있습니다. 작든 복잡하든 모든 프로젝트의 소프트웨어 테스트를 수행하는 동안 직면하게되는 몇 가지 문제가 있습니다.

다음은 몇 가지 주요 과제입니다.

• 일반적으로 주제 인식 문제와 고객 비즈니스에 대한 좋은 지식 부족에 직면하는 숙련 된 테스터 부족.
• 일반적으로 테스터는 완료해야 할 작업 목록이 많을 때 품질 테스트를 통해 테스트 범위보다 작업 범위에 주로 집중하기 때문에 시간도 요소로 간주됩니다.
• 먼저 실행해야하는 테스트 케이스를 우선 순위로 결정합니다. 이것은 일반적으로 일의 경험에 의해 달성됩니다.
• 요구 사항을 잘못 이해 한 경우 모든 테스트 노력을 제로로 만들 수있는 요구 사항에 대한 적절한 이해.
• 더 적은 시간과 더 많은 효율성으로 테스트를 완료하는 데 필요한 최고의 도구를 사용할 수 없습니다.
• 좋은 의사 소통과 분석 기술로 테스터와 개발자 간의 관계를 처리합니다.

Q # 5) 사용 사례 테스트 정의.

대답: 사용 사례 테스트는 '액터'와 '시스템'간에 발생한 일련의 상호 작용을 캡처하는 기능적 블랙 박스 테스트 기술로 정의 할 수 있습니다. 여기서 '액터'는 사용자와 상호 작용으로 표현됩니다.

사용 사례 테스트의 특성은 다음과 같습니다.

• 프로젝트의 기능적 요구 사항이 구성됩니다.
• 처음부터 끝까지 경로 또는 시나리오를 기록합니다.
• 통합 결함, 즉 서로 다른 구성 요소 간의 상호 작용의 결과로 발생한 결함을 다룰 수 있습니다.
• 이벤트의 주요 흐름과 예외적 인 흐름을 설명합니다.
• 사용 사례가 작동하는 데 필요한 전제 조건은 더 일찍 지정해야합니다.

Q # 6) 테스트 전략을 정의하십시오.

대답: 테스트 설계 및 일반 테스트 접근 방식을 결정하기 위해 프로젝트 관리자가 일반적으로 수행하는 일련의 지침 또는 테스트 접근 방식을 테스트 전략으로 정의합니다. 테스트 계획의 작은 부분으로 발견되며 여러 프로젝트에서 사용됩니다.

제품의 특성 및 도메인, 제품 실패 위험, 제안 된 도구 작업에 대한 전문 지식 등과 같은 요인을 기반으로 다양한 테스트 접근 방식을 따릅니다.

이러한 접근 방식은 다음과 같이 추가로 분류됩니다.

• 사전 예방 적 접근 , 빌드가 생성되기 전에 테스트 설계 방식이 시작됩니다. 따라서 빌드 전에 버그를 찾고 수정하는 데 도움이됩니다.
• 반응 적 접근 , 테스트 설계 및 코딩 완료 후 테스트 접근 방식이 시작됩니다.

Q # 7) 품질 관리와 품질 보증의 차이점을 설명하십시오.

대답: '품질 관리' 과 '품질 보증' 테스트 프로젝트 또는 제품과 관련하여 사용되는 두 가지 주요 용어입니다. 일반적으로이 분야를 처음 접하는 테스터는 둘의 실제 차이점을 이해하지 못합니다.

아래 표의 도움으로 차이점을 이해합시다.

Q # 8) 프로젝트에서 QA를 시작하기에 좋은시기는 언제인가요?

대답: SDLC (Software Development Life Cycle)에 따르면 테스트 단계는 '구현 및 코딩'단계가 완료된 후 실행됩니다. 그러나 오늘날의 시나리오에서 최상의 결과를 얻으려면 프로젝트를 시작할 때 프로젝트 또는 제품의 QA를 시작해야합니다.

이 접근 방식을 따르면 다음과 같은 주요 이점이 있습니다.

• 고객의 품질 기대치를 충족하기위한 초기 프로세스 계획.
• 팀 간의 좋은 의사 소통.
• 테스트 환경을 설정하는 데 필요한 충분한 시간을 제공합니다.
• 테스트 계획을 조기에 검토하고 승인 할 수 있습니다.

Q # 9) 검증 및 검증 프로세스를 차별화하십시오.

대답: 검증 및 검증 프로세스는 일반적으로 두 가지 유명한 질문에 의해 결정됩니다. 우리가 시스템을 구축하고 있습니까?” 과 '올바른 시스템을 구축하고 있습니까?' .

아래 표에서이 두 프로세스의 다른 차이점을 살펴 보겠습니다.

Q # 10) 파괴 테스트의 이점을 설명하십시오.

대답: 파괴 테스트는 다양한 하중에서 제품의 고장 지점을 결정하기 위해 테스트 팀이 수행하는 테스트 형식으로 정의됩니다. 즉, 강도, 인성, 경도를 결정하거나 견고성을 결정하기 위해 애플리케이션 구조 성능을 평가합니다.

다음은 파괴 테스트의 이점입니다.

• 애플리케이션 설계의 약점이 결정됩니다.
• 응용 프로그램의 서비스 수명을 결정하십시오.
• 비용과 실패를 줄이는 데 도움이됩니다.

Q # 11) 재 테스트는 회귀 테스트와 어떻게 다릅니 까?

대답: 재 테스트와 회귀 테스트에는 몇 가지 차이점이 있습니다.

이것은 아래 표에서 쉽게 이해할 수 있습니다.

Q # 12) 데이터 기반 테스트에 대해 무엇을 알고 있습니까?

대답: 자동화 테스트 스크립트가 기록 된 사용자 작업 시퀀스로 테스트 할 애플리케이션 영역 만 포함한다는 것은 모든 자동화 테스터에게 분명합니다. 일반적으로 이러한 작업은 기록 중에 입력 한 조건 하에서 입력 데이터 만 수행되므로 오류가 발생하지 않습니다.

데이터 기반 테스트는 여기에서 애플리케이션이 모든 유형의 입력 값에 대해 예상대로 작동하기를 원합니다. 이를 위해 데이터 기반 테스트에 필요한 데이터는 하드 코딩되지 않지만 테스트 스크립트는 CSV 파일, ODBC 소스 등과 같은 데이터 소스에서 데이터를 가져옵니다.

요약하면 데이터 기반 테스트는 루프에서 다음 작업을 수행합니다.

Mac에서 dat 파일을 어떻게 열지

• 저장소에서 입력 테스트 데이터를 가져옵니다.
• 작업을 수행하기 위해 응용 프로그램에 입력 된 데이터입니다.
• 예상되는 결과로 실제 결과를 확인하십시오.
• 새 입력 테스트 데이터로 동일한 단계를 다시 반복하십시오.

Q # 13) 추적 성 매트릭스는 무엇입니까? 모든 프로젝트에 필요합니까?

대답: 모든 프로젝트의 추적 성 매트릭스는 새로운 기능의 구현, 기존 기능의 향상 등과 관련된 프로젝트의 진행 상황을 추적하는 수단입니다. 추적 성 매트릭스를 통해 항상 모든 측면을 유지하면서 프로젝트 진행 상황을 주시 할 수 있습니다. 날짜.

요구 사항 추적 성 매트릭스는 실제로 요구 사항 사양 문서에 따라 아래에 언급 된 매개 변수로 구성됩니다.

요구 사항 추적 성 매트릭스의 매개 변수는 다음과 같습니다.

• 요구 사항 문서의 모든 섹션은 RTM (Requirement Traceability Matrix)에서 다루어야 할 지점입니다.
• 각 요점의 헤드 라인은 요구 사항 사양에있는 각 섹션의 헤드 라인입니다.
• 각 포인트에 따라 해당 특정 섹션에 대해 작성된 테스트 케이스 ID가 언급됩니다.
• 버그 / 새 기능 ID도 각 섹션에 언급되어 있습니다.
• 가장 중요한 점은 프로젝트 빌드 및 기능이 구현 된 기능 추적도 유지된다는 것입니다.
• 또 다른 매개 변수에는 섹션이 완전히 테스트되었는지 또는 아직 테스트 중인지 여부가 포함됩니다.

Q # 14) 애자일 테스트의 이점을 설명하십시오.

대답: 테스터로서 초점은 최종 사용자 요구 사항을 이해하고 가장 중요한 것은 최종 사용자 측의 결함이 없다는 점을 이해함으로써 더 짧은 시간에 양질의 제품을 제공하는 것입니다. 여기서 애자일 테스트는 애자일 소프트웨어 개발의 원칙을 따르고 클라이언트의 요구 사항을 신속하게 검증하는 그림에 나와 있습니다.

다음은 애자일 테스트의 이점입니다.

• 교차 기능 애자일 팀이 테스트에 포함되어 결과를 빈번한 간격으로 제공합니다.
• 많은 시간과 비용을 절약합니다.
• 문서화 및 최종 사용자의 피드백이 적습니다.
• 테스터뿐만 아니라 관리자, 고객, 개발자를 포함한 전체 팀이 대면 커뮤니케이션에 참여합니다.
• 매일 회의의 결과로 문제를 미리 잘 결정할 수 있습니다.
• 팀 생산성을 높이고 프로젝트의 기술적 측면을 더 잘 이해합니다.

Q # 15) 음성 검사 란 무엇입니까?

대답: 네거티브 테스트는 제품 또는 애플리케이션의 안정성이 유지되는지 확인하거나 예상치 못한 입력이 제공 될 때 실패하지 않는다는 것을 확인하는 방법입니다. 이 형식의 테스트의 주요 목적은 가능한 잘못된 입력 데이터에 대해 응용 프로그램의 유효성을 검사하는 것입니다.

이러한 형태의 테스트는 다음과 같이 알려져 있습니다. '실패 테스트'또는 '오류 경로 테스트' 주요 목적은 부정적인 시나리오에서 응용 프로그램 기능의 신뢰성을 확인하는 것입니다. 또한 소프트웨어 약점을 드러내고 결함을 발견하며 데이터 손상에 대한 명확한 아이디어를 제공합니다.

Q # 16) 임시 테스트와 탐색 테스트를 차별화합니까?

대답: 임시 테스트와 탐색 테스트에는 몇 가지 차이점이 있습니다.

아래 표에서 차이점을 확인하십시오.

Q # 17) 자동화 테스트가 수동 테스트보다 선호되는 이유는 무엇입니까?

대답: 글쎄요, 자동화 테스트와 수동 테스트는 모두 테스트 세계에서 중요성과 존재를 가지고 있습니다.

다음은 수동 테스트보다 자동화 테스트가 선호되는 몇 가지 중요한 측면입니다.

• 테스트를 실행할 때마다 동일한 테스트 스크립트를 사용할 수 있으므로 자동화 테스트가 가장 안정적이고 효율적인 것으로 간주됩니다.
• 회귀 테스트 및 반복 실행의 경우 가장 선호됩니다.
• 자동화 테스트는 장기 실행의 경우 비용 효율적인 것으로 간주되어 더 나은 소프트웨어 품질을 보장합니다.
• 테스트 스크립트는 재사용 가능하고 빠르며 모든 사람이 결과를 볼 수 있습니다.
• 자동화 테스트에 사용되는 도구는 수동 접근 방식에 비해 더 빠르고 안정적입니다.

그러나 몇 가지 더 많은 요인이 자동화 테스트가 수동 테스트보다 선호된다는 것을 결정합니다. 위에서 언급 한 것이 주요 요인입니다.

Q # 18) '테스트 효율성'과 '테스트 효율성'에서 무엇을 이해하고 있습니까?

답변 : 테스트 효율성 특정 기능을 수행하거나 실행하는 데 사용되는 리소스 및 테스트 코드의 수를 계산하는 것으로 정의 할 수 있습니다. 또한 소프트웨어 제품 생성에 사용되는 리소스 수를 결정합니다.

이것은 다음 공식에 의해 결정될 수 있습니다.

테스트 효율성 = (해결 된 결함 수 / 제출 된 총 결함 수) * 100

테스트 효과 테스트 환경과 소프트웨어 애플리케이션에 미치는 영향을 평가하는 척도로 정의 할 수 있습니다. 여기서 고객 응답은 애플리케이션 요구 사항이 충족 될 때 평가됩니다.

이것은 다음 공식에 의해 결정될 수 있습니다.

테스트 효과 = (발견 된 결함 수 / 실행 된 테스트 케이스 수)

Q # 19) 프로젝트 테일러링 과정을 설명하세요.

대답: 프로젝트 조정은 프로젝트의 성과가 정확하고 비즈니스 요구 사항에 부합하는지 확인하는 일관되고 지속적인 프로세스입니다. 전체 프로세스에는 조직의 현재 운영 요구 사항에 따라 프로젝트 데이터를 검토하고 수정하는 작업이 포함됩니다.

검토 프로세스는 조직 수준에서 수행되지만 맞춤 계획의 구현은 프로젝트 수준에서 수행됩니다. 조직의 주요 목표와 요구 사항은 물론 고객과 사용자 관계도 프로세스에서 고려해야 할 두 가지 주요 요소입니다.

조정 프로세스에서 조직 목표에 따른 몇 가지 측면은 다음과 같습니다.

• 프로젝트 접근
• 전략
• 관련된 제어 및 프로세스
• 역할과 책임

Q # 20) 프로젝트 내 결함의 우선 순위와 심각도를 어떻게 구별합니까?

대답: '우선 순위'와 '심각도'모두 버그에 할당되어 문제 / 버그를 수정을 위해 취해야 할 순서대로 분류합니다. 이는 다양한 요인을 기반으로합니다.

아래 표의 차이점과 함께 더 많은 것을 이해합시다.

Q # 21) 모든 애플리케이션에 대해 성능 테스트를 수행해야하는 이유는 무엇입니까?

대답: 간단한 언어로 성능 테스트는 다양한 상황에서 애플리케이션의 동작과 응답을 결정하기 위해 수행됩니다. 이는 애플리케이션 안정성, 확장 성, 속도 등에 관한 정보를 수집하는 데 도움이됩니다.

성능 테스트를 수행하는 이유는 아래에서 이해할 수 있습니다.

• 워크로드에서 애플리케이션 구성 요소의 응답 시간과 성능을 결정합니다.
• 사용자 활동의 응답 시간이 계산됩니다.
• 광범위한 기술 언어를 가진 숙련 된 프로그래머가 필요합니다.
• 로드중인 애플리케이션의 동작을 결정합니다. 즉, 사용자 수가 즉시 증가하는 경우입니다.

Q # 22) 사양 기반 테스트 란 무엇입니까?

대답: 이름 자체에서 정의한대로 사양 기반 테스트는 수행 된 테스트의 기반이되는 기능 사양이있는 응용 프로그램의 요구 사항 사양을 기반으로 수행됩니다.

이러한 형태의 테스트는 사용자가 여러 데이터를 입력하고 출력을 관찰하는 '블랙 박스 테스트'와 동일합니다. 사양 및 테스트 계획으로 모든 수준의 테스트에 적합합니다.

Q # 23) CMMI를 설명하십시오.

대답: CMMI는 Capability Maturity Model Integration을 나타냅니다. 이 모델은 SEI (Software Engineering Institute)에서 개발했습니다. 제품 또는 시스템을 관리하고 개발하는 데 관련된 프로세스가 품질을 결정한다는 원칙을 기반으로합니다.

또한 제품 또는 전체 조직에 대한 프로세스 개선 지침을 제공합니다.

CMMI는 다음과 같이 5 단계로 나뉩니다.

• 레벨 1: 머리 글자
• 2 단계: 관리
• 레벨 3 : 한정된
• 레벨 4 : 양적 관리
• 레벨 5 : 최적화 됨

Q # 24) CMMI 구현의 장점을 설명하십시오.

대답: CMMI를 구현하면 몇 가지 이점이 있습니다.

다음과 같이 나열됩니다.

• 제품 라이프 사이클에 대한 자세한 적용 범위와보고를 제공하므로 프로세스 개선에 도움이됩니다.
• 조직의 기존 표준, 프로세스 및 절차는 CMMI 구현의 일부로 개선됩니다.
• CMMI 구현의 결과로 정시 배송과 고객 만족도가 향상되었습니다.
• 또한 오류를 조기에 발견하므로 효과적인 관리와 비용 절감으로 이어집니다.

Q # 25) 일부 자동화 테스트 도구를 등록하십시오.

대답: 자동화 테스트 도구 중 일부는 다음과 같습니다.

• 셀렌
• 물
• 풍차 비슷한 것
• 비누
• 텔루르

Q # 26) 단위 테스트에서 회귀 테스트를 할 수 있습니까?

대답: 명확히. 회귀 테스트는 다른 결함 수정의 부작용으로 코드에 도입되었을 수있는 원치 않는 결함을 테스트하는 것입니다. 단위 테스트는 코드의 작고 독립적 인 부분을 실행하는 테스트 실행입니다.

회귀 테스트는 단위 테스트에서 통합 테스트, 최종 승인 테스트에 이르기까지 모든 수준에서 수행 할 수 있습니다. 회귀 테스트는 관점을 기반으로 테스트하는 반면 단위 테스트는 수준 (Bottom Up, Top-down) 접근 방식입니다.

문 # 27) 연기 테스트와 Sanity 테스트의 차이점은 무엇입니까?

대답:

• 스모크 테스트는 빌드의 이전 눈에 띄는 기능 또는 기존 기능을 테스트하는 반면, Sanity 테스트는 새로 추가 된 모듈, 빌드의 수정 된 결함에 대한 검증입니다.
• 연기 테스트가 먼저 수행 된 다음 Sanity 테스트가 이어집니다.
• 연기 테스트는 소프트웨어가 제공하는 중요한 기능의 테스트를 포함하므로 소프트웨어 전체에 걸쳐 확장됩니다. 반면, 온 전성 테스트는 최근에 추가 된 모듈로 좁혀지고 심층적으로 테스트됩니다.

문 # 28) 사무실에서 수동 테스터로서 일상적인 활동은 무엇입니까?

안내서: 시스템에서 가장 먼저 확인하는 것은 현재 반복의 요구 사항 / 개선 사항 또는 버그 상태에 대한 대시 보드를 새로 고치는 것입니다. 그 다음에는 테스트 시나리오 및 테스트 사례로 정의하기위한 일일 스크럼 통화 및보고, 토론 및 브레인 스토밍 세션이 이어집니다.

이러한 사례는 검토에 따라 재 작성한 후 실행됩니다. 비 기능적 요구 사항에 대해 고객과 연락하는 것 또한 제 업무의 주요 활동 중 하나입니다.

문 # 29) 사무실에서 자동화 테스터의 일원으로서 일상적인 활동은 무엇입니까?

오토메이션: 나의 하루는 새 빌드에서 테스트 케이스를 실행 한 경우 어제의 자동화 결과를 논의하는 일일 상태 회의로 시작됩니다.

실행주기를 Health Check라고하여 빌드의 상태를 확인할 수 있습니다.

그 다음에는 스크립트 실패, 기능의 디자인 변경을 기반으로 결함을보고합니다. 스크립트 / 라이브러리 또는 함수를 유지하고, 새로운 요구 사항에 대해 새 스크립트를 자동화하고 체크인하고 필요한 경우 함수 라이브러리의 새 함수를 체크인합니다.

때로는 자동화를 통해 회귀 결함을 찾아 테스트 스위트에도 추가하기 위해 테스트 스크립트를 개별적으로 다시 실행해야합니다.

Q # 30) 요구 사항과 결함 및 개선 사항을 어떻게 구별합니까?

대답 : TO 요구 사항 구현, 테스트 및 전달에 필수적인 사용자 스토리입니다.
안 상승 기존 기능에 추가되거나 즉석에서 추가 된 기능입니다.
에 결함 예상되는 사용자 스토리에서 완전히 벗어난 것입니다.

또한 사양에 달리 명시되지 않는 한 요구 사항의 특정 영역을 결함이 발견하면 요구 사항 또는 그 일부라고도 할 수 있습니다.

문 # 31) 개발자가 제출 한 버그 수정을 거부하면 어떻게합니까?

대답 : 결함 수정을 결정하는 중요한 요소는 할당 된 '우선 순위'입니다. 결함이 우선 순위가 높은 경우 주요 기능을 차단하고 지속적으로 재현되는 쇼 스토퍼는 빌드에서 수정해야합니다.

테스터와 개발자가 함께 배송 할 제품의 품질에 기여하기 때문에 동일한 내용이 개발자에게 효과적으로 전달되어야합니다.

개발자가 짧은 기간 내에 버그를 수정하도록 설득하는 데 도움이 될 수있는 다른 측면은 버그에 대한 품질보고와 개발자가 릴리스에서 버그 수정이 가장 중요하다는 사실을 이해하도록하는 것입니다.

문 # 32) 개발자가 제출 한 내용이 버그라는 것을 부인할 때 어떻게합니까?

대답 : 결함 수명주기의 가장 중요한 단계는 '거부 됨'으로 기록 된 사건 보고서가 유효하지 않음을 의미합니다. 요구 사항을 설명하는 비즈니스 요구 사항 문서는 소프트웨어 및보고 된 사건의 성격을 이해하는 데 도움이 될 수 있습니다.

버그를 분석하고 버그에 대한 결과를 개발자와 팀에 공개합니다. 결함 인 경우 기록에 실패하지 마십시오. 때때로 테스터는 갭 분석을 제공하고 개발자에게이를 제시해야합니다. 그래도 갈등이 해결되지 않으면 팀의 선배들이 참여해야합니다.

문 # 33) 먼저 재 테스트 또는 회귀 테스트는 무엇입니까?

대답 : 코드를 재실행하기 때문에 재 테스트가 먼저 발생합니다. 간단히 말해서 미리 정의 된 단계를 반복적으로 실행하는 것입니다. 코드를 수정 한 후에는 필요하지 않습니다. 그러나 회귀 테스트는 해결 된 결함의 부작용을 평가하는 것입니다.

확실히 하나의 결함을 해결하고 다른 하나를 코드에 추가하는 것은 테스트 프로세스의 목적이 아닙니다. 테스터의 가장 좋은 발견과 가장 좋은 발견은 일반적으로 회귀 결함입니다. 회귀 테스트없이 빌드를 릴리스해서는 안됩니다.

문 # 34) 베타 테스트의 대안은 무엇입니까?

대답 : 베타 테스트는 개발자의 개입이 가장 적은 클라이언트 사이트에서 진행되며 실제 프로덕션 환경의 오류를 기록합니다. 그러한 관행이 회사에서 수행되지 않는 경우 더 안전한 아이디어는 최신 빌드를 얻기 위해 대기열에 있지 않은 고객에게 먼저 제품을 배송하는 것입니다.

며칠 동안 클라이언트 구내의 특정 서비스 컨설턴트는 소프트웨어를 사용하고 환경에서 릴리스의 안정성을 보장하는 활동을 기록 및 모니터링 할 수 있으므로 주요 버그가 수정되지 않은 경우에도 사전에 테스트 할 수 있습니다. 대상 클라이언트에 전달합니다. 또 다른 접근 방식은 편향되지 않은 테스트를 위해 팀 내 요구 사항의 교체 테스트입니다.

문 # 35) 애자일 구현 / 방법론의 단점은 무엇입니까?

대답 : 단점은 다음과 같습니다.

1. 스프린트는 일반적으로 마감일이 매우 제한적입니다.
2. 문서화가 우선이 아닙니다
3. PBI (제품 백 로그 항목) 간 전환이 빈번 할 수 있습니다.

문 # 36) 영향 분석이 중요한 이유는 무엇입니까?

대답 : 리스크 기반을 실천하기 위해서는 영향 분석이 이루어져야합니다. 이를 통해 고객의 관점에서 중요한 모든 심각한 버그를 시간 전에 해결할 수있는 방식으로 테스트 케이스를 설계 할 수 있습니다. 비즈니스, 고객의 요구 및 소프트웨어 사용에 대한 좋은 연구가 이루어져야합니다.

예를 들어, 은행 도메인의 소프트웨어와 관련된 가장 중요한 위험은 보안입니다. 이미 존재하는 소프트웨어에 추가 된 새로운 양식은 취약 할 수 있습니다. 적절한 링크, 리디렉션 및 탐색을 적절한 페이지에 추가하고 필요한 경우 프록시를 설치하여 상당한 양의 보안 테스트를 수행하는 것이 좋습니다.

문 # 37) 각 성능 테스트, 스트레스 테스트 및 부하 테스트 예제의 도움으로?

대답 : 여기에서 취할 수있는 가장 좋은 사례는 라이브 웹 사이트입니다.

성능 시험 실시간 시나리오와 유사한 조건을 통과 할 때 시스템의 결함을 확인하기 위해 수행됩니다. 스트레스를받는 조건에서 수행 할 필요는 없습니다. 성능 테스트의 출력은 시스템이 생산에 들어갈 준비가되었는지 여부를 확인하는 데 도움이됩니다.

간단한 티켓 예약 흐름의 경우 성능 문제로 인해 속도가 느려질 수 있습니다. 예를 들어, 조인을 사용하는 일부 쿼리는 데이터베이스에 데이터를 부적절하게 저장하거나 불필요한 절을 구현 한 경우 약간 느립니다.

스트레스 테스트 소프트웨어를 극한 조건 (무겁고 분산되지 않은 부하, 제한된 계산 리소스, 높은 동시성)에 두어 수행되는 성능 테스트 유형입니다.

시스템이 데이터 손실 또는 손상, 스트레스 제거 후에도 리소스 활용, 무응답 또는 처리되지 않은 예외와 같은 특정 동작을 보이면 스트레스 테스트에서 실패한 것입니다. 때때로 디스크 오류, 불필요한 GDI 수 증가가 결과가 될 수 있습니다.

예를 들어, 이미 대용량 메모리를 사용하고 있거나 반복적 인 요청으로 공격하는 컴퓨터에서 호스팅되는 웹 사이트의 경우 중단되거나 로그 아웃되지 않아야합니다.

부하 테스트 임계 값에 도달 할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템 동작을 관찰합니다. 워크로드 모델, 메트릭 및로드 수준은 일반적으로로드 테스트에 대한 입력입니다.

예를 들어, Tatkal 예약 시간이 가까워지면 Tatkal 예약 시간이 오전 10시 또는 오전 11시에 가까워지면서 시스템에 로그인 한 사용자 수가 증가하기 때문에 열차의 좌석 가용성을 가져 오는 시간이 점차 증가합니다.

문 # 38) 회귀 테스트를 수행하는 동안 가장 큰 어려움 중 하나는 무엇 이었습니까?

대답 : 회귀 테스트를 수행하는 동안 다양한 문제가 발생할 수 있습니다.

• 테스트를 반복적으로 실행하는 것은 테스터에게 그리 흥미롭지 않을 수 있습니다.
• 때때로 그러한 테스트는 즉각적인 사고가 필요하기 때문에 시간이 많이 걸립니다.
• 비즈니스 가치 손상.
• 회귀 테스트 케이스를 부적절하게 선택하면 발견되는 주요 회귀 결함을 건너 뛸 수 있습니다.
• 따라서 생산에서 결함을 재현하는 것은 일관성이 없습니다.
• 실행할 대형 스위트.

문 # 39) 테스트 시나리오, 테스트 사례, 테스트 계획, 테스트 전략을 문서화하라는 요청을받은 경우 무엇으로 시작하고 나머지는 어떤 순서로 진행합니까?

대답 : 순서는 테스트 전략, 테스트 계획, 테스트 시나리오 및 마지막으로 테스트 케이스입니다.

문 # 40) 위의 문서화를 놓친 경우 어떻게합니까? 어떤 결과가 발생할지 테스트 계획을 문서화하지 못했다고 가정 해 보겠습니다.

대답 : 테스트 계획 문서화를 놓치면 객관적인 접근 방식을 테스트하고 테스트에 중점을 두는 범위가 공백이됩니다. 그러면 테스트 할 기능, 테스트 기술, 기준 통과 또는 실패, 궁극적으로 테스트와 관련된 주요 위험을 결정하기가 어렵습니다.

문 # 41) 최근에 얻은 빌드 테스트를 시작하는 방법 : 따라야 할 접근 방식이 있습니까? 먼저 연기 테스트를 시작한 다음 Sanity 테스트를 시작합니까?

대답 : 연기 테스트> 위생 테스트> 탐색 적 테스트> 기능 테스트> 회귀 테스트 및 최종 제품 검증.

문 # 42) 팔로우 한 버그 보고서의 형식을 설명 하시겠습니까?

대답 :

버그 보고서에는 다음 정보가 포함되어야합니다.

• 버그 ID
• 요구 사항 / 향상 / 기존 버그에 매핑
• 버그 요약 / 제목
• 제품 버전
• 우선 순위
• 구성 (시스템 사양)
• 전제 조건
• 단계
• 예상되는 결과
• 실제 결과
• 로그. 스냅 샷, 비디오 클립
• 상태
• 기타 비고

문 # 43) 회귀 테스트 케이스를 어떻게 선택하거나 회귀 테스트 스위트를 구성합니까?

대답 : 예. 이것은 영향 분석의 결과입니다. 테스트중인 여러 영역에서 사용되거나 액세스되는 기능, 다른 기능과의 통합, 그리고 시스템의 종단 간 또는 흐름 테스트 전반에 걸친 간단한 매핑입니다.

또한 이전 빌드에서 동일한 기능에 대해 이전에 제출 된 결함을 선택할 수도 있습니다. 이상적으로는 기능을 사용하는 5 개 이상의 서로 다른 테스트 사례를 사용하여 하나의 결함을 회귀 테스트해야합니다.

문 # 44) 다음과 같은 결함의 예와 함께 올 수 있습니까?

• 낮은 우선 순위 높은 심각도 결함
• 높은 우선 순위 및 낮은 심각도 결함

대답 : 특정 운영 체제에서 지정된 타임 스탬프에서만 재현 될 때 응용 프로그램이 충돌하는 결함은 심각도가 높고 우선 순위가 낮은 결함 일 수 있습니다.

더블 클릭으로 열리지 않지만 오른쪽 클릭으로 열리는보기에 대해 제출 된 결함은 우선 순위가 높고 심각도가 낮은 결함 일 수 있습니다.

문 # 45) 주어진 종이가 백서인지 테스트하기위한 효과적인 테스트 케이스 하나를 작성합니까?

대답: 흰 종이에 쓰는 원본 잉크의 색상이 그대로 유지되면 용지는 흰색입니다. 예를 들어, 빨간 잉크로 흰 종이에 글씨를 쓰면 잉크의 색상은 펜에서 빨간색으로 유지되고 종이에도 빨간색으로 나타납니다.

노트 : 이 질문에 대한 다른 많은 답변이 있습니다. 근본적인 논리로 그러한 유효한 대답을 생각할 수 있습니다.

문 # 46) 차터 테스트는 무엇입니까?

대답: 테스트를 시작하기 전에 헌장 아래에 나열된 목표 및 의제에 따라 수행되는 세션 테스트를 헌장 테스트라고합니다.

여기에서 테스트는 문서에 덜 집중하고 테스트에만 집중하는 고정 된 시간 슬롯에서 수행됩니다. 테스트 엔지니어가 일정 시간 내에 소프트웨어를 확인하는 탐색 테스트의 다른 변형입니다 ( 예를 들어, 단 2 시간) 개발 된 일부 휴리스틱을 기반으로합니다.

문 # 47) 매우 짧은 시간에 제공 될 우선 순위가 높은 릴리스가있는 경우 어떻게 접근합니까?

대답: 그러한 경우에는 신중한 계획이 도움이 될 수 있습니다.

시간 부족 시나리오에서 테스트를 지원하기 위해 다음을 수행 할 수 있습니다.

• 회귀 테스트를 실행하기 위해 기존의 업데이트 된 자동화 스크립트를 사용합니다.
• 흐름 기반 시나리오를 종단 간 테스트합니다.
• 우선 순위가 높은 테스트 케이스를 실행하고 시간이 허용되면 우선 순위가 낮은 케이스로 전환하십시오.
• 이전 버전에서 제기 된 우선 순위가 높은 버그를 다시 테스트합니다.
• 신속한 소프트웨어 테스트
• 개발자는 테스트에서 더 많은 범위를 얻기 위해 단위 테스트를 실행하도록 요청할 수 있습니다.

문 # 48) 주변에있는 모든 장치 / 물체 (예 : 의자)에 대한 테스트 케이스를 작성합니까?

대답: 여기서 조언은 다음과 같습니다. 항상 요구 사항 수집부터 시작하십시오. 소프트웨어 개발 수명주기에 대한 성숙도를 보여줍니다. 물건을 고른 후 부담없이 질문 해주세요.

이 경우 :-

• 어떤 종류의 의자입니까? 사무실 의자, 연구 테이블 의자, 소파 의자, 식탁 의자, 안락 의자?
• 나무, 강철, 플라스틱, 실내 장식 등 의자를 만드는 데 사용되는 재료는 무엇입니까?
• 치수 (의자 유형에 따른 높이, 무게)를 물어보십시오.
• 가용성을 요청하십시오. 그리고이를 바탕으로 사례 초안을 작성하십시오.

테스트 케이스는 의자 유형마다 다르므로 사고 능력에 더 적합합니다 ( 예를 들어, 의자의 용도, 의자 유형에 따른 치수, 휴대용 비 음료, 경량, 구매 옵션).

각 의자에 대해 성능 테스트 사례는 다음과 같습니다. 인장 강도 또는 최대 하중 지지력을 유도합니다.

문 # 49) 모든 것이 자동화 될 수 있습니까?

대답: – 어느 정도 그렇습니다. 그러나 다른 소프트웨어와 마찬가지로 자동화 도구에는 한계가 있습니다. 또한 테스트중인 소프트웨어 또는 테스트중인 애플리케이션은 계속 업그레이드됩니다.

따라서 소프트웨어 테스트가 수동 개입없이 실행될 수 있다는 보증은 없습니다. 결국 도구는 테스터만큼 똑똑합니다. 그것은 단지 소프트웨어 테스트이고 또 다른 소프트웨어입니다. 결함을 테스트하고 찾을 수있을만큼 지능적이어야하는 것은 코드 / scripts / 라이브러리입니다.

결론

이 연습이 몇 가지 질문으로 준비하는 데 도움이되고 인터뷰를 시작하는 데 도움이되고 질문에 답하는 동안 자신감을 다듬을 수 있기를 바랍니다. 또한 이력서 / 프로필에서 나올 수있는 다른 시나리오 기반 질문이있을 수 있습니다.

따라서 인터뷰는 면접관과 후보자 모두에게 윈-윈 상황이 될 수 있도록 사전에 직접 모의 면접을 연습하는 것이 좋습니다. 품질 분석가는 단순히 제품의 품질뿐 아니라 소프트웨어 테스트를 위해 따르는 프로세스에도 중요한 피드백을받는 테스트 엔지니어 그 이상입니다.

감사합니다. 인터뷰에 행운을 빕니다!

추천 도서

• 인터뷰 질문 및 답변
• 25 개 이상의 가장 인기있는 ADO.NET 인터뷰 질문 및 답변
• 25 Best Agile Testing 인터뷰 질문 및 답변
• 답변이있는 스팍 인터뷰 질문 (가장 인기있는)
• ETL 테스트 인터뷰 질문 및 답변
• 20 개의 가장 인기있는 TestNG 인터뷰 질문 및 답변
• 인기 오이 인터뷰 질문 및 답변 상위 30 개 이상
• 가장 인기있는 50 가지 CCNA 인터뷰 질문 및 답변