릴리스 후 테스트를 효과적으로 수행하고 릴리스가 라이브 클라이언트에 미치는 영향을 최소화하는 방법

how perform post release testing effectively

QA로 경력을 시작했을 때 제품을 SaaS로 제공하는 회사에서 일했습니다. 프로덕션 릴리스는 중요했으며 라이브 클라이언트의 기능에 영향을 미칠 가능성이있었습니다.

고객 기반이 증가함에 따라 위험을 관리하고 출시가 실제 고객에게 미치는 영향을 최소화하기 위해 QA 팀은 출시 후 테스트 연습.

이것은 나에게 완전히 새로운 것이었고 내 마음에 많은 질문과 의심이있었습니다.

• 출시 후 테스트 란 무엇입니까?
• 모든 것을 제대로 테스트했는데 왜 출시 후 테스트를해야합니까?
• 모든 것을 다시 테스트합니까? 출시 후 검증에서 정확히 무엇을합니까?
• 문제를 발견하면 어떻게됩니까? 기타.

처음 몇 번의 프로덕션 릴리스에서 모든 답변을 찾았다는 것을 인정하게되어 기쁩니다.

여기서 나는 그 지식을 여러분 모두와 공유하고 있습니다. 나는 내가 답을 발견 한 방법을 보여주기 위해 질문과 답 형식으로 기사를 쓰기로 결정했다.

학습 내용 :

• 포스트 프로덕션 릴리스 확인이란 무엇입니까?
• 출시 후 검증 단계에는 어떤 작업과 활동이 포함됩니까?
• 모든 것을 다시 테스트해야합니까?
• 포스트 프로덕션 릴리스 검증 전략을 어떻게 공식화합니까?
• 포스트 프로덕션 릴리스 테스트 계획은 누가 작성합니까?
• 포스트 프로덕션 릴리스 테스트 계획은 누가 승인합니까?
• 포스트 프로덕션 릴리스 검증 계획은 언제 생성합니까?
• 포스트 프로덕션 릴리스 확인을 완료했습니다. 무엇 향후 계획?
• 문제를 발견하면 어떻게됩니까?
• 포스트 프로덕션 릴리스 확인 프로세스에 대해 또 알아야 할 사항은 무엇입니까?
• 결론:
• 추천 도서

포스트 프로덕션 릴리스 확인이란 무엇입니까?

정의상 게시하다 방법 후 , 생산 릴리스 배포를 나타냅니다. 라이브 / 프로덕션 환경에 과 확인 포함 릴리스 된 기능이 요구 사항을 충족하는지 확인 .

추천 읽기=> 테스트를 시작하기 전에 '테스트 환경'을 효과적으로 준비하는 방법

목표는 프로덕션 / LIVE 환경에서 릴리스를 확인하는 것입니다.

Windows 10 용 최고의 맬웨어 제거 도구

그러나 다음 질문이 발생합니다.

• QA 환경에서 모든 것을 테스트 할 때 포스트 프로덕션 릴리스 테스트를 수행해야하는 이유는 무엇입니까?
• 테스트 환경에서 철저하게 릴리스를 테스트했지만 프로덕션에서 문제가 발생할 것으로 예상하는 이유는 무엇입니까?

우리가 완전히 따랐을지라도 생산에 문제가있는 데는 여러 가지 이유가 있습니다. 품질 보증 프로세스 (예 : 테스트 계획 , 테스트 계획 검토, 테스트주기, 회귀 테스트 기타.)

생산에 문제가있는 이유 :

1) 데이터 문제 – 프로덕션 및 테스트 환경에서 사용 가능한 데이터는 다를 수 있습니다. 이로 인해 테스트 환경에서 일부 문제가 누락 될 수 있습니다.

2) 배포 문제 – 회사에 수동 빌드 배포 프로세스가있는 경우 릴리스가 배포 문제에 더 취약 할 수 있습니다. 일반적인 시나리오로는 구성 또는 사이트 설정 누락, DB 스크립트 누락, 배포 순서를 따르지 않음 (코드 우선, DB 등), 종속성이 잘못 설치된 등이 있습니다.

또한 읽으십시오=> QA 테스터가 배포 프로세스에 대해 알아야 할 사항

3) 식별되지 않은 영향 영역 – 영향을받는 영역이 팀에 의해 정확하고 완전하게 식별되지 않은 일부 시나리오가있을 수 있습니다.

예를 들면, 고려 SaaS 환경.

팀이 이전 테이블 스키마를 사용하여 리팩터링 된 DB 테이블이 클라이언트에 미치는 영향을 식별하지 못한 경우 (예 : 데이터 손실, 데이터 마이그레이션 이 문제는 정확한 요구 사항이있는 잘 계획된 프로젝트에서 발생할 가능성이 적습니다. 그러나 가능성은 여전히 ​​존재합니다.

4) 알려지지 않은 영향 영역 – 이는 릴리스의 범위와 영향을받는 영역을 알 수없는 경우 발생할 수 있습니다. 예를 들어, 공통 DB와 아키텍처를 공유하는 여러 소프트웨어 제품이있는 회사에서는 작은 변경만으로도 많은 제품의 기능이 손상 될 수 있습니다.

출시 후 검증 단계에는 어떤 작업과 활동이 포함됩니까?

일반적으로 포스트 프로덕션 릴리스 작업 및 활동에는 다음이 포함됩니다.

• 포스트 프로덕션 릴리스 확인
• 검증 결과보고
• 프로덕션에서 발견 된 문제보고
• 출시 후 검증 데이터 정리
• 출시 후 모니터링 (해당하는 경우)

모든 것을 다시 테스트해야합니까?

반드시 그런 것은 아닙니다. 이는 릴리스 할 빌드와 영향 분석에 따라 다릅니다.

정기적 인 QA주기 동안 자세한 테스트를 수행해야합니다. 릴리스 후 검증은 해당 릴리스에 대한 전체 테스트 계획에서 파생 된 포스트 프로덕션 릴리스 검증 테스트 계획을 따라 수행해야합니다.

포스트 프로덕션 릴리스 검증 전략을 어떻게 공식화합니까?

포스트 프로덕션 릴리스 검증 계획은 정규 테스트 계획과 유사한 방식으로 수행되어야합니다.

전략 품질 보증주기 동안 따라온 테스트 흐름과 동일한 라인에 있어야합니다. 최대 기능 범위를 허용하는 가장 중요하고 중요한 단계를 포함하는 것이 중요합니다.

html 인터뷰 질문 및 답변 pdf

좋은 포스트 프로덕션 릴리스 전략은 다음과 같아야합니다.

• 새로운 기능과 주요 기존 기능을 테스트하는 단계 포함
• 주요 영향 영역 확인
• 최대 기능 범위 허용
• 선택 사항 : 테스트 환경에서 발견 된 모든 중요한 버그를 포함합니다.
• 선택 사항 : 테스트 케이스의 우선 순위 포함

포스트 프로덕션 릴리스 테스트 계획은 누가 작성합니까?

이는 회사마다 다르며 조직 구조에 따라 다릅니다.

다음 QA 팀 조직의 예를 들어 보겠습니다.

이 시나리오에서 특정 프로젝트에 대한 QA는 초기 포스트 프로덕션 릴리스 테스트 계획을 공식화합니다.

포스트 프로덕션 릴리스 테스트 계획은 누가 승인합니까?

이는 회사마다 다르며 조직 구조에 따라 다릅니다.

다시 이전 질문에 표시된 것과 동일한 조직 구조를 고려하여 포스트 프로덕션 릴리스 테스트 계획을 검토하고 승인해야합니다. 테스트 리드 또는 QA 관리자 .

포스트 프로덕션 릴리스 검증 계획은 언제 생성합니까?

포스트 프로덕션 릴리스 테스트 계획은 요구 사항, 개발 범위 및 영향 영역을 식별하고 잠근 후 소프트웨어 개발주기 동안 언제든지 만들 수 있습니다. 일반적으로 QA가 스프린트 중간에 포스트 프로덕션 릴리스 테스트 계획을 만드는 것이 더 쉽습니다. 이를 통해 검토 및 승인을위한 충분한 시간이 확보됩니다.

이 테스트 계획을 포함하는 것이 좋습니다. 공식 QA 사인 오프 문서 프로젝트가 배포 및 릴리스 단계에 들어가기 전에

포스트 프로덕션 릴리스 확인을 완료했습니다. 무엇 향후 계획?

출시 후 확인이 완료된 후 다음 단계는

1) 검증 결과 전달 – 검증 결과는 생산에서 발견 될 수있는 모든 문제를 포함하여 이해 관계자에게 전달되어야합니다.

2) 결함 관리 도구에서 생산에서 발견 된 문제보고 –에 근본 원인 분석 촉진 과 추적 성 .

3) 출시 후 검증 데이터 정리 – 검증이 완료된 후 데이터 정리를 수행해야합니다.

예를 들면, 고려 전자 상거래 애플리케이션 출시 프로덕션에서 테스트 주문을 생성했다고 가정합니다. 이 테스트 주문은 확인이 완료된 후 취소해야합니다.

4) 포스트 프로덕션 릴리스 모니터링 (해당되는 경우) – 일부 릴리스는 프로덕션 모니터링이 필요합니다.

예를 들면, 팀이 애플리케이션의 페이지로드 시간을 개선하기 위해 개선 한 경우, 출시 후 개선이 실제로 나타 났는지 확인하기 위해 일정 기간 동안이를 모니터링해야합니다. 모니터링 책임자는 명확하게 식별되고 전달되어야합니다.

문제를 발견하면 어떻게됩니까?

모든 문제는 결함 관리 도구 이해 관계자에게 전달됩니다. 프로덕션에서 중요한 문제가 발견되면 문제를 추가로 조사하기 위해 빌드를 롤백해야하는 경우 결정을 내려야하므로 결과를 즉시 전달해야합니다.

발견 된 모든 문제가 결함 추적 도구에보고되는 것이 중요합니다. 일반 QA주기 버그와의 분리를 보여주기 위해 별도의 문제 유형 (예 : 포스트 프로덕션 버그)으로 제기하는 것이 좋습니다. 근본 원인 분석을 위해 필요한 경우 이러한 문제를 쉽게 필터링 할 수 있습니다.

포스트 프로덕션 릴리스 확인 프로세스에 대해 또 알아야 할 사항은 무엇입니까?

실제 포스트 프로덕션 릴리스 확인 프로세스, 계획 및 전략 외에도 다음은 몇 가지 지침입니다.

• 출시 후 검증의 범위와 목적에 대한 명확한 기대치를 설정하는 것이 중요합니다. 이해 관계자 (내부 및 외부)는 다음 사항을 인식해야합니다.
  • 팀은 프로덕션에서 모든 것을 테스트 할 수 없습니다.
  • 팀은 출시 후 검증을 위해 따로 떼어 놓은 몇 시간 동안 테스트를 할 수 없습니다.

따라서 프로덕션 테스트는 기본적으로 승인 된 포스트 프로덕션 릴리스 테스트 계획을 기반으로합니다.

한계:

적절한주의를 기울여야합니다 포스트 프로덕션 릴리스 테스트의 범위를 결정합니다. 프로덕션에서 실제로 테스트 할 수있는 항목과 양에는 제한이 있습니다. 프로덕션 환경에는 라이브 클라이언트 데이터가 있으며 매우 신중하게 처리해야합니다. 데이터 마이그레이션, 업데이트, 삭제 등과 관련된 변경 사항에 대해서는 추가 계획을 수행해야합니다.

예 # 1) : eSurvey 회사의 경우 테스트에 설문 조사 응답 및 제출이 포함되는 경우 QA는 고객 설문 조사 수집 데이터 및 통계에 영향을주지 않도록 확인 후 테스트 설문 조사 삭제 요청을 보내야합니다.

IS xample # 2) : 전자 상거래 회사의 경우 가격 업데이트 SQL 작업이 매일 자정에 실행되고 최종 가격을 웹 사이트에 업로드한다고 가정 해 보겠습니다. 이 SQL은 출시 후 확인을 위해 주문형으로 여러 번 실행할 수 없습니다. 이로 인해 완성되지 않은 데이터가 프로덕션으로 푸시 될 수 있습니다.

또한, 그것은 기회를 증가시킬 수 있습니다 DB 교착 상태 클라이언트 애플리케이션 성능에 영향을 줄 수있는 업무량이 많은 시간 동안 CPU 및 메모리 리소스를 많이 소비합니다.

• 출시 후 테스트 및 모든 관련 활동에 필요한 노력이 내장되어 프로젝트 계획에 포함되어야합니다. 비즈니스 규칙 및 프로젝트 세부 사항에 따라 이는 프로젝트 오버 헤드로 간주되거나 QA주기에 포함되거나 릴리스 관리 계획의 일부로 포함될 수 있습니다.
• 출시 후 확인 과정에서보고 된 문제에 대해서는 근본 원인 분석을 수행하여 문제가 조기에 발견되지 않은 이유와 문제가 발생하지 않도록 다음 번에 더 잘 할 수있는 조치를 찾아야합니다. 근본 원인 분석을 통해 팀은 이러한 과거 문제에서 학습하고 구현의 공백을 메울 수 있습니다. 조직 구조에 따라 테스트 리드 또는 QA 관리자는 프로젝트 팀의 의견을 바탕으로 근본 원인 분석을 완료 할 수 있습니다. 몇 가지 일반적인 근본 원인은 코딩 문제, 요구 사항 문제, 설계 문제, 데이터 문제, 타사 제한 사항, 테스트 시나리오 누락 등이 될 수 있습니다. 해당하는 수정 및 예방 조치를 만들고 추적 할 수 있습니다.
• 서버 로그 릴리스 후 빌드를 모니터링하는 데 사용할 수도 있습니다. 서버 로그 고객에게 보이지 않지만 백엔드에서 문제를 일으킬 수있는 이벤트 또는 문제가 포함될 수 있습니다. 이 모니터링은 Dev 리드 및 DevOps 팀에 작업 항목으로 할당 될 수 있습니다.

예:

프로젝트 개요 :

소셜 미디어 애플리케이션, 특히 가입 프로세스를 다음과 같이 변경해야합니다.

1. 성 필드 유효성 검사를 제거해야합니다. 이전에는 '성에는 4 자 이상이어야 함'으로 구현되었습니다 (기존 필드 개선).
2. 사용자가 프로필에 표시 할 이메일 주소의 개인 정보 설정을 지정할 수 있도록 이메일 주소 옆에 토글 버튼을 구현합니다 (새 기능 요청).
3. 사용자는 자신의 아바타를 선택할 수 있어야합니다 (새로운 기능 요청).
4. 가입 프로세스 중 API 호출을 줄여 애플리케이션 성능 향상 (개선)

포스트 프로덕션 릴리스 검증 계획 :

결론:

현재 대부분의 소프트웨어 회사와 애자일 방법론 채택 , 프로덕션 릴리스 수가 증가했습니다.

예를 들면, 사용 중 폭포 모델 , 팀은 1.5 개월마다 프로덕션 릴리스를 가질 수 있지만 애자일 프로세스를 사용하면 동일한 팀이 이제 2-3 주마다 프로덕션 릴리스를 가질 수 있습니다.

모든 프로덕션 릴리스에서 우리는 라이브 클라이언트의 기능에 고의로 또는 무의식적으로 영향을 미칠 가능성이 있습니다. 출시 직후 포스트 프로덕션 릴리스 확인을 채택하면 실제 고객이 몇 가지 문제를 발견하기 전에 릴리스를 롤백하는 안전망을 제공하는 동시에 릴리스에 대한 추가적인 확신을 얻을 수 있습니다.

높은 영향 / 위험 프로젝트 용 , 포스트 프로덕션 릴리스 확인 계획은 테스트 시나리오의 우선 순위에 따라 구성 될 수 있습니다. 중요 우선 순위 테스트를 먼저 실행하고 결과 및 문제에 대해 이해 관계자에게 커뮤니케이션을 보낼 수 있습니다. 중요한 문제가 발견되지 않으면 포스트 프로덕션 릴리스 확인을 계속할 수 있습니다. 그렇지 않으면 애플리케이션 다운 타임과 라이브 클라이언트에 대한 영향을 최소화하기 위해 롤백 결정을 내려야합니다.

또한 포스트 프로덕션 릴리스 테스트를 자동화 할 수 있습니다. 테스트 스크립트는 회귀 테스트로 모든 릴리스 후 요청시 실행될 수 있습니다. 다시 말하지만, 프로덕션에서 자동화 된 테스트 스크립트를 실행하는 동안에는 라이브 클라이언트 데이터 및 기능에 영향을 미칠 수 있으므로주의를 기울여야합니다.

포스트 프로덕션 릴리스 검증은 최후의 방어선 모든 소프트웨어 회사를 위해. 우리가 문제를 파악하지 못하면 고객은 소프트웨어 회사의 명성에 치명적일 수 있습니다.

소프트웨어 테스트 인터뷰 질문 및 답변

제품의 안정성을 유지하려면 배포 후 즉시 프로덕션에 배포 된 변경 사항을 확인하는 것이 중요합니다.

저자 정보 : 이 유용한 기사는 Neha B가 작성했습니다. 그녀는 현재 품질 보증 관리자로 일하고 있으며 사내 및 해외 QA 팀을 이끌고 관리하는 일을 전문으로합니다.

포스트 프로덕션 릴리스 테스트 전략 / 팁 / 경험을 독자와 공유하십시오.

추천 도서

• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 시험 입문서 eBook 다운로드
• 프로덕션 릴리스 전에 수동 테스트의 7 단계 실제 구현
• HP LoadRunner 자습서를 사용한 부하 테스트
• 실용적인 소프트웨어 테스트 QA 프로세스 흐름 (출시 요구 사항)
• 데스크톱, 클라이언트 서버 테스트 및 웹 테스트의 차이점
• 감마 테스트 란 무엇입니까? 최종 테스트 단계
• 조기 테스트 란 무엇입니까 : 조기 테스트, 자주 테스트하지만 어떻게? (실용 가이드)