QA 포트폴리오에 오류 화면만 붙이면 무엇을 발견했는지는 보여도, 어떻게 확인했는지는 잘 드러나지 않아요. 다른 사람이 같은 조건에서 따라 해볼 수 있는 사례 하나를 만들어보세요. 단, 공개가 허용된 작업이나 본인의 연습용 앱을 사용해야 합니다. 오류 목록 대신 한 사례의 흐름을 보여줘요 Mozilla의 버그 작성 지침은 정확한 재현 단계와 기대·실제 결과를 적고, 관찰한 사실과 추측을 구분하도록 안내합니다. 이를 포트폴리오에 활용할 때는 다음 구조를 시작점으로 삼아보세요. 폴리오쉽의 편집 제안이며 모든 채용사의 필수 양식은 아닙니다. 사례 한 장에 남길 항목 • 제목: 어떤 조건에서 무엇이 잘못되는지 한 문장. • 환경·시작 상태: 앱 빌드, 운영체제·브라우저 버전, 계정 상태, 필요한 테스트 데이터. • 재현 단계: 실제 입력값과 조작 순서를 번호로 작성. • 기대 결과: 무엇이 나와야 하며 그 기준은 어디에서 확인했는지. • 실제 결과: 직접 관찰한 화면·메시지와 재현 횟수. • 후속 확인: 추가로 비교한 조건, 수정 후 확인 결과 또는 미확인 상태. 가상 메모 앱으로 보는 작성 예시 아래는 설명을 위해 만든 사례이며 실제 테스트 결과가 아닙니다. 제목: ‘새 메모 저장 뒤 목록에 제목이 표시되지 않음’. 시작 상태: 연습용 빌드 A, 저장된 메모가 없는 상태. 실제 기록에서는 OS와 브라우저의 정확한 버전도 적습니다. 단계: ① 새 메모 열기 ② 제목에 ‘회의 메모’, 본문에 ‘다음 일정 확인’ 입력 ③ 저장 버튼 누르기 ④ 목록에서 방금 저장한 항목 확인. 기대: 연습용 명세에 따라 목록에 ‘회의 메모’ 표시. 실제: 목록 항목은 생기지만 제목 영역은 비어 있음. 미확인: 서버 저장 여부와 발생 원인. 화면만 보고 ‘데이터가 유실됐다’고 단정하지 않음. 내가 한 검증을 한 단계 더 붙여요 이 사례를 실제로 점검한다면 새로고침 후에도 같은지, 다른 제목에서는 어떤지 등 비교할 조건을 정해볼 수 있어요. 수행하지 않은 비교는 ‘추가 확인 계획’으로 남깁니다. 재현 빈도도 기억으로 채우지 말고, 같은 시작 상태에서 몇 번 시도해 몇 번 나타났는지 기록하세요. 이 횟수가 전체 사용자의 오류 발생률을 뜻하지는 않습니다. 수정 확인과 전체 품질 보증은 달라요 수정본을 받았다면 빌드와 날짜, 동일한 재현 절차의 결과를 적고 인접 기능을 추가 점검했는지 구분하세요. 아직 받지 않았다면 ‘수정 후 확인 대기’가 정확합니다. 개발자의 수정과 내가 수행한 재검증을 나누고, 한 사례가 통과했다고 서비스 전체에 오류가 없다고 쓰지는 마세요. 공개본은 따로 검토하세요 화면·로그에서 고객 정보, 계정·토큰, 내부 주소를 제거하고 공개 권한을 확인하세요. 회사 자료의 공개 허가가 없다면 독립적인 연습 사례를 만들고 ‘개인 실습’이라고 표시합니다. 미공개 보안 취약점은 포트폴리오에 노출하지 마세요. 오늘은 공개 가능한 사례 하나를 골라, 설명 없이 읽어도 시작 상태와 조작 순서를 알 수 있는지 확인해보세요. 폴리오쉽 에디터 · 공식 에디토리얼 AI의 도움으로 작성한 정보성 글이며, 개인의 실제 경험담이 아닙니다. 참고: Mozilla · Bug Writing Guidelines https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html