자동 테스트 성능 향상을 위한 세 가지 패턴

몇 년 전 우리는 개발 과정에서 자동 테스트를 보다 적극적으로 사용하기 시작했지만 몇 가지 어려움에 직면했습니다.

논리적 질문: 자동화 테스트를 시작한 이유는 무엇입니까? 그 해답은 모바일 애플리케이션의 새로운 버전의 주간 릴리스에 있습니다. QA 부서는 새로운 기능을 테스트하고 서비스에 통합하고 회귀 테스트를 수행해야 합니다. 복잡한 회귀 테스트는 일주일에 한 번 이상 수행해야 하므로 상당히 지루합니다. 자동화 덕분에 품질 저하 없이 새 버전을 더 빠르게 출시할 수 있었습니다. 모바일 테스트 자동화에 대한 자세한 내용은 동료 보고서에서 확인할 수 있습니다 .

개발 과정에서 문제는 패턴을 사용하여 해결되는 경우가 많습니다. 즉, 주어진 컨텍스트에서 일반적인 문제에 대한 일반화된 솔루션입니다. 테스트 자동화와 동일하며 좋은 위키 설명도 있습니다. 이 기사에서는 프로세스 패턴에 대해 이야기할 것입니다. 테스트 자동화 프로세스를 구성하고 개선하는 데 도움이 됩니다.

더 이상의 서문 없이 우리가 고군분투하고 있는 어려움과 바로 그 패턴을 사용하여 이를 극복하기 위한 권장 사항으로 넘어 갑시다. 이것이 우리가 겪었고 여전히 가지고 있는 유일한 문제가 아니라는 점에 유의하십시오. 그러나 이 기사의 틀 내에서 나는 그것들에 집중하기로 결정했습니다.

패턴 # 1. 도움을 요청

흔히 그렇듯이 우리 모두는 서로 다른 경험, 지식 및 기술을 가지고 있었습니다. 그 당시 팀의 모든 사람이 테스트 자동화에 직면한 것은 아니었습니다. 일부는 이동 중에 배워야 했습니다. QA 팀의 동료가 복잡성에 대처할 수 있도록 자동화 팀의 도움을 요청했습니다. 다른 사람들이 이미 유사한 문제에 직면하여 해결책을 찾았을 수 있기 때문에 문제에 갇힌 경우 너무 오랫동안 혼자 처리할 필요가 없다는 아이디어입니다. 그리고 자동화자들이 질문으로 넘쳐나지 않도록 우리는 이 접근 방식을 공식화하기로 결정했습니다. ASK FOR HELP 패턴은 훌륭한 솔루션으로 판명되었습니다 .

" 도움을 요청하고 모든 것을 스스로 하려고 시간을 낭비하지 마십시오 ."

어떤 팀도 주어진 시간에 필요한 모든 기술을 가질 수 없으며 필요할 때 몇 명의 전문가가 필요할 때 의지할 수 있습니다.

그러나 단순히 패턴을 따르는 것만으로도 새로운 문제가 발생할 수 있음이 밝혀졌습니다. 테스트 자동화 팀은 평소보다 훨씬 더 자주 질문을 받기 시작했습니다(예: 환경 설정에 대한 질문). 시간이 지남에 따라 우리는 다른 팀원들이 같은 질문을 한다는 것을 알아차리기 시작했습니다. 간단하고 잘 구성된 질문에도 컨텍스트 전환이 필요하기 때문에 자동화 장치가 모든 사람에게 대답하는 데 많은 시간이 걸렸습니다.

내부 StackOverflow

Wiki에는 가장 일반적인 문제에 대한 솔루션에 대한 설명서와 설명이 포함되어 있습니다. 위키에 가능한 모든 오류와 설명을 문서화하는 것이 최선의 접근 방식은 아닐 수도 있지만, 우리는 그것들을 한 곳에 보관하는 것이 유용할 것이라고 생각했습니다. 이것이 우리가 로컬 스택 오버플로를 만드는 아이디어를 얻은 방법입니다. 이를 위해 오픈 소스 Scoold 솔루션을 사용했습니다 . 요청 처리의 첫 번째 줄에 사용하기 위한 것으로 회사 직원에게만 일반 스택 오버플로처럼 작동합니다. 누군가 문제가 있을 때마다 로컬 스택 오버플로를 방문하여 솔루션을 찾거나 전문가 중 한 명이 답변할 질문을 작성하기만 하면 됩니다.

이것이 우리의 로컬 StackOverflow의 모습입니다.

장점

프로세스가 게임화되어 더 많은 사람들이 솔루션을 찾는 데 참여합니다. 우리는 다른 줄무늬나 제목을 생각해내지 않았습니다. 표나 별의 수는 아무 의미가 없습니다. 그리고 우리는 당신에게 이것에 도취하라고 조언하지 않습니다. 게이미피케이션은 주요 요인이 아니라 참가자에게 추가적인 인센티브일 뿐입니다.
우리는 문제를 해결하는 데 시간과 에너지를 덜 소비합니다. 첫째, 눈에 잘 띄기 때문에 해결하기가 더 쉽습니다. 둘째, 한 사람에서 다른 사람으로 넘어가는 작업의 수가 감소합니다.
채팅에는 추적 및 검색이 어려운 메시지와 스레드가 더 적습니다. 메신저는 문서를 저장하고 그것을 진실의 근원으로 언급하기에 가장 좋은 장소가 아닙니다. 스택 오버플로가 훨씬 더 편리합니다.

단점

구현을 시작할 책임이 있는 사람은 없습니다. 가장 간단한 솔루션의 생성을 자극할 사람이 필요합니다. 우리는 운이 좋았습니다. 우리의 경우 dr0pt4ble 이 그러한 사람이 되었고 주도권을 자신의 손에 맡겼 습니다. 경영진이 그러한 계획을 이해하고 지원하는 것도 마찬가지로 중요합니다.
솔루션의 낮은 인기도: 플랫폼이 우리가 예상한 것만큼 즉시 인기를 얻지는 못했습니다. 모든 새로운 도구는 사용자의 사랑을 위해 싸워야 하며 모든 사람이 변화를 좋아하지 않기 때문에 이해할 수 있습니다. 첫날부터 사이트에서 과도하게 활동하지 않았을 수도 있지만 점차 거의 모든 관련 질문을 사이트로 리디렉션하고 테스트 자동화 팀 외부의 사람들을 문제 해결에 참여시킬 수 있었습니다.
질문에 대한 답변이 충분히 빠르지 않을 수 있습니다. 이 경우 메신저에서 새로운 질문에 대한 알림을 구현하는 것이 좋습니다. 그러나 오늘날 많은 사람들이 재택근무를 하고 인스턴트 메신저에는 알림이 넘쳐나면서 소리를 끄고 싶은 유혹이 고조되고 있습니다. 각 팀은 이 문제를 다르게 처리하지만 우리에게는 Slack의 Automator 채팅에서 알림을 보내는 것이 좋습니다.

패턴 # 2. 표준 설정

가능하면 모든 애플리케이션과 플랫폼에서 코드를 재사용하여 유지 관리 및 지원을 단순화하려고 합니다. 그러나 수년에 걸쳐 많은 사람들이 개발한 다른 시스템과 마찬가지로 코드의 다른 부분을 다른 스타일로 작성할 수 있습니다. 자동화된 테스트를 통한 우리의 주요 언어는 Ruby입니다(우리 회사의 모바일 테스트 자동화 기록에 대해 agile_seph here ). 다양한 스타일의 코드를 작성할 수 있기 때문입니다. . 그러나 다른 사람의 코드로 작업하는 것은 어려울 수 있습니다.

이 문제를 해결하기 위해 SET STANDARDS 패턴을 선택했습니다 .

" 자동화 아티팩트에 대한 표준을 입력하고 준수하십시오 ."

이것이 없으면 여러 사람이 동일한 프로젝트에서 작업하고 각자 고유한 스타일과 방법이 있음이 드러날 수 있습니다(모든 사람이 다른 언어를 사용하는 것처럼). 자동화에 직접 관련된 분들의 의견을 수렴하여 문제를 해결하기 시작했습니다. 우리는 모든 사용자에게 유용한 스타일 규칙을 개발하는 것을 목표로 했습니다. 그리고 결정에 참여한 모든 사람들이 앞으로 그것을 고수하려고 노력할 것입니다. 그래서 우리는 그 과정의 모든 참가자들이 받아들이고 따르는 지침을 만들었습니다. 말 그대로 공통 언어를 찾는 데 도움이 되었습니다.

우리는 무엇을 했습니까?

코드 개정 주기를 단축하는 데 도움이 되는 최신 가이드 및 문서(예: 환경 설정 방법, 테스트 실행 및 유지 관리 방법)가 포함된 로컬 Wiki를 만들었습니다. 우리는 모든 문서 를 여러 부분으로 나누어진 Confluence에 저장합니다 . 팀은 문서의 관련성을 정기적으로 확인합니다.
위키에 팀 간 회고 및 계약을 추가했습니다. 매월 회의를 열고 각각의 결과를 바탕으로 실질적인 결론을 내립니다.
테스트 코드 및 마일스톤 및 검증 방법에 대한 코드 레벨 제한 사항에 대해서는 RuboCop (Ruby용 정적 분석기 및 코드 서식 도구), 안전 검사 (Guard Chesks) 및 사전 커밋 후크(pre-commit-hooks)를 포함한 표준화된 도구를 구현했습니다 .
레거시 코드를 정리하고 일반 매개변수화된 단계 및 방법을 강조 표시했습니다. 기존 방법을 사용할 수 있는 경우 고유한 방법을 만들지 않는 것이 좋습니다. 몇 가지 모범 사례가 포함된 샘플 프로젝트는 여기에서 볼 수 있습니다 .
테스트 자동화 팀은 코드 품질 위원회를 구성했습니다. 그는 누구나 참여할 수 있는 질문과 작업 목록을 가지고 있습니다. 또한 질문이 있는 모든 사람을 위원회 회의에 초대하여 문제를 해결하는 데 도움을 줍니다.

장점

테스트를 유지 관리하고 오류를 수정하는 데 드는 시간과 노력이 줄어듭니다. 코딩 가이드를 통해 무엇을 어떻게 작성해야 하는지 매우 쉽게 이해할 수 있습니다.
코드를 검토하는 데 시간이 덜 걸립니다. 한편으로는 코드가 더 깔끔해지며, 다른 한편으로는 리뷰어와 피어 리뷰어를 위한 진실의 소스가 항상 있습니다.
다른 팀에서 작성한 코드로 작업하기 위해 추가 노력이 필요하지 않습니다. 우리는 동일한 저장소에서 작업하는 여러 팀이 있으며 표준과 관행이 다를 수 있습니다. 그러나 경계를 아는 것은 특정 균일한 스타일을 고수하는 데 도움이 됩니다.

단점

문서가 생성된 후에는 아무도 동반하지 않습니다. 이것은 모든 문서, 특히 항상 사용되지 않는 문서의 일반적인 문제입니다. 따라서 문서 유지 관리를 담당하는 사람을 지정하고 Confluence에서 전자 메일로 알림을 보내어 아무도 의견을 무시하지 않도록 설정했습니다.
회고적 회의를 조직하고 사람들을 참여시키는 것은 어렵습니다. 관심 있는 모든 직원이 문제를 해결하느라 바쁘지 않을 때 시간을 내기가 쉽지 않습니다. 따라서 그러한 회의는 사전에 강력하게 계획되어야 합니다.

패턴 번호 3. 정보 공유

팀으로서 우리는 기술을 향상시키기 위해 노력하므로 모든 사람이 복잡한 버그의 원인 분석, 사례 연구, 도구 설계 및 동료에게 유용할 수 있는 기타 정보와 같은 지식을 공유할 것을 권장합니다.

이 패턴을 SHARE INFORMATION 이라고 합니다 .

“ 상사, 개발자 및 기타 테스터에게 정보를 요청하고 공유하십시오 . ”

우리에게 이것은 광범위한 지식으로 테스트 자동화를 개선하는 방법입니다. 이 패턴을 구현하기 위해 주간 짧은 프레젠테이션인 QA Lightning Talks를 시작했습니다. 누구나 10~15분 이내에 주제를 제안하고 이야기할 수 있습니다. 회의에는 명확한 타이밍이 있으므로 많은 시간을 들이지 않고도 새로운 것을 배울 수 있는 좋은 기회입니다. 참석하지 못하신 분들을 위해 회의 영상을 내부 도서관에 보관하고 있습니다.

보고서는 테스트 및 자동화에만 국한되지 않습니다. 예를 들어, bayandin 은 Homebrew 프로젝트를 지원한 경험에 대해 이야기 한 적이 있습니다. 그리고 인도주의적 OpenStreetMap 에서 내가 "카우치 지도 제작자"라는 사실에 대해 말한 적이 있습니다. 저는 지도가 제대로 표시되지 않은 지역의 지도를 만든 다음, 적십자나 국경없는의사회와 같은 다른 조직의 직원들이 작업에 사용합니다. 이 보고서의 요약 버전은 나중에 EuroSTAR 2020 컨퍼런스의 Soapbox 세션에서 발표되었습니다.

장점

팀원들은 누가 무엇을 하고 있는지 더 잘 이해하고 있습니다. 대기업에서는 벙커 와 같이 팀이 고립되어 작업을 시작하는 경우가 많습니다 . 그리고 그러한 짧은 대화는 의사 소통하고 함께 일하는 다른 방법에 귀중한 추가 요소가 될 수 있습니다.
지식의 총량이 증가하고 있습니다. 그리고 연구 에 따르면 지식을 공유하면 부서 간 및 부서 내 의사 소통이 향상됩니다.
자기 개발 및 성장을 위한 추가 동기 부여. 다른 사람들이 하고 있는 일과 그들을 도울 수 있는 방법을 보는 것은 새로운 것을 배우거나 지식을 심화하도록 영감을 줄 수 있습니다.

단점

모든 사람이 연설을 하고 싶어하는 것은 아닙니다. 프레젠테이션을 해야 할 뿐만 아니라 청중에게 말하기 위해서는 용기와 노력이 필요합니다. 우리는 공연의 길이를 제한하고 말하고 싶어하는 모든 사람에게 도움과 지원을 제공함으로써 이 순간을 다림질했습니다. 많은 사람들이 이미 이 분야에서 첫 걸음을 내디뎠습니다.
청중의 관심을 유지하고 늘리는 것은 어렵습니다. 우리는 매번 주제를 변경하고 주제에 초점을 맞춥니다. 예를 들어, 프로젝트 중 하나는 티켓의 모든 테스트 실행 결과를 테이블로 수집하고 이를 Jira에 통합하는 것이었습니다. 테스트 자동화 팀원 중 한 명이 다음 회의에서 이에 대해 말했습니다.

보너스: 훈련 패턴 - 페어링(Pair Up)

위의 단계를 수행한 결과에 대해 자세히 알려 드리겠습니다. 예를 들어 QA 엔지니어는 불안정한 자동화 테스트를 작성, 유지 관리 및 분석하는 책임을 지기 시작했습니다. 따라서 우리는 더 나아가 테스트 자동화 프레임워크와 툴킷과 관련된 일부 작업을 수행하도록 만들기로 결정했습니다. 테스터가 일상적인 작업 외에도 프레임워크를 연구하고 코드 기반과 긴밀하게 작업할 수 없다면 이러한 단계는 불가능했을 것입니다. 그리고 일상적인 일은 효율적으로 해결했지만 도움 없이는 그 일을 넘기가 쉽지 않을 것 같았다.

이 목표를 달성하기 위해 PAIR UP 패턴을 사용했습니다 .

" 경험이 많은 직원은 경험이 적은 직원을 한 켤레 받습니다 ."

QA 엔지니어를 위한 내부 멘토링 프로그램을 시작했습니다. 그것은 무엇입니까? QA 엔지니어는 짧은 기간(보통 2주) 동안 Automators에 합류하여 자신의 백로그가 아닌 해당 팀의 백로그에서 작업합니다. 이들은 수석 자동화 엔지니어 중 멘토의 도움을 받습니다. 내부 멘토링의 목적은 학습입니다. 우리는 다음과 같은 매니페스트를 개발했습니다.

마감일을 엄격하게 준수하지 않고 학습에 집중합니다 .
벙커 작업이 아닌 대화식 토론.
멘토링 종료 시 소급 검토가 아닌 조기 및 정기적 피드백.

오른쪽의 진술이 가치 있는 반면, 왼쪽의 진술은 우리에게 더 가치가 있습니다.

나는 최근 연설 에서 멘토링, 왜 그리고 어떻게 실천하는지에 대해 더 자세히 이야기했습니다 .

결과

이러한 패턴의 사용은 통신과 코드 작업 모두에서 여러 어려운 문제를 해결하는 데 도움이 되었습니다. 우리는 새로운 수준의 자동화에 도달했습니다. 동시에 프로세스가 간소화되고 팀 구성원이 업무에 과부하가 걸리지 않습니다.

우리가 해결할 수 있었던 문제

동료에게 도움을 요청하는 것을 꺼림(“도움 요청” 패턴을 사용하여 결정). Seretta Gamba와 Dorothy Graham 은 저서 A Journey through Test Automation Patterns: One team's adventures with Test Automation 에서 "도움을 요청하는 것을 두려워하지 마십시오. 대부분의 사람들은 실제로 도움을 받는 것을 즐깁니다."라고 말했습니다.
테스트 코드 기반을 유지하는 데 드는 높은 비용("표준 설정" 패턴을 사용하여 결정됨). 오랫동안 자동화 작업을 해왔다면 표준이 필수입니다.
정보 벙커 ("정보 공유" 패턴을 사용하여 해결). 다른 사람들과 의사 소통: 토론 중에 종종 새로운 아이디어가 떠오릅니다.

이 기사에서는 테스트 자동화에 적합한 몇 가지 패턴만 설명했습니다. 하지만 우리의 경험과 추천이 당신에게 영감을 주기를 바랍니다.

테스트 자동화에서 겪었던 어려움과 해결 방법을 댓글로 알려주세요.

카카오블로그