성공적인 버그없는 소프트웨어를 생산하기위한 테스트 릴리스 프로세스를 개선하는 방법

how improve test release process

'개발 단계'에서 '테스트 단계'까지 소프트웨어를 제공하는 일반적인 프로세스를 살펴 보겠습니다. 프로덕션 / 클라이언트에 버그없는 성공적인 소프트웨어 릴리스 .

소프트웨어 회사에서 이러한 프로세스를 간과하거나 건너 뛰어 테스트 관리가 제대로 이루어지지 않아 ' 버기 ”소프트웨어가 클라이언트에 출시되어“ 불만족스러운 고객 ”.

그래도 각 릴리스마다 테스트 팀이 많은 시간과 노력을 기울이고 있습니다. , 출시 된 소프트웨어의 품질이 정의되거나 벤치마킹되지 않거나 예상 기준을 충족하지 못하는 경우, 고객과의 회사 평판에 영향을 미칠뿐만 아니라 가장 중요한 프로젝트 팀인 테스트 팀 전체를 저하시키고 사기를 떨어 뜨립니다. .

이 시나리오에서 테스트 팀의 일원 인 경우 '내 테스트 기능을 개선하는 방법과이 상황을 극복 할 수있는 더 좋은 방법'을 계속 생각할 수 있습니다.

여러 도메인 및 플랫폼과 여러 테스트 프레임 워크를 사용하는 소프트웨어 애플리케이션 및 엔터프라이즈 제품 릴리스에 관련된 다양한 테스트 팀에 대한 경험을 바탕으로 몇 가지 팁과 제안을 제공하고 싶습니다. 테스트 릴리스 프로세스를 개선하는 방법 , 이는 세계적 수준의 소프트웨어를 제공하기위한 테스트 엔지니어 또는 테스트 관리자로서의 직업 생활을 단순화합니다.

학습 내용 :

• 테스트 릴리스 프로세스
• 테스트 릴리스 프로세스 개선 :
• 테스트 릴리스 콘텐츠 관리 및 제어
• 샘플 릴리스 보고서 템플릿 :
• 결론:
• 추천 도서

테스트 릴리스 프로세스

아래 표는 입력, 프로세스 및 출력과 같은 세 가지 범용 단계가있는 테스트 릴리스 프로세스의 개요를 제공합니다.

YouTube 비디오를 mp4 무료로 변환

모든 테스트 팀은 독특한 체크리스트 소프트웨어 릴리스의 경우 소프트웨어의 도메인 및 플랫폼과 프로젝트 관리 방법론 (예 : Agile Scrum 등) 및 수동 / 자동 테스트 프레임 워크에 따라 테스트 실행을 시작하기 전에 릴리스 된 빌드를 수락하여 시간과 노력을 절약합니다.

이것은 테스트 릴리스 단계에서 가장 중요한 효율성 매개 변수 중 하나입니다.

테스트 릴리스 프로세스 개선 :

1) 릴리스 보고서 검토 새로운 기능, 기존 기능의 사용자 정의 / 수정, 이전 빌드의 버그 수정, 연기 테스트 또는 이성 테스트 또는 둘의 조합 실행을 시작하기로 결정합니다.

2) 업데이트 검토 문서 테스트 아직 업데이트되지 않은 경우 새로운 기능 및 버그 수정에 따라. 일반적으로 소프트웨어 개발 수명주기 동안 이러한 문서는 정기적 인 주간 프로젝트 검토 회의를 기반으로 테스트 팀에 의해 업데이트됩니다.

삼) 구성 저장소에서 소프트웨어 빌드 검토 빌드 번호, 버전 번호에 대해 업데이트되며 프로젝트 계획에 정의 된 표준에 따라 릴리스 이름으로 레이블이 지정되거나 주석 처리됩니다. 또한 빌드가 성공적으로 컴파일되고 테스트 서버에 설치되었는지 확인하십시오.

4) 출시 후 빠른 프로젝트 검토 회의 예약 릴리스 된 빌드의 장단점, 알려진 버그 및 중요한 기능 등에 대해 논의하고 잘못된 의사 소통을 방지하고 중요한 클라이언트 요구 사항을 검토합니다. 소프트웨어 릴리스의 품질에 큰 영향을 미치므로 개발 팀과 테스트 팀 간의 구두 의사 소통을 엄격히 피하십시오.

5) 버그 추적 도구가 올바르게 구성되었는지 확인 , 프로젝트의 할당 된 테스트 팀과 개발 팀의 경우 소프트웨어 빌드 및 릴리스 번호와 소프트웨어의 모듈 / 기능은 버그를 효율적으로 기록하는 데 도움이됩니다. 그렇지 않은 경우 프로젝트 관리자 또는 테스트 관리자에게 높은 우선 순위로 에스컬레이션해야합니다.

6) 빌드를 개발 팀에 반환 Smoke 또는 Sanity Testing에서 빌드가 실패하더라도 타협없이. 엄밀히 말하면 Smoke Testing에서 시스템이 실패한 경우 테스트를 계속해서는 안됩니다. 이렇게하면 많은 시간과 노력이 절약되고 후속 릴리스에서 릴리스되는 소프트웨어의 품질이 향상됩니다.

7) 1에 프로젝트 출시 일정^성요일 이는 테스트 관리자가 빌드 안정성을 기반으로 다가오는 테스트주기를 계획하고 프로젝트 관리자에게 빠른 테스트 보고서를 보내어 소프트웨어의 품질을 미리 향상시키는 데 도움이됩니다. 개발 팀이 금요일에 프로젝트 릴리스를 예약하는 경우 주말은 수동 또는 자동 빌드 프레임 워크의 빌드 문제뿐 아니라 모든 슬립 페이지에 활용할 수 있습니다.

8) 테스터가 도메인에서 올바르게 교육되었는지 확인 이는 테스트 팀이 테스트 일정을 준수하고 다음 테스트를위한 시간을 모으는 데 도움이됩니다. 또한 테스트 팀은 교육을 받아야하며 프로젝트에서 화이트 복싱이 필요한 경우 스크립팅 및 SQL과 같은 필수 기술에 대한 노출이 있어야합니다.

9) 여러 프로젝트에서 테스터 할당 방지 실시간 테스트 실행 품질에 큰 영향을 미치기 때문입니다. 실제로 숙련 된 테스터조차도 기능과 기능을 간과하고 일부 테스트 케이스가 작업으로 과부하되거나 기한이있는 여러 프로젝트에 할당 될 때 실패하지 않는다고 가정하여 테스트 케이스를 건너 뜁니다.

10) 열정을 가진 테스트 팀에 감사드립니다. 테스터는 'Day'를 위해 일하거나 'Call it a Day'라고 말해서는 안됩니다. 소프트웨어에 여러 모듈이 있고 기능 전문가가 완전히 또는 부분적으로 통합되거나 상호 연관되어있는 경우 테스터는 최종 소프트웨어 / 제품의 품질을 목표로하는 광범위한 적용 범위 및 추적 성 매트릭스로 테스트 케이스를 작성 / 실행하는 데 열정을 가져야합니다. 외관상의 문제조차도 '버그'이고 '버그 1 개'로 간주되기 때문입니다.

열한) 소프트웨어 설치가 쉽고 간단한 지 확인 개발 관리자 또는 설치 관리자가 동일한 작업을 수행 할 때까지 기다리지 않고 필요할 때 테스트 팀이 소프트웨어를 다시 설치하는 데 도움이되므로 사용 가능한 테스트 시간이 불필요하게 단축됩니다. 예를 들어 Windows 기반 설치는 쉽지만 다중 계층 테스트 환경에서 여러 웹 서버와 광역 네트워크를 포함하는 경우 테스터가 소프트웨어를 설치하는 데 몇 시간이 걸릴 수 있습니다. 만약 소프트웨어 테스트 커버 및 설치, 제거 , 소프트웨어의 패치 또는 업데이트에 대해서는 테스트 팀과 함께 테스트 사례를 실행하는 프로세스에 대해 자세히 논의 할 가능성이 높습니다.

12) 라이센스와 함께 자동화 된 도구를 사용할 수 있는지 확인 에 대한 자동화 테스트 프레임 워크 . 자동화 된 도구가 여러 사용자에게 적절하게 구성되고 라이선스가 부여 된 경우 자동화 된 프레임 워크에서 테스트 사례를 실행하는 것은 수동 테스트 시나리오에 비해 쉽습니다. 특히 테스트 계획에 정규 테스트 케이스 실행 및 회귀 테스트와 별도로 성능 및 부하 테스트가 포함되는 경우 테스터는 여러 서버, 여러 브라우저, 여러 사용자 등과 같은 여러 환경에서 테스트 케이스를 실행해야합니다.

13) 고스트 시스템이 테스트를 위해 설정되었는지 확인 테스트 실행을 시작하기 전에. 고스트 머신은 테스트 환경이 다른 머신입니다. 예를 들어, 웹 애플리케이션 소프트웨어는 Chrome, Firefox, Internet Explorer와 같은 모든 브라우저를 사용하여 Windows 7 및 Access DB 또는 Windows 2008 및 SQL Server 또는 Windows 8 및 Oracle 또는 메인 프레임 및 DB2 등과 같은 여러 환경에서 테스트하도록 계획 될 수 있습니다. , Safari 등 일부 '시스템 테스트' 하드 디스크를 완전히 포맷하고 새 소프트웨어를 설치하거나 패치 및 업데이트 등으로 기존 소프트웨어를 업데이트해야합니다.

14) 새로운 기능 / 변경 요청 구현 방지 테스트 실행을 중지하고 테스트 단계를 다시 설명하기 위해 소프트웨어를 다시 릴리스합니다. 이는 외부 고객을 만족 시키거나 적어도 경영 운영위원회 또는 때때로 영업 / 마케팅 팀의 요구를 충족시키기위한 비즈니스 요구 사항에 따라 많은 소프트웨어 조직에서 매우 나쁜 관행입니다. 고객의 변경 요청은 항상 'Agile'프로젝트 환경에서 권장되지만 테스트 팀에 소프트웨어를 출시하기 전에 적절히 계획하고 구현해야합니다.

테스트 릴리스 콘텐츠 관리 및 제어

테스트 릴리스 콘텐츠를 관리하고 제어하는 ​​것은 모든 IT 소프트웨어 또는 아래 그림에 설명 된 비 IT 소프트웨어 환경에서도 가장 중요합니다.

• 프로젝트 관리자 및 / 또는 프로젝트 운영위원회는 조직 매트릭스의 권한에 따라 각 릴리스의 콘텐츠를 선택할 책임이 있습니다.

• 버그 및 / 또는 새로운 기능과 고객의 변경 요청이 식별되고 승인되면 개발 / 구현이 시작되기 전에 프로젝트 이해 관계자에게 알려야하는 개발 팀에서 구현합니다.

• 구현 된 최종 릴리스를 기반으로 테스트 팀은 관련 문서를 업데이트하고 그에 따라 테스트를 준비합니다.

• 테스트 팀은 릴리스 보고서에 정의 된 요구 사항에 따라 Smoke / Sanity 테스트를 시작합니다.

• Sanity가 통과되면 테스트 팀은 일정 및 할당 된 작업 즉, 기능 테스트, 비 기능 테스트, 보안 테스트, 시스템 테스트, 성능 테스트, 부하 테스트, 사용자 수락 테스트 등에 따라 테스트 실행을 시작합니다.

• 첫 번째 테스트주기가 완료되면 테스트 보고서가 모든 이해 관계자와 개발 팀 관리자에게 전송되어 다음 테스트 실행 반복을 계획합니다.

• 테스트 보고서의 상태와 버그 심각도 및 복잡성에 따라 두 번째 테스트 실행 또는 회귀 테스트의 전체주기가 사용자 승인 테스트와 함께 계획됩니다.

• 계획된 테스트 실행주기를 완료하면 기능, 기능 및 버그 수정의 통과 / 실패 / 실패에 대한 테스트 보고서가 프로젝트의 모든 이해 관계자에게 전송됩니다.

샘플 릴리스 보고서 템플릿 :

노트 : 릴리스 보고서 용 샘플 MS Word 템플릿도 아래에서 다운로드 할 수 있습니다.

아래에서 ' 샘플 출시 보고서 ”는 전체 프로젝트 팀의 직업 생활을 이전보다 훨씬 더 행복하게 만드는 릴리스 프로세스의 주요 측면을 다룹니다.

GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03

# 1) 범위

XYZ Company Limited 용 GPS 내비게이션이 내부 테스트를 위해 출시되었습니다. 릴리스 된 버전은 1.0.7, 릴리스 번호는 14.0, 빌드 번호는 105.25.03입니다. 이 소프트웨어 릴리스에는 이전 릴리스의 새로운 기능과 주요 버그 수정이 포함되어 있습니다. 연기 테스트는 개발 단계에서 통과되지만 회귀 테스트를 진행하기 전에 Smoke & Sanity가 필요합니다.

# 2) 참고 문헌

GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3

# 3) 출시 설명

이 릴리스는 GPS 내비게이션의 제어 릴리스이며 다음과 같은 특징과 기능을 포함합니다.

*로 표시된 기능은이 릴리스의 새로운 기능입니다.

다음 기능은이 릴리스에서 구현되지 않았습니다.

1. 모듈 1

1.1 특징 1

1.1.1 기능 1

# 4) 구성 관리
구성 관리 도구로 Visual Source Safe를 사용하고 있습니다. 빌드는 다음 경로에서 사용할 수 있습니다.

내부 링크 : http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
외부 링크 : https : // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13

# 5) 설치 지침 및 단계
빌드 설치에 대한 자세한 정보를 QA / 테스트 팀에 제공합니다.

# 6) 문제 / 버그 수정
버그 상태는 결함 추적 시스템에서 업데이트됩니다.

# 7) 수정해야 할 문제 / 버그

# 8) 결과물

# 9) 알려진 버그 / 문제

# 10) 출시 체크리스트

=> 다운로드: 샘플 릴리스 보고서 템플릿을 다운로드하려면 여기를 클릭하십시오. MS Word 형식으로.

결론:

테스트 릴리스 프로세스를 지속적으로 개선하는 방법

팁 # 1) 소프트웨어 릴리스 및 빌드 유지 관리의 중요한 요소를 처리하고 중앙 집중식 소프트웨어 구성 관리 시스템을 담당 할 릴리스 엔지니어링 팀을 구성합니다.

팁 # 2) 소프트웨어 개발 수명주기, 제품 개발 수명주기 및 소프트웨어 테스트 수명주기와 관련된 프로세스를 따르도록 프로젝트 팀에 동기를 부여하고 감사합니다. 우리는 프로세스를 정의 할 수 있지만 관련된 사람들이 따르지 않는 한 프로세스를 정의 할 필요가 없습니다.

팁 # 3) 경험과 이전 기록을 기반으로 테스트 노력을 추정하십시오. 테스트 케이스를 작성하는 것은 동일한 실행과 완전히 다릅니다. 테스터는 테스트 할 내용, 테스트 방법 및 테스트시기를 이해해야합니다. 그렇지 않으면 테스트주기가 여러 번 발생하더라도 테스트주기에 주어진 노력이 낭비됩니다.

팁 # 4) 마지막으로 가능하고 가능한 경우 보편적으로 허용되는 테스트 도구를 사용하여 테스트 단계를 자동화하십시오. 자동화 된 빌드 도구와 자동화 된 테스트 도구를 사용하면 테스트 노력이 50 % 이상 줄어들어 소프트웨어 품질이 향상되고 자동화 프레임 워크가 올바르게 설계된 경우 100 % 품질이 보장됩니다.

팁 # 5) 마지막으로, 테스트 릴리스는 단순한 작업이 아니라 프로젝트의 모든 이해 관계자가 쉽고 편안하게 생활 할 수 있도록하는 기술입니다.

저자 정보 : Balu A.는 20 년 이상의 IT 소프트웨어 경험과 Microsoft, Oracle, Java 및 Mobile 기술을 사용하는 도메인 전반에 걸쳐 엔터프라이즈 애플리케이션 및 이동성 솔루션을 제공하는 프로젝트 및 테스트 관리 경험을 가진 숙련 된 기술 기능 IT 전문가입니다. 그는 기본적으로 사람들이 올바른 태도를 가진 리더가되도록 장려하려는 열정을 가진 리더이며 프로세스 중심 환경에서 일하는 것을 좋아하며 프로세스가 직원의 효율성, 품질 및 생산성을 향상 시킨다고 믿습니다.

에다음 튜토리얼, 우리는 배울 것입니다 – 방법 테스트 케이스 효율성을 개선합니다.

아래 의견에 귀하의 생각 / 질문을 알려주십시오.

프로세스에 따라 소프트웨어 릴리스가 있습니다!
뛰어난 생산성과 노력으로 예정대로 테스트 완료 !!
버그없는 품질 보증 소프트웨어 제공을 달성하십시오 !!!

이 기사가 마음에 들면 친구들과 공유해보세요!

추천 도서

• 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 소프트웨어 테스팅 QA 어시스턴트 작업
• 소프트웨어 테스팅에서 몽키 테스팅이란 무엇입니까?
• 경력으로 소프트웨어 테스트 선택
• 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
• 샘플 버그 보고서
• 실용적인 소프트웨어 테스트 QA 프로세스 흐름 (출시 요구 사항)