Slavn Blog

광고 시스템이 탄생하기 전에도 성공적인 베타 테스트가 시작됩니다! 그 아이디어가 이상하게 들립니까? 베타 테스트가 신중하게 설계된 시스템의 체계적인 증명을 포함한다고 생각할 때는 그렇게 이상하지 않습니다. 전자 장치, 웹 사이트 또는 자동 도구와 같은 마지막 순간에 신청할 수있는 히트 또는 미스, 크로스-핑거 및 애호가의 도둑 반창고가 아닙니다.우리는 모두 데스크톱에 거의 숨을 쉬지 않는 잘 알려진 존경받는 소프트웨어 회사의 소프트웨어 프로그램의 예를 보았습니다. 그들은 벌레로 가득 차있는 것처럼 보이며, 따라서 우리가 일을 수행하는 데 도움이되는 것보다 더 많은 슬픔을 유발합니다. 또는 우리는 멋지게 보이는 웹 사이트를 사용하려고 노력하지만 쇼핑 카트에서 주문 페이지로 얻을 수는 없습니다. 또는 우리는 새로운 위젯을 구입하지만 지침 책자를 사용하더라도 기본 메뉴에서 우리가 예상하는 방식으로 중요한 기능으로 점프 할 수 없습니다 아이큐테스트

당신은 당신의 비즈니스를 이런 식으로 좌절시키는 회사의 순위에 비즈니스를 촉구하고 싶습니까? 물론 그렇지 않습니다! 그러므로 나는 당신이 다르게 일을 할 것이라고 확신합니다.

그렇기 때문에 테스트에는 체계적이고 지루하지만 필수 불가결 한 활동이 포함됩니다. 광기에 대한 방법이 없다면, 당신은 시스템을 무작위로 두드리는 것 이상의 일을하지 않기 위해 우연히 그것을 깨는 방법을 찾을 수 있는지 확인합니다. 그렇다면 노력을 올바르게 추정하고 과정을 수행하며 테스터를 행복하게 유지하기 위해 무엇을 알아야합니까? 테스트 성공을 달성하기위한 10 가지 전략은 다음과 같습니다.

1. 설계 테스트 시나리오.

“테스트 시나리오”란 무엇입니까? 각 테스트 시나리오는 시스템을 설계하고 개발하도록 팀을 안내하는 “사용 시나리오”의 미러 이미지 여야합니다. 사용 시나리오는 고객이 시스템과 가지고있는 하나의 일반적인 상호 작용을 설명합니다. 예를 들어, 자동화 된 텔러 머신의 경우 하나의 시나리오에는 고객이 현금을 인출하기 위해 카드를 삽입하는 것과 관련이 있습니다. 다른 시나리오에서는 고객이 입금합니다. 다른 한편으로, 그 또는 그녀는 잔액을 확인합니다.

시나리오는 사용자가 비정상적이고 의도하지 않은 작업을 포함하여 시스템과 상호 작용할 수있는 타당한 방법을 나타내야합니다. 따라서 시나리오와 테스트 시나리오를 사용하면 잼 카드, 취소 된 거래 또는 과잉 계정과 같은 가능한 오류 조건을 설명해야합니다.

2. 테스트 절차를 작성하십시오.

테스트 절차는 테스터가 따라야 할 순서를 포함하여 테스트 시나리오를 어떻게 행사할 것인지 지정합니다. ATM의 예에서 “이 순서로 현금 교파를 철회하는 시험 : $ 20, $ 30, $ 50, $ 100. 반대 순서로 다른 테스트를 실행하십시오 : $ 100, $ 50, $ 30, $ 20. 그런 다음 임의 순서로 여러 테스트를 실행하십시오.” 또한 각 경우에 무엇을 기대 해야하는지 설명해야합니다.

절차가 모든 새로운 시스템 기능 또는 변경 사항을 테스트하기를 원합니다. 또한 다양한 조합으로 기능을 테스트하는 절차를 원할 것입니다. 예를 들어, 당신은 1) 현금 인출, 2) 잔액 정보 확인, 3) 예금을 지정할 수 있습니다. 순서를 변경하고 오류 조건을 테스트하십시오.

3. 필요한 데이터를 결정하십시오.

시스템이 데이터베이스에 값을 저장하는 경우 시나리오를 테스트하기 위해 일부 일반적인 데이터를로드해야합니다. ATM 예에서 값에는 인출 한도를 테스트하고 균형 정보를 제공하기위한 계정 잔액이 포함됩니다. 샘플 데이터 세트를 작성하고 테스트 할 시스템을 사전로드하십시오. 매우 높고 낮은 값을 포함하는 것을 잊지 마십시오!

4. 테스터를위한 특정 역할을 계획하십시오.

특정 테스트 시나리오 및 관련 데이터 세트에 집중하도록 각 테스터를 예약하십시오. 충분한 테스터가있는 경우 각 테스트 시나리오를 다루기 위해 둘 이상을 할당하십시오. 각 사람은 다르게 접근합니다.

5. 버그보고 시스템을 만듭니다.

양식, 데이터베이스, 이메일 메시지 또는 조합으로 설계 될 수 있습니다. 테스터가 각 테스트 라운드에서 오류를 찾을 때 버그 보고서를 제출하도록합니다.

6. 테스트 일정을 설정하십시오.

일정은 베타 테스트의 여러 반복을 허용해야합니다. 그들이 참여할 각 라운드에 대한 테스터의 일정을 지우십시오.

7. 모든 재료를 테스트 할 준비를하십시오.

다음 항목은 킥오프 회의를 준비해야합니다. 새 또는 업데이트 된 시스템, 고정 된 버그, 새 또는 업데이트 된 문서, 테스트 시나리오 및 절차 등에 대한 버그에 대한 목록 또는 설명.

8. 시작 날짜를 설정하십시오.

시작일에 킥오프 회의를 개최하십시오! 진행 점검도 예약하십시오. 테스터가 주어진 체크 포인트에 도달하기 전에 수많은 버그를 찾거나, 특히 중요한 버그를 발견하고, 테스트를 중지하고, 버그 및/또는 문서를 수정하고, 1 단계로 돌아갑니다. 다시 시작하기 전에 요청하십시오 : 새로운 테스트 시나리오 또는 데이터 세트가 필요합니까?

9. 각각의 새로운 테스트 기준에 대한 새로운 테스트 라운드를 수행하십시오.

이는 각 수정 라운드 후에 처음부터 처음부터 처음부터 테스트를 시작하는 것을 의미합니다. 무언가가 고정 될 때마다 다른 것을 “파괴”할 수 있기 때문에이 요구 사항을 회피 할 수 없습니다. 새로운 버그가 없을 때만 테스트주기를 중지하십시오.

10. 잘한 일에 대한 보상을 계획하십시오.

테스트는 매우 지루합니다. 테스터는 목표에 집중할 수 있도록 특별한 인센티브가 필요합니다. 고품질 시스템을 생산하는 데 도움이되지만 사후 테스트 당사자는 사기를 해치지 않습니다! 철저한 베타 테스트는 품질 시스템을 생산하는 데 필수적입니다. 정시에 수정할 수없는 오류를 발견하면 알려진 결함이있는 시스템을 해제하기로 결정할 수 있습니다 ( “read-me”노트에 문서화). 스테이크가 높을 수 있으므로 진행하기 전에이 옵션을 조심스럽게 평가하십시오.