Proven by Intelligence

문서 기반 검증, 왜 중요한가?

소프트웨어 검증 업무를 수행하다 보면 종종 이런 상황을 마주하게 된다.

“코드는 구현되어 있는데, 무엇을 기준으로 검증해야 하지?”

테스트를 수행하기 위해서는 정상 동작의 기준이 필요하다. 그리고 그 기준이 되는 것이 바로 요구사항 명세서, 설계서, 인터페이스 문서와 같은 개발 문서이다.

많은 사람들이 소프트웨어 검증을 단순히 테스트 케이스를 작성하고 실행하는 활동으로 생각하지만, 실제 검증의 시작점은 문서에 있다.

문서 기반 검증(Document-Based Verification)이란?

본 글에서는 요구사항 명세서, 설계서, 인터페이스 문서 등 개발 문서를 기준으로 수행하는 검증 활동을 '문서 기반 검증'이라고 표현하고자 한다.

문서 기반 검증은 요구사항 명세서, 설계 문서, 인터페이스 문서 등을 기준으로 소프트웨어가 의도한 대로 구현되었는지 확인하는 검증 방법이다.

검증자는 구현 코드를 기준으로 판단하기보다, 문서에 정의된 요구사항과 설계를 기준으로 테스트 케이스를 설계한다.

즉,

• "코드가 동작하는가?"

• "문서에 정의된 내용대로 동작하는가?"

를 확인하는 과정이라고 볼 수 있다.

문서가 완전하지 않다면?

이론적으로는 문서가 검증의 기준이 되어야 하지만, 실제 프로젝트에서는 문서가 항상 완벽하지는 않다.

검증 과정에서는 다음과 같은 문제를 자주 마주하게 된다.

• 요구사항이 모호하게 작성된 경우

• 특정 조건이 누락된 경우

• 설계서와 요구사항 간 내용이 다른 경우

• 구현 내용과 문서 내용이 일치하지 않는 경우

이러한 상황에서는 테스트 케이스를 작성하는 것 자체가 어려워진다.

특히 자동차와 같은 임베디드 시스템에서는 ECU 간 통신, 진단 기능, 시스템 통합 시험 등 여러 기능이 연계되어 동작하므로 문서의 명확성이 더욱 중요하다.

검증에서 발생하는 문서 이슈

예를 들어 Unit Design Specification에 특정 함수가 입력 값 범위를 벗어날 경우 예외 처리를 수행한다고 기술되어 있다고 가정해 보자.

하지만 허용 범위와 예외 처리 방식이 구체적으로 정의되어 있지 않다면 검증자는 기대 결과를 명확하게 정의하기 어렵다.

개발자는 입력 값을 무시하도록 구현할 수 있고, 다른 개발자는 기본값을 적용하도록 구현할 수도 있다. 반면 검증자는 오류 코드를 반환할 것으로 예상할 수 있다.

이처럼 문서의 모호성은 동일한 요구사항에 대해 서로 다른 해석을 유발하며, 불필요한 이슈와 재검증을 발생시킬 수 있다.

통합시험에서도 반복되는 문제

통합시험에서도 문서의 불명확성은 자주 문제가 된다.

예를 들어 A 제어기와 B 제어기가 CAN 통신을 통해 연동된다고 가정해 보자.

문서에는 "배터리 이상 상태 발생 시 상태 정보를 송신한다"라고만 기술되어 있다.

하지만 어떤 조건에서 이상 상태가 판단되는지, 어떤 CAN 메시지와 Signal 값을 전송해야 하는지, 수신한 제어기는 어떤 동작을 수행해야 하는지가 명확하게 정의되어 있지 않다면 검증자는 기대 결과를 판단하기 어렵다.

개발자는 특정 상태 값을 전송하도록 구현할 수 있고, 검증자는 다른 상태 값이나 동작을 기대할 수 있기 때문이다.

이처럼 통합시험에서는 인터페이스와 시스템 동작에 대한 명확한 문서가 검증 결과의 신뢰성을 좌우한다.

검증 과정에서 드러나는 문서의 가치

검증 과정에서는 코드 결함 뿐만 아니라 문서 결함도 함께 발견된다.

실제로 검증 단계에서 발견되는 문제 중 상당수는 구현 오류가 아니라 요구사항 또는 설계 문서의 불완전성에서 비롯된다.

따라서 검증은 단순히 소프트웨어의 품질을 확인하는 활동이 아니라, 개발 산출물 전체의 품질을 검토하는 과정이라고도 볼 수 있다.

검증자가 발견한 문서의 모호성이나 누락 사항은 향후 개발과 유지보수 과정에서 발생할 수 있는 문제를 예방하는 데 큰 도움이 된다.

좋은 검증의 출발점

테스트 자동화 도구와 검증 기법은 계속 발전하고 있지만, 검증의 기준이 되는 문서가 불완전하다면 검증의 효과는 제한적일 수밖에 없다.

명확한 요구사항과 일관된 설계 문서는 개발자에게는 구현 기준이 되고, 검증자에게는 평가 기준이 되며, 프로젝트 전체에는 의사소통의 기준이 된다.

특히 여러 시스템이 연계되는 환경에서는 문서의 품질이 곧 검증 품질로 이어진다.

실제로 필자가 수행하는 소프트웨어 검증 업무에서도 테스트 케이스를 설계하기 전에 요구사항과 설계 문서의 완전성을 먼저 검토하는 경우가 많다. 이는 검증의 출발점이 코드가 아닌 문서임을 보여주는 대표적인 사례라고 할 수 있다.

마무리

소프트웨어 검증은 단순히 코드의 동작 여부를 확인하는 활동이 아니다.

검증의 기준이 되는 문서를 이해하고, 문서와 구현 결과가 일치하는지 확인하며, 문서의 모호함과 누락까지 발견하는 과정이다.

실제 프로젝트에서는 요구사항 누락, 인터페이스 정의 부족, 예외 상황 미정의 등 문서 품질 문제로 인해 검증이 어려워지는 경우가 빈번하게 발생한다.

결국 소프트웨어 품질을 높이기 위해서는 코드 품질 뿐만 아니라 요구사항과 설계 문서의 완성도 역시 함께 관리되어야 한다.

검증은 코드의 오류를 찾는 활동인 동시에, 문서의 모호함과 누락을 발견하여 개발 품질을 향상시키는 중요한 과정이라고 할 수 있다.

신뢰할 수 있는 소프트웨어 품질은 체계적인 검증에서 시작됩니다.

MDS인텔리전스 소프트웨어검증센터는 자동차, 국방, 철도 등 다양한 산업 분야에서 축적한 검증 경험을 바탕으로 고객의 소프트웨어 품질 확보를 지원하고 있습니다.

3자 검증, 테스트 설계 및 수행, 검증 프로세스 구축 등 소프트웨어 검증 서비스에 대해 궁금하신 사항이 있으시면 언제든지 swtest@mdsit.co.kr로 문의해 주시기 바랍니다.