테스트 자동화에서 개발 협업 요청은?

QA 업무를 진행할 때 개발팀과 협업했던 내용을 정리해 볼 겸 글을 작성해 봤습니다.

저는 업무를 요청할 때 최대한 논리적인 이유로 요청을 했었는데, 제가 업무를 진행했던 과정도 한번 정리해 보면 다른 QA 분들도 도움이 되지 않을까 싶어서 포스팅을 뜨끈하게 구워보겠습니다 :)

 

QA 업무 중 테스트 자동화 업무를 진행할 때 개발팀의 손길이 필요하지 않으신가요?

 

 

주어진 상황에서 해결이 된다면 큰 문제가 없지만, 저는 테스트 자동화 스크립트를 개발할 때 개발 지원 요청이 필요했었습니다.

웹 페이지에 보이는 요소(Element)의 식별자가 충분하다면 괜찮았겠지만 저는 매우 부족한 상태로 업무를 진행했었습니다.

 

 

그래서 이전에 포스팅했던 방식처럼 ID, Class와 같은 독립적인 요소가 있다면 편했지만, 그 외의 항목은 요소 + 상대 경로의 xpath를 활용해서 스크립트를 동작하도록 진행했었습니다.

 

 

이전 포스팅 : 부족한 식별자로 신뢰도 있는 자동화 스크립트 구성하기

부족한 식별자로 신뢰도 있는 자동화 스크립트 구성하기

 

없는 살림에 이것도 감지덕지한 마음으로 많지 않은 식별자를 활용하여 스크립트를 구성했습니다!

 

 

그럼 자동화 스크립트는 안정적일까요?

 

 

 

 

따란~! 툭. 하면 엌하고 무너질 수 있는 자동화 스크립트가 구성되었습니다!!

 

그럼 안정적인 테스트 자동화 환경을 만들기 위해 어떤 것이 필요할까요..?

 

---

☝️첫 번째 레슨. 개발팀에 대놓고 요청해 보기

 

 

아이 뭐 방법이 있습니까 개발자 슨생님들~ 자동화 잘 안 돌아가는데 요소 하나만 넣어주시죠~?

 

안되는데 어뜨케~ C렙 슨생님들 개발팀에서 이거 안 해줘서 자동화 못하겠어요 ㅠ

 

이렇게 협업 요청을 한다면.. 해주기야 하겠죠..?

 

 

맷집이 좋으신 분들이라면 가능하겠으나, 저는 이런 성격이 아니라 안될 것 같습니다 하핳..

 

---

✌️두 번째 레슨. 현상을 공유하고 안쓰럽게 말해보기.

 

저는 우선 이 방법을 활용했습니다. 냉정하게 얘기하면 테스트 자동화 스크립트를 개발하는 것은 QA 엔지니어의 업무니까요.

 

개발 업무 중 요소의 식별자를 추가하는 작업이 포함되어야 한다면 불만이 많이 있을 것이라고 예상했습니다.

개발팀은 필요 없는 작업인데 왜 해줘야 하죠..? 우리 바쁜데..

그리고, 식별자 추가 해드리면 잘 되는 거 맞아요? 시간 낭비하는 것 아닌가..?

 

 

테스터의 업무에 복수를 꿈꿨던 개발자의 반격 기회랄까...?

 

QA의 직업병인지 모르겠지만, 제가 개발팀의 입장이 되어본다면 위처럼 생각될 수 있을 거라고 예상했습니다. 

타 팀의 요청으로 개발 업무가 추가되는 것은 좋지 않은 경험이 될 수 있으니까요..!

 

그럼 이제 식별자를 추가해야 하는 이유를 설명해야 했습니다.

그전에 자동화의 동작 방식부터 설명이 필요했기 때문에 문서를 써보기 시작했습니다.

 

 

요소를 찾고, 동작을 수행한다의 반복으로 테스트 자동화가 진행되는 것을 간략하게 공유하고, 요소를 잘 찾을 수 있어야 안정적인 테스트 환경이 구성된다는 것을 전달드렸습니다.

 

const menuNameLocator = 'h1 >> text='+menuName;

// menuNameLocator의 위치에서 menu 전체 Locator를 찾는 방식
const menuLocator = this.page.locator(menuLayer).locator('xpath=../span/div');

 

그리고 간단한 코드 예시를 통해 현재 이런 방식으로 요소를 찾고 있고, 직접적으로 찾을 수 없는 요소들은 xpath의 상대경로를 섞어서 사용하고 있지만, 구조가 살짝이라도 바뀐다면 테스트 동작은 실패하게 된다.

 

 

그럼 우리는 실패 원인을 확인하고 다시 상대 경로를 수정해 주고 테스트 동작을 확인하는 방식으로 유지보수를 하고 있지만 이건 임시방편으로 언제 무너질지 모르는 집을 구축하고 있다는 것을 공유드렸습니다.

 

 

딱 필요한 항목에 식별자만 추가되면 우린 안정적인 테스트 자동화 환경을 제공해 드릴 수 있다는 것을 어필했죠.

 

 

간절함이 먹혔을까요..? 그래서 돌아온 답변은 "그럼 어떤 기준으로 식별자를 추가해 드리면 될까요?"였고 개발팀과의 협업을 시작할 수 있게 되었습니다.

 

 

---

🤟세 번째 레슨. 남들과 비교하기.

 

저도 어떤 것을 어떤 방식으로 개발하도록 요청해야 할지 명확한 기준을 세우는 것이 필요했습니다.

 

그래서 떠오른 것은 QA 컨퍼런스에서 봤던 연사분들의 자료를 활용하여 우리도 우리의 기준을 만드는 것이었습니다.

가장 많이 활용했던 것은 무신사 페이지와 발표 내용이었습니다.

 

발표 후기 링크 : [IT Conference/QA Conference (2024, 3rd)] - 2. 자동화의 신뢰성을 높이기 위한 액션

2. 자동화의 신뢰성을 높이기 위한 액션

 

 

자동화 환경 구축이 잘 되어있는 무신사 페이지 요소를 확인하고 어떤 식으로 안정적인 테스트 자동화 시스템을 구축하고 있는지를 공유하였습니다.

 

그렇게 필요한 레이아웃이나 버튼에 "data-testid"라는 요소가 추가된다면, 이를 활용하여 테스트 자동화를 만들 수 있다는 것을 공유하였고, 추가적으로 개발 진행 시 이런 항목이 있다면 testid를 추가해 달라고 요청했습니다.

 

• 이미지로만 구성된 버튼
  • 이미지 자체가 버튼이 되는 경우 별다른 식별 요소가 없다면 선택하기 어렵기 때문에 식별자가 필요
  • 이미지로 된 버튼이 상태를 표시하고 있다면 현재 상태 요소도 추가 (예시 : 즐겨찾기 on [★] / off [☆] 시 현재 상태 값)
• 데이터가 변경되는 버튼 or 드롭다운
  • 텍스트로 버튼 식별이 가능하나, 상황에 따라 텍스트가 달라지기에 요소 자체에 식별자가 필요

 

 

실제로 요청한 항목은 더 있었지만, 명확한 기준이 아닐 수 있기에 포스팅에는 더 추가하지 않겠습니다 :)

 

---

개발팀과의 협업 최종 결과는?

 

현재 상태를 공유하고, 설득과 협업 끝에 개발팀에서 자체적으로 테스트 자동화에 도움 될 부분이 있다면 적극적으로 지원해 주는 방식으로 업무가 진행되었습니다.

 

식별자가 추가된 덕분에 안정적인 테스트 자동화 환경 구축을 할 수 있었고, 화면 구조가 바뀌어서 선택할 요소의 위치가 바뀌더라도 식별자가 있기 때문에 바뀐 위치에서 정상 테스트가 진행되는 것도 확인할 수 있었습니다.

 

이것은 유지보수 비용이 크게 감소할 수 있었던 작업이었고, 협업하는 과정에 논리적인 설득이 추가되면 조금 더 수월하게 진행된다는 것을 배운 작업이었습니다.

 

QA 업무가 아니더라도 사내 업무를 진행할 때 근거를 기반으로 한 업무 제안 요청을 하는 것이 어떨까 생각되어 업무 중 있었던 협업을 예로 들어 포스팅해 봤습니다 :)

 

 

경험으로 배운 다른 사례가 기억난다면 새로운 포스팅 해보겠습니다! 읽어주셔서 감사합니다 :)