brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 호뎡 Jul 18. 2024

SW 결함 예지력을 높이려면?(블랙박스 테스팅)

개발자와 실 사용자는 확실히 다르다.

보통 소프트웨어 아키텍처라고 하면 무엇이 떠오르시나요?

아시는 분들도 계실 거고 만들어보지 않으신 분들도 물론 있으시겠죠...!

좀 똑똑한 개발자분들은 프로젝트의 개요를 듣고 아키텍처나 코딩 로직을 바로 연상해 보시는 분들도 계세요.

저는 소프트웨어 아키텍처를 무려 3년 동안이나(.....) 다른 거로 착각하고 살았었습니다......

~~모듈 전송 사항? 그게 뭐지? 먹는 건가?~~

그렇다면, 화이트박스 테스트를 진행한다고 하면 소스코드를 열어볼 텐데, 이를 통해 얻을 수 있는 정보가 무엇일까요?

바로 코드의 짜임새입니다. 내부 구조의 얽히고설킨 관계를 직접 확인해 볼 수 있는 것이죠.

그렇다면 화이트박스 테스트는 소프트웨어의 컴포넌트와 내부 구조의 성격을 파악해서 테스트를 설계하겠죠?

그래서 이를 구조 기반 테스트 설계를 진행한다고 합니다...!

여기서, 화이트박스 테스팅은 개발자가 진행하는 게 효과적일 수 있습니다.

왜냐하면 코드 설계자 그 자체가 코드의 성격 파악을 가장 잘하고 있는 사람이니까요...!

다만 업로드가 진행될수록 시스템에는 더 많은 기능이 추가될 것인데.... 문제는 이를 개발자만의 영역에서는 해결하기 힘들 정도 일이 커지는 경우가 많다는 것입니다..!

때문에 부랴부랴 시스템 내놓기 전에 애뮬레이터 돌려서 직접 기능들을 하나하나 확인해 보곤 하죠.... 버전이 올라갈수록 기능의 영역은 걷잡을 수 없이 커지고 사람은 필요해지는데 오류는 감당할 수 없어서 사용자들의 불만이 점점 늘어나기 시작합니다....

개발과 동시에 론칭 이후에도 출시 시스템의 기능들을 하나하나 점검할 수 있을까요?

감당하실 수 있겠냐고 물었습니다.

비교적 초반 인력이 많이 부족한 스타트업에서 이런 문제가 많이 발생하는 것 같더라고요.

무작정 시도하는 건 추천드리지 않습니다. 그렇지만 기능 테스트는 해야 하는데... 조금 더 효율적인 방법이 있지 않을까요? ㅎㅎ

다들 화이트박스 테스트란 말을 어디서 들으셨나요? 관련 수업을 들으시는 분이라면 수업 중에 들으셨을 수도 있겠지만, 자격증 공부하시는 분들도 많이 접하셨을 거예요.

그러면 자연스럽게 따라오는 단어, 블랙박스 테스트도 들어보지 않으셨나요?

의미도 그에 대응하듯이, 코드를 열어보지 않고 실행하는 테스트라는 의미가 있죠.

소스코드를 오픈하지 않고 수행되는 테스트는 각 기능이 정상적으로 작동하는지 입증하는 단계로 소프트웨어 인터페이스에서 실시되는 기능 테스트가 주를 이루게 됩니다. :)

여기서 핵심은, 화이트박스 테스트가 구조기반이라면 블랙박스 테스트는 무엇을 기반으로 할까요?

블랙박스 테스팅이 필요한 이유는 바로 명세서에 정의된 기능. 즉 요구사항 명세서를 통해 결함 발견에 대한 실마리를 잡아내기 훨씬 수월하기 때문인데요,

요구사항 명세서가 정확하고 세부적일수록 이를 통해 소프트웨어가 어떤 기능을 수행해야 하는지 명확히 이해할 수 있기 때문에 정확한 테스트 케이스를 작성할 수 있겠죠?

그래서 명세 기반 테스트를 진행하기 위해서는 블랙박스 테스트가 필요합니다!

기능문제나 호환성 문제, 성능문제 등 하필 고객이 앱을 사용중일 때 오류가 발생하면 일이 커져버리니까 블랙박스 테스팅을 철저히 수행하는 것이 중요하다고 볼 수 있는 것이에요 :0

사실 구조적 테스팅도 특정 유형의 구조에 대한 커버리지를 평가하는데요,

커버리지는 저번에 말했듯이 특정 부분이 테스트된 정도이구요, 이는 테스팅이 충분히 수행됐음을 측정하는 것이 목적이에요.

그래서 구조 기반 기법도 커버리지 방식이 많아요.

구문 테스팅과 커버리지, 결정 테스팅과 커버리지, (다중) 조건 테스팅과 커버리지 등.....

아직은 감이 잘 잡히지 않지만 일단은 구조 기반 커버리지를 쌓는 데 의미가 있다고 볼 수는 있겠죠?

명세 기반 기법도 마찬가지로, 명세서를 기준으로 한 분석이나 테스팅 방법이 여러 가지인데,

이게 참 흥미롭습니다...!

시스템에 이벤트나 행위에 집중한다던지, 어떤 입력란에 확실한 값이 아닌, 이도 저도 아닌 애매한 위치에 있는 값을 일부로 집어넣는다던지... 분기점에서 분기에 따라 정말 일관되게 동일한 결과를 내는지 등..... 기능 적으로 시스템의 결함이 날 확률이 높은 부분을 집중 공략 합니다!!

이게 바로 블랙박스 테스팅의 매력이죠. ٩(ˊᗜˋ*)و

화이트박스 테스팅이랑은 다르게 변수, 이례적인 상황을 많이 발견할 수 있고 완전 실 사용자의 관점에서 사용해 보기에 해당 테스트는 아무리 만족스러운 시스템일지라도 어디서 말썽을 부릴지(?) 예측이 도저히 불가능해서 지속적으로 유지해야 합니다...!

시스템이라는 게 아주 완벽해 보일지라도 허점은 분명히 존재하거든요.