개발자의 테스트 시나리오를 통해 보는 프로그래밍 씽킹
실제 제품이 완성이 되기전에, 제품을 사용하면서 발생할 수 있는 모든 경우의 수를 생각해 보는 과정은 제품의 완성도 뿐만 아니라 시장 경쟁력을 높이는데 매우 중요한 역량이 됩니다.
오늘날처럼 빠르게 변화하는 시장에서는 단순한 결점 하나가 제품이 소비자로 부터 외면 받기에 충분한 이유가 됩니다.
그럼 아직 개발도 되지 않은 제품에 대한 결함, 혹은 발생할 수 있는 모든 경우의 수를 어떻게 생각해 낼 수 있고, 또 그런 역량은 어떻게 만들어질 수 있을까요?
저는 이 이야기를 개발자가 프로그램을 개발하고난 후 테스트 시나리오를 바탕으로 수행하게 되는 테스트 과정을 통해 전달해 보려고 합니다.
‘세상에 믿을 사람 하나 없다’ 라는 말이 있습니다.
특히 비즈니스를 하는 사람에게서 ‘믿는 도끼에 발등 찍혔다.’ ‘정말 믿을 사람 하나 없다.’ 라는 말을 심심치 않게 듣게 됩니다.
저는 이 말이 앞으로 제가 얘기할 ‘테스트 시나리오’를 위한 가장 중요한 자세라고 생각합니다.
먼저 테스트 시나라오가 무엇인지 살펴보도록 하겠습니다.
소프트웨어에서 테스트 시나리오란 소프트웨어 테스트를 위해 작성된 문서로 설계된 입력값과 실행조건에 의한 기대 결과를 기록한 문서입니다.
쉽게 얘기하자면, 개발된 소프트웨어가 정상적으로 동작하는지를 테스트하기 위한 문서입니다.
테스트 시나리오에서 가장 주목해야 할 점은 고의로 실패/에러를 유도하는 비정상적인 케이스가 작성이 되고, 이를 테스트 한다는 것입니다.
앞서 말한 ‘세상에 믿을 사람 하나 없다’ 라는 말 처럼, 프로그램을 개발하고 테스트를 할 때는 그 누구도, 그 어떤 시스템도 믿지 말고 모든 경우의 수를 도출해서 테스트를 하는 자세가 가장 중요합니다.
잠시 제가 미국에서 프로젝트를 했던 경험을 얘기해 보려고 합니다.
저는 특정 프로그램을 개발하는 개발자로써 프로젝트에 참여를 하게 되었습니다.
저는 이때 굉장히 큰 충격을 받았는데요.
개발을 하기에 앞서 프로그램을 어떻게 개발해야 하는지를 기록한 개발명세서를 받았습니다.
이렇게 개발을 어떻게 해야 하는지에 대한 기능이 명시 되어 있는 개발명세서를 받는건 너무나 당연한 일입니다.
그런데 제가 놀란 건 개발명세서와 함께 테스트 시나리오를 전달 받았다는 사실이였습니다.
제가 지금까지 알고 있던 상식은 테스트 시나리오는 개발이 완료된 후 완료된 개발을 테스트 하기 위해 작성이 되는것이 테스트 시나리오였는데, 개발도 하기전에 테스트 시나리오를 받은 것입니다.
더욱더 놀란 것은 테스트 시나리오가 정말 너무나 완벽하게 작성이 되어 있었다는 것입니다.
제가 개발자로 일하면서 받았던 가장 큰 충격 중에 하나 였습니다.
테스트 시나리오를 받고 개발에 착수를 하게 되니까 테스트 시나리오에 작성된 모든 케이스를 통과하기 위한 코드를 무조건 작성을 해야 했고, 결국 내가 개발한 프로그램이 어떠한 테스트를 거칠 것이라는 것을 알고 개발을 하는 것과 모르고 개발을 하는것과 엄청난 차이가 있다는 것을 깨닫게 되었습니다.
일반적으로 우리나라에서는 테스트 시나리오는 프로그램 개발이 완료가 된 후 현업 혹은 컨설턴트, 때로는 프로그램을 개발한 개발자가 직접 작성을 하게 됩니다.
그나마 현업이 테스트 시나리오를 작성하면 다행인데, 프로젝트에 참여한 컨설턴트 혹은 개발자가 테스트 시나리오를 작성하게 되면, 이미 개발된 프로그램을 잘 알고 있기 때문에, 개발된 프로그램이 아무 문제 없이 통과되기 위한 테스트 시나리오를 작성하게 됩니다.
그리고 이미 프로그램을 사용해봤기 때문에, 어떤것은 되고, 어떤것은 안되는지 이미 잘 알고 있기 때문에 더더욱 테스트 시나리오는 방어적으로 작성이 됩니다.
이렇게 테스트 시나리오를 통과한 많은 프로그램은 실제 운영이 되면서 많은 문제를 발생시키게 됩니다.
그런데 제가 미국에서 경험한 것 처럼, 테스트 시나리오가 개발전에 미리 작성이 되니까, 테스트 시나리오에는 현업과 컨설턴트의 요구사항이 프로그램 구현 난이도와 상관없이 비즈니스를 기반으로 작성이 되었고, 개발자 입장에서는 테스트 시나리오를 이해하면 내가 개발할 프로그램을 이해하는데 굉장히 큰 도움이 되었습니다. 그리고 내가 개발한 프로그램이 통과해야 할 케이스가 무엇인지 명확해져서 당연히 개발된 프로그램 코드의 수준은 높아질 수 밖에 없었습니다.
테스트 시나리오는 이미 그 자체로 설계도와 같습니다.
테스트 시나리오를 제대로 작성하기 위해서는 개발할 제품에 대한 명확한 이해가 있어야 합니다.
그리고 그 제품을 사용하면서 발생할 수 있는 다양한 상황을 최대한 도출 할 수 있어야 합니다.
정상적인 상황 뿐만이 아니라 비정상적인 상황을 모두 반드시 포함해야 합니다.
실제 제품이 완성이 되기전에, 제품을 사용하면서 발생할 수 있는 모든 경우의 수를 생각해 보는 과정은 제품의 완성도 뿐만 아니라 시장 경쟁력을 높이는데 매우 중요한 역량이 됩니다.
오늘날처럼 빠르게 변화하는 시장에서는 단순한 결점 하나가 제품이 소비자로 부터 외면 받기에 충분한 이유가 됩니다.
그럼 개발자가 아닌 우리도 이러한 역량을 키우기 위해서 개발자 처럼 테스트 시나리오를 작성하는 훈련을 해야 할까요?
우리는 프로그래밍 씽킹을 통해 개발자가 아니여도 이러한 역량을 충분히 키울 수 있습니다.
프로그래밍 씽킹은 관찰-탐험-확장-세분화-발전 이라는 5단계로 이루어져 있습니다.
프로그래밍 씽킹 5단계
- 관찰단계 – 사물을 다각도로 살펴보기
- 탐험단계 – 가능한 모든 경우의 수를 찾아내기
- 확장단계 – 깊게 사고하고, 과정을 구체적으로 확장하기
- 세분화단계 – 과정을 쪼개서 여러과정으로 세분화하기
- 발전단계 – 각 과정을 다시 한번 세분화하여 확장하기
나는 20년이 넘는 시간을 IT에 종사하면서 훌륭한 프로그래머는 단지 소프트웨어 프로그램을 개발하는 역량을 넘어서 프로그램 뿐만 아니라 모든 문제에 대한 접근 방법 및 이를 해결하는 방법에 있어서 탁월한 모습을 보게 되었다. 그래서 프로그래머가 문제를 해결하는 방법에 대해서 관찰하고, 이를 비즈니스에 적용할 수 있는 방법을 고민하게 되었고 “프로그래밍 씽킹” 이라는 방법론을 만들게 되었다.
