QA/Test 업무를 하다보면, 당연한 업무들이지만 한 번 쯤은
"내가 정말 잘 하고 있을까?" 라고 내 스스로, 혹은 팀에게 되물으며 한 번쯤 다시 생각해봐야할 것들이 있습니다.
그 중에 근래에 근무하면서 몇 가지 생각이 든게 있어서, 글에 나열해봅니다.
도입한 프로세스의 관리
테스트 업무를 하다보면 뭔가 삐걱거리는 경우가 많이 있습니다. 이것을 해결하기 위해 문제를 도출해내고, 이 문제를 막기 위해 어떠한 과정들을 프로세스화 하는 경우가 많습니다.
"이 프로세스대로 업무를 하면 원래 겪던 문제들은 방지할 수 있을꺼야!"
라면서 말입니다.
그렇지만 한 번 도입한 프로세스가 정말로 잘 적용되고 있는지 에 대해서 한 번쯤 되돌아볼 필요가 있습니다.
이해관계자들과의 소통 및 프로세스 모니터링
테스트 프로세스가 올바르게 수행되고 있는지 이해관계자들과 정기적으로 소통하는 것도 유지관리의 한 부분입니다. 테스트 활동이 제품의 품질에 기여하고 있음을 관련 부서나 관리자들이 관심을 가지고 지켜보도록 유도해야합니다.
한 편, 어떠한 문제를 해결하기 위해 도입한 프로세스에 대해서, 왜 이 프로세스를 지켜야하는 지 잘 이해하지 못한 채로 업무를 진행하는 이해관계자가 있을 수 있습니다. 이러한 이해관계자가 있다면 프로세스에 대한 이해도가 낮은 상태에서 같이 협업해야하므로 뭔가 삐걱거릴 수 있습니다.
관리자는 프로세스를 정기적으로 모니터링하면서 이러한 이해관계자들에게 정기적인 설명을 해야겠습니다. 실무자라면 업무를 진행하면서 문제있을만한 상황에 대해 관리자와 주기적으로 소통하고 개선책을 강구해야합니다.
정기 미팅 및 제품 품질과 관련된 대시보드 제공
테스트 프로세스, 테스트 현황에 대해 정기적인 공유를 하고, 특정 버전에서의 이슈 갯수나 테스트 커버리지 등의 지표를 공유합니다.
현재 운용하고 있는 프로세스에 대해서 특정 이슈가 없는지 미팅을 통해 의견을 받는 것도 좋습니다. 직접 물어보는 것도 좋고, 팀원들 대상으로 익명의 설문조사나 인터뷰를 진행하여 의견을 수렴하는 것도 좋습니다.
이해관계자들과의 Shift-left
실행중인 테스트 프로세스에 대해서, 프로세스 초기 단계부터 이해관계자들을 적극적으로 참여시켜 프로세스에 대한 이해도와 몰입도를 높이는 작업을 수행합니다. 이 활동을 통해서 도입한 프로세스가 제대로 수행될 수 있도록 관리감독할 수 있으며, 예외적인 상황에서 발생할 수 있는 이슈들에 대해서 이해관계자가 동일한 수준의 컨텍스트를 가지고 대응할 수 있도록 할 수 있습니다.
리그레션 테스트케이스 관리
새로운 기능이 추가되거나 수정될 때마다 기존 기능에 문제가 생기지 않았는지를 확인하는 리그레션 테스트는 꾸준히 수행해야하는 테스트입니다. 이 때 테스트케이스의 관리가 핵심입니다. 서비스가 시간이 지남에 따라 기능들이 추가되거나 삭제되거나할 텐데, 테스트케이스들도 계속 업데이트되어야하고, 더 이상 유효하지 않은 테스트는 테스트케이스를 수정하거나 혹은 제거하고, 새로운 기능에 맞는 테스트를 추가하는 작업이 필요합니다.
실제로 살충제의 패러독스 현상 때문에, 동일한 리그레션 테스트를 반복하다보면 더 이상 새로운 결함을 찾지 못할 가능성이 있습니다.
Spec-out된 기능들에 대한 테스트케이스 관리
업무를 하다보면, 개발팀에서 테스트 담당자들에게 공유하지 않은 채로 기능을 제거하거나 하는 경우가 심심치 않게 있습니다. 이 경우라면 스펙아웃된 기능에 대한 테스트케이스에 대해 직접 테스트를 해보려고 할 때까지 기능이 제거된지 모르는 상태로 있을 수 밖에 없습니다.
테스트 담당자는 주기적으로 개발팀과 커뮤니케이션을 하면서 추가/제거되는 기능들에 대해 확인하고 테스트케이스들을 사전에 관리하여 테스트 수행 직전에 혼란에 빠지는 일이 없어야합니다.
우선순위 부여
프로덕트의 수명이 길어지면 질수록, 리그레션 테스트케이스들의 양도 많아지기 마련입니다. 유지중인 테스트케이스들을 매번 배포마다 수행하면 정말 좋겠지만, 현실적인 리소스의 문제로 모든 케이스들을 정해진 시간안에 수행하기란 어려운 일입니다. 따라서 기능의 중요도에 따라 우선순위를 설정하고, 특정 우선순위의 이상의 테스트케이스들만 실행하는 것이 하나의 방법입니다.
한 번 우선순위를 부여했다고 오랜기간동안 우선순위를 유지할 필요는 없습니다. 추가되는 기능들과 비교해보고 더 우선순위가 높은 기능들이 있다면, 우선순위를 변경해줄 필요도 있습니다.
A/B 테스트 관리
기능들 중에는 A/B 테스트를 수행하는 경우도 있습니다. 기존 버전의 기능과 신규 버전의 기능을 동시에 관리해야하는 셈입니다. 이 경우에 테스트케이스에 대해서 기존 케이스는 어떻게 할지, 신규 기능의 테스트케이스를 어떻게 할지를 고민해봐야합니다.
자동화시킨 수동 테스트케이스들의 관리
테스트 자동화는 결국 수동으로 수행하던 테스트케이스들에 대해 자동화하는 것을 의미합니다. 그렇다면, 수동 테스트케이스와 자동 테스트 코드는 맵핑관계로 나타낼 수도 있는데, 기능 상의 변경이 일어난다면 수동 테스트케이스를 갱신해줘야하고, 갱신된 수동 테스트케이스에 따라 자동 테스트 코드도 같이 관리를 해주어야합니다. 이 때, 어떻게 해야 번거로운 작업들이 발생하지 않을지를 고민해야합니다.
단일 케이스 관리
수동으로 수행하는 많은 테스트케이스들은 그다지 상세하지 못한 경우들이 많습니다. 사람이 수행하기 때문에 꽤나 높은 추상도를 가진 케이스들이 많이 있습니다. 이러한 테스트케이스를 자동화하는 경우에는 어쩔 수 없이 1:N으로 쪼개야하는 경우가 있을텐데요, 이 때 이 맵핑관리를 어떻게 해야 번거로운 일이 발생하지 않을 지에 대한 고민이 필요합니다.
이렇게 하지 않으면 어떤 케이스를 자동화했는지의 판단이 어려울 수 있습니다.
자동화시킬 테스트케이스의 선정
수동 테스트 케이스 중 자동화할 테스트케이스를 꾸준히 선정하고 자동화된 테스트의 구현내용이 정말로 수동케이스를 커버하고 있는지를 체크해야합니다. 일단 반복적으로 꾸준하게 실행하면서, 수동으로 실행할 때는 시간이 많이 드는 케이스를 후보로 선정하여 자동화를 수행합니다. 자동화가 완료되면 수동 테스트케이스에 자동화 여부를 추가하여 테스트 수행 담당자가 이미 자동화된 테스트를 수행하지 않도록 해야합니다.
테스트 자동화 커버리지
수동 테스트케이스 대비 얼마만큼 자동화되어있는지를 꾸준하게 추적해야합니다. 기존대비 자동화여부가 떨어지고 있다면 왜 떨어졌는지, 커버리지를 다시 일정 이상 올릴 수는 없는지를 챙겨야하며, 올릴 수 없는 경우에는 왜 올릴 수 없는지 원인 파악과 함께 대응 방안도 강구해야합니다.
자동 테스트 유지보수 전략
리그레션 테스트케이스를 관리해야하듯이, 자동화 시킨 테스트 코드들에 대해서도 지속적인 유지보수를 진행해야합니다. 테스트가 항상 제품의 기능을 정확하게 검증하도록 해야합니다.
A/B 테스트 관리
A/B 테스트를 진행중인 기능에 대해서 A의 경우와 B의 경우 둘 다 자동화를 할 지 결정해야합니다. A/B테스트의 기간, 중요도 등을 고려해서 이해관계자들과 상의하여 자동화여부를 결정해야합니다.
대응하게 된다면 config 혹은 server flag를 통해서 조작을 해야하는데, 테스트 실행 전에 해당 기능을 on/off할 수 있는 fixture를 준비해서 테스트하기 수월하게 진행되어야겠습니다.
일반적으로는 플래그가 off일 때는 기존 테스트를 수행하도록 하고, on 상태에서 추가로 발생하는 시나리오만 별도의 테스트로 만드는 방식이 효율적일 것입니다.
중복된 테스트 스크립트의 작성을 최소화하는 방향으로 고민되어야합니다.
식별자 관리
개발팀과 논의하여 의미있는 UI Identifier를 사용합니다. UI가 바뀌더라도 의미 상 동일한 역할을 하는 UI 컴포넌트라면 동일한 기존과 동일한 식별자를 사용해서 테스트케이스가 계속 유지되도록해야합니다.
또한 Identifier를 최대한 관리하기 쉽게하기 위해서는 어떻게해야할지에 대한, 테스트 자동화 프레임워크 레벨에서의 고민도 함께 되어야합니다.
모듈화와 재사용성이 고려된 구조
테스트 자동화 코드 실행 시에 여러 군데에서 실행되는 함수들을 한 곳으로 모아서 재사용할 수 있도록 해야합니다. 각 테스트마다 중복으로 코딩하지 않고 한 군데에서 작성한 코드를 여러 테스트에서 재사용할 수 있어야 유지보수가 편해집니다.
한 편, 예외적인 케이스가 있을 수 있으므로 그러한 경우에도 충분히 고려해야합니다.
Flaky한 테스트들의 주기적인 관찰
테스트 코드 혹은 시나리오는 변화가 없는데 어떨때는 실패하고 어떨때는 성공하는 테스트들이 있습니다. 이러한 테스트에 대해서 주기적인 관찰과 함께 어떻게 하면 성공율을 개선시킬 수 있을지 고민해봐야합니다.
테스트 코드의 문제라면 좀 더 다른 방법의 대응방법은 없을지 고민해봐야합니다. 프로덕트의 문제 혹은 인프라의 문제라면 개발자들과 함께 대응방법에 대해 논의해야할 수도 있습니다.
테스트 데이터 관리
몇몇 테스트는 선제적으로 특정 값이 설정되어있는 데이터 혹은 계정을 이용하여 테스트를 수행해야할 수도 있습니다. 이 때 해당 값이 너무 오래되진 않았는지를 정기적으로 체크하고, 테스트가 제대로 성공하고 있는지, 현재 데이터가 기능과 너무 동떨어진 데이터는 아닌지를 확인해야합니다.
테스트 업무를 하면서 뭔가를 했다! 한 후에 유지관리 측면에서 생각해봐야할 것들에 대해서, 아마 더 많은 것들이 있지만 당장 떠오르는 것들에 대해서 간략하게 기재해보았습니다.
일단 했다! 라고 하면 그 후에는 알아서 잘 돌아가겠거니~ 라고 하지 말고, 지속적인 관심을 통해 개선을 하고, 더 나아가서 조직과 서비스에 유의미한 임팩트를 가지고 올 수 있는지에 대해 고민해봐야할 부분이라 생각합니다.
끄읏.
