6 basic skills that every tester should have
소프트웨어 테스팅 또는 QA는 저임금 또는 저임금 직업이라는 오해에도 불구하고 신규 이민자가 IT 산업에 진입 할 수있는 최고의 플랫폼입니다.
테스터에게 필요한 가장 중요한 기술은 버그를 찾는 능력 . 그리고 당신이 버그를 찾는 것을 좋아하는 사람이라면이 분야에서 사랑하고 성장할 것입니다.
하지만 버그를 찾고 QA 프로세스를 더 잘 처리하는 데 도움이되는 기술은 거의 없습니다.
이 기사는 대부분의 회사에서 따르는 QA 프로세스를 보여주고 신규 테스터에게 테스트에 대한 설명을 제공합니다.
세부적으로 문서화 프로세스 및 표준, 테스터의 사전 작업, 제약 조건 기반 테스트, 부분 개발 중 테스트 및 마지막으로 사인 오프 프로세스를 배웁니다.
의 시작하자.
학습 내용 :
- #1. 선적 서류 비치
- # 2. 시험 준비
- #삼. 테스트 프로세스 – 수행 할 테스트는 무엇입니까?
- # 4. 부분 개발 단계에서 테스트
- # 5. 버그 신고 문서
- # 6. 사인 오프 프로세스
- 결론
- 추천 도서
#1. 선적 서류 비치
문서화는 테스트에 필수적입니다. 대부분의 회사는이 작업을 신규 이민자에게 할당합니다. 성공하려면 좋은 어휘 문서화 표준 등과 같은 나머지 사항은 귀하가 통제 할 수없고 팀과 회사의 프로세스에 의존하기 때문입니다.
또한 문서화 프로세스의 가치를 확인하십시오. 장점은 많습니다. 요구 사항 변경을 추적하고, 테스트 단계를 추적하고, 작업을 기록하는 데 도움이됩니다.
추천 읽기=> 소프트웨어 테스팅에서 문서가 중요한 이유
# 2. 시험 준비
사용 가능한 모든 문서 중에서 다음은 무시할 수 없습니다. 이를 제공 가능한 문서라고도하며 클라이언트, 개발자 및 테스터의 이해를 연결합니다.
a) 테스트 계획 : 시작부터 끝까지 테스트 흐름을 차트로 표시합니다. .
테스트 계획은 테스트 단계의 범위와 활동을 나타냅니다. QA 리더가 만든 팀은 테스트 계획에 기록 된 모든 내용에 대해 기여하고 최신 정보를 유지해야합니다.
테스트 계획을 세우는 방법
일부 팀에는 마스터 계획 및 단계 현명한 계획과 같은 여러 수준의 테스트 계획이 있습니다.
테스트 계획에는 다음이 있어야합니다.
- 프로젝트 이름 및 버전
- 테스트 계획 식별자 – 작성자, 초안 번호, 생성 날짜 등
- 소개 – 프로젝트, 목표 및 제약에 대한 개요
- 참조 – 입력으로 사용 된 참조 목록 (정확하고 최신 버전을 사용하는지 확인)
- 테스트 항목 – 모듈, 버전, 범위, 범위 외 등
- 전체 테스트 접근 방식 / 테스트 전략 – 사용할 도구, 결함 추적 프로세스, 수행 할 테스트 수준 등
- 합격 / 불합격 항목 기준 – 테스트 실행 지침
- 일시 중지 및 재개 기준
- 테스트 결과물 – 테스트 사례, 테스트 보고서, 버그 보고서, 테스트 메트릭 등
- 테스트 환경 세부 정보
- 연락처 정보가 포함 된 팀 명단. 각 모듈 또는 테스트 유형에 대해
- 테스트 견적 – 시간과 노력. 예산 세부 정보는 기밀이며 여기에서는 찾을 수 없습니다.
- 위험 및 완화 계획
- 승인
- 기타 지침
또한 읽으십시오=>
- 처음부터 테스트 계획 문서를 작성하는 방법
- 테스트 계획 형식
- 실제 테스트 계획 예 (pdf) [다운로드]
b) 테스트 시나리오 :
각 요구 사항에 따라 '테스트 대상'에 대한 한 줄 포인터이며 일반적으로 스프레드 시트를 통해 문서화되고 추적됩니다.
대부분은 다음을 포함합니다.
- 모듈 / 구성 요소 / 기능 이름 (로그인, 관리자, 등록 등)
- 시나리오 ID는 참조 용입니다 (예 : TS_Login_001).
- 시나리오 설명 – '테스트 대상'예 : 로그인을 통해 유효한 자격 증명을 가진 사용자가 성공적으로 로그인 할 수 있는지 확인
- 시나리오 중요성 – 시간이 부족한 경우 우선 순위 지정 – 높음 / 중간 / 낮음
- 요구 사항 ID – 추적 용
추가 읽기=>
c) 테스트 케이스 :
정확한 테스트 케이스는 정확한 테스트 결과를 제공합니다. 스프레드 시트는 일부 회사에서 테스트 관리 도구를 적용하더라도 테스트 사례 작성을위한 인기있는 매체이며 특히 초보자에게 적합합니다. 테스트 케이스 작성의 기초는 SRS / FRD / Req 문서입니다. 그러나 충분하지 않은 경우가 많으므로 BA / Dev 팀과 많은 가정과 토론을해야합니다.
효과적인 테스트 케이스 작성 테스터가 가져야하는 가장 중요한 자격입니다. 일반적으로 모든 테스트 케이스는 양성 / 음성으로 분류됩니다. 긍정적 인 테스트 케이스 유효한 입력을 제공하고 긍정적 인 결과를 얻고 있습니다. 네거티브 테스트 케이스 잘못된 입력을 제공하고 정확한 오류 메시지를 받고 있습니다.
이에 대한 자세한 내용은 다음을 확인하십시오.
모든 테스트 케이스가 갖는 몇 가지 공통 속성은 다음과 같습니다.
- 시나리오 ID – 테스트 시나리오 문서에서 가져옴
- 테스트 케이스 ID – 고유 식별 및 추적 용. 예 : TC_login_001
- 테스트 설명 – 테스트 된 테스트 조건에 대한 간략한 설명
- 실행할 단계 – 테스트 방법에 대한 자세한 단계별 지침
- 테스트 데이터 – 테스트 단계에 제공된 데이터
- 예상 결과 – 예상 한 결과
- 실제 결과 – 테스트 실행시 AUT의 응답
- 상태 – 통과 / 실패 / 실행 안 함 / 미완료 / 차단됨 – 테스트 결과를 설명합니다.
- 코멘트 – 추가 세부 사항
- 실행자 – 테스터 이름
- 실행 날짜 – 테스트가 실행 된 날짜
- 결함 ID – 테스트 실패시 테스트 케이스에 대해 결함이 기록됩니다.
- 구성 세부 정보 – OS, 브라우저, 플랫폼, 장치 정보 (선택 사항)
추천 읽기=>
#삼. 테스트 프로세스 – 수행 할 테스트는 무엇입니까?
수많은 테스트 유형이 있지만 모두 해당 AUT에서 수행 할 수있는 것은 아닙니다. 시간, 예산, 비즈니스의 특성, 애플리케이션의 특성 및 고객의 관심은 애플리케이션에서 수행 할 테스트를 선택하는 핵심 요소입니다.
예를 들면: 온라인 커머스 포털이라면 스트레스 테스트와 부하 테스트가 필수입니다. 그러나 놓쳐서는 안되는 테스트 유형 중 일부는 다음과 같습니다.
- 블랙 박스 테스트
- 회색 상자 테스트
- 단위 테스트 (적용된다면)
- 통합 테스트
- 증분 통합 테스트
- 회귀 테스트
- 기능 테스트
- 재시험
- 온 전성 테스트
- 연기 테스트
- 수락 테스트
- 사용성 테스트
- 호환성 테스트
- 종단 간 테스트
- 알파 테스트
- 베타 테스트
# 4. 부분 개발 단계에서 테스트
일반적으로 중간 수준 및 신생 기업의 경우 시간과 리소스가 제한됩니다. 여기에있는 테스터는 모듈 통합 전에 테스트 프로세스를 시작할 수 있습니다. 즉, 단위 및 중간 통합 테스트를 수행 할 수 있습니다.
이러한 단계의 결과는 정확한 것으로 계산할 수 없으므로 모든 준비가 완료되면 전체 블랙 박스 테스트를 계획해야 할 수 있습니다. 그 부분을 간과하는 것은 비용이 많이 들고 비효율적 일 수 있습니다.
# 5. 버그 신고 문서
지금까지 만들게 될 가장 중요한 QA 문서입니다.
다음은 좋은 버그 보고서에 있어야하는 필드입니다.
- 결함 ID – 일반적으로 일련 번호
- 결함 설명 – 문제에 대한 한 줄 설명
- 위치 – 문제가 발견 된 AUT의 모듈 / 영역
- 빌드 번호 – 버전 및 코드 빌드 번호
- 재현 단계 – 문제를 일으키는 단계 목록
- 심각도 – 문제의 심각성을 설명하는 수준 (낮음, 중간, 높음, 차단제 등)을 설정합니다.
- 우선 순위 – 개발자가 결함이 수정 될 순서를 결정하도록 설정합니다 (P1, P2, P3 등. P1- 최고).
- 할당 대상 – 해당 시점의 결함 소유자
- 보고자 – 테스터 이름
- 상태 – 버그 수명주기 단계를 나타내는 다른 상태
- 신규 – 버그가 발견되어 방금보고 됨
- 공개 – QA 리드의 검증
- 할당 됨 – 각 개발자에게 할당하기 위해 개발 책임자에게 보냈습니다.
- 진행 중 / 진행중인 작업 – 개발자가 작업을 시작했습니다.
- 수정 됨 / 해결됨 – 개발자가 작업 완료
- 확인 / 종료 됨 – QA 팀이 다시 테스트하여 버그가 수정되었음을 확인했습니다.
- 재 테스트 – QA 팀이 개발자의 해결 방법에 동의하지 않고 재 작업을 위해 버그를 추가로 진행합니다.
- 중복 – 유사한 버그가 이미 존재합니다.
- 지연됨 – 유효한 버그이지만 이후 릴리스에서 수정됩니다.
- 유효하지 않음 – 버그가 아니거나 재현 할 수 없거나 정보가 충분하지 않습니다.
추가 읽기=>
- 좋은 버그 보고서를 작성하는 방법
- 샘플 버그 보고서
- 마케팅 및 버그 수정 방법
- 버그보고가 예술인 이유
# 6. 사인 오프 프로세스
사인 오프 최종 문서를 보내는 것은 QA 리드 / 관리자의 임무입니다. 그러나 최종 검토 및 감사를 위해 팀은 위 문서 (테스트 시나리오, 테스트 케이스 및 결함 로그 문서)를 제출해야합니다.
모든 것을 교정하고 최종 버전을 보내십시오.
또한 읽으십시오=>
- 효과적인 테스트 요약 보고서 작성 방법
- 테스트 실행을 현명하게보고하는 방법
- 샘플 테스트 요약 보고서 [다운로드]
결론
이것이 제가 테스터 였을 때 직접 목격하고 경험 한 과정입니다.이 과정이 유용한 정보가 되었기를 바랍니다.
마지막으로, 테스트 경력은 저에게 절대적인 기쁨이었고 여러분도 그러하길 바랍니다.
당신의 경력에 최선을 다하십시오!
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 [QA 테스트 자동화 도구]
- 알파 테스트 및 베타 테스트 (전체 가이드)
- 시험 입문서 eBook 다운로드
- 기능 테스트 대 비 기능 테스트
- 소프트웨어 테스트 기본 지식을 확인하기위한 20 가지 간단한 질문 [온라인 퀴즈]
- 완벽한 소프트웨어 테스트 이력서 가이드 (소프트웨어 테스터 이력서 샘플 포함)
- 빌드 검증 테스트 (BVT 테스트) 전체 가이드
- 다국어 웹 사이트 테스트를위한 7 가지 기본 팁