how test an application without requirements
기술적으로 요구 사항이없는 응용 프로그램은 없습니다. 특정 작업을 수행하지 않는 소프트웨어를 상상해보십시오. 어디로도 이어지는 계단이 될 것입니다.
모든 소프트웨어에는 요구 사항이 있으며 특정 작업을 대상으로합니다. 특히 문제에 대한 해결책입니다. 그래서 필요없는 소프트웨어는 가능성이 없습니다.
그러나 문서화 된 요구 사항이없는 소프트웨어는 불행히도 대부분의 사람들이 우리는 좋아한다. 더 나쁜 것은 문서가 불충분하거나 부정확하거나 매우 오래되었다는 것입니다. 슬프게도 이것도 발생합니다.
C ++로 무엇을 할 수 있습니까?
솔직히, 잘 문서화 된 기능 / 시스템 요구 사항 문서를 정교한 사용 사례와 모의 화면으로 대체 할 수는 없습니다. 빠른 개발주기와 최소한의 문서화로의 패러다임 전환으로 인해 이것이 업계에서 드물다는 사실을 인정해야합니다.
따라서이 기사는 우리가 이러한 상황에 처했을 때 따랐던 일부 관행에 대한 시도입니다.
또한 읽으십시오 :
먼저 몇 가지를 살펴 보겠습니다. 문서가없는 이유는 다음과 같습니다.
- 보류 된 프로젝트가 다시 열림
- 작업 프로세스 형식이 적은 문서화
- 문서가있을 수 있지만 상세하거나 완전하지 않을 수 있습니다.
- 연속 릴리스 및 이전 버전 관련 정보가 보관되지 않아 기존 기능이 새 기능과 어떻게 반응하는지 이해하는 데 차이가 있습니다.
이것들은 우리 테스터들이 용감하게 교차하고 성공적으로 등장해야하는 모든 장애물입니다. 그래도 정확히 맞죠?
다음은 요구 사항없이 애플리케이션을 테스트하는 3 가지 방법입니다.
방법 # 1 :
손에 넣을 수있는 작은 문서로 작업하십시오. 기본 단순 백 로그 (애자일 프로젝트), 도움말 파일, 이메일, 이전 버전의 BRD / FRD 또는 이전 테스트 케이스 (ALM 도구에서 확인하면 찾을 수 있음) 등이 될 수 있습니다.
조사하고, 주위에 물어 보면, 비록 그것이 얇더라도 문서화 된 재판이 항상 있습니다.
이것이 해결되지 않으면 소프트웨어 사용자로서의 경험을 할인하지 마십시오.예를 들면, 은행 계좌에 대한 이체 작업을 테스트해야한다면 누구도이 방법을 알려주지 않아도됩니다. 온라인 뱅킹 고객으로서 우리 모두는 이체 할 수있는 많은 자금이있는 계좌를 오가야한다는 것을 알고 있기 때문입니다.
모든 상황이 그다지 간단하지는 않지만, 그럴 수도 있다는 데 동의했습니다.
방법 # 2 :
소프트웨어 제품의 향후 릴리스를 테스트하기위한 참조로 이전 / 현재 버전의 애플리케이션을 사용하십시오. 이제 저는 이것이“응용 프로그램을 참조로 사용하여 테스트 케이스를 작성하지 마십시오”라는 규칙에 위배된다는 것을 인정합니다. 그러나 우리가 완벽하지 않은 상황에서 일할 때는 우리의 필요에 맞는 규칙을 만들어야합니다.
그렇게 할 때 다음 측면을 관점에서 유지하는 데 도움이됩니다.
- 응용 프로그램에 버그가있을 수 있으므로 등록 후 시스템이 직접 Screen1 (예제를위한 특정 가상 화면)으로 이동하는 경우 – 이것이 올바른 동작이라고 가정하지 마십시오. 또한 필드가 영숫자 문자를 사용하고 전화 번호 인 경우-응용 프로그램을 예상 기능에 대한 승인 된 예로 받아들이지 않는지 확인하는 질문입니다.
- 위의 상황에서는 판단력을 사용하고 응용 프로그램의 도움을 받아 빠르게 시작할 수 있지만 제대로 작동하는지 질문하려면 비판적이어야합니다.
방법 # 3 :
프로젝트 팀 구성원과 대화하십시오.
- 회의에 참석하겠다고 제안하십시오.
- 단위 및 통합 테스트 단계에 참여할 수 있는지 물어보십시오.
- 그렇지 않은 경우 개발 팀이 단위 및 통합 테스트 결과를 공유 할 수 있는지 물어보십시오.
- 편리한 시간에 지식 전달을위한 시간을 마련하십시오.
이제 예제에서 메서드를 적용 해 보겠습니다.
장바구니에 항목을 추가 할 수있는 쇼핑 사이트가 있다고 가정 해 보겠습니다. 이상적으로는 문서가있는 경우 항목을 추가하는 방법, 주어진 시점에 몇 개의 항목을 가질 수 있는지, 추가 한 항목이 갑자기 재고가 없어지면 어떤 일이 발생하는지, 최대 개수는 얼마인지 알려 주어야합니다. 같은 품목을 동시에 구매할 수 있습니다. 우리의 상황은 현재 해당 품목이 없습니다.
방법 # 1 적용 :
가능한 문서를 찾으십시오. 개발자 팀에게 모형 화면이 있는지 / ALM 도구를 살펴 보거나 어떤 것이 있는지 물어보십시오. 무언가를 찾으면 좋은 출발점이 될 것입니다. 그러나이 방법이 아무것도 나타나지 않으면 테스터의 판단 / 직관.
우리는 모두 쇼핑 카트가 작동하는 방식을 알고 있으므로 가정하고 다음과 같은 몇 가지 기본 시나리오에 도달합니다.
- 상품을 열람 또는 검색 후 장바구니에 담을 수 있습니다.
- 장바구니에 상품을 추가하면 상품 목록이 새로 고침됩니다.
- 사용자는 장바구니에 항목을 몇 개 추가 한 후에도 계속 쇼핑 할 수 있어야합니다.
- 동일한 항목을 두 번 추가하면 추가 된 항목의 수가 증가합니다.
- 항목을 업데이트 할 수 있습니다.
- 항목을 제거 할 수 있습니다.
- 합계는 추가 된 모든 가격의 합계와 동일해야합니다.
- 입력 한 우편 번호를 기준으로 세금을 계산해야합니다.
- 그에 따라 배송비가 추가되어야합니다.
우리는 계속할 수 있지만 당신이 그림을 얻을 것이라고 확신합니다.
방법 # 2 적용 :
사용 가능한 이전 버전의 애플리케이션이있는 경우 클릭 할 위치, 입력 할 위치, 확인할 항목 등의 정확한 단계를 작성해야하므로 테스트 케이스를 작성하는 데 도움이 될 수 있습니다. 스크린 샷 / mockups / wire- 프레임 – 가능하다면 훌륭한 대체물이 될 수도 있습니다.
아래 화면에서 볼 수 있듯이 필드 이름, 버튼 또는 기타 요소 등이 분명합니다. (확대보기를 위해 이미지를 클릭하십시오)
이제이 시점에서 테스터는 다음과 같은 몇 가지 질문을합니다.
헬프 데스크 인터뷰 질문 및 답변 기술
- 금액 상자에 숯불을 넣으면 어떻게 되나요?
- 언제 너무 많은 항목을 추가합니까?
- 최대 번호는 얼마입니까? 걸릴 수있는 항목의? 기타.
방법 # 3 적용 :
질문 목록을 BA, 개발자 또는 고객에게 가져가 설명을 구하십시오. 방법 3이 완료되면 상세한 테스트 케이스를 작성하고 정교한 문서를 사용할 수있을 때와 마찬가지로 자신있게 테스트를 수행하는 데 필요한 모든 정보를 거의 갖추고 있어야합니다.
훨씬 더 많은 단계와 더 많은 후속 조치라는 데 동의했지만 품질 테스트를 보장하기 위해 이러한 단계는 불가피합니다.
결론적으로, 문서가 없거나 불충분 할 때 모든 것이 손실되지 않습니다. 아직 희망이 있습니다! 비슷한 상황에서의 경험을 공유 해주세요.
저자 정보 : 이 유용한 게시물은 STH 팀원 Swati S가 작성했습니다.
언제나 그렇듯이 귀하의 의견, 질문 및 제안을 환영합니다.