네덜란드 헤이그에서 열렸던 EuroSTAR 2018에 다녀왔습니다

안녕하세요. LINE에서 테스트 자동화 업무를 맡고 있는 김유빈입니다. 저는 지난 2018년 11월 네덜란드 헤이그에서 열린 EuroSTAR(Europe’s No.1 Software Testing Conference)에 다녀왔습니다.  EuroSTAR는 1993년부터 매년 유럽에서 열리고 있는 유럽에서 가장 오랫동안 유지되고 있는 소프트웨어 테스트 분야의 컨퍼런스입니다. 매년 다양한 분야의 주제를 다루고 있는데요. 올해는 bitcoin과 AI(Artificial Intelligence), microservices, IoT(Internet of Things) 등의 분야를 다뤘습니다.

 

EuroSTAR는 에너지가 넘치고, 재밌고, 친근한 분위기의 행사이며, 참여자들간의 네트워킹을 강조하는 행사입니다. 4일간 행사에 참여하면서 이미 EuroSTAR에 한번 이상 참여했던 분들은 물론 20년 이상의 경력을 가진 전문가들도 쉽게 만날 수 있었는데요. 이들과 만나면서 EuroSTAR가 긴 역사 동안 소프트웨어 테스터들에게 얼마나 많은 사랑을 받았는지 느낄 수 있었습니다. 참가자들은 모두 새로운 사람들과 교류하는 것을 즐겼고, 서로 간의 네트워크를 활발히 쌓는 분위기였습니다. 그래서 비록 혼자 참가했지만 새로운 사람들과 재미있게 행사를 즐기고 올 수 있었습니다. 또한 한국에서는 소프트웨어 공학이나 소프트웨어 테스트 업무를 하는 사람을 만나는게 쉽지 않았는데요. 그곳에선 수백명의 소프트웨어 테스터를 한 자리에서 만날 수 있어서 감회가 새로웠습니다.

올해 EuroSTAR는 60개 이상의 sessions과 workshop, tutorials, talks, exhibition으로 구성되어 4일간 진행되었습니다. 또한 QuizPub와 Test Lab Party, Fun Run(5km marathon), Open Discussion:Women in Testing 등과 같은 다양한 행사가 매일 진행되었는데요. 이런 행사 구성을 보면서 EuroSTAR가 참가자간의 네트워킹을 정말 중요하게 생각한다는 것을 다시 한번 느낄 수 있었습니다.

저는 아래와 같은 keynote와 workshop, session에 참여했는데요. 그 중에서 Opening 행사와 함께 아래 진하게 표시된 두 가지 세션의 내용을 이번 글에서 공유해드리고자 합니다.

Day1Day2Day3Day4
  • Workshop
    • Driving Lessons for Test Automators
  • Workshop
    • Testing Intelligence Machines
  • Keynote
    • Exploring Testing from First Principles
  • Session
    • Understanding the Test and Risk in Bitcoin
    • Testing in the Hundred Microservices World
  • Lightning Strikes
  • Keynote
    • Testing in the Dark
  • Session
    • Strategy for Continuous Testing in iDevOps
    • Accepting Ignorance – The Driving Force of a Good Tester
    • Increasing the tester’s creativity – a scientific approach
    • DevOps : an Unknown Future for Tester? Or An Opportunity
    • What works: Lesson from 20000 Testers
  • Keynote
    • The Dragon of the Unknown
    • What is Your Overall Career Goal?
  • Session
    • As the World Turns
    • Testing for Cognitive Bias in AI
    • Dice Tower Game : Risk vs Value
  • Opening Note by the EuroSTAR chair

     

    Opening 행사는 모든 참석자가 모인 가운데 현재 EuroSTAR의 의장인 Rikard가 시작했습니다. 그는 opening 주제를 발표하기 전에, 이 행사의 주 목적은 서로 대화하고 네트워킹 하는 것임을 강조하였습니다. 그는 주변인과 대화할 시간을 5분 주면서, 참석자들에게 미리 배부된 포커카드를 대화 주제로 활용해보라고 말했습니다. 그는 불어로 ‘나는 모른다’를 의미하는 ‘je ne sais pas’를 소개했는데요. 이 키워드가 소프트웨어 테스터가 지녀야 할 중요한 마음가짐이라고 말하였습니다. ‘je ne sais pas’는 이후에 다른 session에서도 종종 언급되었습니다. 이 키워드를 통해 참석자들이 같이 일하는 동료와 서로 끊임없이 질문하며 소통해야 한다는 걸 강조하는 것 같았습니다.

    Workshop : Driving Lessons for Test Automators

     
     

    행사 첫째 날엔 하루 종일 workshop이 진행되었는데요. 저는 테스트 자동화 컨설턴트인 Seretta Gamba의 ‘Driving Lessons for Test Automators’라는 workshop에 참여했습니다. Seretta Gamba는 40년 이상의 개발과 테스트 자동화 경험을 가지고 있으며, 현재 Steria Mummert ISS GmbH의 테스트 메니저인데요. 2001년, 자신의 회사에서 테스트 자동화 업무를 맡아서, 빠른 결과를 얻을 수 있는 프레임워크를 개발하며 테스트 자동화 분야의 경력을 시작하였습니다. 발표자는 이 기술을 여러 컨퍼런스에서 공유했는데요. 이 과정에서 Dorothy Graham을 만나 ‘Test Automation Pattern Wiki’를 함께 개발하였고, Test Automation Pattern에 관한 책을 집필하여 현재까지 꾸준히 개정판을 출간하고 있습니다.

    워크샵은 크게 아래와 같은 주제로 진행되었는데요. 실습 위주의 workshop이어서 같은 테이블에 앉은 참석자들과 하루 종일 다양한 아이디어를 논의해 볼 수 있었습니다. 

    • Test Automation Issues
    • Test Automation Patterns
      • Process Patterns
      • Design Patterns
      • Execution Patterns
      • Management Patterns
    • Summary
      • Game : Snakes and Ladder

    Test Automation Issues & Test Automation Patterns

    Seretta Gamba는 자동차를 안전하게 운전하기 위해서 교통법규를 테스트하고 운전면허증을 발급받듯이, 효율적이고 지속 가능한 테스트 자동화를 구현하는 Test Automator가 되기 위해서도 Test Automation Pattern을 테스트하는 소프트웨어 자동화 자격증이 필요하다고 말했습니다. 그리고 Test Automation Pattern에 대해 자세히 살펴보기 전, 우선 Test Automation Issue를 process, design, execution, management의 4가지로 분류하여 정의하였는데요. 각 이슈를 해소하기 위해 어떤 Test Automation Pattern을 활용할 수 있는지도 아래와 같이 표로 함께 정리하였습니다.

    CategoryTest Automation IssuesTest Automation Pattern
    ProcessThe test automation process has not reached the necessary maturityHow to set up or improve the test automation process
    DesignEfficiency and maintainability problemsHow to design the test automation testware to be efficient and easy to maintain
    ExecutionUnreliable executionHow to make test execution easy and reliable
    ManagementManagement has not given the necessary supportHow to manage test automation

    Test Automation Pattern의 개념을 이해할 때는 다음과 같은 개념을 주의해야 한다고 말했습니다.

    • 패턴 각각은 숙련된 테스터들의 경험에 의해 검증된 것이므로 각 상황에 독립적인 해결책이다.
    • 강제로 규정하는 사항은 아니다.
    • unit-test 혹은 test pattern과는 구분되는 개념이다.

    다음으로 Test Automation Patterns Wiki에 대해 소개했습니다. Test Automation Patterns Wiki에서는, 테스트 자동화 과정 중 발생한 이슈에 적용된 Test Automation Pattern의 설명을 볼 수 있고, Test Automation Pattern을 적용하는 과정에서 얻은 정보와 아이디어를 공유하고 있으며, 각 패턴 별 구체적인 설명과 유저들의 질문에 대한 피드백도 제공하고 있습니다. 발표자는 위 사이트에서 소개하는 Test Automation Pattern을 하나씩 소개하고 각각의 패턴을 연습문제에 적용하는 실습을 진행했습니다. 이를 통해 각 패턴별로 어떤 특징을 가지고 있는지 비교할 수 있었는데요. 수업 중 인상 깊었던 패턴에 대해 아래와 같이 정리해 보았습니다.

    CategoryTest Automation PatternDescription
    ProcessDocument the testware자동화 스크립트, 테스트 데이터는 문서화되어야 한다. 문서화는 아래 4가지 장점을 갖는다.
    • 접근성 증대
    • 이해가능한 형태
    • 재사용성 증대
    • 요구사항 혹은 유저스토리 등의 변경사항 기록 가능
    위 장점들은 시간과 노력을 절약해준다.
    DesignComparison design비교는 sensitivity와 specific 방식이 있다. 좋은 테스트 자동화란 이 2가지의 비교기법을 적절히 혼합하여 사용하는 것이다.
    • Sensitivity 비교
      • 고수준에서 소수로
      • 넓은 범위로 Sanity Check
      • 회귀테스트와 유지보수 시 좋음
    • Specific 비교
      • 상세한 수준에서 다량으로
      • 특정 측면에 집중
      • 개발 시 좋음
    ManagementShare information관리자, 개발자, 테스터, test automater는 서로 긴밀히 공조하며 질문하고 정보를 공유해야 한다.
    • 의사소통에는 ‘7%의 규칙'(활용단어:7%, 목소리톤:38%, 바디랭귀지:55%)이 성립한다.
      • 이 규칙에 따르면 의사소통할 땐 문장에 사용된 단어보다 목소리톤과 바디랭귀지가 훨씬 중요하다.
    • 앞서 말한 4개의 역할은 기본적으로 각각 타 역할에게 요구하고, 제공해야 할 정보가 있다.
    • 즉, 서로 간에 적극적인 의사소통이 중요하다.
    Inadequate supportTest automator는 관리자, 개발자, 테스터 등으로부터 충분하게 서포트받지 못한다.
    • 관리자는 좋은 테스트 자동화를 위해 필요한 시간과 돈의 투자 측면에 대해 잘 알지 못한다.
    • 테스터는 자동화 테스트 케이스를 작성할 시간이 충분하지 않다.
    • 테스트 자동화 팀은 관리, 운영을 위한 시간을 별로 갖지 못한다.
    • 다른 사람의 도움이 필요하지만 아무도 당신을 도와줄 시간이 없다.

    발표자는 좋은 test automator가 되기 위해 갖추어야 할 자질로 두 가지를 꼽았는데요. 첫 번째는 좋은 자동화 전략 선택 능력, 두 번째는 유지가능한 testware를 정의하는 능력이었습니다.

    마지막으로 주사위 게임을 통해 하루동안 배운 개념을 퀴즈로 풀어보며 정리했고, 소프트웨어 자동화 자격증을 수여 받으면서 workshop은 마무리되었습니다.

    소감

    이렇게 하루동안 Test Automation Pattern에 대해 배웠는데요. 그동안 테스트 자동화 작업을 하면서 정리되지 않았던 개념들이 각각의 패턴으로 정리되는 것 같아 유익한 시간이었습니다. 그리고 자동화 테스트 스크립트를 개발하는 연습 문제 하나에 여러 개의 패턴을 각각 적용해보면서 패턴 간의 차이를 직접 느껴볼 수 있었던 게 굉장히 인상 깊었습니다. 연습 문제를 해결하는 과정에서 참석자들과 의견을 주고 받으며 논의하는 시간을 많이 가질 수 있었는데요. 이를 통해 패턴에 대한 각자의 생각과 경험담을 들을 수 있었습니다.

    테스트 자동화 관련 업무를 해 본 사람이라면 Test Automation Pattern을 이해하는데 큰 무리가 없을 것이며, 당연한 내용이라고 생각할 수도 있습니다. 하지만 이 개념을 미리 알고 있는 상태에서 테스트 자동화 작업을 한다면, 특정 자동화 패턴이 사용되는 목적을 명확히 알 수 있고, 적용에 따른 결과를 예측하는 데에도 도움이 될 것이라고 생각합니다. 또한 패턴 각각의 개념에 대한 정의가 확장되어 있어서 한층 심화된 지식을 얻을 수 있을 거라고 생각합니다.

    Session : Testing in the hundred Microservices World: When The Pyramid Becomes An Hourglass

     

    다음으로 공유드릴 내용은 microservice를 위해 모래시계 형태의 새로운 테스트 모델을 제시한 Isabel Vilacides의 session입니다. Isabel은 과거 Atlassian에서 근무했으며, 현재는 CloudBees에서 디렉팅 엔지니어로 활동하고 있습니다. 발표자는 과거에 경험했던 문제사항을 어떻게 해결하였고, 그 과정에서 어떤 교훈을 얻었는지 공유하기 위해 이 session을 준비했다고 말했습니다.

    테스트 관점에서 monolith 구조와 microservice 구조의 차이점

    우선, monolith와 microservice 각 구조에 대해 간단하게 알아보았습니다. Monolith는 단일 구조 형태로 전체 개발자가 하나의 프로젝트를 함께 작업하는 형태이며, 각 개발자의 작업이 서로 의존적이라고 말했습니다. 반면, microservice는 여러 개의 컴포넌트가 합쳐져 하나의 프로젝트를 구성하는 형태로, 작은 조직은 작은 책임을 갖게 되며, 각 조직은 서로 독립적으로 작업이 가능한다고 말했는데요. 이에 따라 monolith와 비교할 때 통합 작업이 더 중요해진다고 말했습니다.

    다음으로 기존의 테스트 피라미드 형태에 비추어 monolith와 microservice 구조를 살펴 보았는데요. 먼저, E2E(end-to-end) 테스트 관점에서 두 구조 간의 차이점을 비교하였습니다. Monolith는 작은 변경에도 전체 테스트가 실패할 수 있다고 지적하였고, microservice는 컴포넌트 간의 관계가 복잡해져서 E2E 테스트의 신뢰성이 낮아진다고 지적하였습니다. 이어서 unit test와 integration test 관점에서 monolith 구조는 테스트를 위해 기본적으로 mock 작업이 바탕이 되어야 하고, 실제 테스트를 수행할 때 신뢰성이 보장되며, 테스트 수행속도가 빠르고, 유지 보수가 간편한 것이 특징이라고 말했습니다. 그리고 integration test 관점에서 microservice 구조는 테스트를 위해 각 서비스 별로 mock 작업이 이루어져야 하고, monolith 구조에 비해 테스트 속도가 느리며, 신뢰성이 낮고, 유지 보수에 많은 비용이 발생하게 된다고 말했습니다.

    Microservice 구조를 위한 새로운 형태의 테스트 모델: 모래시계 모델

    Isabel은 microservice 구조에서 fast, robust, reliable한 통합테스트가 가능하도록 consumer-driven contract testing 기법을 적용한 모래시계 형태의 새로운 테스트 모델을 제시했습니다. Consumer-driven contract testing이란 여러 개의 기대결과(contracts)를 바탕으로 각각의 API를 검증하는 테스트 기법입니다. 하나의 service가 독립적으로 배치되어 정상적으로 동작하는지 검증할 수 있는 기법이며, Pact 프레임워크를 활용하여 쉽게 구현할 수 있다고 말했습니다. 이 새로운 테스팅 피라미드를 이용해 기존 테스팅 피라미드가 커버하지 못했던, 아래 영역들을 추가로 커버해야 한다고 말했습니다.

    • 배포 후 검증에 중요성 부여
    • 배포 상태 확인
    • 배포 후 모니터링
    • 앱이 평소에 어떻게 작동하는지 이해할 것

    PDV(post-deployment-verification) Monitoring 단계에서 문제가 발생했을 경우, rollback이 이루어져야 합니다. 효율적으로 rollback 할 수 있는 방법으로 아래 3가지 기법이 제시되었습니다.

    • Configuration을 통해 사용자가 보는 feature를 쉽게 enable/disable하는 ‘Feature flags’ 기법
    • Feature를 small user group에만 배포해서 모니터링하는 ‘Canary rollouts’ 기법
    • 자사의 제품에 미리 적용하여 배포 전에 미리 검증하는 ‘Dogfooding’ 기법

    Isabel은 마지막으로 microservice를 테스트할 때 고려해야 할 중요한 3가지를 아래와 같이 요약하며 발표를 마무리 했습니다.

    • 테스트와 그 결과값보다는 소비자와 공급자 간의 통합에 중점을 둔다.
    • 무엇이 잘못되었을 때 그것을 직접 파악할 수 있는 개발 체계를 갖춘다.
    • 개발 과정에서 무언가 잘못되었을 때, 그것이 가능한 한 최소한의 고객에게만 영향이 가도록 한다.

    소감

    저는 지금까지 검증 분야에서 근무하면서 소프트웨어 릴리즈 이후 고객으로부터의 버그 리포트 외에 추가적인 모니터링 및 테스트의 필요성에 대해 고민해 본 적이 없습니다. LINE Client는 여러 서비스가 집약되어 있기 때문에 PDV Monitoring 방식을 사용하면 E2E 테스트에서 검출하지 못한 결함을 조기 검출하는데 효과적일거라고 생각합니다. 또한, 새 버전의 배포는 많은 사용자들에게 직접적으로 영향을 주기 때문에 PDV(Post-deployment verification)가 중요하고, 필요한 단계라고 생각합니다. 물론 많은 서비스가 엮여있기 때문에 효율적으로 모니터링할 방안은 고민해보아야 할 것입니다. 이 세션을 통해 테스트 자동화의 범위를 좀 더 넓게 생각하는 계기를 마련할 수 있었습니다.

    마치며

    저는 4일 동안 workshop과 여러 session에 참석하면서 다양한 분야에서 테스트 자동화가 어떻게 적용되고 있고, 어떻게 발전하고 있는지를 배울 수 있었습니다. 특히 AI와 machine learning, bitcoin 분야에 소프트웨어 테스트가 어떻게 적용되었고, 어떤 새로운 개념이 추가되었는지 알아볼 수 있는 좋은 기회였습니다. 그리고 workshop과 식사시간, 다양한 이벤트에 참여하여 여러 분야의 테스트 전문가들과 대화할 수 있는 기회를 가질 수 있었는데요. 이를 통해 제 시야도 넓힐 수 있었습니다. 다만 한가지 아쉬웠던 부분은 session이 전반적으로 humanity나 철학적인 주제, 네트워킹에 치우친 것처럼 느껴졌다는 것입니다. 구체적인 기술사항에 대해 공유하기엔 session 시간이 좀 부족했던 것 같습니다.

    테스트 자동화 분야의 다양한 전문가를 만나고 싶거나, 전반적인 기술 동향에 대해 알아보고 싶으신 분이 계신다면 EuroSTAR를 추천드립니다.