프리온보딩 - QA 챌린지 사전 미션

이번에 프리온보딩에서 QA 챌린지 신청을 받고 있어서 신청해보았다.

개발자로 2년 일하고 현재 회사에서 QA Engineer로 포지션을 제안받아 약 1년 반 동안 일을 하는 중인데 내가 아닌 다른 QA Engineer들은 어떻게 일을 하고 있을지 항상 궁금해왔었다.

일반적으로 QA Engineer들이 어떤일을 하는지에 대해서 알 수 있는 좋은 기회가 되지 않을까 생각이 되어 신청을 하게 되었다.

사전미션이 있어서 풀어보았다.

1. 소프트웨어 기획/개발/배포 단계별 수행할 수 있는 테스트 활동들에 대해 설명해주세요.

기획

• 요구사항 분석 : 요구사항이 명확한지, 잘못된 부분은 없는지 오류나 누락을 분석합니다.
• 설계 검토 : 설계 문서의 오류나 누락을 검토합니다.

개발

• 단위 테스트 : 단위(unit)를 테스트 하며, 일반적으로 작고 빠르게 테스트 하는 것이 특징입니다.
• 통합 테스트 : 단위를 넘어 외부 종속성을 포함하여 테스트를 진행합니다.
• E2E 테스트 (end to end, 종단간) : 최종 사용자 입장에서 테스트를 진행합니다.
• 정적 테스트 : 소프트웨어를 실행하지 않고 코드의 오류, 보안 문제, 스타일 가이드 준수 여부 등을 테스트합니다.

배포

• 인수 테스트 : 제품을 배포하기전 최종적으로 테스트를 진행합니다. 요구 사항을 충족하는지 확인합니다.
• 유지 보수 테스트 : 배포 후 제품이 정상적으로 동작하는지 확인합니다.

2. 테스트 중인 서비스의 특정 동작에서 오류가 발생하고 있습니다. 클라이언트(i.e, 프런트엔드) 이슈인지 서버 이슈인지 어떻게 확인할 수 있을까요?

보통 클라이언트에서 에러에 발생했을 경우 해당 에러에 대한 정보가 로그에 나오게 됩니다. 그 로그를 기준으로 이것이 클라이언트 이슈인지, 서버 이슈인지 확인할 수 있습니다.

네트워크 통신을 확인하여 API의 응답 코드나 response를 확인해 보는 것도 에러를 유추하는데 큰 도움이 됩니다. 네트워크를 거치지 않고 발생되는 에러라면 클라이언트 이슈일 가능성이 높을 수 있습니다.

3. 「소프트웨어 테스팅의 7가지 원리」중, 살충제 패러독스(Pesticide Paradox)란 무엇인가요?

초기에는 유효하던 테스트가 이후 변경사항에 따라 유효하지 않게 되는 것을 의미합니다.

해당 테스트에서 input 영역이 정확하게 정의가 되어 있다면 문제가 되지는 않습니다. 변경사항에 의해 테스트의 input 영역이 변경되었다면 그에 대한 테스트도 추가/수정을 해주어야 합니다.

테스트에 대해서도 품질관리가 필요하다는 것을 의미합니다.

4. DB, 백엔드, 프런트 서비스 검증 시 주로 어떤 툴을 사용하시나요? 활용 사례를 말씀해주세요.

보통 백엔드와 DB는 묶어서 들어가고 프론트의 경우 일반적으로 웹과 앱으로 나눠지게 되는것 같습니다.

백엔드

백엔드의 경우 단위테스트를 통해 각 도메인의 중요 로직들이 정상적으로 동작하는지 확인합니다. (junit, jest, mocha 등)

통합테스트 단계에서는 mocking 라이브러리를 사용할 수 있습니다. (mockito 등) 결정성을 보장하기 어려운 비관리 의존성에 대해서만 mocking을 사용 하는 것이 좋습니다.

DB

DB의 경우, 백엔드의 통합테스트 단계에서 테스트가 진행됩니다. 통합 테스트 단계에서 mocking 라이브러리를 사용할 수 있으나, DB의 경우 관리 의존성이기 때문에 mocking하지 않는 것이 좋다고 생각하는 편입니다.

프론트엔드

프론트엔드도 마찬가지로 주요 로직에 대한 단위테스트를 구현합니다. (jest, mocha 등) 단위 테스트는 최대한 gui에는 연결되지 않는 것이 좋다고 생각합니다. gui와 연결되면 깨지기 쉬운 테스트가 되기 때문입니다.

그러나 프론트엔드의 특성상 gui가 들어갈 수 밖에 없기 때문에 이러한 부분들은 통합 테스트, e2e 테스트를 통해 진행해야 합니다.

최근에는 시각적 요소에 대한 테스트도 진행하기도 합니다. (chromatic 등)

e2e 테스트

end to end 테스트의 경우 playwright나 cypress, selenium 등을 많이 사용합니다. 실제 사용자 관점에서 어플리케이션의 모든 구성 요소를 종합적으로 확인합니다.

5. QA에게 프로그래밍 역량(코딩)은 얼마나 중요하다 생각하시나요? 어떤 목적으로 활용하시는지 사례를 말씀해주세요.

QA

QA 에게는 필수적이지는 않지만 유용할 것입니다.

QA 가 버그 보고서를 더 정교하게 작성할 수 있다면 개발자들이 버그를 확인하는데 도움이 될 수 있습니다.

QA 엔지니어

QA 엔지니어에게는 매우 중요하다고 생각합니다.

첫번째는 자동화된 테스트를 구축하는데 도움이 됩니다.

두번째는 팀 프로세스 내에서 어떻게 테스트를 더 좋은 방식으로 수행할 수 있을까에 대해서 의견을 제시하는데 도움이 됩니다.

세번째는 버그를 분석하고 디버깅하여 개발팀에 효과적인 피드백을 제공할 수 있다면 개발자들에게 도움이 됩니다.

6. 애자일 개발문화에서 QA 엔지니어의 역할은 무엇이라고 생각하시나요?

• 요구사항, 기획, 설계를 리뷰합니다.

• 개발자와 PM/PO 등 팀 구성원들과 밀접하게 협력하고 소통하여 테스트에 대한 의견을 제시하고 테스트 전략을 개발합니다.

• 반복적인 테스트들을 자동화하여 시간을 정약하고 품질을 향상시킵니다.

기타

만약 테스트 이론적인 부분에 부족함을 가지고 계신다면, ISTQB 실러버스 중 다음의 주제들을 읽어오시면 프리온보딩 세션의 내용을 이해하는데 도움이 될꺼예요. (50p 내외)

• 1장 테스팅 기초
• 2장 소프트웨어 개발 수명주기와 테스팅
• 3.1장 정적 테스팅 기초
• 4장 테스트 기법

ISTAB CTFL의 한글 실라버스는 여기서 받을 수 있다.
http://www.kstqb.org/board_skin/board_view.asp?idx=426&page=1&bbs_code=4&key=0&word=&etc=ISTQB