탐정토끼님이 작성한 블로그들을 읽고 정리한 내용입니다.

테스트에서 (더 잘, 더 자주) 배우기

• 🔗 원문 아티클
• 📌 3줄 요약
  • 전에 해본 적 없는 낯선 것에 적응하고 도전할 때 학습이 일어나고, 피드백을 받아야 한다.
  • 테스트를 미룰수록 비용은 커지기 때문에, 테스트는 개발 초기에 일찍, 자주 해야 한다. (Shift Left Test)
  • 명세를 검토하거나 탐색하는 등 수동 테스트로 맹점을 찾아내고, 자동화는 핵심에 집중하자.
• 💡 시도해볼만한 것들
  • 테스트를 나중에 몰아서 하기 보다 조금씩 자주, 일찍 해보자. 수동 테스트도 좋다.
  • 팀에 전문 테스터가 없더라도, 테스트를 개선하고, 테스터의 관점을 가져보자.
  • 개발하기 전에 요구사항을 테스트 케이스로 만들고 “이런 경우는 어떻게 되지?”하는 질문을 던져보자. (탐색적 테스트)
  • 실제 상황과 비슷한 테스트를 만들자. 우리가 놓치고 있던 맹점을 탐색해보자.
  • QA에서 보고된 에러들을 살펴보고 비슷한 것을 묶어서 패턴을 찾아보자. (에러 패턴 분석하기)
  • 테스트를 귀찮게 만드는 비용을 찾아서 줄이고 더 편하게 개선해보자.
  • 모든걸 자동화하기 보다 비용 대비 효율이 큰 적정기술에 집중해보자.
  • 기존 코드를 리팩토링하거나 수정하기 전에 회귀 테스트로 안전망을 쳐주자.
• Three Amigos: 비즈니스(기획자/PO), 프로그래밍(개발자), 테스트(테스터) 의 관점이 모두 필요하다는 Agile Practice 중 하나이다.
  • 많은 회사에 테스트 전문가가 없다. 기획자나 개발자가 알아서 테스트 해야 한다.
  • 애자일 표방하는 곳에서도 개발 막바지에 케이스를 정의하거나 QA를 한다.
  • 테스터는 “이러면 어떻게 되나요? What if” 라는 질문을 던지고, 허점을 발견해주는 역할을 한다.
  • 전문 테스터가 있으면 좋겠지만, 역할보다 중요한 건 행동이다. 어느 팀에서라도 누군가는 QA와 테스트를 해야 한다.
• 요구사항 명세를 테스트 케이스로 정의하고 합의하기
  • 로그인 기획 분석 예시
• 탐색적 테스팅(수동테스트)으로 내가 모르는 것 찾기
  • 우리가 생각했던 명세와 케이스에만 의존하는 테스트는 위험하다.
  • 테스트에서 배우려면! 명세와 케이스에 질문을 던지고, 생각하지 못했던 영역을 탐색해야 한다.
  • 탐색적 테스트: 액셀에 적어놓은 케이스들을 기계적으로 눌러보거나, 짜놓은 유닛 테스트가 100% 커버리지를 달성하는지에 집중하지 않는다. 구체적인 목적과 수단을 가지고 다양한 경로와 상황을 탐색한다.
  • 이러한 테스트를 일찍, 자주 해라.
• 테스트 비용 줄이기
  • Vercel을 이용해 github에 push할 때마다 preview 배포를 하여 핸드폰으로 접속해 테스트한다.
  • 크롬 데브툴 사용하기 (와이파이 연결)
  • 회사 내부 ip 이용해 개발 중인 데브 서버에 바로 접속하기
• 우리에게 필요한 적정기술부터 시작하기
  • 우리가 이미 알고 있고 정확하게 정의한 명세를 검증하는 일은 자동화 테스트가 잘한다. 수동 테스트보다 다양하고 치밀한 케이스를 테스트할 수 있다.
  • 수동테스트는 창의적으로 우리가 모르는 걸 탐색하고 사용성 문제를 발견하는데에 효과적이다. 하지만 기존에 잘 돌아가던 게 여전히 잘 돌아가는지 확인하는 회귀 테스트에는 적합하지 않다.
• 회귀 테스트
  • 에러를 고치거나 기능을 수정하다 보면 기존에 잘 돌아가던 로직을 망가트리기도 하고 이미 고쳤던 에러가 재발하기도 한다. 이미 작성한 기능이 의도대로 잘 돌아가고 있는지 검정하는 테스트를 말한다.
  • QA에서 새로운 이슈가 나올 때마다 테스트를 추가하면서, 기존 테스트와 새로운 테스트를 모두 만족시키는 새로운 구현을 개발하는 식으로 작업하기
• 커버리지 100%가 아니라 중요하고 가치있는 곳에 집중하자.
  • 타입스크립트를 쓰고 테스트 커버리지 100%로 테스트한 코드에도 버그는 많을 수 있다.
  • 타입과 테스트는 우리가 알고 있고, 명시한 케이스만 테스트한다. 커버리지 같은 수치에 집착하다가 중요한 경게값과 암묵적인 가정들은 테스트되지 않은 채로 방치되는 경우도 많다.
  • 자동화 테스트와 수동 테스트를 적절하게! 명확한 목적과 이익을 생각하고, 비용과 저울질해라.

우리에게는 프론트 테스트가 필요할지도 모릅니다.

• 🔗 원문 아티클

테스트에 대한 사람들의 생각

• 앱의 안정성을 보증하고, 유지보수를 쉽게 해준다.
• 에러를 잡는 QA를 위한 일이고, 개발자에게는 도움이 되지 않는다.
• 귀찮고 어렵다. 만들어봤자 보수하는데 비용이 더 든다.