테스트레일 블로그에 포스팅된 객원 필자(Dee Ann Pizzica)의 “데브옵스(DevOps) 테스트 전략: 테스터가 참전하고 승리하는 법”을 번역하였습니다.

원문 링크: https://blog.gurock.com/devops-test-strategy/

회사에서 새로 시작된 큰 프로젝트에서 이슈가 보고된다. 이 프로젝트는 매우 높은 기술 수준이 요구되므로, 숙련된 개발자들이 포함된 데브옵스 팀과 함께 사내 최우수 인력들이 참여하고 있다. 원활한 운영을 위해서 인프라 의존도 역시 상당한 시스템이지만, 소프트웨어 프로젝트이므로 버그, 서비스 장애, 중단 등은 있기 마련이다. 이에 경영진은 품질을 더 향상시켜야겠다는 판단하에 QA팀을 참여시키기로 한다.

만약 당신이 이런 상황에 처했다면 많은 과제들에 직면하게 된다. 이런 상황에서 어떻게 시작할 것이지 그리고 데브옵스 팀에게 어떻게 권장 사항을 전달할 것인지를 살펴보기로 하자.

현황 파악부터 시작

데브옵스 팀에게 권장 사항이나, 더 좋은 아이디어를 제공하기에 앞서, 당신은 이 프로젝트가 무엇이고 누가 참여하는 지에 대해 더 많이 알아야 한다.

개요 파악
가능한 빨리 개발팀장 또는 프로젝트 관리자와 이야기할 시간을 잡자. 이야기를 나누는 동안에는, 테스터로서 역할 수행을 잘 해내기 위해서 당신이 알아야 할 것들이 무엇인지를 이해하는 것에 집중하자. 프로젝트의 기본 사항들, 참여한 사람들과 각 역할에 대해 파악한다면 일단 성공이다.

해당 팀과 일을 시작하기 전에 미리 알고 싶은 질문들이 있을 것이다. 프로젝트의 목표들과 주요 일정들을 파악하자. 프로젝트 팀이 걱정하고 있는 것들이 무엇인지도 파악해야 한다. 중단, 지연, 부정확한 데이터 등의 이슈도 파악하자. 프로젝트 팀은 이미 성능에 대해 크게 우려하고 있을 수도 있다. 프로젝트팀에서 당면하고 있는 이슈의 사례를 가능한 많이 말할 수 있도록 도와주도록 하자.

또한, 프로젝트팀이 당신에게 기대하고 있는 것이 어떤 것들인지를 물어보자. 당신이 집중해야하거나 또는 전혀 관여하지 말아야 할 특정 시스템이나 팀의 영역이 있는지도 파악하면 좋다.

문서 읽기
처음 시작할 때에는, 프로젝트 문서가 있다면 무엇이든 읽어두는 것이 도움이 된다. 세세한 내용까지 이해를 하지 못할 수도 있다. 하지만 문서를 읽으면, 적어도 해당 프로젝트 안에서 사람들이 어떤 식으로 어떤 이야기를 하는 지를 알 수 있다. 또한 문서를 읽는 동안, 몇가지 상세한 내용을 통해 사전 토의에서 정확히 이해하지 못했던 것들에 대해 윤곽을 잡을 수 있다.

잘 알지 못하는 개념들이 문서에 꽤 많을 수도 있다. 문서에 있는 용어나 도구 중 데 들어본 적 없는 것들은 찾아보자. 중요해 보이는데 혼자 힘으로 완전히 이해하기 힘든 것들은 따로 메모를 해두었다가 나중에 질문하도록 하자.

팀 토론과 회의 참석
문서 읽기를 할 때와 마찬가지로, 팀 회의에 처음 참여하면 모든 내용을 따라가지 못할 것이다. 회의 진행을 너무 방해하지 않는 수준에서 가능한 많은 정보를 파악할 수 있도록 노력하자. 처음에는 주로 들으면서 메모만 하는 것도 좋다. 적어도 프로젝트 팀이 지금까지 어떻게 해왔는지에 대해 많은 것을 알 수 있게 될 것이다.

어느 프로젝트든 새로 참여하게 된다면, 굳이 하지 않아도 되는 질문들은 피하자. 바로 회의에 참여하게 된다면, 그 회의의 목표와 논의 주제가 무엇인지 정도는 분명히 알고 있어야 방해꾼이 되지 않는다. 학습 단계와 신뢰를 구축하는 단계에서는 질문을 던지기 보다는 던저야할 질문을 명확히 준비하는 것에 집중해야 한다.

개발자 인터뷰
팀원들을 아직 모르더라도 일단 1:1 대화 시간을 정하자. 개요 파악 미팅 중에 팀원 구성에 대한 질문을 했다면, 당신은 이미 각 팀원의 역할에 대해 알고 있을 것이다. 하지만, 역할을 맡긴 사람과 맡은 사람이 서로 다른 생각을 하는 경우는 흔하다. 따라서 그 사람이 팀에서 어떤 부분을 맡고 있으며, 매일 하는 작업이 무엇인지를 반드시 물어보도록 하자.

각 팀원들과 대화하는 시간은 당신이 사전 학습 과정에서 메모해두었던 것들을 질문하기에도 좋은 때이다. 그들에게 작업하고 있는 화면을 보여달라고 부탁하고, 어떻게 시스템이 작동하는지 어떤 도구들을 사용하고 있는지를 파악하자. 대화 중에 복잡한 개념이 나오면 멈추고 질문하기를 반복하면 해당 개념을 이해하는 것 뿐만 아니라 당신이 더 적극적으로 그 프로젝트에 참여하고 더 많이 알고 싶은 마음이 생기는데도 도움이 된다.

1:1 인터뷰 중에는 상대방이 해당 프로젝트에서 어떤 위험이나 문제를 우려하고 있는 지를 파악하는 것에 촛점을 맞추어야 한다. 당신 스스로 파악할 수 있는 이슈라고 하더라도, 대해 그들은 더 많은 우려와 더 많은 아이디어를 가지고 있을 확률이 높다. 또한 이 인터뷰는 각 개발자가 개별 테스트를 어떻게 수행하고 있는지를 질문하기에 알맞은 기회이다. 개발자들이 무엇을 어떻게 테스트하는 지를 파악하면, 앞으로 당신이 권장 사항을 준비할 때 필요할 정보들을 많이 확보할 수 있다. 물론 당신에게 어떤 점을 기대하는지에 대해 각각 물어볼 수 있는 기회이기도 하다.

권장 사항 제시하기

프로젝트의 목표들을 파악하고 당신에게 무엇을 기대하는 지를 질문하고, 팀원 각자와 대화하면서 현재 작업이 어떻게 진행되고 있는 지를 모두 파악했다면, 이제 작업을 착수할 준비가 되었다. 당신이 “품질”때문에 어떤 프로젝트에 참여하게 되었다는 것은, 그 프로젝트팀이 해소해야할 몇가지 오류들이 이미 있다는 의미이다.

모니터링 구현
프로젝트 팀은 고객보다 먼저 문제를 알 수 있어야 한다. 안정화로 가는 가장 큰 단계 중 하나는 시스템의 불안정 문제가 어디에서 왜 발생하는지를 이해하는 것이다. 모니터링이 도움이 된다.

데브옵스 팀은 많은 도구들을 사용한다. Runscope를 확인하여 API 성능을 체크하자. 특정 API가 다운되면 경고를 할 수 있도록 시스템 다운을 모니터링 하는 것부터 시작할 수 있다. 데이터 무결성 체크도 설정할 수 있다. 이것은 나쁜 데이터가 시스템 실패를 일으킬 수도 있다는 점을 프로젝트 팀에게 상기시킬 수 있는 기회이기도 하다.

Grafana라는 도구도 고려해보자. Grafana는 데이터베이스 상의 정보도 유지할 수 있는 모니터링 도구이다. API 응답 시간 뿐만 아니라 CPU 사용에 따라 경고를 할 수도 있다. 개발자들이 심각도를 바탕으로 경고의 기준점을 어떻게 잡을 것인지, 복잡한 실행 단계를 어떻게 테스트할 것인지를 결정할 수 있도록 도와주기 위해 당신의 테스팅 능력을 사용하자.

모니터링 시, 테스팅과 마찬가지로, 당신은 중요한 정보를 먼저 찾고자 한다. 그리고 발견된 버그는 우선 얼마나 중요한 버그인지를 측정해야한다. 모든 버그를 같은 수준으로 다룰 수는 없다. 프로젝트 팀에서 알림 기준을 설정 할 때에는 다음 방식을 적용하자. 한밤중이라도 받아야 하는 알림, 24시간까지는 기다릴 수 있는 것, 과도한 소음 정도로 취급할 것 등이 무엇인지 모두가 공감할 수 있도록 하자. 알림이 너무 과도하면 프로젝트 팀이 지쳐 떨어지게 되고 도구의 효과도 떨어진다. 테스트를 현명하게 선택함으로써 테스트가 안정적이고, 가치가 있고, 적시에 알림을 주도록 하자.

체크리스트 사용
테스터에게 가장 좋은 도구 중 하나는 체크리스트이다. 체크리스트란 너무 복잡하거나 너무 중요한 것 중 어느 것이든 당신이 절대 빠뜨리면 안되는 정보 목록을 놓치지 않도록 도와준다. 현재 이미 가지고 있는 체크리스트를 보다 향상시키고 싶다면 아툴(Atul Gawande)의 “체크리스트 점검표(The Checklist Manifesto)”를 살펴보면 좋다.

데브옵스 팀에 권장 사항을 전달할 때에는 체크리스트들을 지참하자. 데브옵스팀은 아마 당신의 체크리스트 모음집을 운영지침서로 받아들일 수도 있다. 훌륭한 운영지침서라면 시스템 운영을 원활하게 유지하기 위해 필요한 모든 절차에 관한 정보가 담겨있다.

데브옵스팀은 긴급 상황을 다루기에도 바쁘기 때문에 운영지침서 작성을 소홀히 하는 경향이 있다. 즉 오류를 수정하는 각 단계를 일일이 적어내려갈 시간이 없기 때문에 그냥 머리 속에 담아두려고 한다. 그 결과, 여러면에서 위험이 발생한다. 예를 들어, 팀원이 조직을 떠나면 그 직원과 함께 노하우도 떠나버린다. 또는 팀원이 너무 지치거나 과도하게 스트레스를 받을 때 그 압박감으로 너무 당연하고 중요한 단계를 깜빡 빠뜨릴 수도 있다.

데브옵스팀에서 이미 운영지침서를 가지고 있다면 좋은 상황이다. 그 지침서를 따라 가면서 정확한지, 최신 내용이 반영되었는지, 철저하게 되어있는지만 확인하면 된다. 만약 운영지침서가 없다면, 한가지 지침부터 시작하도록 도와주자. 프로세스를 문서화 하는 것은 시간이 많이 걸리지만, 올바른 체크리스트 하나가 프로젝트 팀을 재앙에서 구해줄 수도 있다.

자동화
사람의 실수를 줄이고, 당신이 커버하는 범위를 넓히려면, 가능한 많은 테스트와 절차를 자동화를 하자. 당신이 테스트 자동화 담당자가 아니더라도, 당신은 테스트 자동화에 기여할 수 있다. 테스트 코드를 직접 작성하지는 못하더라도, 당신은 효과적인 테스트 어떤 것인인지 잘 알고 있기 때문이다.

개발팀과 함께 프로젝트 각 단계를 도와줄 테스트 세트를 파악하는 작업을 하자. 데브옵스팀에서는 지속적 제공 (Continuous delivery)에 촛점을 맞추기 때문에, 당신은 변경이 적용될 때 마다 수행되는 핵심 기능들 모두를 커버할 수 있는 테스트 세트를 확보하고 싶을 것이다. 또한, 유지 보수 시 별도로 신경쓸 정도가 안되는 특정 기능을 위한 특별한 테스트가 있는 지를 찾아 볼 수도 있다. 자동화 세트는 자주 다듬어서, 고객의 우려 또는 시스템 중단 등으로 인해 파악된 중요한 이슈들을 바탕으로 지속적으로 추가해나가자.

더 나아가 멋지고 훌륭하게
위 시나리오의 핵심 메시지를 기억하자: 당신은 이 프로젝트에 참여했고, 당신으로 인해 프로젝트가 달라 질 수 있다. 너무 많은 것을 빠르게 배워야 하는 상황에서는 누구나 움츠러들기 쉽다. 하지만 스스로를 격려하고 뛰어들어보자. 당신은 이미 테스터로서 역량을 갖추고 있다. 당신은 듣고, 찾아내고, 배우고, 질문한다. 함께 작업하는 일원이자 의견을 제시할 수 있는 사람으로서 갖추어야 할 역량을 이미 갖추고 있다. 게다가 소프트웨어를 어떻게 나누어야 하는지도 잘 알고 있다. 이 역량들을 장점으로 활용하여, 프로젝트에 기여함으로서 모범이 될 수 있다.

이글의 작성자(Dee Ann)는 열정적이고 호기심많은 소프트웨어 테스터이다. 테스트 경력이 15년 이상이며, 그동안 여러 산업군을 넘나들며, 매우 복잡한 비즈니스 로직을 담은 여러 모바일과 웹 애플리케이션을 지원했다. 현재는 BRD사의 엔지니어링 이사로서, 재능있는 팀과 함께 iOS와 안드로이드용 암호화폐 지갑 앱을 지원하고 있다.