Robot Framework와 QA팀 동행기: 시작과 도전(1)여러분의 테스트 자동화는 어떻게 시작하고 준비하셨나요?안녕하세요, 오늘은 저희 QA팀이 겪었던 테스트 자동화의 도전과 새로운 시작에 대해 이야기해보려고 합니다.혹시 여러분은 테스트 자동화에 도전하시나요? 아니면 이미 구축까지 완료를 했나요? 저희 여기어때 QA팀도 테스트 자동화에 대해 끊임없이 도전하고 있답니다. 그 동안 저희는 “TestProject”라는 도구를 사용하여 테스트 자동화를 구축해왔고, 여기어때 기술 블로그에도 소개가 되었습니다.그런데… 사건이 발생했습니다!어느 날, 저희가 잘 사용하던 “TestProject” 도구가 서비스 종료를 한다는 소식이 들어옵니다. “뭐지? 무슨 일이야?”라는 생각이 들었지만, 저희는 당황하지 않았습니다. 왜냐하면, 언제나 예기치 않은 상황에 대비하는 것이 우리의 일이기 때문입니다.새로운 도전의 시작도구가 사라졌다고 해서 테스트 자동화가 멈출 수는 없습니다. 저희는 새로운 도구와 방법을 찾기 시작했습니다. 새로운 도구를 선택하고, 기존의 테스트 케이스를 이전하고, 새로운 환경에 맞게 최적화하는 과정은 쉽지 않았지만, 저희는 한 발 한 발 나아갔습니다. 이 글은 그 여정의 시작과 도전의 이야기를 전하기 위해 작성하게 되었습니다.자~!! 이제 같이 시작해 보겠습니다.Let’s QA go~!!!!!!테스트 자동화 도구는 너무 많다.. 우리한테 맞는 건 무엇일까?STEP 1. 처음 두 개의 테스트자동화 툴을 비교 분석했습니다.두 도구 모두 유료 도구로 codeless의 레코딩 방식으로 쉽게 테스트 자동화를 구축할 수 있는 도구들입니다. 앱 개발과 테스트 자동화 분야에서 인기 있는 도구들은 처음에 무료로 배포되다가 일정 시점 이후에 라이선스를 요구하는 모델을 채택하고 있습니다. 이러한 모델은 초기에는 사용자 기반을 빠르게 확보하는 데 효과적일 수 있지만, 장기적으로는 몇 가지 문제점을 야기할 수 있습니다.유료 테스트 자동화 도구의 문제점위 문제점을 고려하여 우리가 스스로 개발하고 우리 기술로 만들어야겠다는 생각을 하게 되었습니다.STEP 2. 다음으로는 어떤 Open Source 기술로 개발을 해야할까 결정해야 했습니다.Open source의 테스트 자동화 도구들위 그림에서 본 것처럼 Open Source 도구들이 다양한 점과 개발 언어도 다른 점이 문제가 되었고, 그래서 찾은 도구가 바로~ Robot Framework입니다.여기서 간단하게 Robot Framework에 대해서 설명 드리겠습니다.Robot FrameworkPython 기반의 도구로 웹/앱/API/DB까지 테스트 자동화를 구축할 수 있는 도구이며, 키워드 기반으로 사전 정의된 키워드를 사용해서 테스트케이스를 작성하고 테스트를 실행 할 수 있습니다.Robot Framework의 ArchitectureRobot Framework Architecture1. Test Data (테스트 데이터) : 테스트 데이터는 테스트 시나리오의 입력값과 기대 결과를 포함하며, 테스트의 정확성과 신뢰성

안녕하세요. 스포카 QA Leader 염주일입니다. 스포카 QA 팀에서 오픈소스 자동화 도구인 Appium을 사용하여 Mobile App 테스트 자동화의 첫발을 내디뎠습니다. 지금까지의 테스트 자동화 구축 과정에 관해 이야기해볼까 합니다. 테스트 자동화를 구축하려는 이유가 무엇인가요? 보통 아래와 같은 이점을 얻기 위해 테스트 자동화를 구축하려 하죠. * 테스트 커버리지 확대 * 테스트 일관성과 신뢰성 확보 * 테스트 비용 절감 및 기간 단축 테스트 자동화 구축과 컨설팅을 전문적으로 수행하는 업체들의 일관된 광고 토픽이기도 한데요. 일정 수준의 커버리지가 확보된, 일관되고 신뢰할 수 있는 테스트를 효율적으로 수행할 수 있는 이점이 있다고 볼 수 있겠습니다. 이것만 보면 테스트 자동화를 하지 않을 이유가 없군요! 하지만, 단점도 있습니다. 한번 볼까요? * 제한적인 검증 케이스 * 발견되는 버그가 많지 않음 * 테스트 자동화 구축 및 유지보수 비용 증가 뭐지? 테스트 자동화의 장점이 단점에 의해 일부 상쇄되는군요! 왜 그럴까요? 장점을 기준으로 현실적인 이야기를 해 볼게요. 먼저 테스트 커버리지 확대는 일부 맞는 말이긴 해요. 다만, 자동화만으로는 여러 가지 이유로 달성하기 힘들죠. 특히, 엣지 케이스와 일부 네거티브 테스트 케이스는 자동화로 구현하기가 상당히 어렵습니다. 비용도 많이 들고요. 테스트 자동화는 테스트 커버리지를 늘리는데 보조재 역할을 한다고 볼 수 있어요. 테스트 범위의 일정 부분이 자동으로 수행되면서, 테스트 엔지니어가 다양한 테스트를 할 수 있는 시간을 벌어주죠. 테스트 커버리지 확대의 주체가 테스트 엔지니어이긴 한데요, 결과적으로 자동화의 도움으로 커버리지가 늘어난다고 볼 수 있겠네요. 다음 테스트의 일관성과 신뢰성을 확보하는 것 역시 맞는 말입니다. 테스트 엔지니어의 컨디션에 따라 달라지는 테스팅의 품질을 걱정할 필요가 없죠. 다만, 테스트 조건의 다양성을 갖추지 않고 일반적인 소프트웨어 테스트, 즉 버그를 찾기 위한 테스트를 수행하는 관점으로 자동화를 활용하고자 한다면, 일관성과 신뢰성이 무가치하게 느껴질 정도로 테스트 자동화의 유효성을 찾지 못하게 될 수 있습니다. 여러 구축 사례에서 볼 수 있을 것 같은데요. 어렵게 테스트 자동화를 구축했지만, 이것을 통해 새로운 버그를 찾지 못하는 것에 실망하는 글들을 웹상에서 종종 볼 수 있습니다. 이런 현상은 테스트 조건을 적절하게 변경하고 유지보수하지 않아 발생하는 것으로 볼 수 있을 것 같아요. 일종의 살충제 패러독스를 겪게 되는 겁니다. 이런 이유로 고정된 조건의 테스트 자동화는 테스팅이라고 볼 수 없다고 이야기하시는 분들도 있습니다. 하지만, 이 부분은 약간 논란의 여지가 있다고 생각됩니다. 사전 정의된 테스트 단계를 실행하고, 실제 결과를 예상된 결과와 비교하는 것 자체로 범위를 규정하고 활용한다면 충분히 가치가 있다고 생각해요. 리그레션 테스트가 이 범주에 속하죠. 마지막으로 테스트 비용 절감 부분은 테스트 자동화 적용 분야에 따라 다름이 있습니다만, 대체로 구