7 step practical implementation manual testing before production release
수동 테스트에 대한이 시리즈의 이전 게시물에서 수동 테스트의 기본 사항에 대해 가능한 한 많은 정보를 제공하려고했습니다.
놓쳤다면 여기에서 읽을 수 있습니다 .
당신이 찾고 있던 답변에 최대한 가까이 다가가는 데 성공적 이었기를 바랍니다.
그렇다면 수동 테스트의 실제 구현에 대해 더 많이 알고 싶지 않습니까? 어떻게 더 익숙해지고 실제로 경력을 시작하는 방법을 알고 싶으십니까?
이 기사는 이러한 모든 측면을 조명합니다.
시작하자.
학습 내용 :
- 수동 테스트주기
- 프로덕션 출시 전 7 가지 실제 수동 테스트 단계
- # 1) 요구 사항 수집
- # 2) 요구 사항 토론 / 공유
- # 3) 디자인
- # 4) 테스트 시나리오 / 테스트 케이스 설계
- # 5) 개발 단계
- # 6) 테스트 단계
- # 7) 비즈니스 분석가 (BA) 검토
- # 8) 배송 / 출시
- 수동 (인간 읽기) 테스트 유형
- 추천 도서
수동 테스트주기
이해하다 수동 테스트주기 또는 소프트웨어 테스트 수명주기 (STLC), 먼저 소프트웨어 개발 수명주기 (SDLC)를 이해해야합니다. 이미 이해하고 계실 것입니다.
사람들은 별도로 언급하지만 실제로 공존 할 수 있는지 확실하지 않습니다. 그들은 서로 밀접하게 통합되어 있습니다. 글쎄, 이러한주기조차도 인터넷 공간에서 생성되고 떠 다니는 많은 버전을 가지고 있으며, 어떤 개발 모델이 선택되는지에 따라 크게 다릅니다.
대부분의 세상은 민첩하게 가고 있습니다 요즘에는 애자일을 중심으로 작업을 단순화 할 것입니다.
프로덕션 출시 전 7 가지 실제 수동 테스트 단계
내가 간다.
내가 SDLC와 STLC에 대해 이야기하고 있다는 것을 기억하십시오.
# 1) 요구 사항 수집
비즈니스 분석가 (요구 사항 수집을 담당하는 개인 / 팀)는 요구 사항을 문서화합니다. 그들은 요구 사항을 문서화합니다. 그게 가장 중요합니다. 여기에만 집중할 수 있습니다. 문서화 된 위치는 덜 중요합니다.
사람들은 자신에게 적합한 것을 문서화하기 위해 무엇이든 사용하지만 MS 워드 문서와 같은 기존 플랫폼, Jira / Rally와 같은 최신 플랫폼 및 Trello와 같은 새로운 시대 도구에 국한되지 않습니다.
# 2) 요구 사항 토론 / 공유
그런 다음 Business Analyst는 문서화 된 요구 사항을 개발 팀, 테스트 팀 및 UX 팀 (필요한 경우)과 공유해야합니다. 이는 일반적으로 세 가지 기능 모두의 SPOC (단일 연락 창구 또는 전체 팀)가 전체 요구 사항을 충족하고 이해하는 공식 회의를 통해 발생합니다.
건전한 업무 문화에서 요구 사항은 모든 각도에서 논의되고 회의의 각 구성원은 질문과 의문을 제기 할 수 있습니다. 모든 질문에 답하고 요구 사항의 수정이 필요한 경우이 단계를 완료로 간주 할 수 있습니다. 다시 말하지만,이 특정 회의 / 단계라고 부르는 것과 그 문서는 회사마다 다릅니다.
추가 읽기=> SRS 문서 검토 방법
모든 질문에 답하고 요구 사항에 필요한 수정이 완료되면이 단계는 다음과 같이 간주 될 수 있습니다. 끝난 .
다시 말하지만,이 특정 회의 / 단계라고 부르는 것과 그 문서는 회사마다 다릅니다.
예를 들면 문서는 SRS (시스템 요구 사항 사양), 요구 사항 문서, Epic, 사용자 스토리, 스토리 포인트 (최소 요구 사항 단위) 등으로 호출되거나 분류됩니다. 유사한 행에서 요구 사항이 공유되는이 회의는 요구 사항 토론 회의, 그루밍, 구멍 뚫기 회의 등, 내 요점을 이해했으면 좋겠습니까?
다른 이름에 관계없이 항상 주요 아이디어를 기억할 수 있도록 이러한 용어를 누르십시오.
이 회의 게시 두 단계는 특정 순서없이 동시에 트리거됩니다. 다음 두 단계를 참조하세요.
# 3) 디자인
개발 팀은 요구 사항이 논의되고 주요 보류 지점이 없을 때 기술 설계를 시작합니다. 이 단계에서 수행되는 작업은 회사마다 다릅니다.
이 단계에는 다음 작업이 포함될 수 있지만 이에 국한되지는 않습니다.
- 개발 접근 방식 결정
- 디자인 문서 준비
- 순서도 디자인
- 노력 추정
- 이 새로운 요구 사항이 기존 기능에 미치는 영향 파악
- 기존 데이터 등을 패치해야합니다.
UX 팀은 UI가 변경되거나 새로운 화면이 개발 될 때이 단계에 참여할 수도 있습니다. UX 팀은 토론에서 기능 / 기능에 대한 UI 프로토 타입으로 개발 팀과 테스트 팀을 돕습니다. 이것은 Photoshop 문서, 간단한 이미지, PowerPoint 프레젠테이션 또는 개발 팀이 화면을 개발해야하는 방법을 이해하게 만드는 다른 모든 것이 될 수 있습니다.
노트: 이상적으로 이러한 화면 또는 최소한 해당 초안 버전은 팀이 더 나은 이해를 구축 할 수 있도록 요구 사항 토론 세션에만 표시됩니다. 주어진 시간에 참조 할 수 있도록 원래 요구 사항에 태그가 지정됩니다.
# 4) 테스트 시나리오 / 테스트 케이스 설계
설계 단계와 병행하여 테스트 팀은 논의 된 요구 사항을 기반으로 테스트 시나리오 및 / 또는 테스트 사례를 구축하는 것으로 시작합니다. 테스트 시나리오가 항상 먼저 작성되고 테스트 케이스로 분리되는지 여부는 다시 일정하지 않습니다.
제 생각에는 테스트 시나리오를 문서화하든 그렇지 않든 항상 테스트 케이스 앞에 있습니다. 테스트 시나리오는 당신이 말할 수있는 글 머리 기호이며, 더 자세히 드릴 다운하도록 안내합니다. 테스트 케이스 작성이 끝나면 개발 팀과 공유하여 테스트 범위에 대한 아이디어를 제공 할 수 있으며 발생했거나 발생한 개발이 작성된 테스트 케이스를 충족하는지 확인할 수도 있습니다.
테스트 케이스 작성이 끝나면 개발 팀과 공유하여 테스트 범위에 대한 아이디어를 제공 할 수 있으며 발생했거나 발생한 개발이 작성된 테스트 케이스를 충족하는지 확인할 수도 있습니다.
이상적으로 작성된 테스트 케이스는 다음과 같은 여러 각도에서 테스트 리드 또는 동료의 검토를받습니다.
- 요구 사항 범위
- 맞춤법 문법
- 테스트 케이스 작성 표준 (팀 / 회사가 따르는 템플릿 만 있음)
- 하위 호환성
- 플랫폼 호환성
- 테스트 데이터 참조
- 대상 테스트 유형 등
추가 읽기=> SRS 문서에서 테스트 케이스 작성
이상적으로는 검토 및 수정이 필요한 경우에만 개발 팀에 전달됩니다.
'테스트 케이스 작성이 끝나면 모든 테스트 케이스가 주어진 요구 사항에 대한 완전한 지식과 특정 시간까지 발견 된 가능한 테스트 시나리오를 기반으로 작성되었습니다'라고 말한 적이 있습니다. 처음에 100 % 테스트 케이스 커버리지를 확보하는 것은 거의 불가능합니다.
임의의 (그러나 의도 된) 동작, 순전히 임의의 동작 (원숭이 테스트) 및 일부 드문 시나리오에서 찾을 수있는 결함이 있습니다. 이 중 몇 가지를 놓칠 가능성이 있습니다. 그리고 언젠가는 아주 기본적인 것조차 놓칠 수 있습니다. 결국 당신은 인간입니다. 그러나 여기서 적어도 좋은 테스트 케이스 검토와 구조화 된 테스트 케이스 작성 방법은 당신을 구할 수 있습니다.
종종 테스터 또는 테스트 팀은 진실을 밝히거나 요구 사항에 대해 더 많이 생각할 때 기존 청크에 점점 더 많은 테스트 케이스를 추가합니다.
글쎄, 지금 쯤이면 어떤 단어 (소프트웨어 테스팅에서 표준이 된)가 아직 사용되지 않았기 때문에 소프트웨어 테스팅에 대한 나의 지식을 의심하고있을 것입니다. 테스트 계획이 맞습니까?
이것에 대해 말씀 드리겠습니다. 나는 테스트 계획에 언급 된 대부분의 정보가 필요하다고 굳게 믿지만, 그것들을 모두 같은 장소에 문서화하고 그것을 절대적으로 의무화하는 것은 내가 논쟁의 여지가 있다고 생각하는 것입니다.
어쨌든, 그것은 완전히 별개의 주제입니다. 이것에 대한 '정장'정보를 공유하는 것은 어렵지만 시도해 보겠습니다.
테스트 리드 또는 테스트 리드와 함께 테스트 계획을 준비하거나 필요한 정보를 다른 위치에 문서화합니다.
추가 읽기=> 테스트 계획 문서 작성 방법
이 단계에서 완전히 동결되어야하는 정보 :
- 테스트 범위 : 요구 사항, 이전 버전과의 호환성, 플랫폼, 장치 등
- 테스트 할 사람 / 팀
- 테스트 노력 추정
- 제한 사항 : 사전에 허용 된 모든 가정 또는 제한.
- 사람들은 추가로 입력 기준, 종료 기준, 위험 등을 문서화합니다. 이는 정상적인 이해 여야하므로 별도의 언급이 필요하지 않다고 생각합니다.
- 입력 기준 (테스트 시작시기) : 테스트에 사용할 수있는 기능의 테스트 가능한 부분이있을 때 시작하는 경우는 거의 없습니다. 전체 기능이 테스트 될 때까지 기다리는 사람은 거의 없습니다. 기본 흐름이 작동하는 것으로 확인되면 테스트가 시작됩니다.
- 종료 기준 (중지시기) : 차단제가없는 경우 오픈 스테이지 테스트에서 중대 및 중대 (영향을받을 수있는) 결함을 중지 할 수 있습니다. 또는 중간에 너무 많은 결함이있는 경우 적절한 이해 관계자가 테스트를 중지 할 수 있습니다.
- 위험 : 문서화 된 계획에 따라 테스트가 수행되지 않는 경우 비즈니스 위험 또는 기능적 위험.
# 5) 개발 단계
설계 단계 이후의 개발 팀은 테스트 가능한 요구 사항 청크의 개발이 완료 될 때 실제 개발 및 단위 테스트로 시작됩니다. 구현시 청크 테스트를위한 기능을 전달하거나 전체 기능을 한 번에 전달할 수 있습니다.
이상적인 시나리오에서는 테스트를 위해 개발 된 기능을 전달하기 전에 공식 코드 검토 및 화이트 박스 테스트가 수행됩니다. 이상적으로, 개발 팀은 요구 사항 및 설계 문서 외에도 테스트 팀에서 제공 한 테스트 사례를 참조해야합니다.
# 6) 테스트 단계
앞서 언급했듯이이 단계의 시작은 회사마다, 팀마다 다릅니다.
테스트 팀은 전체 요구 사항의 테스트 가능한 (독립적으로 테스트 할 수있는 것) 부분이 개발되거나 전체 요구 사항이 개발 될 때 테스트를 시작합니다.
현재 클라우드 기반 웹 호스팅 서비스의 리더는 어느 회사입니까?
이 단계에서 더 자세히 살펴보고 중요한 작업에 대해 이야기하겠습니다.
- 테스터 / 테스트 팀은 테스트 라운드 (탐색 테스트 및 서면 테스트 케이스 실행) 및 로깅 결함으로 시작합니다.
- 개발 팀은 우선 순위에 따라 문제를 해결합니다.
- 테스트가 진행되는 환경에서 새 빌드 (코드)가 수행됩니다.
- 해결 된 결함은 테스터 / 테스트 팀에서 확인하고 수정 됨으로 표시됩니다.
- 이주기는 시간 종료 기준에 도달 할 때까지 계속됩니다.
- 필요에 따라 결함은 유효하지 않음, 중복으로 표시되고 향상으로 분류 될 수도 있습니다.
회사마다 다른 또 다른 점은 수행해야 할 테스트 라운드 수입니다. 경우에 따라 첫 번째 테스트 라운드는 준비된 작은 기능 부분에서 수행되고 모든 요구 사항이 개발되면 다른 환경에서 엔드 투 엔드 테스트 라운드가 이어집니다. 그러나 나는 또한 사람들이 세 번의 적절한 전체 테스트 라운드를 수행하고 네 번째 라운드를 이성 / 연기 라운드로 수행한다고 들었습니다.
여러 테스트 라운드를 수행하는 첫 번째 의제는 다양한 환경에서 기능을 테스트하는 것이고, 두 번째는 모든 스토리 포인트가 개발되면 엔드 투 엔드 테스트를 수행하는 것입니다. Sanity 라운드는 일반적으로 릴리스의 모든 스토리가 독립적으로 개발되고 테스트되면 빠른 자신감을 얻습니다.
자세한 단계 읽기=> 테스트 실행 단계
# 7) 비즈니스 분석가 (BA) 검토
비즈니스 분석가는 테스트 결과를 참조하거나 테스트 결과를 참조하고 실제 느낌을 얻기 위해 응용 프로그램을 가지고 놀면서 요청 된 기능을 검토합니다. 이 단계는 기업 전반에 걸쳐 다른 조치를 취합니다.
BA는 한 번에 또는 청크로 전체 릴리스의 범위를 검토 할 수 있습니다. 이에 따라이 단계는 최종 온 전성 테스트 전 또는 테스트 팀의 최종 온 전성 테스트 라운드 후에 올 수 있습니다.
위의 7 단계는 특정 릴리스 (배송)에서 모든 사용자 스토리 / 요구 사항을 충족해야합니다. 모든 요구 사항에 대해 이러한 모든 단계가 완료되면 릴리스가 배송 준비가 된 것입니다.
# 8) 배송 / 출시
릴리스는 Business Analyst가 성공적으로 검토 한 후 배송 준비로 태그가 지정됩니다.
추천 읽기=> 테스트 릴리스 프로세스
수동 (인간 읽기) 테스트 유형
전체 테스트 유형에 대해 숫자로 이야기해야한다면 어딘가에서 이름이 다른 100 가지 유형의 테스트 . 솔직히 말해서 나는 이러한 모든 유형 (말장난 의도)의 차이점을 이해할만큼 똑똑하지 않습니다.
간단하고 간단합니다. 인간의 노력과 지능으로 주어진 요구 사항에 대해 응용 프로그램의 기능을 테스트합니다. 테스트 범위 및 의제에 따라 몇 가지 유형으로 더 나뉩니다. 다음 단락에 나열된 유형.
테스트 범위 및 의제에 따라 몇 가지 유형으로 더 나뉩니다. 다음 단락에 나열된 유형.
허용된다면 휴먼 테스트 (모든 테스터가 수동 기능 테스트 이상을 수행하도록 권장합니다)의 몇 줄을 말씀 드리겠습니다. 이제 혼동하지 마십시오. 제 생각에 수동 기능 테스트는 인간 테스트의 하위 집합입니다. 인간의 마음 만이 할 수있는 일이 너무 많기 때문입니다.
다음은 인간 테스트로 분류 할 수있는 인기 있고 중요한 테스트 유형의 목록입니다.
- 수동 기능 테스트 : 인간의 노력과 지능으로 주어진 요구 사항에 대해 응용 프로그램의 기능을 테스트합니다. 또한 시스템 테스트, 단위 테스트, 연기 테스트, 온 전성 테스트, 통합 테스트, 회귀 테스트, UI 테스트 등과 같은 테스트 범위 및 의제에 따라 여러 유형으로 나뉩니다.
- 성능 시험 : 이것은 비 기능 테스트로 분류됩니다. 그러나 실행은 사람이나 도구에 의해 수행되지만 다시 구현하는 사람은 사람입니다. 테스터는 부하 테스트 및 모든 도구를 사용하지 않아야하는 경우 응답 시간 측면에서이 테스트를 수행해야합니다 (허용 가능한지 확인하기 위해).
- 브라우저 / 플랫폼 호환성 테스트 : 테스트중인 애플리케이션은 브라우저와 플랫폼 (또는 모바일 애플리케이션 인 경우 기기)에서 예상대로 보이고 작동해야합니다 (분명히 브라우저 엔진에 따라 약간의 차이가있을 수 있음).
- 사용성 테스트 : 우선 이것이 그 자체로 거대한 주제이며 일반적으로 사용성 테스트 전문가가 소유하고 있다는 것에 동의하겠습니다. 나는 테스터로서 우리가 덜 쓸모없는 것을 발견하면 적어도보고하거나 강조해야한다고 믿습니다. 그렇지 않으면 우리의 견해를 공유해야합니다.
- 보안 테스트 : 다시 한 번 매우 거대한 테스트 유형이며 물론 많은 실제 지식이 필요합니다. 테스터는 사용 가능한 지식과 해당되는 경우에 따라 URL 변조, 교차 사이트 스크립팅, SQL 주입, 세션 하이재킹 등과 같은 최소한의 기본 테스트를 배우고 실행해야합니다.
- 다중 테넌시 테스트 : 애플리케이션이 다중 테넌트 인 경우 (예 : 여러 클라이언트의 데이터를 보유하는 단일 인스턴스)이 테스트는 필수입니다. 요구 사항에 명시적인 언급과 관계없이이 작업을 수행해야합니다. 한 고객의 데이터가 다른 고객에게 표시되는 것은 일종의 개발 및 테스트 범죄입니다.
노트: 위의 견해는 나의 개인적인 견해입니다. 또한 지식에 대한 광범위한 테스트 유형 목록을 살펴보고 필요한 경우 따르거나 사용하는 것이 좋습니다. 수년에 걸쳐 나는 당신이 무언가를 사용하든, 믿든 믿지 않든, 당신의 분야에서 널리 사용되는 개념에 대한 지식을 여전히 가지고 있어야한다는 것을 이해했습니다.
이 부분은 여기까지입니다. 읽어 주셔서 감사합니다. 의견에 의견 / 피드백을 공유하십시오.
이것의 다음과 마지막 부분에서 수동 테스트 자습서 시리즈 , 나는 당신 모두를 돕기 위해 노력할 것입니다 테스트 필드에 들어가기 위해 어떤 준비를해야하며 거기에 들어갈 수있는 가능한 방법은 무엇입니까?