솔로 테스터를 위해 정기적 인 버그 배쉬/폭도 테스트 활동을 수행하는 것이 좋습니다. 스프린트/기능 개발 주기가 끝날 때 실행할 수 있는 활동입니다. 당신은 팀을 초대,함께 몇 가지 간식/음료를 얻을 시간 주위에 대한 테스트 모두를 얻을.
설정
모든 사람이 데이터/장치를 손에 넣기 전에 설정해야 장치/브라우저 범위가 양호한지 확인할 수 있습니다. 또한 사람들이 시작할 수 있도록 몇 가지 도움말 문서를 준비 할 수 있습니다. 나는 사람들이 테스트 무엇의 시각적 인 지표가 손 전에 준비 커버리지 아이디어에 마인드 맵이 좋아. 또한 손 전에 테스트 계정의 무리를 생성하고 팀에 배포 할 수 있습니다.
가벼운 버그보고
가벼운 버그보고를 장려해야합니다;버그 바로 가기 만들기
초점은 버그를 보고하는 방법에 얽매이지 않고 버그를 찾는 데 있어야 합니다. 더 많은 정보가 필요한 경우 버그 배쉬 후 항상 문제를 명확히 할 수 있습니다.
버그 배쉬에서 테스트 할 내용
테스트 할 내용을 결정하기위한 3 단계 휴리스틱(생각,가이드 또는 엄지 손가락 규칙):
- 최근에 무엇이 바뀌 었습니까? 변화는 새로운 위험을 초래합니다. 어떤 기능이 구축 되었습니까? 어떤 코드가 리팩토링 되었습니까? 어떤 라이브러리가 업데이트 되었습니까? 팀이 먼저
- 회귀 테스트를 테스트하도록 집중하십시오. 핵심 기능의 최대 다스 시나리오의 체크리스트를 가지고(어쩌면 등록 주위에,지불 및 주요 물건 사람들은 제품과 함께 할). 1),테스트할 때 사례 옆에 이름을 붙여서 적용 범위에 대한 아이디어를 얻을 수 있도록 요청할 수 있습니다.
- 때로는 펜 테스트 버그 배쉬 세션이나 성능 테스트 배쉬 또는 크로스 브라우저 테스트 배쉬를 수행하는 것이 합리적 일 수 있지만
프로덕션
에서 테스트 할 때마다 발생할 필요는 없습니다. 아주 같은 어떤 환경이 없습니다.
하지만 프로덕션에서 테스트 할 수없는 경우 테스트 환경이 안정적인지 확인,데이터가 설정되고 팀에게”버그 배쉬 테스트를 제외하고는 만지지 마십시오”요청을했습니다.
포스트 버그 배쉬
자신의 시간 동안 사람들에게 감사 버그를 계산하고 최고의 버그 사냥꾼에 명성을 제공해야합니다. 테스트/품질은 결국 팀의 책임입니다. 결과 및 수상 트로피와 함께 감사 이메일을 보내. 나는 전에 우리의 번호를 하나의 버그 사냥꾼 트로피 기지에 수지 코뿔소 버그의 트로피를 나눠했습니다:
