📌 자동화를 하게 된 이유QA를 위해 다양한 준비를 한다. 기획/디자인 파악 -> 테스트 케이스 작성 -> 테스트 환경 세팅. 그리고 QA 기간이 돌아오면 본격적으로 테스트를 진행하게 된다. 스프린트 범위에 따라 적게는 200개, 많게는 1000개의 테스트 케이스가 나오는데, 1인 QA다 보니 이걸 혼자 다 돌린다. 빠르게 개발되어야 하는 스타트업 환경에서 FAIL은 생각보다 자주 나오고, 1000개의 TC 중 중복을 걷어내도 최소 100개의 버그 티켓이 나오는 경우가 있다. 이걸 하나하나 Jira에 손으로 만드는 시간은 결코 무시하기 어렵다. 그런데 따지고 보면 티켓에 적는 내용 대부분은 TC에 이미 있다. 발생 과정, 기대 결과, 테스트 대상까지 이미 다 적혀있는 내용을 다시 복사해서 붙여넣는 행위..

CLAUDE.md, Skill, Command, Agent — 이 네 가지만 알면 Claude가 달라진다 💡 Claude는 왜 매번 까먹을까?Claude를 처음 업무에 쓰려고 하면 이런 경험을 하게 된다. 오늘 대화에서 "한국어로 답변해줘, 버그 리포트는 이 형식으로 써줘"라고 했는데, 내일 새 세션을 열면 언제 그랬냐는 듯 아무것도 모른다.이건 버그가 아니다. Claude는 세션이 끝나면 모든 걸 잊는 구조다. 매 대화가 완전히 빈 상태에서 시작된다.그래서 같은 설명을 매번 반복하게 된다. "이 프로젝트는 이런 거야, 내 역할은 이래, 이 형식으로 써줘..." 하루에도 몇 번씩. 이 문제를 해결하기 위해 존재하는 개념이 네 가지 있다. 💡 CLAUDE.md — 신입사원 온보딩 문서한 줄 정의Clau..

💡 촉박한 일정일수록, 우선순위가 전부다일정이 촉박해질수록 모든 티켓을 처리하는 건 불가능해진다. 이번 스프린트에서 가장 크게 체감한 지점이었다. 티켓 하나하나를 들여다보면 대부분 기획과 완전히 일치하지 않았고, 사용자 입장에서도 충분히 문제가 될 수 있는 상태였다. 이론적으로는 전부 수정되어야 맞다. 하지만 일정이 계속 밀리고 시간이 줄어들면서, 결국 "모든 걸 다 잡고 갈 수 없는 순간"이 왔다. 이번에는 영향도, 리스크, 그리고 비즈니스 관점을 기준으로 판단했다. 사용자가 실제로 인지하는 문제인가? 지금 이 기능이 비즈니스적으로 핵심인가? 이 두 가지를 기준으로 크리티컬한 이슈부터 처리하고, UI나 문구처럼 사용자가 크게 인지하지 못하는 부분은 일단 후순위로 밀었다. 결과적으로 시연 현장에서는 큰..

🧩 자동화는 코드가 아니라 구조라는 걸 느꼈던 경험스타트업에서는 짧은 스프린트 단위로 기능이 빠르게 변경되다 보니, 정말 다양한 경험과 버그를 계속해서 마주하게 되는 것 같다. 바쁜 일정 속에서도 가끔 일주일 정도 여유가 생기는 시기가 있는데, 그럴 때마다 기존에 어느 정도 구현되어 있던 자동화 코드를 개선해보려고 시도했다. 기존 자동화 코드에는 일부 UI 요소에 data-testid가 적용되어 있었다. 전임자께서 자동화 안정성을 고려해 추가해두신 것이었지만, 해당 정보가 별도의 문서로 정리되어 있지 않고 매 스프린트마다 작성되는 기획 문서에만 일부씩 흩어져 있었다. 그 결과 data-testid 관련 정보는 여러 문서에 분산되어 있었고, 어떤 화면에 어떤 식별자가 존재하는지 한 번에 파악하기 어려웠다..

📌 탐험적 테스팅을 읽고 나서야 보이기 시작한 것들최근 저자 Elizabeth Hendrickson의 Explore It! 책을 읽다가 인상 깊은 메시지를 만났다. 애플리케이션을 사용할 때 한 가지 방식에만 고정되지 말고, 순서와 방법을 의도적으로 바꿔가며 탐험하라는 내용이었다. 처음 읽었을 때는 "당연한 이야기 아닌가?"라는 생각이 들었다. 하지만 책을 덮고 나서 최근 내가 진행했던 QA 경험들을 떠올려 보니, 나는 생각보다 훨씬 제한된 방식으로만 테스트하고 있었다는 걸 깨달았다. 📌 Hover는 모든 환경에 존재하지 않는다가장 먼저 체감한 것은 hover 인터랙션이었다. 데스크탑에서는 hover가 너무 자연스럽다. 툴팁이 나타나고, 버튼이 활성화되고, 메뉴가 펼쳐지는 동작들이 모두 hover를 ..