SW테스트에 대해서 알아보자

세상 어떤 것도 완벽한 건 없습니다.

작은 제품하나라도, 출시과정까지

수 많은 테스트를 거쳐서 나온다고 하죠.

SW역시도, 복잡하고 중요한 SW는

수 많은 개발자의 테스트를 거쳐가면서

수정/보완해나가면서 점점 발전합니다.

 

왜 SW테스트가 필요할까?

"그거 버그가 아니라 스끼린데~~"

예전에 모 프로게이머가 방송에서 한 말이죠.

사실 저 선수가 얄밉게 말하긴 했지만

지금 스타에서 '스킬'로 쓰고있는 것도

엄밀히 말하면 버그인 것들이 많습니다.

지금은 저그의 기본기가 되어버린

'뮤탈뭉치기'도 엄밀히 말하면 '버그'에  속합니다.

왜냐하면 초기 개발자들이 전혀 의도하지 않았던 기능이었거든요.

공식가이드 북 어디에서 뮤탈뭉치기에 대한 개발자들의 설명이 없었어요.

이외에도 미네랄부스팅,벌처P컨 등등

원래 개발자들이 생각하지 않았던 것들이 많이 있습니다.

스타의 경우에는 버그도 하나의 기술이 되어서 잘 풀어나갔지만

실제 게임에서는 버그들이 참 골때립니다.

자동사냥버그니, 아이템확률버그니 등등

 

게임 같은 경우에는 '오픈베타'를 활용해서

게이머를 통한 테스트를 해볼 수 있습니다.

게임사 측은 예상치못한 버그를 잡아낼 수 있고

게이머는 신작을 미리 해볼 수 있으니 좋고.

하지만 모든 SW가 이런 오픈베타가 가능하지 않습니다.

예를들어 자율주행SW.

선뜻 오픈베타테스트 참여할 수 있을까요?

이건 SW가 잘못 설계되면 큰 사고로 이어질 수 있기 때문에

나서기가 쉽지 않습니다.

군사무기에 사용되는 SW는요?

보안이 철저해야하는 금융권SW는요?

그래서 필요한 것이 바로 SW테스트입니다.

 

테스트는 디버깅과 다르다

 

테스트는 디버깅처럼 '오류를 찾아낸다'라는 공통점은 있지만

"오류가 있다"라는 전제를 깔고 시작합니다.

내가 개발한 SW가 잘 돌아갈리가 없어!라는 마인드로

테스트코드를 작성하고 오류를 발견하는 것.

 

테스트는 세세하게 쪼갤 수록 좋다

영문 엔하위키에서 가져온 자료입니다.

요구사항 기획 구현 단계 중

각 단계에서 오류가 발생했을때 얼마나 지연이 되는지 보여주는 표입니다.

구현단계에서 잘못된 게 있으면 금방고쳐지지만

요구사항부터 잘못된 부분이 있다면

그거 고치는데에 엄청난 시간이 할애가 됩니다.

요구사항 그 부분 수정할려면

기획단계도 다시 봐야하고

그러면 구현단계도 다시 봐야합니다.

그래서 훌륭한 개발자들은 요구사항과 기획에 많은 시간을 할애한다고 하죠.

하지만 그럼에도 현실적으로

요구사항 분석에 시간투자를 많이해도

잘못된 것을 바로 찾아내기 어려운 경우가 많습니다.

최악의 경우에는 배포 바로 직전에 알게되는 경우도 허다합니다.

이런 테스트에 대한 가이드를 주는 모델이

바로 V모델입니다.

큰 요구사항부터 차근차근 설계해서 테스트하는 단계를 보여줍니다.

하지만 이 모델도 여전히 한계가 있습니다.

최종단계인 인수테스트를 가야지 사용자 요구 명세가 확실한지 확인할 수 있다는 것.

그 전까지 잘못된 게 있으면 모른체 지나갈 수 있습니다.

그래서 단계별로 세세하게 테스트를 거치는 페러자임으로

애자일 테스트가 있습니다.

쉽게발하면 작은 단위 하나하나 테스트하는 것.

즉, 단위테스트를 진행하는 것입니다.

단계별로 테스트를 거쳐가면서

"이 단계에서 이게 문제가 있구나"라는 걸 좀 더 빠르게 파악할 수 있습니다.

물론 이렇게 세세하게 테스트를 진행한다면

개발시간이 많이 소요가 되기 때문에 불편한 점도 있습니다.

그 대신 미쳐 예상하지 못한 버그에 대해서 확실하게 잡아가기 좋습니다.