어떻게 하면 사람들이 즐겁게 테스트를 작성하도록 할 수 있을까?

프로젝트에서 프로덕트로

 제임스 루이스와 마틴 파울러는 마이크로서비스에 대한 논문에서 마이크로서비스의 특징의 하나로 프로젝트에서 프로덕트로의 패러다임 전환을 꼽고 있다.

 하지만 이는 마이크로서비스에 대한 것 만은 아니다. 소프트웨어의 품질과 기능 그 모든면에서 프로젝트에서 프로더트로의 관점 전환은 대단히 중요한 요소이다. 오늘 소개할 InfoQ의 기사는 바로 그러한 관점의 전환이 소프트웨어 개발과 테스팅을 어떻게 바꿔 놓을 수 있는지를 보여준다.

 자동화 테스트는 메트릭스의 모피어스가 건네주는 알약과도 같아서 일단 처음 어느 정도 고통스러운 시기를 거치게 되지만 한번 제대로 동작하기 시작하면 자동화 테스트가 없는 개발로는 두 번 다시 돌아가지 못한다. 하지만 그 첫 걸음을 어떻게 하면 고통 없이, 또는 적은 고통으로 성공시킬 수 있을까?

 자신의 개발 조직에 자동화 테스트를 도입하려고 하고 있거나 이미 도입하였지만 제대로 정착 시키는 데에 어려움을 겪고 있다면 이 기사가 큰 도움이 되리라 생각한다.

www.workyouenjoy.com

어떻게 하면 사람들이 즐겁게 테스트를 작성하도록 할 수 있을까?

원문 링크 : Leading a Culture of Effective Testing


 저는 제가 개발에서 운영까지 책임을 맞았던 최초의 시스템을 지금도 잘 기억하고 있습니다. 다행히도 설계에서 지원까지 모두 맡았습니다. 몇 년 후, 그 시스템 중 하나의 하위 시스템이 자주 사용되게 되었습니다. 지속적인 기능 추가 요청이 오기 시작했고 복잡성은 증가했습니다. 변경을 할 때마다 나는 주의 깊게 기존의 기능을 확인 했습니다 만 수작업으로 하는 검사는 시간이 걸리고 기능 추가에 따른 복잡성의 증가는 폭발적으로 늘어났습니다.

 다른 사람들과 마찬가지로 나는 자동 테스트에 대해 들어 본 적이 있었지만, 그 방법을 배울 시간이 없었습니다. 그러다가 시간적 여유가 생겼을 때, 나는 몇 가지 책을 읽고 그 방법을 배웠습니다. 그 방법을 현실의 일에 적용 한 결과, 성장함에 따라 변경이 어려워 졌던 서브 시스템의 문제를 해결하기 위해 자동화 된 테스트는 완전한 방법이라고 느꼈습니다. 어느 날 오후, 나는 자동차 드라이브 나가고 있었습니다. 시간에 여유가 생겼던 겁니다. 인터넷에 연결되지는 않았지만 테스트를 작성하는 데 필요한 모든 도구를 가지고 있었습니다. 며칠 후 수동으로 실시하고 있던 검증의 세세한 부분 대다수를 자동화했습니다. 시간 절약 효과는 엄청난 것 이었습니다. 몇 시간 이나 필요했던 테스트가 불과 몇 초 만에 끝나버렸습니다.

 그러나 시간 절약은 두 번째 효과였습니다. 내 머릿속의 모든 시나리오가 크게 변화했습니다. 만든 것에 대한 신뢰의 감각이 되살아 난 것입니다. 아직 복잡성이 증가하지 않는 새로운 시스템에 대한 신뢰와 비슷합니다. 새 릴리스를 할 때 마다 불안감이 머리속을 떠나지 않았습니다. 여러 번 확인 했음에도 불구하고 불안은 사라지지 않았습니다. 응용 프로그램의 릴리스에 따른 지원은 만든 사람이 책임을 져야 했기 때문에 본능적으로 릴리스를 꺼리게 되었습니다. 이러한 상황에서 자동 테스트의 도입은 불안감을 안심으로 바꿔주었습니다.

 테스트에 누락이 있으면, 간단하게 테스트를 추가하고 다시 누락 되지 않도록 했습니다. 자신감이 생기자 위험을 감수하고 새로운 기능을 추가 할 수 있게 되었습니다. 또한 더 이상 문제를 무서워하지 않고 가치를 제공하는 데 주력 할 수 있었습니다.

 수동 테스트의 경우 테스트 시나리오는 수동으로 주의 깊게 설계하고 수동으로 실행하며 수동으로 확인 해야 합니다. 게다가 머리 속에 남아 있는 시간은 길지 않아 쉽게 잊혀집니다.

 자동 테스트의 경우, 시나리오, 실행, 검증은 모두 프로그램에 의해 문서화 되고 자동화됩니다. 유일한 수동 절차는 실행 버튼의 클릭 뿐입니다. 기억에 의존 할 필요도 없으며, 유통 기한이 지난 문서를 의지하여 시나리오를 쫓아 수동으로 수행 할 필요가 없습니다.

 대부분의 개발자가 테스트 자동화의 가치를 인정하면서도 그 혜택을 향유 하는 데 에는 실패했습니다만, 나는 다행히도 장점을 누리기 위한 올바른 방법을 찾을 수 있었습니다.

책임

 만약 제가 테스트에 대해 책임을 지지 않았다면, 테스트를 자동화하는 시간은 없었을 것입니다. 이것은 매우 간단한 것입니다. 자신이 개발을 지원하는 시스템의 사후 지원을 담당하는 것으로, 나는 소프트웨어가 제대로 작동하는지 보장하는 데 큰 관심을 갖게 되었습니다.  오전 5시 전화 받고 일어나 시스템 장애를 해결하는 사태를 막기 위해 나는 문제점이 이월 되지 않도록 꾸준히 노력해 왔습니다.

 개발자야 말로 만든 것을 어떻게 확인 해야 할지 가장 잘 알고 있습니다. 어느 부분에 자신이 없거나 어디에 복잡성이 존재하는지 어디에 문제가 포함될 여지가 있는지 잘 알고 있지요. 개발자 이외에 이처럼 포괄적인 관점을 가지고 있는 사람은 없습니다. 개발자는 작업 자동화 전문가이며, 검증 작업 자동화의 적임자입니다.

 많은 개발자들이 개발 한 시스템의 사후 지원이 가능하며, 그 책임을 다른 사람에게 전달하고 싶어하지 않습니다. 뭔가를 만든 사람은 그것이 성공하는 것을 희망합니다. 우리가 할 수 있는 것은 개개인이 어떠한 것에 대하여 공헌하고 싶어 하는지 묻는 것입니다. 책임을 공유하고 개발자가 시스템의 사후 지원에 기여할 수 있도록 하는 것이 효율적인 테스트의 이점을 누리는 방법입니다.

제각각인 팀을 융합하다

 만약 조직이 소프트웨어 개발의 책임을 여러 팀에 분산 시키게 되면 테스트를 하는 것은 힘든 작업이 됩니다. 불행히도, 고객의 납품이 완료된 이후의 시점부터는 이러한 어려움이 일상화되어 버리게 됩니다.

 테스트가 다른 팀에 맡겨진 경우 대부분의 경우 수동 테스트입니다. 자동화되어있는 경우에도 유지 보수하기 어려운 엔드 - 투 - 엔드 테스트입니다. 엔드 투 엔드 테스트는 운영 환경과 동일한 환경을 설정 해 줘야 합니다. 또한 개별 부분을 잘라낼 수 없습니다. 또한 뭔가 잘못되면 많은 테스트에 영향을 주고, 의미있는 피드백을 실패로 부터 얻을 수 없게 됩니다. 응용 프로그램 업데이트를 비활성화 버리는 취성 엔드 투 엔드 테스트 코드를 정기적으로 업데이트한다면, 수동 테스트에 회귀하는 것은 자연스러운 것입니다.

 분리 된 테스터가 응용 프로그램의 낮은 수준을 테스트 하기 위한 능력과 지식을 가지고있는 것은 드문 경우입니다. 특히 효과적인 검증 될 필요가 있는 단위 테스트 수준의 것은 알 수가 없습니다. 단위 테스트는 시스템을 작은 단위로 분리하고 확인합니다. 이 수준에서는 코드와 애플리케이션에 대한 깊은 이해가 필요 합니다 만, 개발자 만이 이에 대한 지식을 가지고 있습니다. 만약 개발에서 분리 된 테스터가 이러한 단위 테스트에 대한 지식을 지니고 있다면, 그 테스터가 개발팀이 아닌 것은 이상한 일입니다.

 또한, 테스트의 책임이 전가되어 버리면 개발자에게 소프트웨어를 성공적으로 움직이는 것에 대한 책임이 없다 라고도 할 수 있습니다. 하지만 그러면 개발자에게 신뢰하지 않는다는 메시지를 보내 버리게됩니다. 이것은 최악의 마이크로 관리입니다. 우리는 확인 사항이 줄을 설 정도로 많은 새로운 기능을 개발하고 있습니다. 실제로 테스트를 하고 피드백을 하는 데 몇 일, 몇 주 가 소요될 것입니다. 작은 문제가 숨어 있던 것 만으로도 새로운 기능의 구현에 장애가 될 수 있습니다. 그리고 기능 구현이 지연하면 급격하게 진행이 악화되고 마는 것입니다.

 이렇게 개발과 테스트를 분리하는 것은 자연스러울 지도 모릅니다 만, 결과적으로는 테스터의 레이어가 두꺼워지고, 몇 번이나 확인을 하게 되어 버립니다. 나는 3 개 이상의 분리 된 테스트 단계를 가지고 조직을 알고 있습니다. 이 경우 전체 프로세스가 멈추었습니다. 하나의 경쟁 상대가 책임을 직접 개발자와 공유하는 방식의 장점을 발견 하게 되면, 상대적으로 다른 기업에 불리한 위치에 서고, 결국 경쟁에서 질지도 모릅니다.

 책임과 권한의 명확화는 효율적인 테스트를 하는 데 매우 중요합니다. 하나의 팀이 테스트 지원에 책임을 갖게 합니다. 책임 여러 팀에 분산 되어 있다면, 하나의 팀으로 통합 해야 합니다. 테스터가 개발자의 옆에서 일을 하게 하는 겁니다. 또는 각각의 멤버들이 테스터와 개발자 모두의 역할을 서로 확인하고 편견을 제거합니다. 개발자가 일부 단위 테스트를 작성하고 다른 테스트 팀에 전달하는 것이 아니라, 단위 테스트와 엔드 - 투 - 엔드 자동화 된 테스트를 할 것인지, 아니면 수동 테스트를 할 것 인지를 상황에 따라 전체적인 의견을 통해 결정 하도록 합니다.

 새로운 팀의 업무 초첨은 단일 기능 또는 관련된 몇 가지 기능에 한정 시키는 것이 좋습니다. 이렇게 하면, 전원이 함께 일하고 하나의 기능을 개발하고 테스트 할 수 있습니다. 서로 상관 없는 변경 요소를 한 팀에 처리 시킨 다던지, 대규모 변경의 대응을 개발 팀 테스트 팀, 지원팀 사이에서 몇 달에 걸쳐 이동하는 것이 아니라 하나의 팀으로 작은 릴리스에 필요한 모든 것을 수행 하고 1 에서 2 주 기간으로 작업합니다. 이 제한적인 포커싱에 의한 개발 방법은 실제로 생산성을 향상 시키고 있습니다.

 작은 변경을 실시하는 것으로, 고객의 의견을 신속하게 받을 수 있게 됩니다. 변화가 작기 때문에 테스트 환경이나 스테이징 환경도 쉽게 준비 할 수 있고, 외부 고객의 리뷰에 더욱 포커싱 할 수 있게 됩니다. 고객이 확인할 내용에 대해서도 모호함이 줄어듭니다. 피드백이 오는 것도 빠르게 되어, 피드백에 대한 대응도 늦지 않게 됩니다. 큰 덩어리보다 작은 변화가 더 테스트하기 쉽기 때문입니다. 빠르게 피드백을 받고 빠르게 변경하고 출시하여 다음의 작은 기능 세트로 이동합니다.

자동 테스트의 가치를 보여주다

 팀 개개인이 개발, 테스트 및 시스템 지원의 책임을 가지게 되면 두 가지 선택이 있습니다. 하나는 팀이 수동으로 테스트가 효율적이고 않는다는 것을 깨달을 때 까지 기다리는 것. 다른 하나는 도박을 피하고 팀을 교육하는 방법 입니다. 적당한 지침 없이 자동 테스트를 실시하는 데 몇 년이 걸립니다. 개개인이 일상적인 업무량에 치이고 있는 경우에는 특히 그렇습니다. 자동 테스트를 도입한다고 해도 학습하는 데 몇 년이 걸립니다. 그러나 전문가의 도움을 받아 테스트 자동화의 가치를 알리는 것으로,이 기간을 단축 할 수 있습니다.

 자동 테스트에 완전히 매료되어 충분한 성과를 올린 후, 나는 다른 사람들도 동참 시키고 싶다고 생각 하게 되었습니다. 먼저 데모를 실시하여 자동화 된 테스트 도구의 활용 방법을 설명했습니다. 하지만 이 방식은 실패 였다고 생각합니다. 직접 실제 프로젝트에서 자동 테스트를 실시 할 수 있도록 지원하는 것이 아니라 시험 방법을 가르쳐 버린 것입니다. 가르치는 것 만으로는 부족합니다. 테스트의 가치를 증명하는 유일한 방법은 팀이 실제로 책임 지고 있는 일에 대해 테스트를 통해 자신감을 키우는 것을 도와주는 방법 뿐 입니다.

 가장 효율적인 것은 자동화 된 테스트 기법을 실천할 수 있는 기회를 만들고, 복잡하고 오류 나기 쉬운 응용 프로그램에 적용해 보는 것입니다. 개발자는 모두 까다롭고 다루기 귀찮은 시스템을 최소한 하나는 가지고 있습니다. 경험을 통해 불안감을 자신감으로 바꾸는 체험만이 자동화 테스트가 개발의 일부로서 받아지도록 하는 유일한 방법입니다.

개인 개발자가 다음과 같은 것을 경험하면 도입은 더 수월하게 진행 되겠지요.

• 복잡성을 자동으로 테스트하는 것에 대한 신뢰.
• 테스트 주도 개발의 경우 코드를 작성하기 전에 테스트를 작성하여 소프트웨어 개발을 진행해 나가는 것.
• 의미 없는 테스트에 대해서 테스트를 자동화하는 것은 역효과. 이 트레이드 오프를 깨닫기 위해 몇 년을 낭비한다. 많은 자동화 된 테스트를 포기하게 되는 큰 원인.
• 도구가 자동 테스트의 부하를 획기적으로 낮출 것.
• 테스트는 소프트웨어의 변경과 기능 추가가 쉬워 기존 기능도 심플하게된다는 것.
• 기존 문제의 근본 원인 분석 수정에 테스트가 도움이된다는 것.
• 외부의 실시간 시스템과의 통합 등 수동 테스트가 불가능한 영역에서 자동 테스트가 효과를 발휘한다는 것.

개발자 툴 킷 중에서도 자동 테스트에 큰 가치가 있음을 증명하는 것은 간단합니다. 개발자가 자동​​ 테스트가 일을 개선해주는 것을 한번 경험하면 그 이후로는 단번에 가치에 대해 깨닫게 됩니다.

강제로 요구 하지 않기

 데모를 실시하고 자동화 테스트의 전파에 실패한 후, 나는 적어도 팀이 나를 따라 올 수 있는 상태를 만들고 싶다고 생각했습니다. 여기서 저는 또 다른 실패를 저지릅니다. 그것은 응용 프로그램의 일부에 대한 테스트를 쓰는 것을 의무화 한 것입니다. 이것이 실패한 것은 다음의 두 가지 이유에서 입니다.

•  제 자신이 너무 많은 책임을 지고 말아 버렸습니다. 뭔가 좋지 않은 일이 일어 났을 때, 늦게까지 남아있는 역할 이었는데, 그에 따라 많은 테스트가 내 부담이 되었습니다. 나는 잘 작동하지 않을 것 같은 시스템의 일부에 대한 테스트를 선택했습니다. 하지만 테스트 케이스를 전달 하는 과정에서 본래의 의미는 사라져 버렸습니다.
•  의미가 희석 되어 버렸으므로, 가치도 느껴지지 않습니다. 그리고 성급하게 테스트 케이스를 만들었습니다. 그 결과, 테스트 케이스의 질이 희생되었습니다. 이해하기 어렵고, 대충 적당한 , 때로는 부정확 한 사례가 되어 버렸습니다. 룰을 강제 하여 많은 테스트가 만들어 졌지만, 그 테스트가 쓸모 없다는 사실을 깨달았습니다. 목적을 잃어버린 테스트 작성은 벌칙 게임 같은 것입니다. 쓸모없는 테스트는 프로젝트에 유해한 요소가 되어 유지 보수 해야 할 코드의 양만 늘려버립니다. 또한 사용할 수 없는 시험은 장기적으로는 혼란의 씨앗입니다. 시간이 흐르면 의미 없는 테스트가 본래 시스템이 가져야 할 모습을 묘사하고 있는 것으로 둔갑하게 되기 때문입니다.

 책임을 공유하고 테스트 케이스의 장점을 근본부터 이해하게 된다면 그 이후로 프로그래머는 가치가 있는 테스트를 작성하기 시작합니다. 교훈은 매우 간단합니다. 즉, 강제하는 것은 피하라.

그 밖에도 몇 가지 피해야 할 사항들이 있습니다.

• 코드 커버리지 수준을 강제한다.
• 테스트 코드 커버리지는 테스트 케이스가 커버 하는 코드의 양을 측정합니다. 범위가 80 %라면 20 %의 코드는 테스트를 실행하여도 호출되지 않습니다.
• 코드 커버리지는 테스트하지 않은 영역을 손쉽게 찾을 수 있는 긍정적인 면이 있기도 합니다. 그러나 테스트의 품질을 보장​​하는 것은 아닙니다. 테스트 케이스의 효과는 수치로 측정 할 수 있는 게 아닙니다. 또한 응용 프로그램은 테스트 할 가치가없는 영역도 있습니다. 따라서 100 %의 커버리지를 제공하도록 지시를하는 것은 현명한 생각이 아닙니다.
• 코드 커버리지 수준을 강제하는 것은 쓸데없는 테스트를 많이 낳아 버립니다.
• 코드를 작성하기 전에 테스트를 작성하도록 지시한다. 즉 테스트 주도 개발 (TDD).
• TDD는 매우 중요한 기술입니다. 그러나 강제하는 방식으로는 진행하지 말아야 합니다. 응용 프로그램에는 TDD가 유효하지 않은 부분이 존재 하게 마련입니다. TDD의 가치를 나타내는 것은 좋은 것입니다. 그러나 개개인이 자신의 판단에 따라 실천 해야 합니다.
• 테스트 수를 강제한다.
• 이것은 코드의 라인 수를 지시하는 것과 같습니다. 의미가 없습니다.
• 시스템에 불필요한 테스트가 있다면, 과감히 제거해 나갑시다. 테스트 코드는 유지 보수 해야 하는 코드의 양을 늘립니다.

 이러한 강제에 의해 개발자는 난처한 상황에 빠지고, 쓸데없는 테스트가 태어나 시스템의 유지 보수 용이성을 저하 시킵니다.

장애물을 제거

 개발자가 한 번 자동 테스트의 가치를 실감 한 후에는 실천에 들어가는데 걸림돌이 되는 장애물을 제거하는 것이 중요합니다. 장애를 제거하여 수동 테스트의 단점을 제거 할 수 있습니다. 테스트를 자동화하는 것을 어렵게 하고 있는 원인은 어떤 것이 든, 자동 테스트 구축을 실시하지 않는 이유 중 하나에 지나지 않습니다.

장벽을 제거하기위한 도구는 많이 있습니다.

• 테스트 러너
• 테스트 러너를 사용하면 신속하게 테스트 할 수 있습니다. 개발자가 사용하는 개발 환경과 통합하면 좋을 것입니다. 개발자가 TDD를 실천하고 있다면, 코드를 작성하는 만큼 테스트를 쉽게 하고 싶어할 것 입니다.
• 코드 커버리지 측정
• 코드 검사는 개발자가 응용 프로그램을 얼마나 테스트하고 있는지 알려줍니다. 한층 더 테스트를 추진하기에 훌륭한 도구입니다.
• 지속적인 통합 (CI) 서버
• 개개인이 테스트 케이스를 실행하는 이외에, CI 서버를 사용하여 변경이 발생할 때마다 자동으로 테스트를 실시합니다.
• 테스트 전체를 실시 하는 것을 잊어서는 안됩니다. 안전망을 구축하는 것이 테스트의 가치를 높이는 것입니다. 안전망이 없어서 테스트가 무시 된 환경을 여러 번 본 적이 있습니다. 테스트가 작동 하고 있는지 않는지 조차 인식하지 못하는 경우도 있습니다.
• 테스트가 실패하면 즉시 알려주기 때문에 문제를 빠른 시간 안에 바로 잡을 수 있습니다.
• 개발자가 CI 서버를 신뢰하여 만든 테스트에 더 큰 가치를 인정하게 된다면 그 가치를 만끽 하기 위해 테스트를 빨리 만들고 싶어지게 됩니다.

 이러한 도구의 구입 비용을 가지고 고민하는 기업들을 여럿 보아왔습니다. 아이러니하게도 많은 도구의 비용은 개발자의 몇 시간 분 시급보다 낮을 것입니다. 효율적인 테스트를 실현하는 중요한 역할을 하는 도구의 이점에 대해 논하는 것은 시간 낭비입니다.

 지금 바로 실천을 통해 도구를 사용하여 오류를 제거합시다. 시작이 늦으면 늦을수록 손에 들어오는 가치도 작아 져 버립니다.

여유

 기법을 배우고 실천하는 데 필요한 여유도 테스트에 대한 장애 중 하나 입니다. 개발자가 여가 시간에 테스트를 테마로하고 배워주는 기대해야할까요? 아니면 일 동안 시간을​​ 확보하고, 이러한 학습을​​ 지원하는 편이 좋은 것일까 요.

 나는 오랫동안 다양한 테스트 기법의 학습과 적용에 종사하여 "자동 테스트 도구"어떤 때 유용 어떤 때 쓸모 있는지 본능적으로 알게 되었습니다.

개인에게 여유를 주고, 자동 테스트 기술의 연마를 지원합시다.

• 고 부하 일정을 피합니다. 바쁜 와중에 학습을 동시에 진행 하기는 쉽지 않기 때문입니다.
• 불필요한 작업은 중단합니다. 예를 들어, 수동으로 실시하는 테스트 케이스를 문서화하는 것입니다. 이렇게 하면 자동화 하는 인센티브도 생깁니다.
• 자동 테스트를 낭비라고 느끼는 고객 및 이해 관계자도 있을지도 모릅니다. 미신은 추방합시다. 이런 이야기에 의욕을 잃어서는 안됩니다.
• 무엇이 성공하고 무엇이 실패 했는 지를 자주 되돌아 봅시다. 모두가 배운 것을 공유하고 성과를 서로 치하 할 수 있도록 합시다.

성과에 주목하자

 내가 참가한 가운데 가장 효과적인 테스트가 행해진 프로젝트는 모두가 소프트웨어의 성과에 주목하고 있던 프로젝트였습니다. 어떤 보고서를 작성해야 할지 지시를 받는 것이 아니라 내가 원하는 비즈니스 성과를 이해하고 어떠한 보고서가 필요한 지를 결정하는 데 도움이 될 수 있었습니다.

 시스템의 어느 부분이 가장 비즈니스 성공에 기여하는지 이해하고 있었기 때문에 그 부분에 주력했습니다. 비즈니스의 바람직한 성과를 바탕으로 테스트 우선 순위를 정하고있었습니다. 또한, 성과의 관점에서 테스트를 설계하고 있었으므로, 테스트의 기대 값에 대해 고객이나 사용자에게 직접 설명 할 수있게되어있었습니다.

 이것은 테스트에서 최대한의 가치를 끌어낸 예입니다. 이것을 목표로 해야만 합니다. 비즈니스에 가치를 추가하지 않는 코드와 테스트를 억지로 만들어야 하는 것 처럼 우울한 것도 없습니다.

신뢰

 복통을 일으켰다고 합시다. 병원에 도착했을 때, 당신은 접수 계원에게 증상을 설명합니다. 접수 계원은 맹장 상단의 복부를 절개하는 의사에게 진찰을 요구합니다. 그리고 맹장을 절제하는 것을 전문으로 하는 의사도 부릅니다. 또한 절개 한 복부를 봉합 의사도 부릅니다. 당신은 회복실로 옮겨진 이후 의사로 부터 연락이 끊깁니다. 아직 복통이 있습니다. 다시 진찰 해 보니 하면 통증은 담낭이 원인이었습니다. 맹장은 문제 없었습니다.

 다행히도 우리는 이러한 세계와는 무관합니다. 의사의 업무는 내장을 제거하는 것이 아닙니다. 무엇보다 이렇게 하는 전문 능력은 가지고 있지만. 그들은 진찰 부탁 받아 주의 깊게 분석 한 후 해결책을 처방합니다. 수술의 경우 절개를 하고 배운 것을 바탕으로 진단을 확인합니다. 어떤 경우에도 올바른 길을 확보합니다. 수술 후에도 수술이 완벽하다는 것을 알 때까지 환자를 돌봅니다. 그리하여 안전하다는 확신이 들면 회복실로 보내집니다. 회복시에도 상황을 확인하고 회복을 지원하기 위한 조언을 준비합니다. 의사가 아닌 사람도 환자의 용태를 확인하고 있지만 궁극적으로는 의사가 환자의 회복을 담당합니다.

 만약 의사에게 자신의 생명을 맡길 수 있다면, 마찬가지로 자신이 사용하는 소프트웨어 개발자를 신뢰 하는 것도 가능하지 않을까요?

저자에 관하여

 Wes McClure 씨는 기술과 소프트웨어로 기업이 눈부신 성과를 달성 하는 것에 열정을 가지고 지원하고 있습니다. 소프트웨어 개발의 폭 넓은 경험을 바탕으로 비즈니스 목표에 부합하는 소프트웨어를 개발하는 방법의 개선을 실시하고 있습니다.  Full City Tech를 시작해 전문성을 활용하여 고품질의 소프트웨어를 신속하게 제공하고자하는 기업을 지원하고 있습니다.