소프트웨어 개발자로서 가장 큰 목표 중 하나는 고객에게 최대 가치를 제공하기 위해 제품 동작 이해를 극대화해야 한다는 것입니다. 개인 의견이지만 이를 달성하는 간단하지만 효과적인 방법은 개발자가 테스트 시나리오(TS)와 테스트 케이스(TC)를 만들어내는 것을 최소화하는 것입니다. 개발자가 테스트 시나리오를 생각하지 않는다는 의미보다는 기획팀과의 효과적인 의사소통의 열매로 얻어져야 한다는 의미입니다. 하지만 제품팀이 만드는 제품이 무엇인지, 어떻게 동작하는지에 대한 전반적인 이해만으로는 최상의 고객 경험을 제공하기가 쉽지 않습니다. 전반적인 이해는 개인의 모호한 해석이 들어가고 그 결과 취약한 테스트 시나리오가 나오게 됩니다. 취약한 테스트 시나리오와 제품팀의 효과적인 의사소통으로 나온 테스트 시나리오를 비교해보겠습니다. 😢취약한 테스트 시나리오 📄 스토리(Story) 유저가 앱을 실행했을 때 앱에서 피드를 볼 수 있도록 피드를 로드하고 싶다. ✏️인수 기준(Acceptance criteria) - 앱을 사용하는 유저 - 유저가 앱을 실행할 떄 - 피드가 표시된다 이러한 가정을 일반적으로 제품 기능의 “축소 버전” 또는 “고객이 해결해야 할 문제”로 생각합니다. 하지만 이러한 요구 사항은 큰 그림을 나타낼 수 있지만 본질적인 세부 사항은 보여주지 않습니다. 더 많은 질문을 통해 가정은 최대한 제거를 하고 효과적인 테스트 시나리오를 만들어내야 합니다. 취약한 테스트 시나리오를 바꿔보겠습니다. 😎개선된 테스트 시나리오 📄 스토리(Story) 피드를 보려는 고객의 요청 💡이야기(Narrative) - 온라인 고객의 입장(Wifi, 셀룰러 환경) - 앱이 최신 피드를 자동으로 로드하고 싶다 - 언제든지 친구의 최신 피드를 즐길 수 있도록 1️⃣ 인수 기준(Acceptance criteria) #1 - 고객이 인터넷 연결이 가능한 경우 - 고객이 피드 요청할 때 - 앱에서 서버를 통해 최신 피드를 표시해야 한다 - 언제든지 친구의 피드를 즐길 수 있도록 2️⃣ 인수 기준(Acceptance criteria) #2 - 고객이 인터넷 연결이 가능하지 않은 경우 - 하지만 캐싱 된 피드가 있는 경우 - 고객이 피드 요청할 때 - 앱에 저장된 가장 최신 피드를 표시해야 한다 3️⃣ 인수 기준(Acceptance criteria) #3 - 고객이 인터넷 연결이 가능하지 않은 경우 - 캐싱 된 피드가 없는 경우 - 고객이 피드 요청할 때 - 앱은 오류 메시지를 표시해야 한다 이렇게 개선된 시나리오를 코드로 만들 때 훨씬 더 고객의 경험을 생각한 유스 케이스가 나오게 됩니다. 고객에게 최상의 경험을 제공해준다는 것이 가장 큰 목표이지만 개발자 입장에서 이렇게 디테일한 테스트 시나리오가 개발 초기에는 비용이 많이 들 수 있지만 개발자 입장에서 개발해야 할 기능에 대한 명확한 이해와 고객의 문제를 명확하게 파악할 수 있습니다. 때로는 기술의 한계를 맞이할 수 있겠지만 이런 상황 역시 개발 초기에 파악한다면 더 나은 선택으로 이어질 것입니다. 소프트웨어 아키텍처, 설계가 중요한 이유는 한 번 정하면 바꾸기 어렵다는 중요한 이유가 있습니다. 그렇기 때문에 기획서 리뷰 단계부터 기획자와의 효과적인 소통을 통해 설계에 들어간다면 굿투그레잇 할 수 있을 것입니다!!!👍👍👍