FAQ
다음은 Guru99 커뮤니티에서 가장 자주 묻는 질문입니다.
- 비디오를 볼 수 없습니까?
- 프로젝트에 대한 이메일을 받지 못했습니다.
- 애플리케이션에 버그가 있는 경우 버그의 심각도와 우선순위는 누가 결정합니까?
- 시스템과 관련된 Funct.Spec/문서가 없다면 어떻게 하시겠습니까?
- 출시 며칠 전에 쇼 중단 문제를 발견한 경우 테스터는 어떻게 해야 합니까?
- 소프트웨어 품질보증 분야를 선택한 이유는 무엇인가요?
비디오를 볼 수 없습니까?
이 사이트의 모든 비디오는 다음에서 호스팅됩니다. YouTube 여기에 삽입되었습니다…
당신은 아마도 다음 위치에서 웹사이트에 액세스할 것입니다. YouTube 금지되어 있다 (귀하의 회사, 대학 또는 국가 YouTube 금지되어 있습니다)
무제한 환경에서 비디오에 액세스해 보세요.
당신이 할 않습니다. 동영상을 보려면 등록해야 합니다.
프로젝트에 대한 이메일을 받지 못했습니다.
프로젝트 이메일은 24시간 간격으로 전송됩니다. 따라서 목요일 오후 10시에 구독한 경우 다음 이메일은 금요일 오후 10시에 받게 됩니다.
정크메일이나 스팸메일함을 확인해주세요 Mail상자. Gmail을 사용하는 경우 다음을 확인하세요. Promo섹션 탭
저희 시스템에는 이메일을 재전송하는 기능이 없습니다. 여전히 이메일을 추적하지 못하는 경우 다른 이메일 ID로 구독하여 콘텐츠를 받으세요.
애플리케이션에 버그가 있는 경우 버그의 심각도와 우선순위는 누가 결정합니까?
심각도 결함 우선순위는 문제를 파악한 사람(테스터)이 결정하고, 우선순위는 문제를 해결하는 사람(개발자)이 결정합니다.
테스터로서 귀하는 일반적으로 테스트 리드가 검토하는 결함의 우선순위를 지정할 수 있습니다. 개발자는 분석 후 우선순위가 높은 결함인지, 우선순위가 낮은 결함인지 결정합니다. 대부분의 경우 개발자가 수행하지만 테스터가 심각도를 설명하기 위해 참여할 수도 있습니다. 논의 후에 리드가 결론을 내릴 것입니다.
심각도는 기본적으로 애플리케이션이나 제품의 기능과 관련이 있습니다. 우선순위는 개발자가 해당 버그나 결함을 얼마나 즉시 수정할 수 있는지입니다. 우선 순위는 본질적으로 동적이며 심각도는 본질적으로 정적이지만 시나리오에 따라 변경됩니다.
기능 사양이나 시스템과 관련된 문서가 없으면 어떻게 하시겠습니까?
- 먼저 비즈니스 분석가나 SME와 함께 해당 영역을 이해해 보세요. 시스템을 이해하기 위해 탐색적 테스트를 수행합니다.
- 프로젝트에 없는 경우 비즈니스 분석가 또는 SME인 경우 유사한 시스템에서 작업한 사람들과 이야기를 나누십시오.
- 사용자 커뮤니티에 대한 비즈니스 토크를 이해하려면
- 인터넷이나 PMO에서 유사한 제품 사양을 알아보세요.
- 동일한 유형의 응용 프로그램 소프트웨어를 찾고 기능을 이해하십시오.
- 중요한 비즈니스 시나리오, 대체 문서, 애플리케이션 주제에 대한 기사를 찾아보세요.
- 개발자에게 모든 모듈에 대한 설명을 물어보세요.
- 사용자 기록 데이터, 애플리케이션 및 기능
- 애플리케이션을 기술적으로 테스트하지 말고 먼저 사용자 관점에서만 애플리케이션을 테스트하세요.
출시 며칠 전에 쇼 중단 문제를 발견한 경우 테스터는 어떻게 해야 합니까?
- 결함을 다시 확인하고 재확인하고 가능하다면 버그나 결함, 영향 및 가능한 해결 방법을 문서화하십시오.
- 이 사실을 관리자에게 알리고 팀과 논의하십시오. 이러한 쇼 스토퍼는 출시 일주일 전에 팀에 알려지지 않기 때문에 좋지 않습니다.
- 결함이 관리자와 상위 테스트 기관에 도달하면 그들에게 요점을 제시해야 할 수 있으므로 릴리스에 영향을 미칠 수 있으므로 요점을 철저하게 설명해야 합니다.
- 토론이 당신에게 도움이 된다면, 이제 일어나 빛을 발할 시간입니다. 그렇지 않다면, 오늘 배운 교훈을 테이크아웃으로 남겨두세요. 계속 공부하다.
소프트웨어 품질보증 분야를 선택한 이유는 무엇인가요?
최종 사용자나 고객에게 고품질 프로젝트를 제공하려면 관련 코딩에 관계없이 테스트가 필수입니다. 소프트웨어 QA는 버그를 기록할 뿐만 아니라 해당 버그에 대한 솔루션도 제공합니다.
QA 분야에서 테스터는 테스트할 애플리케이션의 전체 기능을 알고 있어야 하며, 이를 통해 다양한 환경에서 개발된 다양한 유형의 애플리케이션, 심지어 프로그래밍의 일부 기본 개념에 대해서도 알 수 있습니다. 테스트를 할 때는 지식이 더 넓어지지만 프로그래밍을 할 때는 지식이 좁아집니다. 개발자는 전체 애플리케이션의 작은 부분만 개발하고 애플리케이션 전체를 알지 못할 수도 있습니다. 이 경우 QA(테스터)의 역할이 더 흥미롭다고 생각했습니다.