🫒 '테스트 코드는 왜 만들까?' 등

'OLIVE LAB'는 오늘도 성장을 갈망하는 일잘러들을 위한 뉴스레터 입니다.
올리브영의 조직 성과와 조직 건강의 지속 성장을 연구합니다.

한 주간 인상깊게 읽은 비즈니스, 리더십, 매니지먼트, 조직문화 관련 아티클을
요약 정리해서 정성껏 담아 보내드립니다:D (마음에 드는 글에 '👍좋아요'도 눌러주세요)

✍️응원, 소감, 궁금하신 내용 그리고 함께 나누고 싶은 내용은 댓글로 남겨주세요.

테스트 코드는 왜 만들까? (Woody's Pick)

출처 : https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/

"개발 관련 이야기이긴 하지만 모든 역할자가 알아두면 좋을, 원활한 커뮤니케이션을 위한 기본 지식이 잘 정리되어 있어 공유하게 되었습니다. 좋은 테스트 코드는 사전에 장애를 막아주고 리팩토링 시에도 도움을 주기도 합니다. 어떤 테스트들이 있고 왜 사용하는 것인지 한번 같이 살펴보시죠 :)"

테스트 코드(Test Code)는 소프트웨어의 기능과 동작을 테스트하는데 사용되는 코드입니다. 소프트웨어 테스트는 소프트웨어의 결함을 찾아내고 수정하는 과정에서 매우 중요합니다.
테스트 코드에는 단위 테스트(Unit Testing), 통합 테스트(Integration Test), 시스템 테스트(System Testing), 사용자 인수 테스트(User Acceptance Testing)등 다양한 종류가 있으며, 각각의 테스트는 특정한 측면에서 소프트웨어를 평가합니다.
테스트 코드를 작성하면 개발자는 소프트웨어가 어떻게 작동하는지를 이해하고, 소프트웨어를 수정할 때 예상치 못한 부작용을 방지할 수 있습니다. 또한 개발자 간의 협업을 원활하게 하고 소프트웨어를 유지 보수하는데 필요한 문서화 작업을 줄일 수 있습니다.
단위 테스트(Unit Test)는 개별적인 코드 단위(보통 함수, 메서드)가 의도한 대로 작동하는지 확인하는 과정입니다. 각각의 코드가 정확한 입력값과 출력값을 반환하는지 확인합니다.
통합 테스트(Integration Test)는 서로 다른 모듈들 간의 상호작용을 테스트하는 과정입니다. 예를 들어 신규로 개발한 API 서버내의 DB 호출 함수가 데이터베이스의 데이터를 잘 호출하고 있는지 테스트하는 과정이라고 생각하면 됩니다.
통합 테스트를 수행함으로써, 전체적인 소프트웨어 시스템의 신뢰성과 안정성을 높일 수 있습니다.
테스트 코드의 긍정적인 요소들은 아래와 같습니다.
- 내가 무엇을 만들고 있는지 정확히 인지
- 리팩토링을 진행할 때 부담 덜어주기 : 테스트 코드가 있으면 수정 후에도 기능이 정상적으로 작동하는지 검증할 수 잇어 개발자는 불안감에서 벗어날 수 있습니다.
- 결합도와 의존성이 낮은 코드를 지향
테스트 코드의 장점은 다음과 같습니다.
- 코드 품질 향상
- 회귀 테스트
- 문서화
- 리팩토링 지원
테스트 코드의 단점도 존재합니다.
- 개발 시간 증가
- 불완전한 테스트 : 모든 시나리오를 고려한 테스트 코드를 작성하기 어려울 수 있습니다. 이로 인해 일부 버그가 테스트를 통과하게 되어 완전한 테스트가 어려운 경우가 있습니다.
- 오버 엔지니어링
- 유지 보수 비용
- 학습 곡선
제가 강조하고 싶은 테스트 코드 사용 이유는 "더 나은 개발자가 되기 위한 좋은 기회와 습관"을 제공한다는 것입니다. 저 또한 테스트 코드를 작성하는 과정에서 많은 도움을 받고 있습니다.

원문 보러가기

Product Owner가 피해야 할 7가지 주요 실수 (Eddy's Pick)

"PO의 역할은 복잡하고 미묘하고 어렵습니다. 과학과 기술과 예술의 만남과도 같습니다. 그러나 제대로 수행될 경우 고객이 사랑하는 훌륭한 제품을 만들어 낼 수 있습니다. 이 아티클은 PO가 피해야 할 7가지 실수를 소개합니다. 이를 반면교사 삼아 해야 할 7가지를 배울 수 있으며 또한, PO가 아니더라도 그들을 위해 무엇을 도와야 할지 생각해보면 좋겠습니다."

Product Owner(PO)는 이해당사자, 고객, 사용자를 만족시키는 역할을 하며, 제품이 올바른 방향으로 나아가도록 시장 조사와 데이터 분석을 합니다. 그들은 스프린트의 작업에 대해 팀과 밀접하게 협업하며, 향후 스프린트를 위한 새로운 사용자 스토리를 지속적으로 제공합니다.
다음 스프린트까지 기다리지 않고, 진행 중인 스프린트에 변경사항을 반영합니다 : 스프린트가 시작된 후에는 개발 팀에게 작업 내용이 변경되지 않을 것이라는 약속을 지켜야 합니다. 이는 고객이나 이해당사자들이 생각을 바꾸거나 새로운 요구사항을 제시하더라도 마찬가지입니다. 중요한 변경사항이라면 스프린트를 중단할 가치가 있지만, 그렇지 않은 경우에는 그저 시급해 보이는 일로 스프린트를 중단하지 않아야 합니다. 다음 스프린트 플래닝에 반영해야 합니다.
스프린트 회의에 참여하지 않습니다 : PO가 스크럼 회의에 참석하지 않으면 팀의 개선이 어려울 수 있습니다. PO의 참석은 개방성을 나타내며 팀원들도 개선을 추구하도록 격려합니다. 이 점을 이해하고 스프린트 회의에 참여해야 합니다.
팀에게 '어떻게'를 알려주기 : PO는 팀에게 구체적으로 어떻게 제품을 만들어야 하는지 지시하는 것이 아니라, 무엇을 만들어야 하는지를 알려주는 역할을 합니다. 이를 통해 팀은 주어진 목표를 달성하는 다양한 방법을 탐색할 수 있습니다. 즉 팀에게 '어떻게'가 아닌 '무엇'을 이야기 해야 합니다.
모든 요구에 '예'라고 대답합니다 : PO는 많은 요구를 받게 됩니다. 하지만 모든 요구에 '예'라고 대답하면, 다른 중요한 항목에 '아니오'라고 말해야 할 수도 있습니다. 따라서 필요한 경우 '아니오'라고 말하는 능력이 중요합니다.
단기 목표에만 집중합니다 : PO는 단기적인 스프린트 목표뿐만 아니라 장기적인 제품 목표를 설정해야 합니다. 이를 통해 우선순위를 결정하고, 항상 당장 중요한 것만 추구하는 것이 아니라 장기적인 성공을 위해 필요한 작업을 진행할 수 있습니다. 즉, 장기목표를 고려하여 우선순위를 결정해야 합니다.
작업을 잘 수행하는데 필요한 권한이 없습니다 : PO는 개발 프로세스를 지연시키지 않기 위해 신속한 결정을 내려야 합니다. 이러한 결정은 나중에 상급자나 조직 내 다른 사람에 의해 번복되어서는 안 됩니다. 의사 결정이 지속적으로 PO가 아닌 타인에 의해 이뤄진다면, 팀원들은 PO의 결정을 잠정적인 것으로 생각하기 시작합니다. PO는 필요한 권한을 갖지 못할 경우, 그 문제를 해결하기 위해 상급자와 대화를 나눠야 합니다. PO가 결정을 내리고 책임을 명확히 해야 합니다.
피드백을 무시하고 자신의 비전에 과도하게 집착합니다 : PO는 고객, 사용자, 이해당사자, 개발자 등으로부터의 피드백을 열린 마음으로 수용해야 합니다. 자신의 비전에 과도하게 집착하면 중요한 피드백을 놓칠 수 있습니다. PO는 모든 제안을 수용할 필요는 없지만, 피드백을 경청하면 좋은 제품이 훌륭한 제품으로 발전할 수 있습니다. 열린 마음으로 피드백을 들어야 합니다.

원문 보러가기

"할일 이론" 파괴적 혁신을 만들어내는 법 (Chad's Pick)

"클레이튼 크리스텐슨 교수는 파괴적 혁신이라는 단어의 열렬한 주창자이자 전파자입니다. 파괴적 혁신 이론으로 엄청난 인지도를 갖게 됩니다. 하지만 여전히 고민이 하나 있었는데요. 그 유명한 파괴적 혁신 이론도 어떻게 혁신을 만들어 낼 것인지는 답을 해주지 못한 거죠. 그런 그가 혁신을 만들어 낼 수 있는 이론을 제시합니다 ."할 일 이론"이라고 부릅니다. PO에게도 인사이트를 줄 수 있는 내용이라 함께 공유해봅니다. "

“할일 이론”의 핵심은 아주 간단한 전제에서 출발합니다. 고객은 제품/서비스를 구매하는 거싱 아니라 발전을 이루기 위해 제품/서비스를 생활 속에 도입합니다.
자동차 통근을 하는 구매자에게 맥도날드의 밀크쉐이크는 “허기의 충족, 차안에서 먹을 정도의 편리성, 지루한 자동차 통근의 무료함 제거”의 발전을 이루기 위해서 도입하는 것이고 오후의 밀크쉐이크를 도입하는 이유는 또 다르다.
할일은 구체적인 상황과 관련하여 정의되며, 성공적인 해결안도 거기에서 나옵니다. 따라서 상황에 대한 정리는 할일을 정의하는데 필수적입니다.
그에 비해 전통적인 마케팅에서 말하는 욕구는 포괄적입니다. “먹고싶다”,”건강하게 살고 싶다”는 중요한 욕구지만 막연한 방향제시에 머물게 됩니다.
할일 이론을 적용은 “할일 적용” “할일 정의 프로세스”, “소비자들의 고용과 해고”, “할일 설명서” 4가지 사항이 필요합니다.
할일 사냥은 고객의 생활 속에서 미해결 상태로 남겨진 일을 발견하는 것입니다. 이 때 아무것도 하지 않는 사람은 해결안을 찾지 못해 아무것도 하지 않는 것으로 단초를 제공할수 있습니다. 부정적인 일을 대신하는 것도 이노베이션의 기회가 된다.
할일 정의 프로세스는 4가지 질문을 대체할수 있습니다. “고객은 어떤 발전을 이루려고 하는가?”. “고객이 처한 갈등 상황은 무엇이며 그 속에서 발전을 가로막고 있는 걸림돌은 무엇인가?”, “어떤 보상적 행동을 통해 갈등과 걸림돌을 보완하고 있는가?”. “그렇다면 고객의 할일은 무엇인가?”
소비자의 고용과 해고- 소비자들은 새로운 해결안을 고용하기 위해서는 현재의 보상적 행동이나 차선책을 해고해야 합니다. 따라서 새것의 매력은 옛것의 관성과 새것의 불안의 총합을 압도할 정도로 강력해야 합니다.
할일설명서 - 위 할일 구성요소를 토대로 할일 설명서를 작성하고 올바른 체험을 제고하는 계획을 세워둔다면 이노베이션의 구체적 행동 지침이자 청사진이 명확해빚.

원문 보러가기

🫒 '테스트 코드는 왜 만들까?' 등

소프트웨어 테스트는 소프트웨어의 결함을 찾아내고 수정하는 과정에서 매우 중요합니다.

테스트 코드는 왜 만들까? (Woody's Pick)

Product Owner가 피해야 할 7가지 주요 실수 (Eddy's Pick)

"할일 이론" 파괴적 혁신을 만들어내는 법 (Chad's Pick)

다가올 뉴스레터가 궁금하신가요?

이번 뉴스레터 어떠셨나요?

댓글

이전 뉴스레터

다음 뉴스레터

다른 뉴스레터