Topic: 문제점 파악
현 회사에 적응하고 있는 와중에 몇 가지 개선하고 싶은 사항들을 발견하기 시작했다.
벌써..?
1. 개발 단계 별 테스트 프로세스 미확립
한정적인 개발 인원으로
1) 신규 기능 개발
2) 기존 기능 수정
3) 정기 배포 (Web은 매주 1번, App은 한달에 한번)
위의 3가지 업무를 수행하고 계시다 보니,
계획되지 않은 테스트가 그때 그때마다 수행되고 있었다.
2. 너무 많은 회의 횟수
도메인 특성 상 국가적인 규제들이 빠르게 생성, 수정되면서 특정 프로그램의 담당 PM, 개발자(프론트/백엔드), 디자이너 분들 모두가 회의 참석이 필수적이고, 횟수도 많다.
위의 내용은 회의가 필요한 사유로 충분하지만,
문제는
1) 회의전에 공유되지 않아 회의 진행 중에 브레인 스토밍을 한다.
2) 공유되더라도 미리 읽어보고 의견을 정리해 오지 않는다.
앞의 이유와 더불어, 기획하고 개발하는데에도 많은 시간이 드는데 1) 정기 배포 2) 기능적 VoC 해결 3) 마감 기한 등의 사유로 일하기에도 시간이 빠듯하다.
그런데, 테스트가 계획대로 이루어지지 않으니, 불필요한 브리핑 회의까지 추가된다.
👍🏻그래도, 여기서 중점적으로 봐야할 점은 서로 의견을 잘 나누면서 수용하는 자세가 있는 팀원들이라는 것 👍🏻
3. 전문가 실종(?)
이건 좀 눈물 많이 나는데, 나 아직 1년 주니어 QA 엔지니어다.
아직 할 줄 아는 것도 많이 없고, 식견도 없는데...
운영 상태를 확인해보면 10년차 QA 마스터님께서 등판하셔야 해결될 일 같다.
진짜 막막하긴 하다....
(🥕🥕🥕🥕원래도 삽질은 많이 했긴 해..🥕🥕🥕🥕)
4. 테스트 이론을 애매하게 알고 있다.
우선 대명사(?)를 나와는 다르게 이해하고 사용하고 계신다.
IT 업계에서 의사소통이 중요한 이유는 하나의 단어(영단어로 되어 있거나)가 여러가지 의미를 내포하고 있기 때문에 모두가 이해할 수 있게 이야기 하는 것이라고 알고 있다.
1) 기능 단위 테스트(?)
기능 테스트인지 단위 테스트인지 알 수 없는 이 단어는..
회의 내용을 자세히 들어보니, 이미 'UI/UX에 입혀놓은 상태에서 버튼 하나의 단위' 로 사용된다.
원래 단위 테스트(Unit Test)란 소스코드의 특정 모듈(프로그램 내 하나의 기능)이 의도된 대로 정확히 작동하는지 검증 하는 절차로, 크기는 함수, 메서드, 개별 코드 등 작은 단위에 대해 테스트 케이스로 분리하고 테스트 코드를 작성하여 테스트 하는것으로 알고 있다.
2) 통합 테스트
얘는 맞는 말인데 왜 적었냐고?
신규 기능 개발에서 통합테스트를 진행하는 것이 아니라,
이미 판매까지 하고 있는 완성된 제품을 테스트하는데 사용되기 때문이다.
통합 테스트(Integration Test)란 모듈을 통합하는 과정에서 모듈 간 인터페이스가 올바르게 작동하는지를 테스트하는 것을 말한다. 일반적인 웹 어플리케이션은 프레임워크, 라이브러리, 데이터베이스, 구현한 코드가 주요 통합 테스트 대상이 된다.
3) 테스트 계획서
얘도 있는 말인데 무슨 문제냐구??
테스트 계획서에 테스트 케이스를 작성하며 만들어 지는데,
이 계획서를 끝으로 더이상의 새로운 TC는 없다.
명확하게 수립해야할 필요도 있고, 필수 산출물들도 없는 상태라 할 일이 많아 보인다.^^
나는 1년 경력의 주니어 QA 엔지니어라 변화를 주려면 많은 시간이 들 것 같다.
시간이 많이 들더라도, 명확한 프로세스를 만들면 지금보다는 나아질 것이라고 본다.
Result
앞으로 현 회사에서 해야할 업무들을 스스로 정리해보았다.
1. 테스트 프로세스 확립
테스트 프로세스라고 하면 좀 막연하긴 한데, 큰 종류로 3가지로 나눴다.
1) 신규 기능 테스트 프로세스
2) 기능 수정 테스트 프로세스
3) 정기 테스트 프로세스
DevOps
V-모델
직군은 QM 이라고 주어졌지만, 실제 역할은 QA, QI, QC, QM 의 업무를 다 한다고 보면 되겠다.
프로세스는 기존에 근무하고 계신 사수분께서 초안의 형식으로 만들어 놓으셨다.
그래서 수정하면서 구체적으로 확립하면 된다고 생각했다.
2. 프로세스 단계별 산출물 정의
테스트 프로세스의 초안을 보아하니 산출물들의 상태가 이상하다.
'테스트 계획서'라고 적혀있지만, 실제 내용은 '테스트 케이스'이다.
요구 사항에 맞게 기능 개발도 안되어 있는 상황에서 어떤걸 보고 시스템 테스트의 TC를 작성하겠다는 것인가.
테스트 단계별로 프로세스를, 수행 담당자를 정의할 필요가 있어 보인다.
3. 상용중인 프로그램 전반적인 테스트
실제로 프로그램을 테스트 해보면서 프로세스, 산출물, 양식 등을 확립할 필요해 보인다.
현재 Quality Assurance나 Quality Management 라는 태그는 아마 이런 활동을 주로 다루며 작성할 것 같다.
기술에 대한 이론 정의 내용과 실제로 투입한 상황을 기록할 예정인데, 너무 구체적인 내용이 작성된다면 비공개 글로 전환할 수 도 있을 것 같다.
4. 테스트 자동화
정기적인 배포가 Web 과 실행 프로그램으로 두 가지 정도 된다.
고정적인 프로그램의 정기적인 배포에는 자동화가 필수라고 생각한다.
이 바쁜 현대 사회에 할 일도 많은데 매번 같은 업무로 시간을 낭비할 수는 없다.
자동화 프로그램에 대해서도 찾아볼 것이 많겠다.
