답변.

요구 사항 테스트는 수동 테스트의 중요한 단계입니다. 여기서의 결점은 미래에 비싼 오류로 이어질 수 있습니다.

문제의 역사:

개발 초기 단계에서 제품 요구 사항은 문서(TS, 사양)의 형태로 기록됩니다. 이들의 잘못되거나 불완전한 작성은 구현 및 테스트 단계에서 여러 가지 문제를 일으킵니다.

문제:

요구 사항은 종종 불완전하거나 모호하거나 상충되는 경우가 있습니다. 이는 오해와 저품질의 제품 구현으로 이어집니다. 테스터는 이러한 문제를 사전에 식별해야 합니다.

해결책:

요구 사항 고에는:

• 요구 사항의 완전성, 명확성 및 일관성을 면밀히 감사하는 것
• 분석가 및 비즈니스 고객에게 명확한 질문을 작성하는 것
• 모든 가정된 사용 사례(양성/음성 사례)를 기록하는 것
• 요구 사항 분석 기술을 사용하는 것: 일관성 테이블, 추적성 매트릭스, 요구 사항 체크리스트

주요 특징:

• 모순 및 '공백' 찾기 — 요구 사항에서 반영되지 않은 불일치 및 상황을 식별
• 분석가 및 팀과의 적극적인 소통 — 세부 사항 명확히 하기, 용어 설명하기
• 명확하고 테스트 가능한 요구 사항 형성 — 요구 사항은 명확하고 실행 가능하며 측정 가능해야 함

함정 질문.

'요구 사항이 테스트 가능하다'는 것은 무슨 의미인가요?

테스트 가능한 요구 사항은 제품에서 충족되었는지 여부를 정확히 알 수 있는 요구 사항입니다. 여기에는 추상, 일반적인 문구 및 불명확한 매개변수가 허용되지 않습니다.

저자만 이해할 수 있는 요구 사항을 품질이 좋은 것으로 간주할 수 있습니까?

아니요. 품질이 좋은 요구 사항은 팀의 모든 구성원(개발자, 테스터, 분석가, 비즈니스)이 명확히 이해해야 합니다.

테스터의 의무에는 요구 사항을 작성하거나 수정하는 것이 포함됩니까?

아니요, 테스터는 문제를 식별하고 책임자에게 보고해야 하지만 요구 사항을 스스로 다시 작성해서는 안 됩니다.

일반적인 실수 및 안티 패턴

• 명확한 질문 없이 요구 사항을맹신하다
• 작은 불일치 및 가정을 무시하다
• 발견된 '공백' 및 모순을 문서화하지 않고 '개발자들이 해결할 것'이라는 희망을 가지다

삶의 예

부정적 사례

테스터가 요구 사항을 받은 후 완전성과 일관성을 검토하지 않고 모호한 표현에 주의를 기울이지 않았습니다. 결국 개발자는 이러한 요구 사항을 다르게 해석하였고, 릴리스에서만 발견된 누락된 시나리오가 발생하였습니다.

장점:

• 요구 사항 작성 단계에서 시간 절약

단점:

• 후속 단계에서 많은 수정 필요
• 버그 수정에 높은 비용 발생
• 고객 불만족

긍정적 사례

요구 사항을 검토하는 단계에서 테스터가 비즈니스 분석가에게 질문을 작성하고 논란이 있는 부분을 명확히 하여 부정적 시나리오를 추가하도록 도왔습니다. 이로 인해 많은 오해를 피할 수 있었고 릴리스 시 버그 수를 크게 줄였습니다.

장점:

• 후속 단계에서 버그 및 수정 사항 감소
• 더 높은 품질과 예측 가능한 결과

단점:

• 프로젝트 시작 시 소요 시간 증가