how review srs document
이것은 우리의 두 번째 튜토리얼입니다. '실시간 프로젝트에 대한 무료 온라인 소프트웨어 테스트 교육' 시리즈. 여기에서 처음이라면 첫 번째 소개 튜토리얼을 확인하십시오. 라이브 프로젝트에 대한 종단 간 소프트웨어 테스트 교육.
이제 SRS 워크 스루가 어떻게 발생하는지,이 단계에서 식별해야하는 것이 무엇인지, 시작하기 전에 취해야 할 사전 단계, 직면 할 수있는 문제 등을 자세히 분석해 보겠습니다. 상세한 방식.
SDLC의 설계 단계 :
SDLC의 다음 단계는 '설계'입니다. 여기에서 기능 요구 사항이 기술 세부 사항으로 변환됩니다. 개발, 디자인, 환경 및 데이터 팀이이 단계에 참여합니다. 이 단계의 결과는 일반적으로 기술 설계 문서 TDD입니다.
입력은 TDD 생성과 QA 팀이 프로젝트의 QA 측면에서 작업을 시작하기위한 SRS 문서입니다. 이는 SRS를 검토하고 테스트 목표를 식별하는 것입니다.
학습 내용 :
자바에서 junit 테스트 케이스를 작성하는 방법
SRS 검토 란 무엇입니까?
SRS는 비즈니스 분석가 및 환경 / 데이터 팀과 공동으로 개발 팀에서 만든 문서입니다. 일반적으로이 문서가 완성되면 자세한 설명이 준비된 회의를 통해 QA 팀과 공유됩니다.
때로는 이미 존재하는 응용 프로그램의 경우 공식 회의와이 문서를 통해 우리를 안내하는 누군가가 필요하지 않을 수 있습니다. 이 작업을 수행하는 데 필요한 정보가있을 수 있습니다.
SRS 검토는 기능 요구 사항 사양 문서를 검토하고 대상 응용 프로그램이 어떤 모습 일지 이해하는 것입니다.
공식 형식과 샘플은 이전 기사에서 모두와 공유했습니다. 모든 SRS가 정확히 그런 방식으로 문서화된다는 의미는 아닙니다. 항상 형식은 내용에 부차적 인 .
일부 팀은 글 머리 기호 목록을 작성하기로 선택하고, 일부 팀은 사용 사례를 포함하며, 일부 팀은 샘플 스크린 샷 (예 : 문서)을 포함하고 일부는 단락의 세부 정보 만 설명합니다.
소프트웨어 요구 사항 사양 검토를위한 사전 단계
1 단계) 문서는 여러 번 수정되므로 참조 된 문서의 올바른 버전 인 SRS가 있는지 확인하십시오.
2 단계) 검토가 끝날 때 각 팀원의 예상 사항에 대한 지침을 설정합니다. 즉,이 단계에서 예상되는 결과물을 결정합니다. 일반적으로이 단계의 결과는 테스트 시나리오를 식별하는 것입니다. 테스트 시나리오는 특정 기능에 대한 '테스트 대상'에 대한 한 줄 포인터에 불과합니다.
3 단계) 또한이 결과물이 표시되는 방식에 대한 지침을 설정하십시오. 즉, 템플릿입니다.
4 단계) 팀의 각 구성원이 전체 문서에 대해 작업 할 것인지 또는 문서를 나눌 것인지 결정하십시오. 특정 팀원과의 지식 집중을 방해 할 수 있으므로 모든 사람이 모든 것을 읽는 것이 좋습니다.
그러나 1000 페이지에 가까운 SRS 문서를 실행하는 대규모 프로젝트의 경우 문서 모듈을 현명하게 분할하고 개별 팀 구성원에게 할당하는 방법이 가장 실용적입니다.
5 단계) SRS 검토는 소프트웨어 테스트에 필요한 특정 전제 조건이 있는지 더 잘 이해하는데도 도움이됩니다.
6 단계) 부산물로 일부 기능을 이해하기 어렵거나 기능 요구 사항에 더 많은 정보를 통합해야하거나 SRS에서 실수가있는 경우 쿼리 목록이 식별됩니다.
시작하려면 무엇이 필요합니까?
- SRS 문서의 올바른 버전
- 누가 무엇을 얼마나 시간을 가지고 있는지에 대한 명확한 지침.
- 테스트 시나리오를 생성하기위한 템플릿입니다.
- 기타 정보-질문시 연락 할 사람 또는 문서 불일치시 신고 할 사람
누가이 정보를 제공합니까?
초보자를위한 컴퓨터 프로그래밍 방법
일반적으로 팀장은 위 섹션에 나열된 모든 항목을 제공 할 책임이 있습니다. 그러나 팀원의 의견은이 모든 노력의 성공을 위해 항상 중요합니다.
팀 리더는 종종 묻습니다. 어떤 종류의 입력입니까? 관심이있는 사람에게 특정 모듈을 할당하지 않는 팀원에게 할당하는 것이 낫지 않습니까? 결정을 내리는 것보다 팀의 의견을 바탕으로 목표 날짜를 정하는 것이 좋지 않을까요? 또한 프로젝트의 성공을 위해서는 템플릿이 중요합니다.
일반적으로 템플릿은 특정 팀의 편리함과 편안함에 맞게 조정될 때 효율성이 더 높습니다. 따라서 팀 리더는 무엇보다 팀 구성원이라는 점에 유의해야합니다. 프로젝트를 원활하게 진행하려면 일상적인 의사 결정에 팀을 참여시키는 것이 중요합니다.
테스트 시나리오에 템플릿이 필요합니까?
테스트 시나리오를위한 템플릿이 필요한 이유는 목록 만 작성하면 충분하지 않습니까?
그것은 확실하다. 그러나 소프트웨어 프로젝트는 '1 인'쇼가 아닙니다. 그들은 포함한다 팀워크 .
각 팀이 소프트웨어 요구 사항 사양의 한 모듈을 검토하기로 결정한 경우 4- 팀이 있다고 상상해보십시오. 팀원 A는 종이에 목록을 작성했습니다. 팀원 2는 엑셀 시트를 사용했습니다. 팀원 3은 메모장을 사용했습니다. 팀원 4가 doc라는 단어를 사용했습니다. 하루가 끝날 때 프로젝트를 위해 수행 된 모든 작업을 어떻게 통합합니까?
또한 어떤 것이 표준인지 어떻게 결정할 수 있으며, 규칙을 만들지 않았다면 무엇이 옳고 무엇이 옳지 않은지 어떻게 말할 수 있습니까?
이것이 바로 템플릿입니다. 전체 팀의 통일성과 동시성을위한 일련의 지침 및 합의 된 형식.
QA 테스트 시나리오를위한 템플릿을 만드는 방법은 무엇입니까?
템플릿 복잡하거나 융통성이 없을 필요가 없습니다.
필요한 것은 유용한 테스트 아티팩트를 만드는 효율적인 메커니즘입니다. 아래에서 볼 수있는 것과 같은 간단한 것 :
이 템플릿의 헤더에는 프로젝트, 현재 문서 및 참조 문서에 대한 기본 정보를 캡처하는 데 필요한 공간이 포함되어 있습니다.
아래 표를 통해 테스트 시나리오를 만들 수 있습니다. 포함 된 열은 다음과 같습니다.
열 # 1) 테스트 시나리오 ID
테스트 프로세스의 모든 엔티티는 고유하게 식별 가능해야합니다. 따라서 모든 테스트 시나리오에는 ID가 할당되어야합니다. 이 ID를 할당하는 동안 따라야 할 규칙을 정의해야합니다.
이 기사에서는 다음과 같은 명명 규칙을 따를 것입니다. TS (테스트 시나리오를 나타내는 접두사) 뒤에‘_’, 모듈 이름 나를 (Orange HRM 프로젝트의 내 정보 모듈),‘_’, 하위 섹션 ( 예를 들어, 나를 내 정보 모듈의 경우 피 사진 등) 뒤에 일련 번호가 있습니다. 예 :“TS_MI_MIM_01”.
열 # 2) 요구 사항
테스트 시나리오를 만들 때 선택한 SRS 문서 섹션에 다시 매핑 할 수 있어야합니다. 요구 사항에 ID가 있으면이를 사용할 수 있습니다. 테스트 가능한 요구 사항을 확인한 SRS 문서의 섹션 번호 또는 페이지 번호가 아니라면 그렇게 할 것입니다.
열 # 3) 테스트 시나리오 설명
'테스트 대상'을 지정하는 한 줄짜리입니다. 이를 테스트 목표라고도합니다.
컬럼 # 4) 중요성
이것은 특정 기능이 AUT에 얼마나 중요한지에 대한 아이디어를 제공하기위한 것입니다. 높음, 중간 및 낮음과 같은 값을이 필드에 할당 할 수 있습니다. 1-5, 5가 가장 중요하고 1이 덜 중요 함과 같은 포인트 시스템을 선택할 수도 있습니다. 이 필드가 취할 수있는 값이 무엇이든 미리 결정해야합니다.
열 # 5) 테스트 케이스 수
하나의 테스트 시나리오를 작성하게 될 개별 테스트 케이스 수에 대한 대략적인 추정치입니다. 예를 들어, 로그인을 테스트하기 위해 다음 상황을 포함합니다. 올바른 사용자 이름과 비밀번호. 올바른 사용자 이름과 잘못된 암호. 올바른 비밀번호와 잘못된 사용자 이름. 따라서 로그인 기능의 유효성을 검사하면 3 개의 테스트 사례가 발생합니다.
노트 : 이 템플릿을 확장하거나 필요에 따라 필드를 제거 할 수 있습니다.
예를 들면 , 헤더에 'Reviewed by'를 추가하거나 생성 날짜 등을 제거 할 수 있습니다. 또한 테이블에 'Created by'필드를 포함하여 특정 테스트 시나리오를 담당하는 테스터를 지정하거나 'No. of Test cases”열. 선택은 당신의 것입니다. 전체 팀에 가장 적합한 방법을 선택하십시오.
이제 Orange HRM SRS 문서를 검토하고 테스트 시나리오를 작성하겠습니다.
네트워크 보안 키는 어디에서 찾을 수 있습니까?프로 팁 : 첫 번째 자습서에서 제공 한 SRS 샘플의 목차를 확인하여 문서가 어떻게 흐르고 얼마나 많은 작업이 포함 될지에 대한 좋은 아이디어를 얻으십시오.
섹션 1 문서의 목적입니다. 거기에는 테스트 가능한 요구 사항이 없습니다.
2.1 절 : 프로젝트 개요-청중-테스트 가능한 요구 사항도 없습니다.
2.2 절 : 하드웨어 및 호스팅-이 섹션에서는 Orange HRM 사이트가 호스팅되는 방식에 대해 설명합니다. 이제이 정보가 테스터에게 중요합니까? 대답은 예와 아니오입니다. 예, 테스트 할 때 실시간 환경과 유사한 환경이 필요하기 때문입니다.
이것은 우리에게 그것이 필요한 방법에 대한 아이디어를 제공합니다. 아니요, 왜냐하면 테스트 가능한 요구 사항이 아니기 때문입니다. 테스트를 수행하기위한 일종의 전제 조건입니다.
섹션 3 : 여기에 로그인 화면과 사이트에 들어가는 데 필요한 계정 유형에 대한 세부 정보가 있습니다. 이것은 테스트 가능한 요구 사항입니다. 따라서 테스트 시나리오의 일부가되어야합니다.
SRS의 몇 가지 섹션에 대한 테스트 시나리오가 추가 된 테스트 시나리오 문서를 참조하십시오. 연습을 위해 유사한 방식으로 나머지 시나리오를 추가하십시오. 그러나 문서의 섹션 4로 바로 이동하겠습니다.
섹션 4 : 미적 / HTML 요구 사항 및 지침-이 섹션에서는 SRS 검토시 테스트 팀이 일부 요구 사항을 이해하지 못할 수있는 방법을 가장 잘 설명하지만 팀은이를 모두 동일하게 테스트 가능한 요구 사항으로 기록해야합니다.
테스트 방법 및 특정 설정 / 검증을위한 팀의 도움이 필요한 경우 현재로서는 알 수없는 세부 정보입니다. 그러나 그것들을 테스트 범위의 일부로 만드는 것은 우리가 그것들을 놓치지 않기위한 첫 번째 단계입니다.
OrangeHRM 애플리케이션에 대한 샘플 테스트 시나리오: (이미지를 클릭하면 확대됩니다)
=> 참조 및 테스트 시나리오 문서 다운로드 자세한 내용은.
SRS 검토에 관한 몇 가지 중요한 관찰 사항
#1) 어떤 정보도 공개되지 않습니다.
#두) 특정 요구 사항이 올바른지 여부와 테스트 가능 여부에 대한 타당성 분석을 수행합니다.
#삼) 별도의 성능 / 보안 또는 다른 형태의 테스트 팀이 존재하지 않는 한, 모든 비 기능적 요구 사항을 고려해야합니다.
# 4) 모든 정보가 테스터를 대상으로하는 것은 아니므로주의 할 사항과 그렇지 않은 사항을 이해하는 것이 중요합니다.
# 5) 중요성과 아니오. 테스트 시나리오에 대한 테스트 케이스의 수는 정확할 필요가 없으며 대략적인 값으로 채워지거나 비워 둘 수 있습니다.
요약하자면 SRS 검토 결과는 다음과 같습니다.
- 테스트 시나리오 목록
- 결과 검토 – SRS 문서를 정적으로 검토 / 검증하여 문서 / 요구 사항 오류 발견
- 더 나은 이해를위한 질문 목록
- 테스트 환경이 어떻게 될지에 대한 예비 아이디어
- 테스트 범위 식별 및 최종 테스트 케이스 수에 대한 대략적인 아이디어-문서화 및 최종 실행에 필요한 시간.
참고할 중요 사항 :
#1) 테스트 시나리오는 외부 결과물 (비즈니스 분석가 또는 개발 팀과 공유되지 않음)이 아니지만 내부 QA 소비에 중요합니다. 이는 100 % 테스트 커버리지 목표를 향한 첫 번째 단계입니다. 완료되면 테스트 시나리오는 동료 검토를 거치고 완료되면 모두 통합됩니다.
QA 문서 검토 방법에 대한 자세한 내용은 다음 문서를 확인하세요. 6 개의 간단한 단계로 테스트 문서 검토를 수행하는 방법.
#두) 다음과 같은 테스트 관리 도구를 사용할 수 있습니다. HP ALM 또는 qTest 테스트 시나리오를 만듭니다. 그러나 실시간 테스트 시나리오 생성은 수동 작업입니다. 제 생각에는 수동으로 더 편리합니다. 1 단계이므로 아직 큰 총을 꺼낼 필요가 없습니다. 간단한 엑셀 시트가 가장 좋은 방법입니다.
이 시리즈의 다음 단계는 – 우리는 테스트 케이스를 만드는 작업을하고 테스트 설계 단계로 넘어갈 것입니다. 그 전에 우리는 또한 – 테스트 계획이란 무엇입니까?전체 QA 프로젝트에서 어디에 적합합니까? 언제나 그렇듯이 최상의 결과를 위해 저희와 협력하십시오.
QA 교육 3 일차 : SRS 문서를 처음부터 작성하는 방법.
계속해서 질문과 의견을 보내 주시기 바랍니다. 독자층에 감사드립니다!