1년간 비행기 SW 테스팅 업무를 수행하며 느낀 점에 대해 간략하게 정리해본다. 현재, 회사에서는 Python을 활용한 SW 품질 검증(Verification) 업무를 수행하고 있다. 여전히 배워야할 것이 많고 알아야할 것들 투성이지만...현재까지 파악한 부분에 대해 이야기 하고자 한다.(이 업무 계속하면 갈수록 이직은 어려워지는 것 같다...나중엔 뼈묻해야할 수도 있다는 점 유의하기 바란다...)
1. 비행기 SW 개발 및 테스팅은 상당히 까다롭고 어렵다.
아무래도 비행기에 탑재되는 SW이기에 무엇보다도 Safety가 관건이다. 이로 인해 일반 SW 테스트보다 훨씬 절차가 까다롭고 복잡하다. 미국에서는 항공기를 제조/개발/운행 등을 하려면 FAA 기관의 인증이 필수인데 이 기관에서 요구하는 절차와 품질 수준이 상당히 높다. 내가 수행하고 있는 업무도 해당 절차에 필요한 업무이기에 수행한다.(바꿔 말하면, FAA 인증이 필요하지 않은 SW 개발에는 나의 역할이 필요 없다는 의미다...슬픔ㅠ)SW 테스트의 경우도 내가 작성하는 Test Case말고도 개발자가 단위 테스트도 진행하고 있다. 예외 케이스를 여러 관점에서 생각해야 하기에 요건정의서/Spec 문서를 꼼꼼하게 분석하고 촘촘하게 테스트 케이스를 설계하는 능력이 필요한 업무인 것 같다.(일반 IT회사에서처럼 독창성이나 창의성 이런 건 상대적으로 덜 중요하다...안전이 달린 문제이기에 무엇보다도 오류를 잡아내는 능력이 탁월해야 한다.)
2. 개발업무와는 달리 코드보다 문서에 집중한다.
개발자는 고객의 요구사항에 따라 기능 구현을 하기 위해 코드 작성에 대부분의 업무 시간을 보낸다면 테스팅 업무는 이보단 요건정의서와 Spec 문서를 보며 해당 기능을 이해하는 데 대부분의 시간을 쏟는다. 물론, 문서로 잘 이해가 가지 않을 적에는 개발자가 작성한 코드를 참고하기도 한다.(해당 모듈 개발자가 자주 바뀔 시에는 Git으로 히스토리를 검색하여 담당 개발자를 알아내 문의하기도 한다...)하지만, 이상적인 업무 방식은 개발자 코드를 보지않고 요건정의서와 Spec 문서만으로 모듈 기능을 이해하고 Test Case를 설계할 수 있어야 한다. 또한, 개발자가 자신의 소스 코드 품질 개선을 위해 심혈을 기울이는 반면 테스트 코드 품질은 그다지 중요하지 않다. 테스트 엔지니어에게 있어서는 다양한 조건에서 해당 모듈이 제대로 동작하는지에 초점을 두고 있어 테스트 코드보다는 Test Case 설계에 더 집중하는 경향이 있다.
3. 커뮤니케이션 역량 + 도메인 지식이 정말 중요하다.
개발자에게도 물론 현업이나 기획자, 디자이너, 테스터들과 소통하기 위한 기본적인 커뮤니케이션 역량은 필요하다. 하지만 내가 느끼기에 SW 테스트 엔지니어는 커뮤니케이션 역량이 절대적인 것 같다. 업무 관련하여 개발자와 수시로 소통해야하는 것은 기본이고 요건정의서나 Spec 문서가 부실할 경우 해당 담당자에게 연락하여 이야기를 해봐야 한다. 특히, 개발자와 긴밀하게 소통하지 않으면 처음부터 업무를 다시 수행하게되는 경우가 있을 정도로 커뮤니케이션이 잘 이루어져야 한다. 하나부터 열까지 개발자 혹은 SW 모듈 담당자에게 물어보며 진행해야 하기에 업무의 자율도가 개발자에 비해 크지는 않다.(이 부분이 상당히 힘들었다. 개발과는 완전 다른 업무 특성 때문에...)
또한, 업무를 하면 할수록 도메인 지식이 중요하다. 현재 내가 종사하고 있는 항공기 업종의 도메인 지식이 있어야 업무를 훨씬 더 수월하게 할 수 있다. 연차가 쌓이면 쌓일수록 해당 지식이 축적되는 것이 테스트 엔지니어로서의 커리어에 필요하다고 볼 수 있다.(매니져님과 1:1 면담 때마다 듣는 말이 시간날 때마다 항공기 기술 Spec 문서를 보라는 이야기다...Java, Javascript같은 기술 문서는 즐겁게 읽히는데 항공기 기술 Spec 문서는 정말...지루하고 재미가 없다. 여기서 나는 해당 업계와 직무가 안맞구나를 확신하게 되었다...)주변에서 기술 Spec 문서를 읽으신 동료분들이 확실히 업무 이해나 처리 속도가 빠른 것을 보면서 도메인에 대한 관심과 흥미가 어느정도 있어야 함을 느꼈다.
총평
결론적으로, 내가 생각하기에 SW 테스트 업무 경험은 TDD 개발 프로세스에 필요한 역량인 Test Case 설계 역량을 배울 수 있는 기회인 것 같다. 요즈음 많은 개발자들이 TDD 방식을 채택하여 기획서를 받으면 바로 코드를 작성하는 것이 아닌 먼저 단위 테스트를 위한 테스트 코드를 작성하며 해당 기능을 구현해 나아가는 방식을 취하고 있다. 이로 인해 SW 품질을 더욱 향상시키며 개발자들 간에 긴밀한 협업이 가능해지는 장점이 있다고 알고 있는데 해당 업무를 통해 이에 필요한 역량을 키울 수 있다고 느낀다. 앞으로 약 2개월 뒤에는 새로운 웹개발 프로젝트로 옮기게 되는데(탈출 성공이다!) 여기서 키운 역량을 십분 발휘하여 멋지게 프로젝트에 임하고 싶다.
P.S. 테스트 엔지니어로 커리어를 쌓아가기엔 개발 업무가 적성에 더 맞고 몰입을 잘 하는 것 같다. 내가 가진 독창성과 창의성을 발휘할 수 있는 직무를 택하는게 나의 정신 건강에도 더 좋을 것 같기에...테스트 업무 경험은 이정도면 충분하지 않을까 조심스레 말해본다...앞서 2번과 3번에서 말한 역량에 강점을 가진 엔지니어라면 테스트 엔지니어로의 커리어도 나쁘지 않다고 생각한다.(2021.07 기준 회사에 퇴사 통보를 하고 2021.09.30까지만 근무하기로 합의 보았다. 중간에 개인적인 일이랑 회사 사정이 겹치면서 퇴사를 결심하게 되었기에...퇴사 후기 때 다루도록 하겠다.)
이 글을 읽는 모두가 즐겁게 코딩하고 즐겁게 배우며 크게 성장하길 바란다:)
참고: 위키백과