지난 몇달간 테스트 자동화를 시행하기 위해 많은 시도, 시행착오를 겪었다.
그리고나서 진행했던 기술세미나 겸 PoC..
이전 회사에서도 PoC를 진행하고 업무에 적용을 했지만, 이번에는 많은 설득과 협업의 과정이 필요했다.

서론 - QA 테스트 자동화 왜 해야할까?

팀내에서 QA에게 원하는 기대효과를 전달하고 이해시키는 시간과, QA에서 생각하는 자동화의 생각을 어필하고 조율하는데까지 꽤 많은 노력이 들었다.

1. (회사에서 QA에게) 원하는 기대 효과

• 비용절감, 생상성 향상, 품질향상, ....
• 개발속도를 높이면서 비용(시간/사람)을 절감하며 소프트웨어 품질을 높인다.

2. (QA 관점에서) 우려되는 점

• QA 리소스가 줄어들지 않는다.
• 수동 테스트가 더 효율적일 수 있다.
• 모든것을 자동화 할 수 없다.
• 테스트 스크립트도 검증이 필요하다.

3. 실제로 진행 과정에서 느꼈던 것

• 또 다른 업무의 추가
• 스크립트 유지보수 업무가 많아서 맞는 방향으로 가고 있는지...
• 팀 내에서도 목표를 맞추기 쉽지 않다.

4. 진행과정에서 최종적으로 합의한 미래 목표

• 리그레이션 범위 커버리지 확대
• 유지보수, 안정성 확보

---

Step1. 테스트 자동화 도구 검토

답정너이긴 하지만, 그래도 합의를 이끌어 내야 하고, 혹은 더 좋은 도구 선정이 있을 수 있기 때문에 진행했던 도구, 언어, 방법 비교 시간들.
업무 외 시간을 할애해야 했기 때문에 3개월 정도 걸렸다.

1. 비교

• 노코딩 녹화 방식
  • selenium, cypress
  • 장점 : 크롬 확장 기능으로 사용자의 동작을 녹화하여 매우 쉽게 적용할 수 있다.
  • 단점 : 정교한 테스트 불가
• API 테스트 방식
  • postman : 하필 진행했던 프로덕트에는 필수 인풋값이 많았고 중요한 내용인데 문서화가 안되어 있어서, API 하나 확인하는데 많은 시간이 걸렸다.
  • 이미 도입된 monitoring tool (datadog) : datadog에서는 UI테스트와 API 테스트를 지원하고 있다. get을 사용해 보기로 했다.
• 스크립트 작성 방식
  • selenium
    • QA에게 제일 보편화된 라이브러리
    • 많이 사용하니까 구글링하면 해결방법을 쉽게 찾을 수 있음
    • 오픈소스 무료
    • 실행 속도 느림
    • 자동화 도구 다른것에 비해 구축시간이 오래 걸림
  • cypress
    • 내장커맨드 사용으로 실행이 빠른편
    • 대시보드 등이 있어서 selenium보다는 구축할게 별로 없음
    • 타임트래블, 디버깅이 시각화 되어 있음
    • javascript, typescript만 지원
    • iframe이나 크로스브라우징 미지원
    • end-to-end 테스트에 적합해서 백엔드 테스트를 할 수는 있으나 제한적으로 보임
    • 무료도 있지만, 사용하고 싶은 기능들은 구매를 해야 함
  • puppeteer
    • chrome, chromium 기반의 모든 브라우저는 헤드리스로 테스트 가능
    • 테스트 수행 속도가 매우 빠름
    • 우리 회사 백엔드 파트에서 이미 사용하고 있기 때문에 문제가 발생되면 빠른 도움을 받을 수 있음
    • selenium에 비해 제한적인 커뮤니티
    • 같은 회사 개발자에게 도움을 받을 수는 있지만 QA에게 친화적이지 않다는 느낌을 받았음

2. 테스트 자동화 도구 선정과 기능

위 비교를 통해 우리는 python과 selenium 라이브러리를 선택했다.
보조 활용으로 API 테스트를 위해서 datadog를 사용하기로 했다.

• QA가 할 수 있는 테스트에 포커싱하자
  • 개발 : 유닛테스트
  • QA : End-To -End 테스트
• QA에게 가장 보편적이면서 무료인 도구를 사용하자
  • selenium, python
  • 파트원 변경이 일어날 것을 대비, 유지보수 할 수 있는 방안 선택
• 좀 더 빠른 효과를 기대하기 위해 API 테스트도 적용하자
  - 이미 사용하고 있는 monitoring tool인 datadog에서 api 테스트를 수행하자

---

Step2. 최저 기능 구현 후 PoC 진행

1. 테스트 코드 작성

• selenium, pytest, pytest-html 사용
• assert 구문으로 pass, fail 체크

2. 테스트 명령 실행

• dev, staging, prodction 환경 설정 옵션에 따라 스크립스 실행
• 테스트 수행 피처를 key값으로 컨트롤

3. 테스트 결과 리포트 생성

• pytest-html과 allure-pytest를 비교해보았으나, allure-pytest가 더 많은 기능을 제공하기 때문에 사용하고 싶었으나, 하면 좋은 기능이 있을 뿐이지, 필수 기능은 pytest-html으로도 충분히 가능했기 때문에 pytest-html을 사용하기로 결정했다.
  

4. 테스트 수행 결과를 slack으로 전송

• 테스트 수행 후 알림
• 링크를 클릭하면, 결과 리포트 웹페이지로 이동됨
  

---

Step3. 업무 적용

• 테스트 관점
  • 프로덕트 테스트 자동화 구현율을 높이기 위한 방안 계획 설계 중
  • 프로덕트 단위에서 프로젝트 단위 업무로 변경되었고, 프로젝트 완료 후 2주 내, 자동화 구현 완료 목표를 세웠다.
• 개발프로세스 관점
  상세한 내용은 개발팀과 논의를 마쳤으나, 외부 공개 시, 혹시라도 문제가 생길까봐 여기까지만..
  1. 코드 커밋
  2. CI/CD 단계
  3. Staging 배포
  4. Production 배포
  

---

후기

비즈니스 레벨에서는 짧은 테스트 주기를 가져가면서 제품에 오류가 없길 바라기 때문에, 수동테스트가 우선 시 되길 바라고
개발 레벨에서는 테스트만 하다보면 계속해서 인원을 충원해야 하는 부담때문에 자동화를 하길 바라고
QA 내부에서는 개인의 커리어를 위해서 자동화를 하길 바라는 분이 계신데, 개발이 어려우니 테스트만 하고싶다는 분도 있고, 어떤분은 테스트는 주니어의 역할 / 자동화는 선임자의 역할 등 우위를 나누는 분도 계시고
개발 프로세스 내 실무진 사이에서는 QA가 개발지식을 넓히는데 경계하는 동료가 있는 반면, 응원해 주시는 분도 계시고
참 많은 이해관계가 얽혀 있는 과정이었다.
상황이 이렇고 혼자서 감내하다보니 감정의 수렁에 빠져 헤어나오기 힘들때도 많았고, 스킬적으로 막혔을때 해결하기까지 많은 시간이 걸려서 육체적/정신적으로 힘든 시간들이었다.
그래도 이런 시간들이 있기에 QA로서 한걸음 더 성장했다고 생각된다.
자동화 테스트에 대해 더 깊이가 생겼고 QA로서 코멘트할 수 있는 능력을 기른것 같다. 그리고 코드를 더 잘 작성해보고 싶은 욕심과 빠르게 작성하고 싶은 의지가 생긴다. 또한, 비기능 테스트를 하려고 할때마다 개발자분들에게 많은 도움을 요청했는데 QA 스스로 할 수 있는 방법을 찾아보자는 생각도 든다.
현재 단계에서 끝이 아니라 지속적으로 고도화할 수 있길!