how test software requirements specification
나는 제품 테스터가되고 싶다
알고 계십니까 “대부분 버그 소프트웨어에서 불완전하거나 부정확 한 기능 요구 사항 때문입니까?” 잘 작성 되었더라도 소프트웨어 코드는 중요하지 않으며 요구 사항에 모호성이 있으면 아무것도 할 수 없습니다.
SRS (Software Requirements Specification)에 대한이 문서에서는 요구 사항이 명확하고 구체적이며 측정 가능하며 모순없이 완전해야한다고 설명합니다.
요구 사항의 모호함을 파악하고 초기 개발 수명주기 자체에서 수정하는 것이 좋습니다.
개발 완료 또는 제품 출시 후 버그 수정 비용이 너무 높습니다. 따라서 SDLC의 설계 사양 및 프로젝트 구현 단계 전에 요구 사항을 분석하고 이러한 잘못된 요구 사항을 파악하는 것이 중요합니다.
학습 내용 :
기능성 SRS 문서를 측정하는 방법?
음, 우리는 요구 사항을 측정하기 위해 몇 가지 표준 테스트를 정의해야합니다. 각 요구 사항이 이러한 테스트를 통과하면 기능 요구 사항을 평가하고 고정 할 수 있습니다.
가져 가자 예, 웹 기반 응용 프로그램에서 작업하고 있습니다. 요구 사항은 다음과 같습니다. '웹 응용 프로그램은 가능한 한 빨리 사용자 쿼리를 처리 할 수 있어야합니다.'
이 경우 요구 사항을 어떻게 동결 하시겠습니까?
요구 사항 만족 기준은 무엇입니까? 답을 얻으려면 이해 관계자에게 다음 질문을하십시오. 응답 시간이 얼마나 괜찮습니까? 그들이 말하는 경우 2 초 이내이면 응답을 수락합니다. 이것이 귀하의 요구 사항입니다. 이 요구 사항을 동결하고 다음 요구 사항에도 동일한 절차를 수행합니다.
설계, 구현 및 테스트 단계에서 요구 사항을 측정하고 고정하는 방법을 방금 배웠습니다.
이제 다른 예를 들어 보겠습니다. 저는 웹 기반 프로젝트를 진행하고있었습니다. 고객 (이해 관계자)은 프로젝트 개발 초기 단계에서 프로젝트 요구 사항을 지정했습니다. 관리자는 검토를 위해 팀의 모든 요구 사항을 회람했습니다. 이러한 요구 사항에 대한 논의를 시작했을 때 우리는 충격을 받았습니다!
모든 사람이 요구 사항에 대해 자신 만의 개념을 갖고있었습니다. 요구 사항 문서에 지정된 '약관'에서 많은 모호함을 발견했으며 나중에 검토 / 명확을 위해 고객에게 전송되었습니다.
의뢰인은 의미가 다른 모호한 용어를 많이 사용하여 정확한 의미를 분석하기가 어려웠습니다. 클라이언트의 다음 버전의 요구 사항 문서는 설계 단계에서 동결 될만큼 명확했습니다.
이 예를 통해 '요구 사항은 명확하고 일관성이 있어야합니다.'
요구 사항 사양을 테스트하기위한 다음 기준은 '누락 된 요구 사항 검색'입니다. 살펴 보겠습니다.
누락 된 요구 사항 발견
많은 경우 프로젝트 디자이너는 각 특정 모듈에 대한 명확한 아이디어를 얻지 못하고 단순히 디자인 단계에서 몇 가지 요구 사항을 가정합니다. 모든 요구 사항은 가정을 기반으로하지 않아야합니다. 요구 사항은 개발중인 시스템의 모든 측면을 포함하여 완전해야합니다.
사양은 두 가지 유형의 요구 사항 즉, 시스템이 수행해야하는 작업과 수행하지 않아야하는 작업을 모두 명시해야합니다.
일반적으로 저만의 방법을 사용하여 지정되지 않은 요구 사항을 파악합니다. 내가 읽을 때 소프트웨어 요구 사항 사양 문서 (SRS) , 지정된 요구 사항과 SRS 문서에서 다루어야하는 기타 요구 사항에 대한 본인의 이해를 기록합니다.
이렇게하면 지정되지 않은 요구 사항에 대한 질문을 더 명확하게 할 수 있습니다.
요구 사항의 완성도를 확인하기 위해 요구 사항을 '구현해야 함'요구 사항, 지정되지 않았지만 '가정'하는 요구 사항, 세 번째 유형은 '상상'유형의 요구 사항의 세 섹션으로 나눕니다. 소프트웨어 설계 단계 전에 모든 유형의 요구 사항이 해결되었는지 확인합니다.
요구 사항이 프로젝트 목표와 관련이 있는지 확인
때로는 이해 관계자가 개발중인 시스템에 올 것으로 예상되는 자체 전문 지식을 가지고 있습니다. 그들은 그 요구 사항이 현재 진행중인 프로젝트와 관련이 있을지조차 생각하지 않습니다. 이러한 요구 사항을 확인하십시오. 프로젝트 개발주기의 첫 번째 단계에서 모든 관련없는 요구 사항을 피하십시오.
가능하지 않은 경우이 특정 요구 사항을 구현하려는 이유와 같은 이해 관계자들에게 질문하십시오. 특정 요구 사항을 자세히 설명하므로 향후 범위를 고려하여 시스템을보다 쉽게 설계 할 수 있습니다.
그러나 요구 사항이 관련성이 있는지 여부를 결정하는 방법은 무엇입니까?
간단한 대답 : 프로젝트 목표를 설정하고 다음 질문을하십시오.이 요구 사항을 구현하지 않으면 지정된 목표를 달성하는 데 문제가 발생합니까? 그렇지 않은 경우 이는 관련없는 요구 사항입니다. 이해 관계자에게 이러한 유형의 요구 사항을 실제로 구현하고 싶은지 물어보십시오.
요컨대 요구 사항 사양 (SRS) 문서는 다음을 다루어야합니다.
- 프로젝트 기능 (수행해야 할 작업과하지 말아야 할 작업).
- 소프트웨어, 하드웨어 인터페이스 및 사용자 인터페이스.
- 시스템 정확성, 보안 및 성능 기준.
- 구현 문제 (위험) (있는 경우).
결론
요구 사항 측정의 거의 모든 측면을 다루었습니다. 요구 사항에 대해 구체적으로 설명하기 위해 요구 사항 테스트를 한 문장으로 요약하겠습니다.
'요구 사항은 불확실성이없이 명확하고 구체적이어야하며, 특정 값의 측면에서 측정 할 수 있어야하며, 각 요구 사항에 대한 일부 평가 기준을 사용하여 요구 사항을 테스트 할 수 있어야하며, 요구 사항은 모순없이 완전해야합니다.'
추가 요구 사항 관련 버그를 피하기 위해 테스트는 요구 사항 단계에서 시작해야합니다. 소통하다 프로젝트 설계 및 구현을 시작하기 전에 모든 요구 사항을 명확히하기 위해 이해 관계자와 점점 더 많이 협력합니다.
소프트웨어 요구 사항 테스트에 대한 경험이 있습니까?
아래 의견에 자유롭게 공유하십시오.
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 [QA 테스트 자동화 도구]
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 파괴 테스트 및 비파괴 테스트 자습서
- 소프트웨어 테스팅의 마인드 매핑-테스팅을 더 재미있게 만드는 방법!
- 요구 사항없이 애플리케이션을 테스트하는 방법은 무엇입니까?
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업