brunch

You can make anything
by writing

C.S.Lewis

by 호뎡 Aug 01. 2024

SW테스트 무한루프에 빠졌다면
(Automation)

꼬리에 꼬리를 무는 테스트


개발 초기에 여러 코드가 중구남방으로 짜여서 형체가 그다지 보이지 않고 있다가 

개발 프로젝트의 결과물이 나오기 시작한다면

결과물의 처음부터 끝까지의 과정을 시연하는 경우가 많죠?


의도한 대로 시연이 잘 된다면 정말 뿌듯하겠지만

뭐 다들 아시잖아요 그러기 힘들다는 것......(^^)>;


UI가 문제였든 데이터베이스가 문제였든

꼭 하나정도는 얻어걸리는 게 있더라구요


사실 시스템의 치명적인 문제들은

단위 테스트 / 화이트박스 테스트를 통해 조기에 발견되는 게 조금 더 나을지도 모릅니다.


개발된 범위가 커질수록 기능들이 서로 연관되는 경우가 많아지고,

코드를 쫓아가는 데 한계에 도달하기 시작하거든요 

물론 우리의 뇌용량도 함께 한계에 도달하지요....


치명적 결함은 그만큼 파급력이 크기에

V모델 피라미드가 한순간에 무너져내리는 수가 있습니다.


ㅋㅋㅋㅋㅋㅋ


시스템 테스트가 정말 중요한 이유를 잘 설명해 주시는 예시 같네요 ㅎㅎ


저렇게 극단적으로 모든 기능이 불능이 되어버리지는 않겠지만

무서운 점은 도미노 하나가 쓰러지면 그게 어디까지 쓰러지게 만드는지 모른다는 겁니다(!!)


그러면 거의 100%의 확률로 새로운 결함이 생길 테고

이 문제점을 찾기 위해 또 한 번의 테스트를 거치게 되지 않을까요?


만약 문제를 고치더라도 동일한 상황이 발생하겠죠!


고친 기능은 과연 문제가 없다고 장담할 수 있을까요?


아니 그럼 뭐 어떡하는 게 좋냐구요?

테스트를 또 하면 되죠~ ㅋㅋㅋㅋ


원래 모든 프로젝트는 테스트를 절대로 배제할 수 없답니다 ㅎㅎ


수정 작업 이후 벌어지는 결함에 대비하기 위한 테스트?

사실 검토 수준으로 대충 하는 작업은 절대 아니거든요!


회귀테스트라고 들어보셨을 거예요...!

초기 개발 후 기능 수정이 이루어졌으나 수정 작업의 파장으로 인해 어떤 결과를 초래하게 되는지

우리는 지켜볼 수밖에 없는 입장이죠?


그래서 한번 더 감시하는 작업을 회귀테스트라고 합니다!


따라서 회귀테스트 진행 시에는 변경의 우려가 있는 범위를 정해놓고,

그 범위를 한번 더 감시하는 작업을 하게 되죠...!


아무래도 반복 작업이다 보니까 유지보수에 들이는 자원을 아까워하시는 분들도 종종 계십니다.


분명 필요한 작업이긴 하나, 이상하게 생산성 없어 보이고 단순해 보이는 부분이 있는 것 같아요....!




예를 들면 로그인을 1000번 해야 한다던가, 같은 상품 구매를 몇백 번 진행해야 한다던가...

약간 막일로 취급받는 업무들은 필요하지만 그만큼의 시간을 사용하기에 아까운 느낌이 든다는 것이죠... 


여기서, 반복작업이라 하면 번거로우면서도 지치지만,

한 가지 특별하고도 기가 막힌 대처 방법이 있다는 거 아시나요?


인류가 산업혁명을 맞이할 때 수많은 공장이 재탄생하였는데

테스트라고 해서 테스트 공장을 못 만들 이유는 없잖아요?


그래서 엔지니어들은 특별한 테스트 공장을 개발하게 되었습니다...!


일련의 테스트 방식을 매크로로 등록해 버리는 것이죠!

시스템 자체가 자동으로 테스트를 진행한다면, 그만큼 할당되는 자원을 절약할 수 있게 됩니다 :)



... 그런데, 이것을 처음부터 끝까지 전부 적용할 수 있을까요?




물론 좋은 솔루션이기는 하나, 당연히 완벽하게 모든 로직을 구현할 수는 없습니다!


소위 말하는 노가다(?) 형식의 작업은 매크로처럼 사용이 가능해도 다른 기능들도 순순히 따라주는 경우는 많이 없으니까요.


간혹 프로젝트 관리자가 자동화 적용을 원하지 않는 경우도 있는데요,

아무래도 자동화 자체의 정확도가 떨어지는 문제를 우려하여 자체 테스트를 진행하게 됩니다.


어느 정도 경력이 있으신 분들은 성능이 애매한 범용 자동화 솔루션을 적용했다가 오히려 반복작업을 더 진행하는 불상사를 염두에 두고 플랜을 세우시고는 해요.


모든 프로젝트는 그 목적과 주 기능, 설계 과정이 전부 가지각색이기 때문입니다...!


그러면 우리는 대안을 생각해 내야겠죠?

이런 문제를 최소화할 수 있는 방법이 무엇일까요?


결함 발생의 우려가 있는 부분을 집중적으로 자동화로 제작하거나, 사용자 입장에서 자주 발생하게 되는 기능 테크트리를 자동으로 테스트할 수 있도록 제작하는 방법이 있겠죠?


위 방법은 해당 시스템의 실행 로직을 미리 분석하고 그에 걸맞은 자동화 제작이 이루어집니다.

PMO 입장에서 정확도를 더욱 높일 수 있는 것이죠!


효율성과 정확도가 비례하는 흔치 않은 기술력,

한번 찾아보셔도 좋을 것 같습니다!!


작가의 이전글 소프트웨어의 역방향 피라미드를 아시나요?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari