버그 없는 Software?

이런 그림을 보신 적이 있으신가요? (이 그림의 정확한 출처를 모르겠습니다.)
개발에 관련된 분들은 보고 피식 웃으실 수 있는 그림입니다. 굳이 번역하면 다음과 같을 것입니다.

"이게 동작하지 않네.... 왜?"
"이게 동작하네.... 왜???"

개발을 하다보면 자신의 코드가 의도한 대로 동작하지 않을 때가 많습니다. 이를 디버깅하는 시간이 많이 필요하고 그 고민으로 많은 분들이 고생을 하죠.
반대로 분명히 있었던 버그가 새로운 기능을 개발 하거나 혹은 다른 버그를 수정했는데 전혀 관련이 없어 보이는 버그가 갑자기 사라지는 경우가 있습니다. 이 경우도 이유를 몰라서 고민을 많이 하게 되죠. 사실 저는 이런 경우가 더 무섭습니다. 수정하지 않았는데 사라지는 버그. 언제 다시 나타날지 모르니까요.

제가 여기에서 하고 싶은 이야기는 버그가 없는 Software는 없다는 것입니다.

소프트웨어 개발 일정!

(출처: giphy.com)

구글링하다가 찾은 이미지가 웃겨서 들고 왔습니다.

프로젝트 종료시간(Deadline)이 다가오는 데 날짜를 수정해버려서 종료시간이 뒤로 밀려가도록 합니다. 현실의 시간을 과거로 바꾸는 거죠.

모든 소프트웨어 프로젝트는 출시일이 정해져 있습니다. 물론 어느정도 변경은 항상 가능하지만 위의 애니메이션 GIF처럼 반복적으로 계속 변경을 할수는 없습니다.

그러면, 원하는 시간내에 원하는 기능을 완벽하게 구현하기 위한 방법이 무엇이 있을까요?
(이 글의 맨 처음에서 이야기 했지만 완벽한 코드를 작성한다는 것은 매우 어렵습니다.)

자원 추가 투입

첫번째로, 개발에 필요한 자원을 늘린다면 빠르고 정확하게 개발을 할 수 있지 않을까요? 아래 그림처럼 많은 개발자와 기획자, QA 등 인력을 대폭 증원하는 것입니다.

(출처: https://medium.com/wearethetin/how-many-developers-did-it-take-to-make-this-webpage-e4ebfee16301)

해결 방법이 아닙니다!

브룩스의 법칙에서 이야기 해주듯이 일정 인원 이상의 투입은 결국은 프로젝트의 출시를 더 늦어지게 하는 이유가 됩니다.

브룩스의 법칙(Brooks' law)

• 지연되는 프로젝트에 인원을 더 투입하면 오히려 늦어진다는 이론
• 개발자를 추가할수록 그들 사이의 미팅, 인터페이스 합의, 의사소통 등과 같은 커뮤니케이션 비용이 기하급수적으로 증가하여서 프로젝트가 지연됩니다.
• N명 추가시 N*(N-1)/2의 의사 소통비용 증가.
  

개발 일정 연장

두번째로는 개발 일정을 연장하는 방법입니다.

현실적으로는 개발 일정을 연장하는 것은 매우 제한적인 선택이고 충분한 만큼의 추가 일정을 확보할 수도 없는 경우가 대부분입니다.

또한 데드라인 효과(Deadline Effect)가 있어서 개발 일정이 지속적으로 연장이 가능하다는 것을 구성원들이 알게 되면 개발의 집중도가 매우 낮아지는 현상이 발생할 것입니다.

데드라인 효과(Deadline Effect)
최종 기한이 정해져 있을 경우에 일에 더 집중하는 현상
기한을 정하고 설문지를 작성해오면 5불을 제공할 경우 66%의 학생이 돈을 받으러 옴. 기한을 정하지 않으면 25%의 학생만이 돈을 받으러 옴.

그래서 Agile!

언제나 정답은 아니지만! 그래서 Agile

애자일(Agile)은 작업 계획을 짧은 단위로 세우고 시제품을 만들어나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발방법론이다.

최소 기능 제품 MVP(Minimum Viable Product): 고객의 피드백을 받아 최소한의 기능(Feature)를 구현한 제품.

데드라인 효과(Deadline Effect)도 있기 때문에 일을 더 효율적으로 할 수 있습니다.

버그의 원인

다양한 분류 방법이 있겠지만 이 글에서는 다음과 같이 분류하고 이야기를 합니다.

1. 요구사항 없음
   ① 사용자가 자신의 요구사항을 잘 모르는 경우
   ② 사용자가 요구사항을 이야기 했지만 기획자나 개발자에게 전달되면서 누락되는 경우
2. 요구사항 오해
   ① 사용자, 기획자, 개발자 등의 서로간의 커뮤니케이션 오류
3. 예외처리
4. 단순 코딩 실수
5. 개발에 사용한 프레임워크 혹은 라이브러리
   ① 호환성 이슈
   ② 프레임워크 혹은 라이브러리 자체 오류

요구사항! 요구사항?

버그의 원인을 분류한 것의 꽤 많은 부분(1,2번)이 요구사항에 대한 내용입니다.

Software도 사용할 고객을 위해서 만드는 것입니다. 그 고객의 요구사항을 Software로 구현하는 것이죠. 그런데 왜? '사용자가 자신의 요구사항을 모른다고 하는 것일까요?' 쉽게 이해가 안되실 것입니다.

스티븐 잡스가 이런 말을 했습니다.

"A lot of times, people don't know what they want until you show it to them"
"사람들은 대개 자신이 원하는 것을 보여주기 전까지는 무엇을 원하는지 모른다"

사실은 사용자는 자신의 요구사항을 명확하게 인식하지 못하는 경우가 많습니다.
개발이 어느정도 진행된 Software의 UI를 만나게 되는 순간에 "이런 기능 저런 기능이 빠졌네요." 하는 피드백을 받아보신 경험이 있으신 분들이 꽤 있을 것입니다.

그래서, 최근에는 전통적인 개발방법론인 폭포수 방법론보다 애자일 개발방법론이 더 관심을 받는 것입니다. 빠르고 작게 개발을 진행한 MVP(Minimum Viable Product)를 고객에게 전달하고 고객의 피드백을 반영하여서 개발을 작은 주기로 반복을 해나가게 된다면 소프트웨어 개발에서의 요구사항 문제를 많이 줄일 수가 있을 것입니다.

다음은 유튜브에 있는 동영상입니다. 재미 있으니 꼭 한번 봐주세요.

Communication gap in programming/software projects... LOL😜 라는 제목입니다.
선택하시면 유튜브 동영상이 열립니다. 먼저 한번 보시고 다음 글을 읽어주십시오.

서로 다른 배경지식과 경험을 가진 사람들이 자신의 언어로 이야기를 하다 보면 위의 동영상과 같이 이야기하는 내용이 제대로 전달이 되지를 않습니다.
누구나 다른 사람의 이야기를 들을 때 자신의 경험이나 기반으로 이해하면서 듣기 때문에 내용이 제대로 전달이 안되는 문제가 어디서나 발생하게 됩니다.

모든 경우에 해당되는 것은 아니겠지만 최근에 다양한 스타트업들이 MVP(Minimum VIable Product)를 기반으로 한 개발을 진행하는 이유가 여기에 있습니다.

Software QA는 어떻게?

8개의 조건이 있을 때 Software QA를 한다면?

35개의 조합 + 그 이상....

경우의 수를 모두 검증할 수 없습니다!!!

Risk-Based Testing

제한된 자원과 제한된 시간내에 대표적인 테스트 방법론은 Risk-Based Testing

위험의 영향과 위험이 나타날 가능성을 기반해서 반드시 확인해야 할 것들을 선택하는 것입니다.

주어진 자원과 시간 내에 우선 순위를 결정하는 기준을 위험과 발생할 가능성 기준으로 정하는 방법입니다.

위험의 크기와 나타날 가능성에 대한 판단이 먼저 이뤄져야 하는데 제 경험상으로는 SQA Engineer가 주도적으로 최초의 안을 만듭니다.
만들어진 자료를 가지고 개발자. 기획자. Product Owner, Project Manager등과 논의 후에 합의를 합니다.
합의된 내용을 기반으로 각 항목별 테스트 방법을 준비하고 실행하고 결과를 공유합니다.

V 모델

전통적인 폭포수 개발방법론에서 사용되던 Software 검증 방법입니다.
핵심은 개발 단계별로 Software QA도 대응되는 활동을 한다는 것입니다.

개발 초기에 찾아내는 오류는 시간과 비용을 상대적으로 크게 절감하게 되어서 프로젝트의 성공적인 완료에 크게 공헌하게 됩니다.

정적 테스팅 vs 동적 테스팅

정적 분석과 동적 분석의 차이점

정적분석 도구

PMD
미사용 변수, 비어있는 코드 블락, 불필요한 오브젝트 생성과 같은 Defect을 유발할 수 있는 코드를 검사
https://pmd.github.io
FindBugs
정해진 규칙에 의해 잠재적인 에러 타입을 찾아줌
http://findbugs.sourceforge.net
CheckStyle
정해진 코딩 룰을 잘 따르고 있는지에 대한 분석
http://checkstyle.sourceforge.net
SonarQube
강력하고 단순한 웹 모니터링 UI 대시보드 제공. 프로젝트 개선 추이 추적 가능. 소스의 중복이나 복잡도, 유닛 테스트의 커버리지와 잠재적인 버그 정보를 프로젝트 단위부터 파일 단위까지 제공.
https://www.sonarqube.org/

적절한 Software QA

가장 일반적인 Software QA의 방법론 및 지식을 위에 정리한 것은 가장 효율적이고 현실적인 방법론을 찾기 위한 노력을 많은 사람들이 하고 있다는 것을 말씀드리기 위함입니다.

No Silver Bullet - Essence and Accidents of Software Engineering
1986년 프레드릭 브룩스가 쓴 소프트웨어 공학 논문
소프트웨어 개발의 복잡성을 일거에 해소할 마법(은탄환) 같은 방법은 없다.

은탄환은 늑대인간에게 치명적인 무기입니다. Software 개발에서 은탄환과 같이 모든 문제에서 해결방법은 없습니다.

자신의 Software에 맞는 방법을 찾아야합니다.
하지만 은탄환은 없기 때문에 최선의 노력을 끊임없이 해야 합니다. 1+1= 2 처럼 정답이 있으면 좋겠지만 정답이 없는 일을 하고 계시는 것입니다.

버그없는 Software는 없습니다!
Software QA는 완벽할 수 없습니다!

결론

끊임없이 도전하고 도전에서 배운 것을 가지고 개선하는 것이 가장 좋은 Software QA입니다.

• 소프트웨어 프로젝트에 참여하는 모든 사람의 충분한 의사 소통을 한다.
• 소프트웨어의 목적에 맞는 우선순위를 합의합니다.
• 합의한 내용을 기반으로 현재 사용가능한 최선의 방법으로 테스트 계획을 수립하고 실행한다.
• 결과를 프로젝트 팀원 모두에게 공유하고 개선 방안을 찾는다.
• 개선 방안을 실천한다.

결론도 어디까지나 개인적인 의견이고 정답은 아닙니다. 참고하시고 본인의 해답을 찾으시고 공유해주세요. 거기에서 또 저는 배우겠습니다.

참고자료

https://taetaetae.github.io/2018/02/08/jenkins-sonar-github-integration/
https://comes.co.kr/blogView?page=1&num=7