문성준의 단단해지기

안녕하세요!!

오늘은 처음 써보는 유머글입니다.

인터넷에서 재밌는 걸 봤는데

이걸 QA 엔지니어 관점에서 봤을 때

단위테스트만 진행하고 통합테스트를 진행하지 않은 결과물

관련한 짤(gif)을 보도록 하겠습니다.

옷 다 젖는 수도꼭지

잠금장치만 확실한 문

이중 보안

보는 사람만 재미있는 워터 슬라이드

좋지 못한 곳에 설치된 물비누 디스펜서

위의 짤(gif)만 봐도

왜 통합테스트가 이뤄져야 하는지 이해가 되시죠??

그냥 웃고 넘길 수 있는 짤(gif) 지만

QA엔지니어 관점에서 다시 보니 웃음과 교훈도 얻을 수 있었습니다.

그럼 이만!

출처 : https://m.cafe.daum.net/dotax/Elgq/3359298?svc=topRank

자동화 QA 관련 카테고리를 생성했습니다.

당분간 cypress에 관한 글을 자주 포스팅 할 것 같습니다.

갑자기 웬 자동화 QA??

라고 생각할 수 있지만, 이제 6년 차 QA 엔지니어로써

언제까지 Manual QA만 진행할 수 없기 때문이죠.

자신의 가치는 자신이 올리는 거라고 자동화 QA 엔지니어로써 첫 단추를 꿰매려고 합니다.

자동화 중 비교적 쉬운 cypress를 선택하였고, cypress는 E2E Test에 특화된 Frontend 테스트 도구입니다.

그럼 cypress를 설치하기 전에 E2E Test가 무엇인지부터 알고 가야 할 것 같습니다.

그리고 왜 자동화 테스트가 필요한지, 좋은 자동화 테스트를 하려면 어떻게 해야 하는지

간단하게 느껴보는 시간을 갖도록 하겠습니다.

E2E TEST가 뭘까?

E2E TEST는 (End To End Test), Endpoint 간의 테스트입니다.
쉽게 말하자면 "사용자 관점에서 테스트하는 것"
풀어 말하자면 "실제 사용하는 것과 같은 조건에서 전체 시스템 테스트" 진행입니다.
주로 사용자에게 제공하는 Web이나 App 등 GUI를 통해서 시나리오, 기능테스트를 수행합니다.
API, DB 등 외부 서비스들을 모두 사용하여 통합된 시스템을 테스트합니다.
그렇기 때문에 위에 말한 것처럼 사용자 관점에서 테스트한다고 말할 수 있습니다.

왜 자동화 테스트가 필요할까?

위와 같이 장점, 단점이 있지만 

높은 비용과 진입장벽이 높다고 생각하기 때문에 자동화 테스트를 꺼려하는 사람들이 많습니다.

그러나 적절한 자동화테스트를 조합한다면 위와 같은 문제를 해결할 수 있습니다.

테스트를 자동화를 하기 위해 코드를 설계하고 테스트를 한다.

엄청 복잡하죠?

그래서 명확한 목적을 가지고 자동화 테스트를 도입해야 합니다.

빠르고, 버그를 찾고, 안정적이게 진행해야 합니다.

실행속도가 느리면 차라리 사람이 하는 게 더 좋습니다. 그래서 항상 실행속도가 빨라야 합니다.

그리고 테스트 코드의 가독성도 좋아야 어떤 내용을 테스트하는지 알 수 있으며 수정도 용이합니다.

그리고 자주 변하는 로직과 변하지 않는 로직을 구분하는 것은

자주 변하는 로직에 대해 자동화테스트를 설계한다고 하면, 변할 때마다 수정이 필요합니다.

테스트를 하기 위해 비효율적인 비용이 들어가는 부분입니다.

그리고 버그를 찾을 수 없는 테스트는 의미가 없습니다. 단순히 "잘 돌아간다" 식의 테스트는 배척해야 합니다.

또, 신뢰성을 바탕으로 자동화 테스트가 진행되어야 합니다.

테스트할 때마다 결과가 달라진다? 특정환경에서만 안된다? 신뢰성이 낮아지게 되는 이유가 됩니다.

그러면 다 자동화 돌리면 되는 거 아닌가?

정답은 NO입니다.

테스트를 위한 자동화 코드를 설계한다고 할 때

설계 비용보다 얻을 수 있는 효과가 더 작다면 사람이 진행해야 합니다.

그리고 모든 모듈에 대해 단위 테스트를 진행해야 한다? 

물론 초기에는 가능하겠지만 운영하고 있는 서비스라면 이것 또한 비효율적입니다.

마지막으로 모든 테스트 케이스를 E2E TEST로만 진행한다?

이것도 NO입니다.

무조건적인 테스트는 없습니다.

주어진 환경, 리소스, 일정 등에 따라 알맞은 퍼즐을 끼워야 합니다. (사실 제일 애매함) 

그래서 결론은?

APP, API, WEB 모두 자동화가 필요합니다.

그리고 어떤 상황에서 자동화 테스트를 추가해야 할지도 알고 있어야 합니다.

그렇게 하기 위해서는 자동화 QA SKILL은 필수입니다.

상황에 닥쳤을 때, 자동화 QA를 알아보는 것이 아니라 

자동화 QA를 어느 상황에 도입해야 할지를 알고 있어야 합니다.

따라서 저는 일단은 cypress 무작정 따라 해보기 시리즈를 작성할 예정입니다.

신입사원이면 모르겠지만

제게는 시간이 여유롭지 않습니다.

직접 부딪혀보며 실무에서 사용할 수 있게끔 SKILL을 끌어올리는 것이 목표입니다.

그럼 다음시간에 만나요!

요즘 읽고 있는 책인데 흥미로운 구절이 있어 적어 보았다.

개발자를 위한 단위 테스트라는 책인데 아직 다 읽지는 못하고 초반에 테스트 관련 내용, 테스트 단위 개발의 필요성만 읽은 상태이다.

읽다가 버그 수정 비용의 증가라는 것을 따로 책에 구분에 놓았길래 흥미가 있어 몇자 적어본다.

<<버그 수정 비용의 증가>>

 

버그 수정 비용은 평균적으로 얼마나 될까? 런던에서 열린 ‘XP Day 2009 컨퍼런스’ 에서 마크 스트리에벡 ( Mark Striebeck) 은 구글에서 결함을 수정하기 위해 지연된 시간을 비용으로 계산해서 공개 하였다.

 

구글이 측정한 바로는 프로그래머가 버그를 만들자마자 즉시 수정한다면 $5 를 쓴 것이다. 같은 결함을 프로젝트 전체 빌드 때 발견하면 비용은 $50이 된다. 만약 통합 테스트까지 살아남으면 $500로 증가하여 시스템 테스트에 이르면 $5000까지 치솟는다.

 

이러한 수치만 보더라 하더라도 문제는 가능한 빨리 발견해야 한다는 건 이론의 여지가 없다.

 

$5 -> $50 -> $500 -> $5000

초기에 발견하지 못하면 1000배 가까이 손해가 발생된다. 만약 초기에 발견하고 완료를 했다면 $4995 는 

회사입장에서 회식비, 보너스로 들어갈 수 도 있는 적지 않은 돈이다.

시스템 테스트까지 발견되지 못한 버그는 어떤 것 들이 있을까?

* 피드백 환영 입니다 *