practical software testing qa process flow
종단 간 QA 소프트웨어 테스트 프로세스 흐름에 대한 전체 개요 :
주 –이 유용한 게시물을 업데이트 된 내용으로 다시 게시하고 있습니다.
소프트웨어 테스팅 전문가의 일은 쉬운 일이 아닙니다. 그것은 똑같이 까다로운 도전들로 가득 차 있습니다. 테스터는 애플리케이션 라이프 사이클의 모든 단계에서주의를 기울이고 열정적이어야합니다.
문제가 있지만 테스트 방법론, 프로세스 및 물론 소프트웨어의 다양한 측면을 자세히 배우고 탐색 할 수있는 엄청난 기회도 여럿 있습니다.
테스트 엔지니어의 역할은 아주 일찍 시작됩니다. 그리고 프로젝트의 개념화부터 테스터는 제품 소유자, 프로젝트 관리자 및 다양한 이해 관계자와 토론에 참여합니다.
'소프트웨어 테스트 프로세스 흐름'에 대한이 자습서는 STLC의 다양한 단계에 대한 전체 개요와 관련된 문제 및 이러한 문제를 쉽게 이해할 수있는 방식으로 극복하기위한 모범 사례를 제공합니다.
학습 내용 :
릴리스 요구 사항 – 전체 개요
요구 사항에서 릴리스까지 각 단계가 명확하게 설명됩니다. 자세히 살펴 보겠습니다.
# 1) 요구 사항
명확한 요구 사항 없이는 프로젝트를 시작할 수 없습니다. 이것은 아이디어를 이해하기 쉽고 형식이 지정된 문서로 작성해야하는 가장 중요한 단계입니다. 요구 사항 수집 단계에 참여하는 프로젝트의 일원이라면 자신이 운이 좋다고 생각하십시오.
무선 라우터의 보안 키는 무엇입니까
왜 궁금하십니까? 그것은 당신이 처음부터 만드는 프로젝트를 목격하고 있기 때문입니다. 창립 이래 자부심이 있지만 책임과 도전도 있습니다.
도전
한 번에 모이는 데 필요한 모든 요구 사항을 상상할 수는 없습니다. 충분히 인내하십시오.
많은 토론이 일어날 것입니다. 그 중 일부는 단순히 프로젝트와 관련이 없을 수 있지만 프로젝트에 중요한 정보가 포함될 수 있습니다. 때로는 토론 속도가 이해 능력을 초과하거나 단순히 제품 소유자에게 관심을 기울이지 않을 수 있습니다.
아래 그림은 요구 사항 수집과 관련된 중요한 단계를 보여줍니다.
누락 된 모든 정보는 프로젝트의 전반적인 이해와 테스트에 큰 영향을 미칩니다. 이를 극복하기 위해이 단계에서 따라야 할 몇 가지 모범 사례가 있습니다.
모범 사례
- 마음을 열고 제품 소유자의 모든 말에주의를 기울이십시오.
- 그냥 듣지 말고 작은 것 같더라도 의심을 없애십시오.
- 빠른 메모 보관을 위해 항상 노트북을 사용하십시오. 정말 적당한 속도로 입력 할 수있는 경우에만 노트북을 사용해야합니다.
- 문장을 반복하고 이해 한 것이라고 생각하는 PO에서 명확하게하십시오.
- 블록 다이어그램, 링크 텍스트 등을 그려 나중에 요구 사항을 더 명확하게합니다.
- 팀이 다른 위치에있는 경우 WebEx 또는 유사한 기록으로 만들어보십시오. 토론이 끝난 후 의심이들 때 항상 도움이 될 것입니다.
각 단계마다 별도의 벽이 없지만 요구 사항은 개발 후반부에서도 변경됩니다. 따라서 아이디어는 대부분의 요구 사항을 파악하고이를 적절하게 문서화하는 것입니다.
필요한 모든 사항이 문서화되면 모든 이해 관계자들에게 배포하고 논의하여 제안이나 변경 사항을 조기에 파악하고 계속 진행하기 전에 모든 사람이 같은 페이지에있게됩니다.
# 2) 테스트 전략
테스터는 소프트웨어를 더 잘 테스트하는 데 충분할뿐만 아니라 모든 이해 당사자에게 제품 품질에 대한 확신을 심어주는 테스트 전략을 제시해야합니다.
도전
이 단계의 가장 중요한 측면은 작업시 오류가없고 지속 가능하며 최종 사용자가 수용하는 소프트웨어 제품을 제공해야하는 전략을 만드는 것입니다.
테스트 전략은 격일로 변경하지 않을 것입니다. 경우에 따라 고객과 테스트 전략을 논의해야합니다. 따라서이 부분은 매우 중요하게 다루어야합니다.
모범 사례
- 다음은 몇 가지 모범 사례이며, 따를 경우 큰 안도감을 제공하고 원활한 테스트 결과를 얻을 수 있습니다.
- 요구 사항 문서를 다시 한 번 살펴보십시오. 대상 소프트웨어의 환경과 관련하여 가져 오기 지점을 강조 표시합니다.
- 소프트웨어가 실제로 배포 될 환경 목록을 만드십시오.
- 환경은 운영 체제 또는 모바일 장치의 한 유형으로 이해할 수 있습니다.
- Windows가 운영 체제 인 경우 소프트웨어를 테스트 할 창의 모든 버전을 나열하십시오. 버전 즉. Windows 7, Windows 10 또는 Windows Server (s)는 요구 사항 문서에 아직 정의되어 있지 않으므로 이러한 사항을 논의해야 할 때입니다.
- 유사한 메모에서 AUT가 웹 기반 시스템 인 경우 논의되고 문서화 된 버전으로 대상 브라우저를 가져옵니다.
- 응용 프로그램에 필요한 모든 타사 소프트웨어 목록을 작성합니다 (필요한 경우 / 지원되는 경우). 여기에는 Adobe Acrobat, Microsoft Office, 추가 기능 등이 포함될 수 있습니다.
여기에 숨겨진 아이디어는 포괄적 인 전략을 수립 할 수 있도록 애플리케이션이 먼저 작동해야하는 모든 필수 및 필수 플랫폼, 장치 및 소프트웨어를 유지하는 것입니다.
아래 그림은 애자일 프로젝트에서 작업하는 경우 테스트 전략의 개요를 이해하는 데 도움이됩니다.
# 3) 테스트 계획
테스터가 AUT에 대한 모든 정보로 무장 한 후 계획 단계에서 전략이 구현됩니다.
테스트 전략과 마찬가지로 테스트 계획도 중요한 단계입니다.
도전
AUT의 성공 (또는 실패)은 주로 테스트 수행 방법에 따라 다르므로이 단계는 전체 테스트 수명주기에서 중요한 측면이됩니다. 왜? 테스트의 일부가이 단계에서 정의되기 때문입니다.
몇 가지 문제를 극복하기 위해 이러한 모범 사례가 실제로 도움이 될 수 있습니다.
모범 사례
- 응용 프로그램을 테스트 할 때 돌을 그대로 두지 않도록 항상 명심하십시오.
- 테스트 전략을 세울 때입니다.
- 소프트웨어가 모든 플랫폼에서 테스트되도록 환경 매트릭스를 만듭니다.
- 마찬가지로 Windows 10 + Internet Explorer 11+ Windows Office 2010+입니다.
- Android 4.2.2+ Chrome 브라우저와 같습니다.
- 애플리케이션이 여러 데이터베이스 (문서화 된 경우)에서 작동하는 경우 데이터베이스 (MySQL, Oracle, SQLServer)를 테스트 매트릭스에 유지하여 일부 테스트와 너무 통합되도록합니다.
- 그에 따라 테스트 머신을 구성하고 이름을 SetUp1, SetUp2 등으로 지정합니다.
- SetUp1에는 Windows 7+ IE 10+ Office 2007+가 있습니다.
- SetUp2에는 Windows 10 이상 IE Edge + Office 2013 이상이있을 수 있습니다.
- SetUp3에는 .apk 파일이 설치된 Android 휴대폰이있을 수 있습니다.
- 축하합니다! 테스트 설정이 준비되었으며 애플리케이션이 작동 할 모든 가능한 플랫폼 조합도 포함되었습니다.
# 4) 테스트
마지막으로 애플리케이션 빌드가 종료되었으며 버그를 찾을 준비가되었습니다! 이제 테스트 계획을 세우고 가능한 한 많은 버그를 찾아야 할 때입니다. 애자일 환경에서 작업하는 경우 그 사이에 몇 가지 단계가있을 것입니다. 그런 다음 스크럼 방법을 따르십시오.
아래 다이어그램은 다양한 테스트 유형의 분류를 보여줍니다.
도전
테스트는 그 자체로 오류가 발생하기 쉬운 번거로운 프로세스입니다! 하나는 응용 프로그램을 테스트하는 동안 많은 문제를 발견합니다. 다음은 구출하기위한 몇 가지 모범 사례입니다.
모범 사례
힘내! 코드에서 결함을 찾으려고합니다. 소프트웨어의 전반적인 작동에주의를 기울여야합니다.
- 항상 테스트 케이스를 거치지 않고 새로운 모습으로 애플리케이션을 보는 것이 좋습니다.
- 소프트웨어 (AUT)의 탐색 경로를 따르십시오.
- AUT에 익숙해 지십시오.
- 이제 특정 모듈의 테스트 케이스 (모두)를 읽으십시오 (선택할 수 있음).
- 이제 AUT로 이동하여 결과를 테스트 사례의 예상 섹션에 언급 된 것과 일치시킵니다.
- 이 아이디어는 지원되는 모든 플랫폼에서 언급 된 모든 기능을 테스트하는 것입니다.
- 사소한 것처럼 보이는 모든 편차를 기록하십시오.
- 편차에 도달하는 단계를 기록하고, 스크린 샷을 찍고, 오류 로그, 서버 로그 및 결함의 존재를 증명할 수있는 기타 지원 문서를 캡처합니다.
- 주저하지 말고 물어보세요. 요구 사항 문서가 있지만 의심 스러울 때가 있습니다.
- 제품 소유자에게 연락하기 전에 의심스러운 개발자 (옆에 앉거나 연락 가능한 경우)에게 연락하십시오. 소프트웨어 작업에 대한 개발자의 관점을 이해합니다. 그들을 이해하십시오. 이 구현이 요구 사항에 맞지 않는다고 생각되면 테스트 관리자에게 알리십시오.
# 5) 출시 전
제품을 시장에 출시하기 전에 제품의 품질이 보장되어야합니다. 소프트웨어는 한 번 개발되었지만 교체 또는 제거 될 때까지 실제로 테스트되었습니다.
도전
소프트웨어는 많은 매개 변수에 대해 엄격한 테스트를 거쳐야합니다.
매개 변수는 다음으로 제한되지 않을 수 있습니다.
- 기능 / 행동.
- 공연.
- 확장 성.
- 상기 플랫폼과 호환됩니다.
또한 수행 된 테스트의 많은 반복에 따라 달라지는 애플리케이션의 성공률을 예측하는 것도 과제입니다.
모범 사례
- 모든 플랫폼의 모든 기능이 테스트되었는지 확인하십시오.
- 테스트되지 않은 영역이나 더 많은 테스트 노력이 필요한 영역을 강조하십시오.
- 출시 전에 모든 테스트 결과의 매트릭스를 유지합니다. 테스트 매트릭스는 제품의 안정성에 대한 전체적인 그림을 제공합니다. 또한 경영진이 출시일에 대한 전화를받는 데 도움이 될 것입니다.
- 제품을 테스트하는 동안 경험에 대한 의견 / 제안을 팀에 제공하십시오.
- 자신을 최종 사용자로 생각하는 귀하의 의견은 소프트웨어에 크게 도움이 될 것입니다.
- 시간 위기 또는 기타 상황으로 인해 일부 테스트를 놓치거나 이에 대해 자세히 설명하지 않습니다. 관리자에게 시험 상태를 알려주십시오.
- 이해 관계자에게 애플리케이션 상태 카드를 제시하십시오. 건강 카드에는 심각도 및 우선 순위와 함께 기록 된, 열림, 닫힘, 간헐적 결함이 모두 포함되어야합니다.
- 릴리스 문서의 초안을 작성하고 팀 전체에 공유하십시오.
- 준비된 릴리스 문서에서 작업하십시오.
- 경영진 / 팀에서 제안한 영역을 개선합니다.
아래 그림은 소프트웨어 릴리스 수명주기 맵을 보여줍니다.
# 6) 출시
마지막으로, 의도 한 사용자에게 제품을 제공해야 할 때가 왔습니다. 우리 모두는 팀으로서 제품을 승인하고 소프트웨어가 사용자를 돕도록 열심히 노력했습니다.
도전
소프트웨어 테스트 엔지니어는 모든 소프트웨어의 출시를 주로 담당합니다. 이 활동에는 프로세스 지향 워크 플로우가 필요합니다. 다음은이 단계에 관련된 몇 가지 모범 사례입니다.
모범 사례
- ACTUAL RELEASE 날짜에 릴리스 문서 작업을하지 않는다는 것을 항상 기억하십시오.
- 항상 실제 출시일 이전에 출시 활동을 계획하세요.
- 회사 정책에 따라 문서를 표준화하십시오.
- 릴리스 문서는 소프트웨어에서 긍정적 인 기대치를 설정해야합니다.
- 문서에서 해당 버전과 관련된 모든 소프트웨어 및 하드웨어 요구 사항을 명확하게 언급하십시오.
- 모든 미결 결함 및 심각도를 포함하십시오.
- 열린 결함으로 인해 영향을받는 주요 영역을 숨기지 마십시오. 릴리스 문서에 배치하십시오.
- 문서를 검토하고 디지털 서명을받습니다 (회사 정책에 따라 다를 수 있음).
- 확신을 갖고 소프트웨어와 함께 릴리스 문서를 발송하십시오.
실제 프로젝트에 대한 QA 테스트 프로세스 – Waterfall 방법
독자로부터 흥미로운 질문을 받았습니다. 회사, 즉 실제 환경에서 테스트는 어떻게 수행됩니까?
대학을 졸업하고 일자리를 찾기 시작한 사람들은 이런 호기심을 가지고 있습니다. 회사의 실제 근무 환경은 어떻습니까?
여기서는 실제 작업 과정에 중점을 두었습니다. 회사의 소프트웨어 테스트 .
새로운 프로젝트를받을 때마다 초기 프로젝트 친숙성 회의가 있습니다. 이 회의에서는 기본적으로 고객이 누구인지 논의합니다. 프로젝트 기간은 얼마이며 언제 제공됩니까? 관리자, 기술 책임자, QA 책임자, 개발자, 테스터 등과 같이 프로젝트에 모두 참여하는 사람은 누구입니까?
SRS (소프트웨어 요구 사양)에서 프로젝트 계획이 개발됩니다. 테스터의 책임은이 SRS 및 프로젝트 계획에서 소프트웨어 테스트 계획을 만드는 것입니다. 개발자는 디자인부터 코딩을 시작합니다. 프로젝트 작업은 여러 모듈로 나뉘며 이러한 프로젝트 모듈은 개발자에게 배포됩니다.
그 동안 테스터의 책임은 테스트 시나리오를 만들고 할당 된 모듈에 따라 테스트 케이스를 작성하는 것입니다. 우리는 SRS의 거의 모든 기능 테스트 사례를 다루려고합니다. 데이터는 일부 Excel 테스트 사례 템플릿 또는 버그 추적 도구에서 수동으로 유지 관리 할 수 있습니다.
개발자가 개별 모듈을 완료하면 해당 모듈이 테스터에게 할당됩니다. 연기 테스트는 이러한 모듈에서 수행되며이 테스트에 실패하면 수정을 위해 모듈이 해당 개발자에게 재 할당됩니다.
합격 된 모듈의 경우 작성된 테스트 케이스에서 수동 테스트가 수행됩니다. 모듈 개발자에게 할당 된 버그가 발견되면 버그 추적 도구 . 버그 수정시 테스터는 모든 관련 모듈의 버그 확인 및 회귀 테스트를 수행합니다. 버그가 확인을 통과하면 확인 됨으로 표시되고 종료 됨으로 표시됩니다. 그렇지 않으면 위에서 언급 한 버그주기가 반복됩니다. (버그 수명주기는 다른 게시물에서 다룰 것입니다)
개별 모듈에 대해 다른 테스트가 수행되고 모듈 통합에 대한 통합 테스트가 수행됩니다. 이러한 테스트에는 호환성 테스트, 즉 다른 하드웨어, OS 버전, 소프트웨어 플랫폼, 다른 브라우저 등에서 애플리케이션 테스트가 포함됩니다.
부하 및 스트레스 테스트도 SRS에 따라 수행됩니다. 마지막으로 가상 클라이언트 환경을 생성하여 시스템 테스트를 수행합니다. 모든 테스트 케이스가 실행되면 테스트 보고서가 준비되고 제품 출시 결정이 내려집니다!
릴리스 할 요구 사항의 단계
다음은 각 소프트웨어 품질 및 테스트 라이프 사이클에서 수행되는 각 테스트 단계의 세부 정보입니다. IEEE 및 ISO 표준.
#1) SRS 검토 : 소프트웨어 요구 사항 사양을 검토합니다.
# 2) 목표 메이저 릴리스에 대해 설정됩니다.
# 3) 목표 날짜 릴리스 계획.
# 4) 세부 프로젝트 계획 지어졌습니다. 여기에는 설계 사양에 대한 결정이 포함됩니다.
# 5) 테스트 계획 개발 설계 사양을 기반으로합니다.
# 6) 테스트 계획 : 여기에는 목표, 테스트 중에 채택 된 방법론, 테스트 할 기능과 테스트하지 않을 기능, 위험 기준, 테스트 일정, 다중 플랫폼 지원 및 테스트를위한 리소스 할당이 포함됩니다.
# 7) 테스트 사양 : 이 문서에는 테스트 전에 필요한 기술 세부 정보 (소프트웨어 요구 사항)가 포함되어 있습니다.
# 8) 테스트 케이스 작성
- 연기 ( BVT ) 테스트 케이스
- 온 전성 테스트 사례
- 회귀 테스트 케이스
- 부정적인 테스트 케이스
- 확장 된 테스트 케이스
# 9) 개발 : 모듈은 하나씩 개발됩니다.
# 10) 설치자 바인딩 : 설치 프로그램은 개별 제품을 중심으로 구축됩니다.
애니메이션을 무료로 볼 수있는 최고의 웹 사이트
#열한) 구축 절차 : 빌드에는 사용 가능한 제품의 설치 프로그램 (여러 플랫폼)이 포함됩니다.
# 12) 테스트 : 연기 테스트 (BVT) : 추가 테스트에 대한 결정을 내리기위한 기본 애플리케이션 테스트입니다.
- 새로운 기능 테스트
- 크로스 브라우저 및 교차 플랫폼 테스트
- 스트레스 테스트 및 메모리 누출 테스트.
# 13) 테스트 요약 보고서
- 버그 신고 및 기타 보고서가 생성됩니다.
# 14) 코드 동결
- 이 시점에서 더 이상 새로운 기능이 추가되지 않습니다.
# 15) 테스트 : 빌드 및 회귀 테스트.
# 16) 제품 출시 결정.
# 17) 출시 후 시나리오 추가 목표를 위해.
이것은 회사 환경에서 실제 테스트 프로세스를 요약 한 것입니다.
결론
소프트웨어 테스터의 일은 도전으로 가득 차 있지만 즐거운 일입니다. 이것은 똑같이 열정적이고 의욕이 넘치며 열정이 넘치는 사람을위한 것입니다. 누군가의 결점을 찾는 것이 항상 쉬운 일은 아닙니다! 이를 위해서는 많은 기술과 결함에 대한 과감한 눈이 필요합니다.
모든 품질 외에도 테스터는 프로세스 지향적이어야합니다. 다른 모든 산업과 마찬가지로 IT의 프로젝트도 단계적으로 진행되며 모든 단계에는 잘 정의 된 목표가 있습니다. 그리고 모든 목표에는 잘 정의 된 수용 기준이 있습니다. 테스트 엔지니어는 많은 양의 소프트웨어 품질을 어깨에 짊어 져야합니다.
소프트웨어의 모든 단계에서 작업하는 동안 테스터는 모범 사례를 따라야하며 각 단계에 관련된 프로세스를 조정해야합니다. 모범 사례와 잘 구성된 프로세스를 따르면 테스터 작업을 쉽게 할 수있을뿐만 아니라 소프트웨어 품질을 보장하는데도 도움이됩니다.
위의 단계에 참여한 적이 있습니까? 아래에서 귀하의 경험을 자유롭게 공유하십시오.
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스팅 과정 피드백 및 리뷰
- 성공적인 버그없는 소프트웨어를 생산하기위한 테스트 릴리스 프로세스를 개선하는 방법