개발자, 버그 상황이 반복되면...
개발 흐름에 대한 이슈가 발생한 것입니다.
개발자에게 프로세스는 매우 중요합니다.
대부분의 버그는 프로세스가 제대로 동작하지 않기 때문에 나타나는 현상입니다.
물론, 개발자들 자체가 '버그'를 만들고, 실수가 나타날 수 있습니다.
하지만, 그런 개발자들은 팀 내에서 정리정돈을 하거나, 업무에서 제외를 시키는 순서로 진행되기 때문에 신뢰도가 있는 팀에서는 이런 상황을 만들지 않으려고 합니다.
하지만, 버그가 등장하고, 수정했는데 '동일'하거나 '비슷'한 버그가 반복되는 경우는
개발 프로세스에 문제가 발생했기 때문입니다.
첫 번째. 개발팀 내부의 단위 테스트가 부족한 경우
개발자 스스로, 기능에 대해서 개발자 PC에서 테스트하고, 보통 '스테이징'이라고 불리는 테스트 공간에서 테스트를 진행하고, 실 서버에 배포를 하는 단계를 거치게 됩니다.
최소 2번 정도의 기본 테스트 과정을 거쳤음에도 불구하고, '버그'가 보이는 이유의 첫 번째는...
'개발자'의 실력 부족인 경우입니다.
매우 당연하게 해당 상황이 반복되면, 팀장이거나 팀 리더급 개발자들이 해당 개발자에 대해서
점검을 하게 되고, 이를 조정하거나, 업무를 조정하거나, 팀에서 제외를 하게 됩니다.
하지만, 그런 상황이 아니라면 다른 경우입니다.
두 번째. 초기 기획이나 비즈니스 흐름이 잘못된 경우
사용자의 요구사항이나 초기에 입력되기로 한 데이터의 값의 숫자나 범위, 구분되는 값들, 사용하는 곳의 상황이 변경되는 등의 사용자 환경이 변경된 경우일 수 있습니다.
암묵적으로 합의되어 진행된 것인데, 예상 못한 시기에 변경되어서 '버그'로 인지되는 경우도 있습니다.
문제는, 초기 기획에서 해당 케이스를 잘못 정의하였거나, 기획서의 내용을 간추려진 상태로 개발된 경우에도 특이상황이거나 특정 상황에서 버그 상황을 만들 수 있습니다.
세 번째. 수정하는 내용이 다른 곳에 버그를 일으키는 상황
기능이든 데이터 이든, 변경이 일어나고, 입력되는 방식, 시기가 변경되게 되면, 이는 다른 비즈니스 흐름이거나 예외상황에 영향을 줄 수 있습니다.
물론, 이런 상황을 대비해서 개발자들은 다양한 장치들을 고안하고, 서포트를 하지만...
그 상황을 너무 단조롭게 생각했거나, 여파를 그다지 고려하지 않은 경우에는
해당 상황을 변경했기 때문에 버그 상황으로 전파될 수 있습니다.
네 번째. 기능이 복잡하면 배포 전에 테스트 과정을 필수적으로 두어야 하는 경우입니다.
1,2,3의 모든 문제를 해소할 수 있는 가장 좋은 방법은, 개발자가 개발이 되면, 해당 기능을 테스터들이 관련 여파나 상황들을 고려하여, 각 단계별 영향도가 있을만한 상황을 고려하여 테스트를 진행하는 것입니다. 그리고, 그 테스트의 영향도에 대해서 문제가 없다고 인지될 경우에만 배포를 하는 형태로 진행하는 방법도 있습니다.
흥미로운 것은 이런 '방법'은 SI업체이거나 공공기관 등의 사용자 요구사항에 대한 절대적인 흐름을 관리하는 형태로 통제하는 방법들이 있습니다. 물론, 이와 관련된 솔루션들도 매우 많습니다.
핵심적인 것은...
배포 전에 '테스트'를 수행하는 단계를 누가 할 것인가?
이 부분입니다.
'누가'테스트를 해야 할까요?
작은 스타트업의 경우라고 하더라도, 개발자 스스로 테스트를 완료하는 단계는 그다지 좋은 것이 아닙니다. 개발자들 특징이 테스트 시에 부정적으로 하는 형태로 진행하는 것은 매우 쉽지 않습니다.
물론, TDD(Test-drvien development)라는 방법도 있습니다.
개발자 스스로 새로운 함수나 기능을 정의할 때에 자동화된 테스트 케이스를 작성하고, 이 테스트 케이스를 통과하는 과정을 스스로 작업할 수 있게 하는 것이죠.
문제는 이런 TDD과정들은 단위 테스트와 기능의 점검에는 우월한 속도와 의미를 가질 수 있습니다.
서버 사이드류의 작업들은 이 과정으로 대부분 해소가 됩니다만, 문제는 UI기준의 웹이나 앱 작업의 경우에는 대응하기가 쉽지 않습니다.
물론, UI 테스트 과정을 자동화하는 방법도 있기는 하지만, 이 역시 그렇게 쉽지 않기 때문에...
보편적으로 사용하는 방법은 서버 개발자들에게는 TDD를 권장하고, 스웨거와 같은 API-DOC 형태로 서비스를 구현하게 하고, 웹이나 앱은 변경 시에 통합 테스트 과정을 충분하게 정리 정돈하여 진행하는 형태로 반복적으로 문제를 해소하는 것이 가장 최선입니다.
결론적으로 별도의 '테스터'를 두는 것이 맞습니다.
하지만,
스타트업의 입장에서는 이러한 '테스터'를 별도로 두기 어렵기 때문에, 대부분은 운영자나 기획자, 디자이너 등이 해당 기능 테스트들을 일정 부분 수행하는 형태로 진행되는 것이 보편적입니다.
( 이 형태가 덩치가 커지면서 R&R상 혼동을 느끼게 되는 경우도 많습니다. 하지만, 테스트 업무는 중요하기 때문에 다른 업무 이상으로 챙겨야 합니다. )
결론적으로 별도의 테스터를 두고, 배포 전에 '테스트'과정을 두는 것이 바람직하며, 해당 '테스터'는 어떤 팀에 속해있던지, 만들어지는 기능에 대해서 실 배포 전에 '테스트'를 하도록 하는 것이 좋습니다.
이 경우에 '테스트 케이스'에 대해서는 '해당 테스터'가 작성하게 하고, 수행하게 하는 것이 좋습니다.
그것이 문제 해결을 위해서 가장 좋고, 각 팀의 신뢰관계를 유지하는 것에 효과적일 것입니다.
테스터들은 기획이나 개발팀에 속해있기보다는, 개발을 총괄하는 담당자나 임원진의 직할조직, 또는 별도의 팀의 형태로 존재하는 것이 바람직합니다.
회사의 규모가 커지면서 테스트의 역할에 대해서는 언제나 고민과 논의의 대상이 될껍니다. 개발업무를 최소화하기 위해서 테스트 업무가 늘어나기도 하고, 프로토타이핑에 대한 테스트와 사용성에 대한 업무까지 테스트 작업자에게 넘어가는 경우까지 많은 우여곡절을 겪게 됩니다.
적절한 비즈니스 속도가 결정되고, 제품의 라인업과 로드맵의 구성이 충분하게 구성되는 형태가 되어야, 이 논란은 최소화될껍니다.
결국, 어떤 속도로 비즈니스를 서비스화 시키고, 이를 배포 운영을 해야 하는 지에 대한 정책적인 결정을 통해서 모든 조직의 구성은 결정되게 마련입니다.
.
.
.
물론, 그렇다면 현재 타이밍에 어떤 조직구성이 맞느냐는 질문이 가장 많이 나오게 됩니다.
정답은 없습니다.
기획이 부실하면, 테스트를 강화해야 하고, 개발자 스킬이나 능력이 부족하다면 그 역시 보강해야 하는 것이구요. 잘하는 조직을 최대한 살리고, 보조적인 팀과 자격을 갖춘 상대들을 끌어올리는 단계를 거쳐야 합니다.
팀과 팀간에 신뢰와 상호 의사소통을 최대한 늘리시고,
일을 잘하는 팀이나 담당자에게 일이 너무 많이 몰려가지 않게 해야 하며,
능력이 부족한 사람이나 팀은 적절한 시기에 정리해야합니다.
따지고 보면...
서비스에 버그가 많아지고...
서비스의 운영에 문제가 많아지는 것은...
결론적으로...
해당 서비스를 운영관리하는 경영진의 책임과 능력의 문제라는 것이죠.
