메뉴

수동 및 자동화 프로젝트에서 테스트 계획은 어떻게 다릅니 까?

how does test planning differ

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

우리 모두는 자동화 프로젝트가 수동 테스트 프로젝트와 본질적으로 다르다는 데 동의합니다. 자율 자동화 프로젝트는 실제로 존재하지 않거나 이상적으로 존재해서는 안되지만 수동 및 자동화 프로젝트는 계획 할 때 다르게 처리됩니다.

혼합 계획 프로젝트는 필연적으로 실행됩니다. 이는 현재 프로젝트에 영향을 미치고 개인의 능력에 그림자를 드리울뿐만 아니라 고객 / 관리 팀에 대한 신뢰를 잃게되어 향후 비즈니스에 영향을 미칠 수 있습니다. 나는 우리 테스터들이 미안하기보다는 안전하다고 말하고 싶다.

=> 전체 테스트 계획 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.

테스트 계획

계획에 대한 좋은 Dilbert 만화 :

프로젝트 계획 dilbert

더 진행하기 전에이 기사가 다루지 않을 내용을 설정하고 싶습니다.

#1) 이것은 자동화 프레임 워크에 대한 심층적 인 논의가 아닙니다. 프로젝트마다 AUT의 특성, 아키텍처, 복잡성, 팀의 전문성 등에 따라 다른 프레임 워크를 사용합니다.

프레임 워크에 관한 정보는 아래 링크에서 찾을 수 있습니다.

테스트 자동화 프레임 워크 1 부 과 2 부 .

#두) 이것은 또한 템플릿, 형식 또는 생성에 관한 것이 아닙니다. 테스트 계획 문서 . 우리는 타당성 분석 라인에서 자동화 프로젝트에 대한 사전 문서화 고려 사항을 다룰 것입니다.

#삼) 이것은 또한 특별히 도구가 아닙니다. SDLC의 모든 활동에는 시간, 노력, 인프라, 즉 돈이 필요합니다.

수동 테스트 프로젝트의 경우 비용 소모 요소는 다음과 같습니다.

  • 사람들
  • 도구 – 테스트 / 결함 관리
  • 인프라 – 환경
  • 시각
  • 훈련

자동화 프로젝트의 경우 위 항목 외에도 다음에 대한 지출이 필요합니다.

  • 자동화 도구
  • 테스트 관리 도구 통합을위한 추가 기능
  • AUT를 지원하는 추가 기능 (예 : SAP, Oracle 등)
  • 프레임 워크 설정
  • 도구 별 교육

이러한 상황에서 자동화 프로젝트의 성공 여부는 코드를 얼마나 잘 작성했는지, 얼마나 많은 재사용 가능한 구성 요소를 작성했는지 또는 원하는 결과를 얻은 코드 줄 수에 달려 있습니까?

하지 마라.

성공을 결정하는 유일한 질문이 있습니다. '수동 경로에 비해 더 나은 ROI (투자 수익)를 생성 할 수 있습니까?' – 즉시가 아니라면 결국.

이 질문에 대한 대답이 '아니오'이면 자동화 프로젝트를 잘못 계획 한 것입니다.

일반적으로 테스트 계획에는 다음 섹션이 있습니다. 고려할 자동화 특정 측면에 중점을두고 각각에 대해 논의 할 것입니다.

자동화 테스트 계획

자동화 테스트 테스트 계획 섹션

섹션 1:범위

  • 여러주기에 걸쳐 계속해서 회귀 할 테스트 사례 / 시나리오를 선택합니다.
  • 때로는 가장 간단한 테스트 케이스를 자동화하기 위해 많은 복잡한 솔루션이 필요합니다. 이것들이 한 번만 사용한다면 분명히 의미가 없습니다. 재사용 성은 당신의 초점이어야합니다.
  • 자동화 테스트는 탐색 테스트를 수행하지 않거나 수행 할 수 없습니다.

섹션 2: 테스트 전략

  • 이 섹션은 자동화 세계에서 프레임 워크라고합니다. 일부 프레임 워크는 생성하기가 매우 어렵고 효과적이지만 시간, 노력 및 역량이 요구됩니다. 항상 중간 지점을 찾고 자원의 과도한 활용을 위험에 빠뜨리지 않고 최선을 다하십시오.
  • 사용할 코딩 모범 사례, 명명 규칙, 테스트 자산을 저장할 위치, 테스트 결과 형식 등을 결정하여 균일 성을 유지하고 생산성을 높입니다.

섹션 # 3 :자원 / 역할 및 책임

  • 이 방향의 첫 번째 단계는 팀의 능력을 이해하고 그림에 나오는 자동화 범위보다 앞서 예상하는 것입니다. 이는 자동화 및 수동 테스트 요구에 모두 적합한 팀을 선택하는 데 도움이됩니다. 또한 올바른 태도를 가진 사람들을 선택하십시오. 사람들은 수동 테스트가 자신의 키 아래에 있다고 생각하지 않습니다.
  • AUT, 테스트 관리, 결함 관리 및 기타 SDLC 활동에 정통한 팀을 선택하십시오.
  • 섹션 # 1 : 범위

섹션 # 4 :도구

다음 규칙에 따라 자동화 도구를 선택합니다.

  • 회사에 특정 도구에 대한 라이센스가 이미있는 경우 사용할 수 있는지 확인하십시오.
  • 오픈 소스 (하지만 신뢰할 수있는) 도구 찾기
  • 팀원들이 이미 도구를 알고 있습니까? 아니면 새로운 사람을 데려 와야합니까? 아니면 기존 훈련을?

섹션 # 5: 일정

  • 코드 워크 스루 및 자동화 스크립트 검사를위한 시간 포함
  • 적시에 스크립트를 유지하십시오. 향후 6 개월 정도 사용하지 않을 코드를 생성하는 경우 주기적으로 유지 관리하여 실패 가능성을 줄이십시오.

섹션 # 6 :환경

  • AUT가 실행할 대상 환경과 사용하려는 자동화 도구가 호환되어야합니다. 이것은 도구에 대한 사전 라이선스로 고려되어야하는 요소 중 하나입니다.
  • 또한 나머지 부분이 관리 도구 가져 오려는 자동화 도구는 추가 이점을 위해 상호 연결될 수 있습니다.

섹션 # 7 :결과물

  • 테스트 스크립트는 결과물입니다. 그러나 모든 사람이 자동화 / 프로그래밍 언어에 능숙하지는 않습니다. 따라서 현재 사용자와 미래의 팀 구성원이 주변에 없을 때에도이 스크립트를 이해할 수 있도록 '방법'문서를 작성하도록 계획하십시오.
  • 스크립트에도 주석을 포함하십시오.

섹션 # 8 : 위험

자동화 솔루션을 제안하려면 자동화 노력이 프로젝트에 부담을주지 않도록 비용 효율적인 도구와 솔루션을 선택해야합니다.

자동화 프로젝트에 대한 ROI는 즉시 긍정적일 수는 없지만 장기간에 걸쳐 명확하게 볼 수 있다는 기대치를 설정하는 것이 중요합니다.

따라서 시스템 자동화를 제안하는 경우

  • 안정적이고 너무 많은 유지 보수
  • 거대한 회귀 스위트에 대한 범위가 있습니다.
  • 수동 개입이 너무 많지 않거나 사람의 직감에 의존하지 않음

섹션 # 9 :테스트 데이터

  • 데이터의 보안 측면을 고려하십시오.
  • 테스트 데이터를 스크립트에 하드 코딩하지 마십시오. 이로 인해 너무 많은 스크립트 유지 관리가 발생하고 수정 중에 오류가 발생할 수 있습니다.
  • 매우 구체적입니다. 수동 테스트 단계 – '이름 입력'의 경우 5 자 이름을 입력 할 수 있습니다. 테스트하는 동안 테스터는 'Swati'또는 'Seela'또는 다른 것을 입력 할 수 있습니다. 그러나 도구의 경우 그러한 가정을 할 수 없습니다. 따라서 정확한 값을 제공하십시오.

섹션 # 10 :보고서 / 결과

  • 스크립트 실행 결과도 기술적이며 나머지 팀에서는 쉽게 이해하지 못할 수 있습니다. 추가 조치로 자세한 결과를 메모장이나 엑셀 시트에 기록 할 계획입니다.
  • 상세한 프레임 워크 문서, 검토 결과, 결함 보고서, 실행 상태 보고서도 예상됩니다.

자동화 애호가로서 우리는 클라이언트 / 관리자가 자동화 제안을 쉽게 구매하지 않는다고 생각할 수 있습니다.

비즈니스 분석가 기술 인터뷰 질문 및 답변

하지만 궁극적 인 목표가 자동화를 통해 ROI를 극대화하는 것이라면 경영진 / 고객의 목표와도 완벽하게 조화를 이룹니다. 이를 통해 우리는 프로젝트를 자동화 할 수있을뿐만 아니라 많은 동의, 협력 및 흥분을 통해 그렇게 할 수 있습니다.

위에 나열된 모든 요소에 대한 계획과 철저한 분석은이 여정을 통해 우리의 동맹이 될 수 있습니다. 다시 말하지만 ROI는 모든 것을 의미합니다.

이 게시물은 STH 작성자 팀 구성원 Swati Seela가 작성했습니다.

질문이나 논의 할 사항이 있습니까? 아래 의견에 자유롭게 게시하십시오.

=> 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.

추천 도서

^