버그 리포팅 할 때 써봤던 항목들 결함이 발견되면 BTS에 회사마다 정해진 양식에 따라 결함을 등록한다. 등록한 결함은 티켓, 일감, 이슈 등으로 불린다. 정보가 너무 없으면 원인 파악하는데 시간이 소요되고, 정보가 너무 많아도 개발자가 다 읽는거 같지는 않다.. 등록된 버그 리포트로 QA의 성향(?)을 파악해보기도 한다. 본인이 작성한 이슈 말고도 다른 사람이 작성한 이슈에서 배울게 있는지 본다. 버그 리포트를 잘 작성하고 잘 관리하여 QA의 자산으로 만들고 다른 툴과 연동하여 차트 같은 시각적인 데이터를 추출해내기에도 좋다. 잘 관리된 이슈는 추후 신규 인원이 들어와 히스트리 파악, 케이스 설계 아이디어 등에 도움이 된다. 이슈 양식은 회사의 정책에 따르면 된다. 아래는 업무를 하면서 양식에 써본 내용들이다. 적절하게 더하거나 빼서 양식에 사용해보자. 이슈 양식은 회사의 정책에 따르면 된다. 아래는 업무를 하면서 양식에 써본 내용들이다. 시스템정보 응용프로그램이라면 OS 환경을 구분하기도 한다. 프로그램이 무겁다면 CPU, 메모리 사양 등에 따라 다른 결과를 줄 수있다. 안드로이드의 경우 iOS와 달리 제조사, 해상도가 너무 다양하다. e.g. CentOS 7.2.1511, intel macOS Monterey, Windows 11, Samsung Galxy s23 Android 12 2340×1080 브라우저 정보 웹 표준이 어느정도 자리를 잡았으나 웹의 경우 브라우저에 따라 다르게 보일 수도 있다. 브라우저가 기능을 지원을 하지않는 경우, css 적용했는데 브라우저 설정이 우선인 경우 등 파악이 가능하도록 브라우저 정보를 적는다. e.g. chrome, safari 환경(서버) 발생하는 환경을 적는다. e.g. OP, STG, DEV 테스트계정 테스트에 사용한 계정정보를 적는다. 앱버전 응용프로그램의 경우 결함이 발생한 버전을 적는다. 사전조건 재현을 하기위한 특별히 설정해야하는 조건이 있는지를 적는다. e.g.배너 설정 0건, bannerItems: [] 재현절차를 '홈'부터가 아닌 경우 특정 페이지 진입 상태로 적기도 한다. e.g. 마이 페이지 진입 상태 발생경로 발생하는 경로를 적는다. 공통 컴포넌트를 사용했을 경우 발생경로가 여러 개일 수 있다. 재현절차 결함이 재현되는 절차를 적는다. 기대결과 재현절차에 대한 기대결과를 적는다. 많은 사람들이 '정상' 이라는 표현을 쓴다. '정상' 이라는 표현은 지양한다. 결함을 보는 사람은 '정상' 이 무엇인지 찾아야한다. 처음부터 똑바로 정확한 표현을 쓰길 바란다. 실제결과 재현절차에 대한 실제결과를 적는다. 재현빈도 항상 발생하는 것인지, 간헐적으로 발생하는것인지 적는다. e.g. 항상 발생 (10/10), 자주 발생 (5/10) 특이사항 양식에 없는 도움이 될만한 특이사항을 적는다. e.g. 디자인 링크, 기획 변경 내역, 개선에 대한 사유 등 첨부파일 재현 영상, 스크린샷, 로그 파일 등을 첨부한다.
로그인 후 모든 글을 볼 수 있습니다.