[QA-TIL] QA의 중요성과 하는일

오늘은 필자가 QA-엔지니어를 공부하며 생각하는

QA의 중요성을 끄적여 보겠다.

사실 QA 라고 한다면

다들 "테스터" 라는 단어로

누구나 할 수 있는 업무라고

생각할꺼다.

 

하지만 말처럼

그렇게나 단순한 직무가 아니다.

 

"QA는 프로젝트의 완성도를 높여주는 일을한다."

 

QA엔지니어는 제품의 품질을 보장하고

제품의 품질을 개선하는 일을 한다.

 

QA도 굉장히 많은 부류가 있다.

 

QA-엔지니어 종류

제약회사, IT기업, 자동차 산업,

항공, 방위, 의료기기 등등

굉장히 많은 곳에서 QA라는 직무가

넓혀져 있다.

 

그중에서 필자는 IT 기업에 속해있는

QA엔지니어를 공부했다.

 

사람마다 다르겠지만,

보통은 개발자에서

QA엔지니어로 넘어가는 분들이 많다.

 

왜냐?

이건 개인적으로 iOS개발을 하다가 느낀부분이지만,

필자는 문제를 해결하고 이를 분석하는데

아주 큰 흥미가 있었다.

 

개발자의 경우 새로운 코드를 작성하고,

기능을 구현하는데 흥미와 가치를 느끼지만,

QA엔지니어는 어떠한 문제를 발견해서

그 문제를 개선하는 데에 초점이 맞춰져 있다.

 

개발자중에서도 버그를 분석한다거나

문제를 해결해 나아가는 그 과정에서

QA엔지니어 업무와 비슷한

흥미를 느끼는 사람들도 있다.

 

일부 개발자들은 단순하게 코드를 작성하는 것보단

제품 전반에 품질에 더 관심을 갖는분도 있다.

 

QA엔지니어라는 직무가 사용자의 경험,

안정성, 성능 최적화 등에 기여할 수 있기 때문에

전반적으로 제품에 약간의 불만이 많은 사람들에겐

매력적이라고 느껴질 수 있을꺼다.

 

이러한 불만이 곧 개선의 원동력이라고 본다.

 

사용자의 경험(UX)을 향상 시키는 일을

QA엔지니어가 한다고 생각하면 쉽다.

 

그렇다면,

"사용자의 경험(UX)은 무엇이냐?"

https://stayjun.tistory.com/229

[UX/UI-TIL] UX.UI.사용성.UCD 각각 어떻게 다른가

이전에 작성한 UX/UI-TIL이다.

위 글을 참고해보면 좋다.

 

사용자 경험을 말해본다면

먼저, 사용성(Usability)이 있다.

제품이 얼마나 쉽게 이해되고,

사용할 수 있는지를 보면 된다.

 

예를들어,

버튼이 직관적인 위치에 있는가?

에러 메시지가 사용자가 이해할 수 있는

언어로 작성되었는가?

 

두번째, 기능성(Functionality)이 있다.

제품의 기능이 사용자가 기대하는 대로

동작을 하고 있는지를 보면된다.

 

예를들어,

로그인 기능이 제대로 작동하는가?

사용자의 데이터를 정확히 처리하는가?

 

세번째, 일관성(Consistency)이 있다.

제품의 디자인과 동작이 일관적이며

예측이 가능한지를 보는거다.

 

예를들어,

웹과 모바일에서 동작 방식이 동일한지?

같은 동작에 대해 동일한 결과를 제공하는지?

 

네번째, 성능(Performance)이 있다.

제품이 빠르고 안정적으로 작동하는지를 보는거다.

 

예를들어,

로딩 시간이 짧고,

서버 에러가 최소화되는가?

 

다섯번째, 접근성(Accessibility)이 있다.

제품이 모든 사용자(장애 포함)에게

접근이 가능한지를 보는거다.

 

예를들어,

색약 사용자도 차트를 이해할 수 있는

색상 조합을 사용하는지?

화면 리더를 사용하는 사용자를 위한

태그가 설정되어 있는지?

 

여섯번째, 감정적 연결(Emotional Connection)이 있다.

사용자가 제품을 사용할 때 느끼는 감정적 만족감이다.

 

예를들어,

디자인이 즐겁고 매력적인지?

피드백이 긍정적이고 동기를 부여하는지?

 

일곱번째, 문제 해결의 용이성(Error Recovery)이 있다.

사용자가 문제가 발생했을 때

쉽게 해결할 수 있는지를 보는거다. 

 

예를들어,

실수로 파일을 삭제했을 때 복구 옵션이 제공되는지?

에러 메시지가 문제 해결 방법을 안내하는지?

 

이런 사용자의 경험을 QA엔지니어가

간접적으로 강화를 하는 역할을 하는데,

어떻게 강화를 하는가가 바로 QA엔지니어의

직무이자, 역할인거다.

 

그렇다면,

QA엔지니어가

일명, 테스터라고도 불리는

이유를 정리해보겠다.

 

QA는 먼저

(1)제품의 요구사항을 검토한 후

(2)테스트 계획을 수립한다.

 

위의 (1),(2)의 과정이

시간도 많이 걸리고

생각보다 상당히 복잡한 부분이다.

 

이렇게 글로만 써 보면,

사실.. "별거 아니네~"

라고 할 수 있겠지만,

생각보다 까다로운 거다.

 

왜냐?

이 (1)과 (2)의 단계가 바로

제품 품질의 방향성과 기준을 결정하는 

핵심 작업이기 때문이라는거다.

 

겉으로는 간단해 보일 수 있지만, 

실제로는 복잡한 문제들을

해결해 나아가야하는 과정인거다.

 

그러면 (1)과 (2)의 단계에서

어떤부분이 까다로운지

작성해보겠다.

 

(1) 제품의 요구사항 검토

첫번째, 요구사항의 모호성

많은 요구사항 문서는 생각보다 명확하지 않고,

애매한 표현으로 작성되기 때문에 여러모로

힘든 부분이 있다는거다.

 

예를들어,

"사용자 친화적이어야 한다"는 요구를

어떻게 측정할 것인가?

 

두번째, 요구사항의 불완전성

초기 설계 단계에서

모든 세부 사항을 정의하기 어렵기 때문에,

요구사항이 누락되는 경우가 많다는거다.

 

예를들어,

결제 시스템에서 "환불 프로세스"가

요구사항에 빠져 있다면 큰 문제가 될 수 있다.

 

세번째, 이해관계자의 다양한 기대

개발팀, 디자인팀, 마케팅팀 등 각 부서의

이해관계자가 요구사항에 대해

서로 다른 기대를 가질 수 있다는거다.

 

QA는 모든 이해관계자의 요구를 고려하면서도

사용자 관점에서 검토해야 한다.

 

네번째, 기술적 제약과 현실성

요구사항이 기술적으로 실현이 가능한지를,

또는

예산과 기한 내에 구현 가능한지를

평가해야 한다는 거다.

 

예를들어,

"1초 이내 응답 시간"이라는 요구사항이

서버 성능으로 인해 불가능할 수 있다.

 

다섯번째, 테스트 가능성 확인

요구사항이 구체적으로 정의되지 않으면,

테스트 가능한지 여부를 판단하기 어렵다.

 

QA는 "테스트 가능성"을 보장하기 위해서 

명확한 검증 기준을 요구해야 한다.

 

여기까지만 봤을 때

벌써 (1)에서부터 굉장히 많은 부분을

고려하고 있다는걸 알 수 있다.

---

(2) 테스트 계획 수립

첫번째, 테스트 범위 정의의 어려움

QA는 테스트할 모든 기능과

비기능적 요소를 고려해야 하지만,

시간과 자원이 제한적이다.

 

무엇을 테스트할지,

무엇을 제외할지를 명확히 결정해야 한다.

 

두번째, 우선순위 설정

모든 결함이 동일하게 중요하지 않으며,

사용자 경험에 가장 큰 영향을 미치는 영역을

우선적으로 테스트해야 한다는거다.

 

예를들어,

로그인 기능이 결함이 있다면

다른 기능보다 우선적으로 해결되어야 한다.

 

세번째, 테스트 유형과 전략 결정

기능 테스트, 성능 테스트, 보안 테스트, 회귀 테스트 등

적합한 테스트 유형을 선택하고 조합해야 한다는거다.

 

많은 회사들이 QA를 뽑을 때 이와같이

많은 테스트 유형과 전략결정을

정확하고 신속하게 조합할 줄 아는 사람을

우선시하기 때문에 신입보다는 아무래도 경력을

조금 쳐 주는 부분이 있고,

자동화와 수동 테스트를 얼마나

배분할지도 결정해야 한다.

 

네번째, 리소스와 일정 관리

QA 팀원의 역량과 테스트 환경의 가용성,

테스트 도구 등을 고려해서 

현실적인 일정과 목표를 수립해야 한다는거다.

 

기한이 촉박한 프로젝트에서는 어느정도

타협이 필요하지만,

이로 인해 품질이 저하되지 않도록 해야 한다.

 

다섯번째, 위험 분석

제품의 결함이 발생할 가능성과,

그 결함이 사용자에게 미칠 영향을

세밀하게 분석해야 한다는거다.

 

높은 위험을 가진 영역에

집중적인 테스트 계획을 세우는 것이

무엇보다 중요하다.

 

여섯번째, 이해관계자와의 조율

테스트 계획은 QA만의 작업이 아니며,

개발팀, 제품 관리자, 고객과의

협업을 통해 확정된다는거다.

 

서로 다른 우선순위와 요구를

조율하는 과정에서 갈등이 발생할 수 있음을

항시 기억해야 한다.

---

이렇게 (1)과 (2)에 대해서

조금 알아봤는데..

 와..

"뭔가 하는일이 많구나..."

라며 느끼는 사람들도 꽤 있을 꺼다.

 

이를 이해하고 위와 같이 느껴졌다면,

QA에 대한 인식이

단순한 테스터에서 벗어난 부분이기 때문에

필자는 다행이라고 생각한다.

 

QA는 정말 단순해 보이지만,

(1), (2)의 과정을 거쳐나아가며

항상 제품의 품질을 최상으로

끓어올리는 존재들이다.

 

반면,

겨우? 그런일 하면서

뭐가 그리 힘들다고... 라는

생각을 하는 분들도 꽤 있을 꺼다.

 

하지만 지금까지 (1)과 (2)는

과정에 불과하다는거다.

 

(1)과 (2)의 과정을 거치면

이제 (3),(4),(5)의 과정을 거치게 되는데

(3)은 실제로 이 (2)의 테스트 계획을

실행하는 거다.

 

(3) 테스트 실행 및 버그 탐지

그러면 얘는 뭐하는건가?

위(2)에서 설계한 테스트 계획에 따라

테스트를 실행하면서

제품이 요구사항을 제대로 충족하고 있는지

확인을 하는 과정과 결함(버그)을 발견해서

보고하는 작업을 진행하는데,

당연히 이과정도 순서가 있다는거다..

 

첫번째, 테스트 환경을 설정

테스트 환경을 준비(셋팅)하고,

실제 사용자 환경과 최대한 비슷하게

구성을 해줘야하는거다.

 

예를들어,

여러 운영체제나 브라우저, 디바이스,

네트워크 상태 등을 시뮬레이션하는거다.

 

두번째, 테스트 케이스 실행

(2)에서 작성된 테스트 케이스(TC)에 따라서

시스템을 테스트 하는데,

테스트에도 유형이 있다.

 

기능 테스트, 비기능 테스트, 회귀 테스트

기능 테스트부터 해보자면,

기능이 요구사항 대로 작동을 하고 있는지

비기능 테스트로 성능과 보안 그리고 접근성 등을

검증해보고, 회귀 테스트로 기존에 기능이

새로운 코드로 인해서 손상이 되지 않았는지

확인하는 업무를 진행한다.

 

세번째, 실제 결과와 기대 결과를 비교

실제 실행 결과랑 요구사항에 따른

기대 결과를 비교해서 그 차이를 식별한다.

예를들어,

버튼을 클릭 하면 제대로 작동하지 않거나

출력 값이 요구사항과 다를 경우

결함으로 기록하는것이다.

 

네번째, 결함(버그)탐지

발견된 문제를 분석하고, 기록하는건데

결함 보고서에 포함해야하는 항목이 있다.

결함요약과 재현단계, 기대결과와 실제결과

환경 정보와 심각도 및 우선순위이다.

결함보고서
결함 요약	재현단계	기대결과	실제결과	환경 정보	심각도	우선순위
회원가입시 "다음" 버튼이 눌리지 않음	모바일 앱에서 개인정보 입력후 다음버튼 클릭	이용약관 동의서로 이동 됨	다음 버튼 클릭시 "무반응"	iPhone 13 Pro iOS 18.1	상	1

대강 이런식이긴 한데,

스크린샷이나 로그가 있다면

문제를 이해하고, 해결하는데

큰 도움을 줄 수도 있다.

 

이건 보편적인 결함보고서에

포함되는 항목들이긴 한데,

회사마다, 업체마다 문서가 다 다르기 때문에

이점은 참고만 하길 바란다.

 

여기까지가 (3)이라면,

이제는 (4), (5)가 남았다.

(4)버그 조치 및 품질 개선

(5)자동화 테스트 도구

이렇게 (4)와 (5)의 과정이

남아 있는데, 이 과정은

전반적으로 문제를 해결해 나아가는

과정인 부분이다.

 

QA꽃이라고 할 수 있는

릴리즈 단계로 가는 거다.

 

(3)의 과정을 거쳤다면,

이제 (4)의 과정을 거칠차례다.

 

(4)는 버그를 조치하거나

품질을 개선하는 작업을 하는데,

어떤 작업을 하는지 천천히 알아보자.

 

(4) 버그 조치 및 품질 개선

이 과정에서는 버그가 해결되는 과정과

품질을 높이는 활동이 이루어진다.

 

주요 활동은

첫번째, 버그 수정 요청

개발자에게 버그를 보고하고,

수정할 수 있도록

수정 요구 사항을 전달한다.

 

여기에는 버그를 재현할 수 있는 단계,

영향을 미친 코드의 범위,

수정해야 할 부분 등을 명확히

전달해야 합니다.

 

두번째, 버그 수정 후 재테스트

버그 수정이 완료되면,

수정된 부분을 다시 테스트하여

버그가 해결되었는지 확인한다.

 

회귀 테스트를 통해 수정된 부분 외에도

다른 기능에 영향을 미쳤는지

확인하는 것도 중요하다.

 

세번째, 버그 재현 확인

수정이 제대로 되었는지 확인한 후,

버그가 재현되지 않는지 테스트한다.

 

만약 수정된 버그가 여전히 발생한다면,

다시 한 번 버그를 추적하여

문제를 해결해야 한다.

 

네번째, 품질 개선 활동

비기능 테스트(성능, 보안, 호환성 등)를

추가로 수행하여, 제품이 최종 릴리즈 전에

품질이 향상되도록 만든다.

 

개선 사항을 지속적으로 파악하고 적용하며,

사용자 경험을 더욱 높이는 작업을 진행한다.

 

다섯번째, 결함 우선순위 및 중요도 조정

해결해야 할 버그가 많을 경우,

버그의 심각도와 우선순위에 따라

조치 우선순위를 정한다.

 

급하게 수정해야 할 중요 결함이 있을 경우,

이를 최우선으로 처리한다.

 

여섯째, 리포트 및 커뮤니케이션

수정된 버그와 개선된 품질에 대한

보고서를 작성하여 관련 팀과

커뮤니케이션을 한다.

 

이를 통해 모든 팀이

버그 수정과 품질 개선에 대한

진행 상황을 알 수 있도록 한다.

 

이렇게 (4)의 과정을 거친 후

(5)자동화 테스트 도구를 수행한다.

---

자동화 테스트 도구

반복적인 테스트를 효율적으로 수행하고,

빠르게 결과를 제공하는 데 중요한 역할을 한다.

 

이 도구는 품질 향상과

테스트 효율성을 크게

높여준다는 것이다.

 

첫번째, 자동화 테스트 도구 선정

자동화할 테스트 유형에 따라

적합한 도구를 선택한다.

 

예를 들어,

Selenium, Appium - UI 자동화 테스트

JUnit, TestNG - 단위 테스트

JMeter - 성능 테스트

Postman - API 테스트

이렇게 존재 한다.

 

두번째, 자동화 스크립트 작성

반복적으로 수행해야 하는

테스트 케이스들을

자동화 스크립트로 작성한다.

 

예를 들어,

로그인 테스트, 회원가입 테스트 등

기본적인 사용자 흐름을 자동화하여

반복 테스트 가능하게 한다.

 

성능 테스트나 회귀 테스트 같은

반복적인 작업에 적합한다.

 

세번째, 자동화 스크립트 실행 및 모니터링

작성된 자동화 스크립트를

정기적으로 실행하고

결과를 모니터링한다.

 

테스트 실행 보고서를 자동으로 생성하고,

테스트 실패 시 알림을 통해

빠르게 대응할 수 있다.

 

네번째, 자동화 도구의 효율성 검토

자동화 테스트가 항상

효과적이지 않을 수 있는데..

예를 들어,

UI 테스트는 복잡한 인터페이스 변화에 민감하여,

수동 테스트가 더 적합할 수 있다는 것이다.

 

자동화가 효율적인 영역과

수동 테스트가 필요한 영역을 잘 구분하여

사용해야 한다.

 

다섯번째, 지속적 통합(CI)과 결합

자동화된 테스트 스크립트를

CI/CD 파이프라인에 통합하여,

개발자들이 코드를 커밋할 때마다

자동으로 테스트가 실행되도록 설정한다는 것이다.

 

이를 통해 문제 발생 시

신속하게 피드백을 받을 수 있다.

 

이렇게 (1)~(3)을 진행하며

이후 릴리즈 단계로써

(4)와 (5)의 중요성으로

(4)는 제품의 최종 품질을 보장하는

중요한 과정이 되고,

발견된 버그를 수정하고,

추가적인 품질 개선을 통해

제품을 개선하는 단계다.

 

(5)는 반복적이고 시간이 많이 소요되는

테스트를 자동화함으로써,

테스트 효율성과 정확성을

크게 향상시킬 수 있다.

 

그래서

QA엔지니어는 (1), (2), (3), (4), (5)의 과정을

거쳐 나아가며 제품이 출시 될때까지 진행하고

점차 더욱 안정적이며, 최상의 품질의 제품이

완성되는 과정에 참여하는 일을

한다는거다.

이렇게 QA과정을 보면

정말 단순한 직무라기 보단,

확실히 "엔지니어"라는 명칭답다

라는 느낌을 주고 있다.