Effective Test Automation Operations Guide(for entry level)

Tom(Inkwon Park)·2022년 5월 1일
2

Test Automation

목록 보기
1/1

(ENG) Effective Test Automation Operations Guide(for entry level)

As you know, Test Automation has gotten attention from a long time ago. Cause of this, a lot of information is nearby us. Recently, Test Automation trend is accelerating further. In South Korea, even though it is not a SDET position, we can find the ‘Automation’ word in QA JD easily. In the meantime, as I have experienced it in practice, I got many failures & successes. I will let you know all about the things that I have experienced.

First, Test Architecture & Framework

  • Let’s imagine building our house. There is a big difference between having a structural drawing or not having it. How about a separate project package like a MVVM, MCT, MVC and assign a test resource in a folder. Also, you should use a test library which supported from program language after selecting a test framework(Selenium, Puppeteer, Playwright, etc). It would be great for your project sketch and give a feeling of psychological stability for your team.

Second, CI/CD

  • You should push your code on CI/CD infra before we get started in earnest. We have prepared a plan which executed test automation in several pipelines. Even if it is the smallest code snippet, push it on CICD(Jenkins, Circle CI, Github/Gitlab runner). The earlier, the better. If you push your local-based code which was big on infra, you would be faced with a variety of difficulties as a package in Docker, env variable, directory, etc. It may take a lof time to engineering your task/job.

Third, the Stateless Test case

  • Isolate the Test case and develope it for easy debugging. You already have experienced the failure of the previous case and the next case being failed or blocked. If there is no reason to have a stateful case in requirement, it would be great if you made a stateless test case with each other. You can also use a Hook(before, after), Decorator Pattern or something. I’m sure our test progress in each running will certainly go up.

Fourth, Parallel testing

  • Provide a Parallel testing environment in your workspace. As you know, the E2E test needs a lot of time and resources. So that is why it is top of test pyramids. We should find out a way to save resources actively. Parallel testing is the easiest one to save a running time in fact. The unit of parallel testing could be a test case or test suite.

Fifth, Collaboration and Maintenance

  • We have to set up an environment for better maintenance. I thought these activities soon result in collaboration. I may not understand the code which wrote by me yesterday, code which wrote by my colleague is more difficult for us. How about preparing code convention in a Test Automation project like an element locator, function, class, etc. We could make ground-rule for writing a code and write code annotation meticulously. It seems easy but It would be good to tame small habits in engineering culture of the QA team.

Sixth, Documentation

  • I have thought QA Engineer has a strong ability to documents something. In fact, we have depended on documents such as Plan, Report, Test Case. Taking advantage of this strength, we could make traceability for test automation project in Google docs, Jira, Wiki, etc. It also would be better use it actively if there is an API which is supported by each platform. At the end of this part, the ‘Readme file’ is also efficient for us to write versions, release notes whenever our project was deployed. This will be helpful to develop the responsibility of the engineer who is in charge of a project.

The end.

(KOR) 효과적인 테스트 자동화 운영 가이드(for entry level)

테스트 자동화라는 개념은 꽤나 오래전 QA, 테스트 업계에 등장했습니다. 그러나 최근 점점 더 빠르고 수준 높은 비즈니스를 요구하는 시장에 부합하기 위해 이전보다 한 층 더 수면 위로 올라왔다고 생각합니다. 국내 QA 공고를 살펴보면 자동화는 우대사항이 아닌 기본 자격에 포함되어 있는 것이 이제는 당연한 얘기가 되었습니다. SDET 포지션이 아님에도 불구하고요. 또한 QAOps라는 포지션도 슬슬 국내에 모습을 드러내고 있고요. 이러한 상황에서 호기심 삼아 그동안 제가 실무에서 겪으면서 느껴왔던 경험들을 작성해 보며 도움이 되는 바람으로 공유해 봅니다.

첫째, 테스트 아키텍처/프레임워크

  • 우리가 집을 짓는 것을 상상해 보죠. 큰 틀에 대한 설계도가 있는 것과 없는 것은 집을 짓는 속도 면에 큰 차이를 보이는 것이 분명합니다. MVVM, MVC, MCT와 같은 패키지 구조를 나눠보고, 하위에 테스트 관련 리소스를 적절하게 배치해 보세요. 이러한 행위는 실제 프로젝트에 참여하는 자신과 동료에게 심리적 큰 안정감을 줄 수 있다고 생각합니다. 또한, Selenium, Puppeteer, Playwright 등 프레임워크를 결정했다면, 프로그래밍 언어별 제공되는 테스트 라이브러리도 꼭 살펴봐야합니다.

둘째, CI/CD

  • 코드를 본격적으로 작성하기 전, CI/CD 환경에 코드를 올리는 것부터 해보세요. 우리는 정기적으로 각 파이프라인 별 테스트 자동화를 구축할 계획을 가지고 있습니다. 사소한 코드 스니펫이라도 CI/CD(Jenkins, Circle CI, Github/Gitlab runner) 인프라에 먼저 올려놓고 이후에 본격적인 코드 작업을 실시하세요. 시기가 이르면 이를 수록 좋습니다. 로컬에서 덩치가 커진 이후 인프라에 코드를 올리면 우리가 예상하지 못한 다양한 난관을 마주하게 되고, 이를 엔지니어링 하는데 많은 시간이 소요될 것임이 분명합니다.

셋째, 테스트 케이스 별 상태 공유 피하기

  • 테스트 케이스를 격리시키고 디버깅이 쉽도록 구현해 보세요. E2E 테스트를 돌리면서 하나의 케이스가 실패하고, 이후 케이스는 테스트 불가능한 blocked 경험이 있을 겁니다. 특별한 요구사항이 없다면, 각 케이스를 격리시키고, 상태 공유를 피하도록 구현하는 것이 바람직합니다. 라이브러리에서 제공되는 hook(before, after), Decorator Pattern을 이용하거나 다양한 방법이 있을 겁니다. 이것은 테스트 케이스 각각 디버깅을 쉽게 해주며, 무엇보다 테스트를 효과적으로 검증할 수 있다고 생각합니다.

넷째, 병렬 테스트

  • 구축한 테스트를 병렬로 돌릴 수 있는 환경을 마련해 보세요. 아시다시피 E2E 테스트는 시간과 비용이 많이 드는 테스트 피라미드 최상단을 차지하고 있는 녀석입니다. 우리는 적극적으로 병렬 테스트를 이용하여 테스트 수행 시간을 줄일 필요가 있습니다. 병렬 테스트의 단위는 테스트 스위트 혹은 테스트 케이스가 될 수 있습니다.

다섯째, 협업 & 유지보수

  • 우리는 지속적으로 유지보수를 잘 할 수 있는 환경을 마련하려고 노력해야 하며, 이러한 활동은 협업에 귀결된다고 생각합니다. 내가 어제 짠 코드는 이해가 안될 수 있으며, 동료가 작성한 코드는 더더욱 이해하기 어려움이 있을 수 있습니다. 코드 컨벤션 element locator, function, class 단위에 네이밍 규칙을 정하고, docstring 등을 적극 활용하여 주석을 꼼꼼히 달아보세요. 이러한 행위는 쉽고, 우스워 보일 수 있지만 QA팀 엔지니어링 문화에 기반을 마련할 수 있을 것입니다.

여섯째, 문서화

  • QA 엔지니어는 누구보다 문서화에 능하고, 잘 해낼 수 있다고 생각합니다. 실제로 우리는 Plan, TC 등 문서에 의존해왔었습니다. 이러한 장점을 살려 구글 독스, 위키, 지라 등 실제 태스크로 가져가는 자동화 프로젝트에 추적성을 마련하여 작업할 수 있도록 합니다. 또한 제공되는 API가 있다면 자동으로 구축해놓으면 더욱 효과적이죠. 뿐만 아니라 매 시험 배포, 릴리즈 단위 혹은 개발 변경사항이 있다면 버저닝을 관리할 수 있는 Readme file을 만들어 관리하면 좋습니다. 이는 주위 동료들에게 작업을 공유할 수 있고, 자동화 담당 엔지니어의 책임감을 한 층 두텁게 할 수 있다고 생각합니다.

끝.

profile
Quality Explore, Dream, Discover

1개의 댓글

comment-user-thumbnail
2022년 5월 2일

좋은 글 감사합니다

답글 달기