메뉴

테스트 케이스 작성을 준비하는 방법 (생산성 팁)

how prepare yourself

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

테스트 케이스 작성을 준비하고 생산성을 높이는 방법 :

테스터가 고품질 테스트 케이스를 작성하기로 결정하고 테스트 케이스 작성의 효율성과 생산성을 높이고 자 할 때 테스터가 이러한 목표를 달성하는 데 도움이되는 핵심 사항이 거의 없습니다.

첫째, IT 업계의 모든 성공적인 소프트웨어 테스터에게 필요한 몇 가지 핵심 사항을 가지고 전문적이고 심리적으로 준비해야합니다. 이것은 ' 입력 ”테스트 케이스 작성을 시작하기 전에 테스터를위한 것입니다.

테스트 케이스 작성

다음으로 테스트 수명주기의 다양한 단계에서 테스터의 성능을 평가하기위한 도구로 사용되는 프로젝트와 관련된 품질 메트릭을 이해해야합니다. 이것은 ' 출력 ”완료 후 테스터 테스트 케이스 작성 .

마지막으로 테스터는 버그가보고되고 문제가 에스컬레이션되고 테스트 보고서가 표준 절차에 따라 준비되고 프로젝트의 이해 관계자가 이해할 수있는 방법을 알아야합니다.

학습 내용 :

소프트웨어 테스트에서 자동화 테스트 란?

테스트 케이스 작성 준비

1) 테스트 케이스 작성은 예술이며 단순한 작업이나 작업이 아닙니다. 소프트웨어의 일부 또는 일부를 설계하고 개발할 수 있지만 효율적인 테스트 접근 방식으로 모든 시나리오에 대해 완전히 테스트되지 않는 한 쓸모없고 누구도 릴리스하고 사용할 수 없습니다. 그래서, 자신을 프로젝트에서 중요한 사람으로 취급하고 테스트 활동을 프로젝트의 중요한 작업으로 취급합니다. .

두) 그만큼 긍정적 인 태도로 열정 , 가장 개인적인 품질 테스터는 프로젝트 수명주기 내내. 열정은 팀 구축 능력에 동기를 부여하고 태도는 품질 테스트 사례를 작성하는 데 큰 생산성을 제공합니다. 즉, 테스트 작성 활동은 프로젝트의 최종 결과물로 훌륭한 결과를 달성한다는 공통 목표를 위해 전문적이고 개인적인 자질이 혼합 된 것입니다.

삼) 긍정적이고 부정적인 테스트 케이스 테스트 케이스 작성의 일부이지만 테스터는 반 양성 버그 찾기를 통해 테스트중인 애플리케이션을 중단하려는 사고 방식 . 이것은 부정적인 사고 방식이 아니라 릴리스 후 누군가가 버그를 식별하는 상황을 피하거나 시스템의 일부 사용자가 시스템을 망가 뜨리는 상황을 피하는 것입니다.

4) 테스터의 효율성 테스트중인 시스템에서 식별 된 버그의 수를 기반으로 평가해서는 안되며, 결과적으로 결함을 발견하는 성공적인 테스트 케이스를 작성하는 능력을 기반으로합니다. 따라서 테스트 케이스는 적용 범위와 추적 성 시스템 경계 및 범위에 따라 최대 값이어야합니다.

5) 애플리케이션 도메인을 철저히 이해 .예를 들면, 웹 사이트 테스트는 수천 명의 사람들이 동시에 사용하는 증권 거래 소용으로 개발 된 금융 소프트웨어를 테스트하는 것보다 쉽습니다. 간단한 웹 사이트 기능은 모든 테스터가 이해할 수있는 반면 재정 조건 및 기능은 관련 교육 배경이나 교육을 받았거나 보유하지 않는 한 모든 테스터가 이해할 수 없습니다. 도메인 경험 .

따라서 테스터가 새 프로젝트에 할당 될 때 자격이 있고 기대에 따라 작업을 수행 할 수 있는지 여부에 관계없이 자체 평가를 수행해야합니다. 기능 요구 사항을 이해하기 어려운 경우 테스터의 효율성 및 성능에 대한 향후 오해를 방지하기 위해 미리 프로젝트 팀에 에스컬레이션해야합니다. 적절한 계획과 교육을 통해 프로젝트 관리자 또는 테스트 관리자가 처리합니다.

6) 수행 할 프로젝트 요구 사항 및 테스트 유형은 프로젝트마다 다릅니다. 테스터는 모든 종류의 테스트를 수행 할 준비가되어 있어야합니다. 능력을 제한하지 마십시오 당신의 기술과 전문성에. 모든 유형의 테스트에 대한 테스트 케이스를 작성하고 실행할 책임과 도전을 감수 할 준비를하십시오.

많은 테스터는 스스로를 조정하거나 수동 또는 자동화 테스터로만 계획합니다. 성능 테스트, 부하 테스트 또는 스트레스 테스트를 수행 할 때 필요한 지식을 교육하거나 수집하여 역할을 수행하고 준비하는 테스터는 거의 없습니다. 그래서, 빨리 배우다 책임을지고 경력에서 성장할 준비가되어 있어야합니다.

7) 테스트 유형 식별 수행 할 AUT 테스트에 필요한 기술. 예를 들면, 일부 프로젝트에는 블랙 박스 테스트 만 필요하고 일부 프로젝트에는 화이트 박스 테스트 기술이 필요합니다. '에 대한 지식 스크립팅 ”또는“ SQL ”또는“ 마크 업 언어 'HTML / XML 등과 같은 또는 소프트웨어 설치 / 문제 해결 방법에 대한 시스템 지식 등은 직접 학습하거나 이에 대한 교육을 받아야하는 프로젝트 별 요구 사항입니다.

8) 테스트 케이스가 성능 테스트, 보안 테스트 및 회귀 테스트 유형. 예를 들면, 아래 로그인 화면을 사용하여 애플리케이션에 로그인하려면 :

테스트 케이스 효율성 2

  • 1000 명의 사용자가 동시에 시스템에 로그인 할 때 애플리케이션이 안정적인지 확인하기 위해 성능 테스트가 필요할 수 있으며이 시나리오를 다루도록 테스트 사례를 작성해야합니다.
  • 애플리케이션이 적절한 권한과 권한을 가진 사용자에게 시스템을 사용할 수있는 권한 만 허용하는지 확인하기 위해 보안 테스트가 필요할 수 있으며 이러한 시나리오를 다루도록 테스트 사례를 작성해야합니다.
  • 모든 릴리스에서 핵심 기능 및 중요 기능이 제대로 작동하는지 확인하려면 회귀 테스트가 필요할 수 있습니다.

9) 테스트 케이스 검토 : 소프트웨어 개발 및 테스트 수명주기에서 가장 중요하고 가장 간과되는 단계 중 하나는 ' 리뷰 ”. 프로젝트 계획에 충분한 시간 할당이 포함 된 경우 검토 과정 프로젝트 개발의 모든 단계에서 가장 우수한 품질의 결과물과 결과물을 기대할 수 있습니다.

예를 들어, 테스트 케이스 작성을 시작하기 전에 테스터는 '요구 사항 사양'문서를 검토하고 문서에서 모든 검토 포인트를 고려하고 업데이트했는지 확인해야합니다. 조직이 적절하고 성숙한 프로세스를 따르고있는 경우 모든 문서 템플릿에는 문서 자체의 첫 페이지에이 변경 정보가 있어야합니다.

테스트 케이스 문서는 다음을 통해 3 회 이상 검토해야합니다.

i) 자체 검토
ii) 동료 검토
iii) 완전성, 테스트 범위, 추적 가능성 및 테스트 케이스가 테스트 가능한지 여부를 다른 사람이 검토합니다.

10) 드디어, 추정하는 방법을 이해하고 테스트 작업 계획 . 하루 중 예정된 예상 시간에만 작업하도록 계획하십시오. 이는 제 시간에 작업을 시작 및 완료하고 다음 날 작업 계획을 가지고 하루를 떠나는 방식으로 달성 할 수 있습니다.

사무실에서 늦은 밤에 머물거나 주말을 보내지 마십시오. 요즘에는 효율적인 프로젝트 관리 접근 방식을 사용할 수 있으며 프로젝트는 Agile 환경에서 실행되고 있습니다. 프로젝트 팀이 이정표를 달성하지 못하면 프로젝트 팀의 비 효율성보다는 비효율적 인 프로젝트 관리로 간주됩니다.

노트 : 명심하십시오. 자동화 된 테스트 , 테스트 케이스는 테스트중인 애플리케이션의 기능 흐름을 완전히 포함하여 최소한 한 번은 명확하게 작성하고 검토해야합니다. 모든 자동화 테스트 도구는 수동 테스트 케이스가 명확하게 정의되고 작성된 경우에만 테스트 케이스를 성공적으로 기록하고 실행할 수 있습니다.

문법보다 더 나은 무료 문법 검사기

품질 메트릭

이것은 소프트웨어 테스트 단계에서 중요한 활동입니다. 테스트 팀은 프로젝트 목표를 달성하는 데 사용되는 다양한 테스트 메트릭을 완전히 알고 있어야합니다. 테스터의 성능은 테스트 실행 단계 만이 아니라 요구 사항 분석, 테스트 사례 작성, 실행, 결함보고 및 최종 테스트보고 단계에서 수집 된 모든 테스트 메트릭을 기반으로 평가됩니다.

몇 가지 중요한 테스트 메트릭을 아래에서 찾으십시오. 테스터의 생산성 향상과 테스트 단계의 효율성을 위해 대부분의 조직이 뒤를이었습니다.

또한 참조테스트 단계에서 사용되는 기타 유용한 테스트 메트릭 :

=> 중요한 소프트웨어 테스트 지표 및 측정 및 라이브 프로젝트 버그 추적, 테스트 지표 및 테스트 사인 오프 프로세스.

1) 평균 테스트 효율성

  • 테스트 노력의 수개월 당 버그.
  • 평균으로 계산됩니다 (테스트 작업 중 수개월 단위의 총 버그 수).
  • 모든 내부 릴리스 후 및 테스트 완료 후 계산됩니다.
  • 허용 한도 : 50 미만이어야합니다.

2) 평균 고객 결함 밀도

  • 배달 후 클라이언트가보고 한 버그 대 수개월 단위의 총 테스트 노력.
  • 평균으로 계산됩니다 (배달 / 테스트 작업 후 수개월 단위의 총 버그 수).
  • 외부 릴리스 및 프로젝트 완료 후 계산됩니다.
  • 허용 한도 : 1 미만이어야합니다.

삼) 기능 테스트 실패

  • 실패한 기능 테스트 케이스의 수 / 실행 된 기능 테스트 케이스의 총 수.
  • 매월 또는 격주로 계산됩니다.

4) 심각도 수준 1의 버그

  • 심각도 수준 1 (차단기)로 식별 된 총 버그 수입니다.
  • 차단 문제로 인해 소프트웨어에 대한 테스트를 계속할 수 없습니다.
  • 매주 계산됩니다.

5) 심각도 레벨 2의 버그

  • 심각도 수준 2 (주요 버그)로 식별 된 총 버그 수입니다.
  • 주요 버그로 인해 기능에 대한 테스트를 계속할 수 없지만 시스템의 다른 부분에서는 계속할 수 있습니다.
  • 매주 계산됩니다.

6) 심각도 레벨 3의 버그

  • 심각도 수준 3 (사소한 버그)으로 식별 된 총 버그 수입니다.
  • 확인 된 버그가 사소하고 테스트를 중지하지 않으므로 테스트를 계속할 수 있습니다.
  • 매주 계산됩니다.

7) 심각도 수준 4의 버그

  • 심각도 수준 4 (외형 문제)로 식별 된 총 버그 수입니다.
  • 확인 된 버그는 외관과 관련이 있으며 다음 릴리스에서 수정 될 예정이므로 문제없이 테스트를 완료 할 수 있습니다.
  • 매주 계산됩니다.

버그보고

버그보고 메커니즘은 애플리케이션 품질을 유지하기 위해 성숙한 테스트 프로세스로 제어되어야합니다. 버그의 상태, 심각도 및 우선 순위를 알 수있는 권한이있는 사람에게 적절한 에스컬레이션 프로세스가 있어야합니다. 있습니다 사용 가능한 많은 무료 및 상용 버그보고 도구 Bugzilla, Mantis 등과 같이 이슈 추적 메커니즘에 매우 효과적이며 프로젝트에서 사용되는 모든 테스트 관리 도구와 쉽게 통합 될 수 있습니다.

모든 테스트 프로젝트에서 매일 온라인 상태보고 메커니즘을위한 표준 절차를 따라야합니다. 이러한 버그 추적 시스템에 기록되고보고 된 모든 버그 / 문제는 즉시 해당 기관에 이메일을 보내야 그에 따라 계획하고 조치를 취할 수 있습니다.

버그보고 프로세스를 자세히 알아 보려면다음 기사를 읽으십시오:

=> 좋은 버그 보고서를 작성하는 방법? 팁과 요령
=> 샘플 버그 보고서
=> 버그보고가 모든 테스터가 배워야하는 기술인 이유는 무엇입니까?
=> 버그 수명주기
=> 웹 및 제품 응용 프로그램에 대한 샘플 버그 보고서

테스트 보고서

버그보고 시스템에서 제기, 기록 및 에스컬레이션 된 버그 보고서 외에도 테스트 보고서는 테스트보고 기간 동안 식별 및 계산 된 테스트 상태 및 기타 중요한 메트릭을 알 수있는 가장 중요한 문서 중 하나입니다.

다음은 간단한 테스트 보고서입니다.

또한 다음 유용한 자습서를 읽으십시오.효과적인 테스트보고:

=> 효과적인 테스트 요약 보고서 작성 가이드
=> 테스트 실행을 스마트하게보고하는 방법 (상태 보고서 템플릿 다운로드)

Android 용 최고의 VR 앱은 무엇인가요

승리의

자야 1

결론

테스트 케이스 작성을 준비하는 프로세스는 프로젝트의 리소스 할당 일뿐만 아니라 자격을 갖춘 테스터로 준비하고 테스트 수명주기 전체 및 출시 후에도 모니터링되는 품질 메트릭을 이해하는 것과 같은 핵심 요구 사항이 거의 없습니다.

따라서 프로세스, 표준, 절차를 따르고 열정으로 품질 메트릭을 엄격하게 준수하면 자동으로 뛰어난 테스트 효율성, 생산성 및 품질 테스터를 가져올 수 있으며 이는 직업 생활에서 습관이 될 것입니다.

이러한 품질 요소는 몇 가지 질문을 통해 자체 분석하거나 그룹 분석 할 수 있습니다. 이는 우리가 테스트 케이스 작성 및 실행에서 효율적인 접근 방식을 달성하기위한 목표에서 자기 및 프로세스 개선을 올바르게 추적하고 있는지 여부를 알려줍니다.

  • 기능 요구 사항 / 사용자 요구 사항 / 비즈니스 사용 사례 문서를 살펴 보셨습니까?
  • 기능 요구 사항 문서를 검토 주석과 함께 적절히 검토하고 업데이트 했습니까?
  • 테스트 할 모든 기능에 대한 화면 프로토 타입을 받았습니까?
  • 테스트 수명주기 동안 테스트 및 추적이 가능한 테스트 케이스를 작성하는 데 익숙합니까?
  • 테스트중인 애플리케이션을 테스트하는 데 필요한 기술과 도메인 지식이 있습니까?
  • 테스트 사례를 실행하는 데 필요한 교육이나 기술 지식이 필요합니까?
  • 품질 문서를 ​​준비하는 시간을 포함하는 테스트 케이스를 작성, 검토 및 실행할 일정이 있습니까?
  • 테스트 케이스를 검토 할 동료와 테스트 할 기능의 완전성 및 적용 범위를 확인하는 공인 주제 전문가가 있습니까?
  • 모든 기능 요구 사항에 대한 충분한 테스트 케이스가 있습니까?
  • 성능, 부하 테스트 및 보안 테스트를위한 충분한 테스트 사례가 있습니까?
  • 설치 및 회귀 테스트를위한 충분한 테스트 케이스가 있습니까?
  • 문제를 에스컬레이션하거나 버그를보고 할 수있는 연락처가 있습니까?
  • 버그 추적 도구가 모두에게 필요한 권한으로 올바르게 구성되어 있습니까?
  • 테스트 계획에 정의 된 모든 프로세스를 따르는 데 익숙합니까?
  • 모든 검토 회의에 참여하고 있으며 개발 또는 관리 팀과 대화 할 기회가 있습니까?
  • 생산성과 효율성이 향상 되었습니까? 아니면 동일한 조치를 취해야합니까?

추천 읽기 = >> 최고의 온라인 문예 창작 과정

테스터가 프로젝트 유형이나 함께 작업하는 조직에 따라 자체 개선 분석을 요청할 수있는 유사한 질문이 많이 있습니다. 가장 중요한 것은 이러한 모든 활동이 프로세스를 따르기 위해 따르는 것이 아니라 다음을 통해 할 수있는 일상적인 습관으로 만들어야한다는 것입니다. 테스트에 대한 열정 뿐.

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

^