https://roadmap.sh/qa 에 올라온, QA Engineer Roadmap에 대해서 살펴봅니다.
이 사이트는 Kamran Ahmed 라는 한 개발자에 의해 시작되었습니다. 초창기에 벡엔드 개발자 로드맵이 인터넷상에서 퍼지면서 유명하게 되었죠.
단순히 로드맵뿐만 아니라 로드맵을 생성하는 도구를 만들었습니다. 각 노드를 클릭해서 설명을 기입할 수도 있죠.
얼마전에 QA 엔지니어의 로드맵을 발표했는데요, 이 로드맵을 살펴보고자 합니다.
물론 제작자 본인은 백엔드 개발자라서 실무자들의 눈에서 볼 때는 동의하기 어려운 부분도 있을 것 같기도 합니다.
테스트와 품질관리 측면에서의 기초적인 개념들을 익힙니다.
작성자의 로드맵에서의 노드에는 이러한 정의가 기재되어 있습니다.
What is Quality
Quality is extremely hard to define, and it is simply stated: “Fit for use or purpose.” It is all about meeting the needs and expectations of customers concerning the functionality, design, reliability, durability, & price of the product.What is Assurance
Assurance is nothing but a positive declaration of a product or service, which gives confidence. It is certain of a product or a service which it will work well. It provides a guarantee that the product will work without any problems as per the expectations or requirements.Quality Assurance in Software Testing
Quality Assurance in Software Testing is defined as a procedure to ensure the quality of software products or services provided to the customers by an organization. Quality assurance focuses on improving the software development process and making it efficient and effective per the quality standards defined for software products. Quality Assurance is popularly known as QA Testing.
품질보증활동은 단순히 테스트를 진행하면서 버그를 찾아내는 것 뿐만 아니라, 프로덕트가 올바르게 만들어지고 있는지 전반적인 프로세스를 체크하고, 버그가 생기는 것을 막는 활동이라고 말할 수 있겠습니다.
종종 Quality Control과 구분되기도 하는데, QC활동은 좀 더 테스팅에 중점을 둔 활동이라면 QA활동은 전반적인 프로세스에 관여하는 활동이라고 할 수 있습니다.
다만 완전히 다른 것이 아니라, QA활동은 QC활동을 포괄하는, 좀 더 상위개념입니다. QA활동을 한다고해서 테스트를 안하는 것이 아닙니다.
테스트는 품질활동의 기본이라고 할 수 있습니다.
ISTQB에서는 테스트담당자와 개발담당자의 마인드셋을 정의하고 있습니다.
그중 테스트 담당자에 대해서는,
등에 대해서 강조하고 있습니다.
테스트 접근방법에 대해서는 대표적인 방법 세 개를 열거하고 있습니다.
보통 테스트담당자가 수행하는 테스트는 블랙박스, 그레이박스 테스팅이 대부분입니다.
테스트 오라클에 대해서는 정의는 있지만 그 실체가 명확하지 않습니다. (저도 실무에서 본 적이 없습니다...)
A test oracle is a mechanism; different from the program itself that can be used to check the correctness of the program's output for the test cases. Conceptually, we can consider testing a process in which the test cases are given to the test oracle and the program under testing.
어떠한 테스트 결과에 대해서, 이 테스트 결과가 맞는 결과인지 비교를 하기위한 어떠한 예상결과집 이라고 생각하고 있습니다.
ISTQB에서는 오라클에 대해서, 실제로 존재하는 시스템 혹은 다른 소프트웨어, 유저 매뉴얼, 개인의 전문지식등이 해당되며, 소스코드는 아니라고 정의하고 있습니다.
테스트의 우선순위는 몇가지 기준에 따라 정해질 수 있습니다.
등등이 있을 수 있습니다.
https://www.geeksforgeeks.org/test-case-prioritization-in-software-testing/
테스트를 관리하는 툴에 대해 열거하고 있습니다.
테스트를 관리하는 것이란, 전체적인 테스트 일정부터 시작하여 테스트케이스, 테스트 진척상황, 버그관리 등을 포함합니다.
여기에 JIRA 도 포함되면 좋을 것 같네요.
전체 프로젝트를 관리하는 툴에 대해서 열거하고 있습니다.
QA/Test담당자는 단순히 테스트업무만 관리하는 것이 아니라, 프로젝트의 전체 프로세스에 같이 딥다이브하여 참여해야하므로, 매니지먼트툴 및 매니지먼트에 대해서도 알고 있어야합니다.
테스트 기법에서는 다시 기능테스트와 비기능테스트로 나뉩니다.
개발 모델 및 테스트 모델에 대한 주제입니다.
애자일 모델에서는 다시 아래와 같은 개념들을 열거하고 있습니다.
저도 SAFe에 대해서는 아직 접해보거나 들어본적이 없어 알아봐야겠다는 생각이 드네요 📝
폭포수 모델은 전통적인 소프트웨어 개발 방법론입니다.
https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8
V모델은 폭포수 형태의 변형된 모델입니다.
제 포스트중에도 서술한 내용이 있으니 참고해보세요.
다음은 매뉴얼테스트 및 그 개념들에 대한 내용입니다.
테스트 주도 개발론에 대해서입니다. 테스트 잠당자가 개발방법론에 대해서 왜 알아야하냐 라고 생각할 수는 있습니다만, 요구사항에 기반한 테스트케이스 혹은 체크리스트를 사전에 개발자에게 좀 더 빠른 타이밍에 공유된다면, 개발자도 참고하여서 유닛테스트케이스를 구성한다던지, 그러한 내용에 방어하기 위한 방어코드 혹은 코드리뷰 시에 좀 더 의식적으로 활동을 할 수 있을 것입니다.
테스트 일정 및 테스트 방법, 리소스 관리 등, 테스트 플래닝에 대한 내용입니다.
테스트 시나리오와 각 기능별 테스트 케이스에 대해서입니다.
테스트를 수행하였으면 테스트 결과에 대해, 이해관계자들에게 결과 보고 및 공유가 되어야합니다.
호환성에 관한 테스트가 수행됭어ㅑ 합니다.
검증과 확인(검사) 의 차이에 대해 이해가 필요합니다.
위 내용은 항상 볼때마다 헷갈리는 개념입니다.
다음은 자동테스트에 관한 내용입니다.
개인적으로는 워딩이 마음에 드는데, 테스트 자동화 가 아니라, 자동화된 테스트 인 점입니다.
모바일의 자동화에 대해서입니다.
모바일 자동테스트에 이용하는 프레임워크에 대한 이해가 필요합니다.
프론트 엔드 테스트에 관해서 입니다.
간략한 웹의 지식들을 필요로 합니다.
몇가지 처음보는 개념들도 있습니다.
브라우저에서 확장도구와 같은 것을 추가해서 사용할 수도 있습니다.
펀더멘탈에서는 개념적인 방법에 대해서 설명하였고, 이 부분에서는 실제로 사용하는 툴들을 소개하고 있습니다.
접근성, 사용성 테스트에 대해서입니다.
테스트 리포팅 툴에 대해서입니다.
Junit이 있는 것으로보아, 단순한 리포팅툴을 포함해서 테스트 프레임워크도 포함되는 것 같네요. (TestNG, PyTest)
에러 로그에 대한 모니터링 툴에 대해서입니다.
테스트담당자는 로그를 확인하고 이슈가 발생하는 원인을 어느정도 유추하고 리포트할 수 있어야하기 때문에, 로그 모니터링 툴에 대해서 기재되어있는 것 같습니다.
git이외에도, SVN도 현업에서 아직도 많이 사용하고 있습니다.
CI/CD는 요새 테스트 업무에서는 핫한 부분인 것 같습니다.
테스트를 자동화시키고 배포와 연결하여 빠르게 반복적으로 수행하기 위해서는 CI/CD에 대한 개념도 알아야할 것 입니다.
브라우저 GUI가 실행되지 않는, headless testing에 대해서입니다.
사실 프론트엔드 자동화테스트 섹션에 있어도 될 것 같은데, 별도로 나와있긴 합니다.
https://www.browserstack.com/guide/what-is-headless-browser-testing
로드맵의 모든 항목을 간략하게나마 훑어보았습니다.
제가 아는 것도 있고, 모르는 것도 있어서 저 또한 계속해서 공부해야겠다는 생각이 드네요.
다만 몇몇개는 직접 실 업무에서 경험하지 못하면 어려울 것 같다는 느낌이 들어서, 어떻게 해야 경험을 쌓을 수 있을까 라는 생각은 듭니다.
이 로드맵이, QA엔지니어가 갖추어야할 덕목, 소양, 능력은 아닙니다. 이것은 어디까지나 상당히 주관적인 내용일 뿐입니다. 다만 무엇을 해야할지 모를때에는 참고해봄직할만 참고서와 같은 존재가 될 것 같습니다.