티스토리 뷰
테스트 자동화
유저 테스트 만으로는 모든 테스트의 광범위한 부분을 체크해 볼 수가 없습니다.
미리 여러 케이스들을 설정하여, 광범위하게 효율적으로 체크하여 더 많은 버그를 찾을 수 있습니다.
(흔히들 말하는 애자일을 도입하는 것이다..)
테스트 자동화 프로세스가 만들어지면, 유저 테스트와 자동화를 병행하여 테스트의 효율을 높일 수 있게 됩니다.
이러한 장점들이 있지만, 무조건 장점만이 있다고는 볼 수 없다....
당연히 위의 프로세스가 잘 이루어져 모두가 만족한다면 좋지만, 현실은 그렇지 않은 경우가 있다..
프로그래밍 기반의 테스트 자동화가 도입된다면, 프로그래밍이라는 진입장벽이 생기는 단점이 있다. (해야지...ㅠㅠ)
테스트 자동화를 위한 테스트 케이스를 준비해야 한다. (테스트 샘플을 AI가 뿅뿅뿅 해서 만들어주지 않으니..)
경험
테스트 자동화를 도입하여 1년 좀 넘게 사용했는데 테스트 케이스가 많아질수록 정말 괜찮다는 생각이 들 때가 많다.
테스트 케이스는 Graphical test 와 Command test 로 크게 분리하여 테스트를 작성하였고,
이슈를 처리하고 나서 자동화를 돌리면, 생각지도 못한 부분에서 side-effect가 일어나는 것을 확인하여
코드를 리팩토링하는데 도움이 정말 많이 됐다.
기존의 개발자들이 코드 리뷰를 진행하고, QA가 없어서 테스트를 같이 진행해주는데 테스트 자동화를 도입하고 나서
기존의 개발 - 코드리뷰 - 유저 테스트 프로세스에서 자동화 테스트 작성이라는 리소스가 추가되어
개발 - 코드리뷰 - 유저 테스트 - 테스트 자동화 케이스 작성으로 변경되었다. (리소스가 추가된 만큼.. 일은 늘어났다...)
이제는 테스트 자동화가 없으면 오히려 어색하고 불안해진다. 그만큼의 효력을 보았기 때문에.. 모두 파이팅..
- Total
- Today
- Yesterday
- vscode
- 스벨트
- vue router
- nextjs13
- 네이버 서치 어드바이저
- Embedding
- seo
- cors
- 서버 to 서버
- Vite
- React
- nodejs
- Git
- vue composition api
- 타입스크립트
- nextjs14
- docker
- NUXT
- 깃허브
- 오블완
- openAI
- Github Actions
- dockerfile
- nuxt2
- svelte
- NextJS
- 티스토리챌린지
- webpack
- AWS
- Storybook
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |