포토/동영상 (1)
|
초창기 소프트웨어 개발 방법은 건축과 많이 닮아있습니다. 아직도 많은 건축 용어가 사용되고 있죠. 소프트웨어 개발 방법이 점점 고도화됨에 따라 개발 프로세스도 다양해지고 있습니다. ‘테스트’가 가장 많은 변화를 보이고 있죠.
기존 프로세스-폭포수 모델-대로 하면 테스트는 개발 프로세스의 뒷부분에 놓여야 합니다. 무언가 만들어지고 나서 확인하는-건축으로 말하면 감리 과정이겠죠- 것이니까요. 하지만 지금은 테스트 모듈부터 만들고 확인 후, 실제 모듈을 개발하기도 합니다. TDD(테스트 주도 과정)이라고 하죠.
이 책은 전반적인 테스트에 대해 설명해 주고 있습니다. QA나 전문테스터가 아닌 개발자가 행해야 할 테스트를 다루고 있습니다. 개발자는 코딩으로 임무가 끝나는 것이 아니라, 자신의 코드에 대한 검중까지 완료해야 합니다. 급하게 코딩만 해놓고 테스트는 나몰라라 하는 시대가 아닙니다.
시프트-레프트 테스트에 대한 설명입니다. 품질 검증을 마지막이 아닌 개발 과정에서 테스트하는 것을 뜻합니다. 테스트 과정을 자동화하고 지속적 통합, 배포 단계에서 실행합니다. 이를 통해 빨리 오류를 찾아내고 수정할 수 있습니다.
테스트가 중요하게 여겨지게 된 것은 애자일 덕분(?)이기도 합니다. 빠른 개발주기는 테스트 또한 짧고, 빠르게 진행되어야 합니다. 그렇기에 테스트를 테스트 담당자에게만 맡기는 것이 아니라 개발자도 자신의 코드에 대한 테스트를 진행하여야 합니다. 자신의 제품에 대한 책임, 장인 정신이 필요하다고 할 수 있겠죠.
시프트-레프트 테스트를 위한 요건입니다. 명확한 요구사항, 심플한 클래스/함수, 단위/통합 테스트 실행, 코드리뷰. 개발에 대한 이해가 없는 비즈니스 담당자들에게 이 부분에 대한 설명이 가장 어려웠습니다. 그냥 빨리 만들어서 보여달라고 합니다. 보여주면...수많은 추가, 수정, 삭제 이슈가 만들어지죠. 이런 변경을 위해서도 꼭 시프트-레프트 테스트 적용은 필요합니다.
요즘음 대부분 MVC 모델로 개발을 하고 있죠. 테스트를 하면서 가장 곤혹스러운 부분이 바로 ‘뷰'입니다. 다른 부분은 다양한 테스트 모듈과 자동화가 가능하지만 뷰 부분은 상당히 까다롭습니다. 그렇기에 저자는 뷰를 명확히 분리하고, 분량을 적게 하라고 권하고 있습니다.
테스트를 자동화하고, 미리 해야 하는 분명한 이유를 잘 보여주는 그림입니다. 모두 개발한 상태에서 마지막 시스템 테스트에서 버그가 발생하면-이 단계에서는 많이, 그리고 큰 이슈의 버그가 발생하더군요- 다시 처음부터 하나하나 확인해야 합니다. 이런 불상사를 막기 위해서라도 테스트는 자주, 짧게 진행할 수 있어야 합니다.
이 책은 ‘개발자'를 위한 테스트 책입니다. 개발 단게에서 놓쳐서는 안 될, 꼭 알고 있어야 할 다양한 테스트 방법을 설명하고 있습니다. 막연했던 테스트가 이제는 조금 명확하게 보이네요. 단위/통합 테스트만으로 아쉬움이 많았는데 더 다양하고 확실한 테스트 방법을 적용해 봐야겠습니다. |
|
근무하는 곳이 대학이라 다양한 프로젝트 경험은 없지만, 지금 몸담고 있는 대학에서 최근에 약 3년에 걸쳐 차세대시스템을 구축했고, 오픈한지 2년정도 되었습니다. 책에 설명된 다양한 용어들이 쉽게 와닿지는 않았지만, 소프트웨어의 품질은 초기에 결정된다는 문구는 정말 와닿았습니다. 차세대시스템 개발시, 프로젝트 규모 대비 인원이 부족해서 깊이 있게 신경쓰지 못한 업무가 몇가지 있는데, 물론 테스트도 초반부터 신경을 많이 쓰지 못했었습니다...오픈하고 나니..버그 투성이였습니다. 지금도 계속 수정중입니다. 어떤 프로그램은 통으로 다시 만들고 있습니다.
그만큼 초반에, 조금씩 작게 쪼개서 테스트를 하는 것이 얼마나 중요한 것인지 알게 되었는데, 이책을 통해 다시 한번 강력하게 느낄 수 있었습니다. 소소코드가 긴 것도 버그의 주범이 될 수 있다는 것. 최근에 자주 변경한 소스코드에서 버그확률이 높다는 것. 모두 저 역시 경험한 내용이었고, 머리속으로만 두리뭉실하게 알고 있던 것이 이 책에 정리되어 있어서 좋았습니다. 또한 다양한 테스트 기법들을 소개하고 있는데, 사실 지금 제가 유지보수하는 개발환경에서 적용하기에 쉽지는 않겠지만 이 책을 통해 개발자가 어느 시점에 어떤 방식으로 어떻게 테스트를 해야 하는지에 대한 이론을 익힐 수 있어서 도움이 되었습니다.
|
|
개발자에게 필요한 서적 입니다. 이책은 개발자를 위한것이라기보다도 PM에게도 필수적인 책입니다. 언어의 관점에서 현대에 들어와선 코딩 한페이지 내에서 이루어진 |
|
네이버 블로그 리뷰: https://blog.naver.com/rock1192/223034597392
경력이 쌓여가면서 점점 더 테스트에 대한 중요성을 느끼고 있다 개발자로 일하면서 신규 프로젝트를 개발하기도 하지만 기존 서비스를 유지보수하거나 개선하는 작업이 훨씬 더 많다고 느끼고 있다 기존 서비스를 유지보수하거나 개선할때 기존 서비스의 테스트 환경이 어떻게 갖춰져있냐 그리고 서비스의 어플리케이션 구조와 아키텍처에 따라 유지보수나 개선작업을 좀 더 수월하게 진행할 수 있다 어플리케이션에 테스트코드가 존재하지 않고 오로지 외부에서 API를 호출해서 테스트하는 것에 의존하고 있는 경우 보통 API를 분석해보면 다수의 클래스가 매우 거대하고 강하게 의존하고 있으며 역참조하고 있을 뿐만 아니라 중첩 if와 for문을 남발하여 코드의 복잡도가 매우 심각한경우가 대다수이다 이런 경우 코드를 유지보수하기가 매우 힘들 뿐만아니라 트래픽이 적을때는 크게 문제가 되지 않을 수도 있지만 트래픽이 증가 하면 어김없이 장애기 발생하고 장애의 원인을 추적하고 대응하기가 쉽지가 않다 그리고 코드의 복잡도로 인해 새로운 기능을 추가하기가 매우 어렵고 기능을 추가할때마다 버그가 발생하고 테스트하기가 매우 어렵다 거대한 클래스들과 서비스간의 의존성 때문에 어떠한 코드를 추가한다고 하면 수많은 의존성을 가진 서비스들을 모두 다 수정해야되 수정범위가 많아지고 이는 또 버그가 발생 요인이 된다 이 책은 이런 잘못된 구조의 서비스 개발을 방지하고자 조기에 서비스의 품질을 올리고 좀 더 수월하게 테스트할 수 있는 좋은 방법들에 대해서 알려주고 있다
시프트 레프트란 소프트웨어 개발 과정과 관련한 접근법으로, 제품이나 프로세스 등의 전체 개발 과정에서 품질을 향상하는 중요한 활동(모델)을 최대한 조기에 설계하고, 코딩 단계에서도 수행하는 전략이다 그 결과, 비용 대비 효과를 높이고 품질 측면에서 다양한 장점을 누릴 수 있다
스크럼의 특성
조기 품질을 보증하는 몇 가지 요건
각 품질의 측면을 고려해 빠르게 실행한다!
단위 테스트를 수행하지 않는 많은 조직에서는, 당연하지만 설계서도 작성하지 않는다 그런 경우 UML을 사용해서 거대한 설계도를 작성하라고 하지는 않지만, 적어도 클래스 다이어그램과 시퀀스 다이어그램만은 작성하라고 권한다 클래스 다이어그램이 있으면 큰 클래스를 방지할 수 있고, 리팩터링의 효과도 시각화할 수 있다
소프트웨어 개발 시 수행하는 테스트 목록
오리지널 워터폴 모델(순차 모델) 소프트웨어
개발을 시작하기 전에 단위 테스트가 코드의 정확성을 확인하는 테스트인지, 혹은 단위 기능에 관한 테스트인지를 명확하게 해야 한다
복잡도(complexity)는 그 수치에 따라 소프트웨어의 유지보수성(maintainability)을 측정할 수 있다고 알려져 있다 복잡도가 높을 수록 유지보수성은 낮아지고, 복잡도가 낮을수록 유지보수성이 높아진다
현장은 회의 자료 작성이나 버그 수정 등에 쫓기면서 이미 지쳐 있다 그런 와중에 막대한 분량의 단위 테스트 업무를 추가할 여유는 조금도 없다 상당수의 현장에서의 현실이며, 이런 소프트웨어 개발 현장은 암울한 상태에서 벗어날 수 없다 소프트웨어 개발 현장에는 이러한 비효율성의 문제뿐만 아니라 경영진의 문제도 있다 애초에 100%의 소프트웨어 품질이란 존재하지 않다. 특히 현대의 소프트웨어는 20년 전에 비해 훨씬 복잡해졌다 그런데도 여전히 '버그를 완전히 없애자'고 말하는 회사들이 있다. 버그는 완전히 없앨 수 없으며, 소프트웨어는 여전히 중간에 동작이 중단되는 행업(hang-up) 현상을 겪는다 이러한 버그는 물론이고 소프트웨어가 중단되는 행업 역시, 소프트웨어가 사용자가 바라는 기능을 충분히 제공하기만 한다면 그렇게 크게 문제가 될 일은 아니다 그런데도 크게 중요하지도 않은 세세한 테스트를 하거나 작은 버그를 수정하느라 엔지니어들은 지쳐간다 개선이란 현재의 업무를 효율적으로 수행하고(잔업을 줄이고), 동시에 품질을 높이는 것이다 현재의 업무를 줄이지 않으면서 태스크를 추가하는 것은, 소프트웨어 개발에서의 개선이라고 말할 수 없다
최근 버그가 어디에서 발생하는지 알게 되었다 소프트웨어 구조상의 문제가 아니라 '일정 기간에, 특히 최근에 여러 차례 변경되었거나, 그 변경 횟수가 많은 파일에서 버그가 발생'한다 그러한 논문이 발표된 뒤에 많은 파생 논문도 발표되었다 결국 대부분의 버그는 소스 코드 파일의 약 10~20% 부분에서 발생한다는 것이다
고전적인 방법에서는 파일 변경 횟수만 고려하지만, 단위 테스트를 수행하는 우선순위의 지표로 파일 행 수의 길이를 추가 한다 파일의 최근 변경 횟수가 많고 행 수가 긴 것부터 단위 테스트를 수행하는 것이 바람질하다는 사고 방식이다 실제로 파일 행 수의 길이는 버그 밀도와 두 번째로 높은 상관관계가 있는 것으로 알려져 있다 그 방법만으로는 부족하다고 판단해 복잡도라는 요소를 추가한다 복잡도와 코드 행 수의 상관관계는 사실 복잡도와 버그 밀도의 상관관계보다 명확하다 파일 단위에서 전체 복잡도 수치는 어떤 의미에서 파일 행 수의 길이와 등가라고 생각할 수 있다
코드가 긴 파일은 규모가 큰 클래스이거나, 깔끔한 구조를 만들지 못해 어디에도 둘 수 없는 함수들의 쓰레기통처럼 변해버린 경우이다 개발자 자신도 물론 그런 파일이 있다는 사실을 납득하지 못하면서도, 마음의 여유가 없다보니 깔끔하게 정리할 수 없는 함수 그룹이 많아질 때도 있을 것이다 그러한 파일을 둘로 자름으로써 개발자들은 분명한 기회를 얻는 경우가 많다 대부분의 경우 많은 개발자는 무턱대고 파일을 자른 채 두는 대신 프로그램 전체를 깔끔하게 만든다
소프트웨어 품질을 보증하기 위해서는 반드시 리팩터링을 해야 한다고 생각한다(하지만 필수로 수행하지 않는 기업이 아직 많아 장벽으로 작용한다) 리팩터링을 하지 않으면 조기/애자일 품질을 보증할 수 없다 리팩터링의 두 가지 흐름
갑자기 복잡한 코드를 대상으로 리팩터링에 도전하고자 코드를 변경하는 것은 그저 무모한 작업일 뿐이다 먼저, 복잡한 관계를 테스트할 단위 테스트를 작성한다 리팩터링에 관해 다음과 같은 사항에 주목한다
디자인 패턴 중 가장 유명한 것은 에릭 감마등이 쓴 책 GoF의 디자인 패턴에서 설명하는 패턴들이다 에릭 감마는 23가지 디자인 패턴을 다음과 같이 정의했다
23가지 디자인 패턴을 충실하게 모두 적용하기란 어려우며, 그저 몇 년 정도의 개발 경험뿐인 개발자에게 그것을 요구하는 것도 무리한 일이다 하지만 신입 개발자가 이러한 디자인 패턴을 기억하고 하나씩 업무에 적용할 수 있게 된다면, 커리어를 개발하는 데 큰 도움이 된다
코드 리뷰란 기본적으로 다른 사람이 작성한 코드를 지적하는 것이 아니라, 본인이 깨닫는 것에 중점을 두는 것이다 어차피 다른 사람이 쓴 코드를 한순간에 이해하기란 어렵다 리뷰가 테스트보다 더 효율적인 버그 발견 방법이라는 사실을 많은 사람이 깨닫지 못하고 있다 리뷰에서 모든 결함을 발견하기란 불가능하고, 테스트를 통해 확실하게 작동을 확인하고자 하는 기분이야 이해하지만, 확실한 리뷰 프로세스를 내재하는 것이야말로 저렴하고도 효율적으로 품질을 향상하는 방법이다
가능한 한 코드 리뷰 전에 기계가 검출할 수 있는 버그는 걸러내고, 사람은 정말 최소한의 작업만 하는 구조로 만드는 것이다 일반적인 리뷰 프로세스에서 리뷰를 수행하기 전에 단위 테스트의 실행 결과가 나온다 단위 테스트가 실패하는 상태에서 리뷰를 진행해도 아무런 의미가 없다 이런 구조를 만들어두면 조직의 개발 효율이 점점 높아진다
조기 테스트 실행의 주요 목적은 품질 개선이지만, 사실은 그 이상으로 개발 효율의 개선이 중요하다고 생각한다 버그가 발생한 시점에 곧바로 수정하면 손이 많이 가지 않는다 버그가 침투하지 않도록 노력하는 조직은 많지만, 그 방식이 잘못됐다고 생각한다 아무리 신경을 쓴다 하더라도 사람은 실수하기 마련이고, 대부분의 사람은 반성하지 않는다 버그가 생기지 않는 구조가 아니라, 생기더라도 곧바로 발견할 수 있는 구조로 만드는 것이 중요하다 개발자 뿐만 아니라 IT에 관련이 있는 모든 사람들이 읽어보아야 될 만한 주제들로 가득하다 프로젝트 진행시 대부분 기능 구현에만 초점이 맞혀져 있고 품질을 신경쓰지 않은채로 개발과 운영을 해나가면서 갈수록 품질이 떨어지고 이슈를 해결하기 힘들고 다양한 장애가 발생하며 점점 손대기 힘들어지고 기능을 추가하고 테스트하기가 어려워지는 것을 느낄 것이다 테스트와 테스트 자동화 그리고 테스트하기 쉬운 구조로 개발하지 않는 서비스는 점점 개발하기 힘들어지고 운영하기도 힘들어 질 것이다 지속적으로 안정적이고 빠르게 개발하고 운영하고 테스트해볼 수 있는 서비스를 원한다면 테스트의 중요성에 대해 반드시 깨우쳐야 하고 테스트의 중요성에 대해 잘모르고 있었다면 이 책을 꼭 한번 읽어보기 바란다 ※출판사로부터 책을 무상으로 제공받아 읽어보고 정성껏 작성한 리뷰 입니다 |