QA 소프트웨어 테스트 체크리스트 (샘플 체크리스트 포함)

qa software testing checklists

소프트웨어 QA 테스트 체크리스트

오늘 우리는 너무 자주 사용되지 않는 또 다른 품질 도구를 제공하여 잃어버린 영광을 되찾기를 희망하면서 세부 사항을 다시 해시 할 것이라고 생각했습니다. ‘체크리스트’입니다.

정의: 체크리스트는 추적을 위해 기록 된 항목 / 작업의 카탈로그입니다. 이 목록은 순서대로 정렬되거나 우연하게 정렬 될 수 있습니다.

체크리스트는 우리 일상 생활의 일부이자 소포입니다. 식료품 쇼핑에서 그날의 활동에 대한 할 일 목록 작성에 이르기까지 다양한 상황에서 사용합니다.

학습 내용 :

• QA 소프트웨어 테스트 체크리스트 개요
  • # 1) 테스트 준비 검토
  • # 2) 종료 기준 체크리스트
  • 테스트 체크리스트
  • 자동화 체크리스트
  • 추천 도서

QA 소프트웨어 테스트 체크리스트 개요

사무실에 도착하자마자 항상 다음과 같이 해당 요일 / 주에 할 일 목록을 작성합니다.

• 가득 따르다 작업 표
• 끝 선적 서류 비치
• 오전 10시 30 분에 해외 팀에 전화
• 오후 4시 모임 등

목록의 항목이 완료되면 취소하거나 목록에서 제거하거나 체크 표시로 항목을 선택하여 완료를 표시합니다. 우리에게 너무 익숙하지 않나요?

그러나 그게 다 사용할 수 있습니까?

자바에서 문자열 배열 반환

IT 프로젝트에서 공식적으로 (특히 QA) 체크리스트를 사용할 수 있으며, 그렇다면 언제, 어떻게 사용할 수 있습니까? 이것은 아래에서 다룰 내용입니다.

본인은 다음과 같은 이유로 체크리스트 사용을 개인적으로 옹호합니다.

• 다목적 – 모든 용도로 사용 가능
• 손쉬운 생성 / 사용 / 유지
• 결과 분석 (작업 진행 / 완료 상태)은 매우 쉽습니다.
• 매우 유연함 – 필요에 따라 항목을 추가하거나 제거 할 수 있습니다.

일반적인 관행과 마찬가지로 우리는 '왜'와 '어떻게'측면에 대해 이야기 할 것입니다.

• 체크리스트가 필요한 이유는 무엇입니까? : 완료 (또는 미완료)를 추적하고 평가합니다. 작업을 기록하여 간과하지 않도록합니다.
• 체크리스트는 어떻게 생성합니까? : 글쎄, 이것은 더 간단 할 수 없습니다. 간단히, 모든 것을 한 점씩 적어 두십시오.

QA 프로세스의 체크리스트 예 :

위에서 언급했듯이 QA 필드에는 체크리스트 개념을 효과적으로 적용하고 좋은 결과를 얻을 수있는 영역이 있습니다. 오늘 보게 될 두 가지 영역은 다음과 같습니다.

• 테스트 준비 검토
• 테스트를 중지하거나 기준 체크리스트를 종료해야하는 경우

# 1) 테스트 준비 검토

이는 모든 QA 팀이 테스트 실행 단계로 진행하는 데 필요한 모든 것이 있는지 확인하기 위해 수행하는 매우 일반적인 활동입니다. 또한 이것은 여러주기가 포함 된 프로젝트에서 각 테스트주기 전에 반복되는 활동입니다.

테스트 단계가 시작된 후 문제가 발생하지 않고 조기에 실행 단계에 들어갔다는 것을 깨닫기 위해 모든 QA 프로젝트는 성공적인 테스트에 필요한 모든 입력이 있는지 확인하기 위해 검토를 수행해야합니다.

체크리스트는이 활동을 완벽하게 촉진합니다. 미리 '필요한 것'목록을 만들고 각 항목을 순차적으로 검토 할 수 있습니다. 시트를 만든 후에는 후속 테스트주기에도 재사용 할 수 있습니다.

추가 정보: 테스트 준비 검토는 일반적으로 작성되며 검토는 QA 팀 담당자가 수행합니다. 결과는 PM 및 다른 팀 구성원과 공유되어 테스트 팀이 테스트 실행 단계로 이동할 준비가되었는지 여부를 나타냅니다.

다음은 샘플 테스트 준비 검토 체크리스트의 예입니다.

이제이 목록으로해야 할 일은 완료로 표시하거나 완료하지 않은 것입니다.

# 2) 종료 기준 체크리스트

이름에서 알 수 있듯이 이것은 테스트 단계 /주기를 중지하거나 계속할지 여부를 결정하는 데 도움이되는 체크리스트입니다.

결함이없는 제품은 불가능하고 주어진 시간 내에 가능한 한 최대한 테스트해야하기 때문에 충족해야하는 가장 중요한 기준을 추적하기 위해 아래 효과에 대한 체크리스트가 생성됩니다. 테스트 단계가 만족 스럽다고 판단합니다.

테스트 체크리스트

테스트를 위해 새 프로젝트를 시작 하시겠습니까? 프로젝트 수명주기의 모든 단계에서이 테스트 체크리스트를 확인하는 것을 잊지 마십시오. 이 목록은 대부분 테스트 계획과 동일하며 모든 품질 보증 및 테스트 표준을 포함합니다.

테스트 체크리스트 :

1. 시스템 및 승인 테스트 생성 ()
2. 수락 테스트 생성 시작 ()
3. 테스트 팀 확인 ()
4. 작업 계획 생성 ()
5. 테스트 접근 방식 생성 ()
6. 수락 기준 및 요구 사항을 연결하여 수락 테스트 ()의 기초를 형성합니다.
7. 시스템 테스트 사례의 하위 집합을 사용하여 수락 테스트 ()의 요구 사항 부분을 구성합니다.
8. 고객이 사용할 스크립트를 작성하여 시스템이 요구 사항을 충족 함을 입증합니다. ()
9. 테스트 일정을 만듭니다. 사람과 기타 모든 리소스를 포함합니다. ()
10. 수락 테스트 수행 ()
11. 시스템 테스트 생성 시작 ()
12. 테스트 팀원 확인 ()
13. 작업 계획 생성 ()
14. 자원 요구 사항 결정 ()
15. 테스트를위한 생산성 도구 식별 ()
16. 데이터 요구 사항 결정 ()
17. 데이터 센터 ()와 계약 체결
18. 테스트 접근 방식 생성 ()
19. 필요한 시설 식별 ()
20. 기존 테스트 자료 획득 및 검토 ()
21. 테스트 항목의 인벤토리 생성 ()
22. 설계 상태, 조건, 프로세스 및 절차 식별 ()
23. 코드 기반 (흰색 상자) 테스트의 필요성을 결정합니다. 조건을 확인하십시오. ()
24. 모든 기능 요구 사항 식별 ()
25. 인벤토리 생성 종료 ()
26. 테스트 케이스 생성 시작 ()
27. 테스트 항목의 인벤토리를 기반으로 테스트 케이스 생성 ()
28. 새 시스템에 대한 논리적 비즈니스 기능 그룹 식별 ()
29. 테스트 케이스를 테스트 항목 인벤토리로 추적 된 기능 그룹으로 분할 ()
30. 테스트 케이스에 해당하는 데이터 세트 설계 ()
31. 테스트 케이스 생성 종료 ()
32. 사용자와 함께 비즈니스 기능, 테스트 케이스 및 데이터 세트 검토 ()
33. 프로젝트 리더 및 QA로부터 테스트 설계 승인 받기 ()
34. 테스트 설계 종료 ()
35. 시험 준비 시작 ()
36. 테스트 지원 리소스 얻기 ()
37. 각 테스트 케이스에 대한 예상 결과 개요 ()
38. 테스트 데이터를 얻습니다. 테스트 사례에 대한 유효성 검사 및 추적 ()
39. 각 테스트 사례에 대한 자세한 테스트 스크립트 준비 ()
40. 환경 설정 절차를 준비하고 문서화합니다. 백업 및 복구 계획 포함 ()
41. 테스트 준비 단계 종료 ()
42. 시스템 테스트 수행 ()
43. 테스트 스크립트 실행 ()
44. 실제 결과와 예상 () 비교
45. 불일치를 문서화하고 문제 보고서 작성 ()
46. 유지 보수 단계 입력 준비 ()
47. 문제 복구 후 테스트 그룹 재실행 ()
48. 알려진 버그 목록을 포함하여 최종 테스트 보고서를 작성합니다. ()
49. 공식 사인 오프 얻기 ()

자동화 체크리스트

이러한 질문에 예라고 답하면 자동화를 위해 테스트를 진지하게 고려해야합니다.

Q # 1) 동작의 테스트 순서를 정의 할 수 있습니까?

대답: 일련의 동작을 여러 번 반복하는 것이 유용합니까? 이에 대한 예로는 수락 테스트, 호환성 테스트, 성능 테스트 및 회귀 테스트가 있습니다.

허용 기준이있는 사용자 스토리 예

Q # 2) 작업 순서를 자동화 할 수 있습니까?

대답: 이것은 자동화가이 일련의 작업에 적합하지 않다는 것을 결정할 수 있습니다.

Q # 3) 테스트를 '반 자동화'할 수 있습니까?

대답: 테스트의 일부를 자동화하면 테스트 실행 시간을 단축 할 수 있습니다.

Q # 4) 테스트중인 소프트웨어의 동작이 자동화가없는 경우와 동일합니까?

대답: 이것은 성능 테스트의 중요한 관심사입니다.

Q # 6) 여러 하드웨어 구성에서 동일한 테스트를 실행해야합니까?

대답: 임시 테스트 실행 (참고 : 이상적으로 모든 버그에는 관련 테스트 케이스가 있어야합니다. 임시 테스트는 수동으로 수행하는 것이 가장 좋습니다. 실제 상황에서 자신을 상상하고 고객이 원하는대로 소프트웨어를 사용해야합니다. 버그가 발견되면 임시 테스트 중에는 쉽게 재현 할 수 있고 Zero Bug Build 단계에 도달했을 때 회귀 테스트를 수행 할 수 있도록 새로운 테스트 케이스를 만들어야합니다.)

Ad-hoc 테스트는 테스터가 소프트웨어 제품의 실제 사용을 시뮬레이션하려고 시도하는 수동으로 수행되는 테스트입니다. 임시 테스트를 실행할 때 대부분의 버그가 발견됩니다. 자동화는 수동 테스트를 대체 할 수 없다는 점을 강조해야합니다.

참고 사항 :

• 위의 두 가지는 체크리스트를 사용하여 QA 프로세스 하지만 사용은이 두 영역에 국한되지 않습니다.
• 또한 각 목록의 항목은 어떤 종류의 항목을 포함하고 추적 할 수 있는지 독자에게 아이디어를 제공하는 표시기이지만 필요에 따라 목록을 확장 및 / 또는 압축 할 수 있습니다.

위의 예가 QA 및 IT 프로세스에 체크리스트의 잠재력을 전달하는 데 성공했으면합니다.

따라서 다음에 반 공식적이고 간단하며 효율적인 간단한 도구가 필요할 때 체크리스트를 제공하는 방향으로 방향을 잡았기를 바랍니다. 때로는 가장 간단한 해결책이 가장 좋습니다.

추천 도서

• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 소프트웨어 테스팅 QA 어시스턴트 작업
• 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
• 경력으로 소프트웨어 테스트 선택
• 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
• ISTQB 테스트 인증 샘플 질문 문서 (답변 포함)
• 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
• 소프트웨어 테스팅 과정 피드백 및 리뷰