-
Notifications
You must be signed in to change notification settings - Fork 10
/
0561.txt
11 lines (6 loc) · 11.8 KB
/
0561.txt
1
2
3
4
5
6
7
8
9
10
11
안녕하세요 포프입니다.
오늘 할 이야기는 테스트 코드를 잘 작성하기 위한 가장 기초적인 전제조건을 말씀을 드릴게요. 참고로 이거는 테스트를 잘 작성을 하는 부분이기 때문에 TDD 하고 아무 상관없고요, 그냥 자동화된 테스트를 얘기하는 겁니다. 이거 굉장히 간단한 거예요. 사실 결론부터 말씀드리면 재현 사례, 어떤 버그의 재현 가능한 재현 과정들을 제대로 적을 수 있어야만 테스트 케이스를 잘 작성할 수 있습니다. 그게 전제 조건이에요. 그럼 반대로 얘기하면 어떤 사람이 재현 과정을 잘 못 적는다? 그럼 그 사람은 테스트를 잘 작성할 가능성이 아예 없습니다.
요거를 좀 얘기를 길게 늘여 얘기할게요. 인턴십이라던가 아니면 co-op이라던가 학교를 다니다가 잠깐 멈추고 학교에서 학점을 인정해 주고 업체 가서 6개월~1년 일하고 오는 것들, 이런 제도가 북미에서는 꽤 흔한 제도입니다. 저는 개인적으로 그렇게 좋아하는 제도는 아니지만 흔한 제도예요. 그 제도화에서 co-op으로 온 학생, 인턴으로 온 프로그램 학생들이 일반적으로 하는 일이 뭐냐? 그러면 프로그래밍 아닙니다. 문서정리 이건 얘기할 거 아니고 QA, 한마디로 테스터 일들을 많이 합니다. 테스터 일을 왜 많이 하느냐? 결과적으로 이 얘기를 하고 있는 거예요. 테스터를 하다 보면 버그를 찾아요. 그럼 그 버그를 보고해야 돼요. 버그 보고하는 문서를 쓰죠? 보통은 버그 트래킹 시스템이 있어요. 그 문서를 쓸 때 그 문서를 보는 사람이 이 버그를 곧바로 재현해서 그 문제점을 고칠 수 있게 재현 가능한 스텝을 적어놔야만 합니다. 이거는 일반적으로 회사마다 템플릿이 있는데 결과적으로 제일 중요한 것들은 어떤 환경에서 윈도우 쓰고, 브라우저는 뭐였고 버전이 몇이었고 이런 거, 이거에서 발생을 했냐? 그리고 어떤 버그가 발생을 했냐? 현재 상태가 뭐였냐? 스크린샷첨부하려면 할 수 있고 기타 등등. 하지만 제일 중요한 거는 제일 중요한 거는 그 버그를 어떻게 해야 프로그래머가 다시 재현을 한 방에 할 수 있냐? 에요. 물론 한방이 재현이 안 되는 버그들이 있어요. 왜냐하면 멀티스레딩 들어가고 타이밍 문제 들어가면 한 10번 시도하면 한 번 나오는 버그들도 있거든요? 그런 경우는 재현율 10% 이런 식으로 적어서 내야 됩니다. 그게 아니라 10번 했는데 10번 다 발생했다 그럼 100%, 아니면 '10번 시도해서 10번 발생했어'라는 재현 과정을 그대로 써야 해요. 이 재현 과정은 뭐냐? 자기 객관화가 엄청나게 필요한 과정입니다. 왜냐하면 이렇게 생각해봐요. 브라우저를 연 다음 네이버 웹사이트에 가서요, 오른쪽에서 세 번째 있는 링크를 눌렀는데 화면이 안 떠요. "뭔 브라우저였는데?", "네가 어느 브라우저였는지 내가 어떻게 알아?", "크롬에서 열었다", "인터렉스 플러스에서 열었다", "파이어폭스에서 열었다" 이런 얘기를 해줘야 돼요. 그리고 셋 다 열어보고 여기선 되고, 여기서는 안됩니다, 여기서는 더 좋아요. 원래는 잘하는 QA는 다 그래요.
첫 번째 그거고, 자 네이버 웹페이지에 갔다 그랬어요 그 네이버 웹페이지 간 네이버 공홈이에요? 아니면 네이버 지도예요? 다 네이버 웹페이지긴 해요. 정확히 뭐냐고요? 정확히 얘기를 해줘야 돼요. 그리고 몇 번째 해서 왼쪽에서 세 번째 링크를 클릭했다 그래요. 그 링크가 바뀔 수도 있고 사람마다 달라질 수도 있을 거 아니에요? 그럼 정확히 무슨 링크인지 무슨 텍스트가 있는지 아니면 비디오로 찍든지 얘기를 해줘야 돼요. 그래서 누가 따라 해도 똑같이 그 상황을 맞이할 수 있는 상황을 만들어야 합니다. 하지만 그런 거 다 생략을 하고 그냥 '나는 버그 발생하는 거 봤으니까 한번 얘기하고 넘어가지'하고 넘어가는 사람도 있어요. 그럼 개발자 입장에서는 그걸 재현을 못 할 수도 있고 재현하더라도 되게 고생했을 수도 있어요. 과연 이렇게 해서 한 건가? 이런 거 이런 거. 근데 엄밀하게 말하면 개발자들은 굉장히 죄송한 얘기지만 QA에 비해서 훨씬 소중한 자원 예요. 소중하다는 게 뭐냐면 구하기 어려워요. 그렇기 때문에 시간을 갈아 넣어야 하는 일이라면 QA가 더 해주고 프로그래머들은 그 일을 덜 하게 해 주는 게 원칙입니다. 이건 경제의 원리라서 좀 안타까운 세상이긴 하지만 어쩔 수 없어요. 그래서 그런 것도 안 한 거야 근데 결과적으로는 이런 것들, 자세적인 측면이든 아니면 논리적이지 못하든 자기 객관화를 못하든 재현 과정을 구현 못하는 분들에게 테스트 케이스를 작성하라고 하면요, 아주 산으로 갑니다. 첫째 뭘 테스트해야 될지조차 잘 몰라요. 어떤 버그가 나오면 결과적으로 내가 재현 과정 적다 보면요, 어떤 것 때문에, 이 단계 때문에 버그가 생겼다는 약간의 상관관계가 보이기 시작을 해요. 그럼 그 상관관계가 보여야지만 어떤 부분에 버그를 테스트할 수 있지도 알거든요?
그거는 그거고, 두 번째는 뭐냐면 제가 재현 과정이라고 얘기했잖아요? 그 재현 과정이 있으면요, 나중에 테스트 케이스는 그 재현 과정을 거의 자동화시키면 끝입니다 사실은. 이걸 자동화, 그러니까 코드로 짜면 되는 거예요. 근데 내 머릿속에서 이 과정조차 정리가 안 돼 있어요. 그러니까 뭔가를 본능적으로 하는 일들을 라면 끓이는 설명서 적듯이 한 줄 한 줄 정리할 수 있는 능력이 없다는 거예요. 그래서 그게 안 되면 코드로 쓰는 순간 막 복잡해져요. 되게 간단하게 1 2 3 4 5 하면 되는 건데 그 코드를 못 쓰고 있어요. 그냥 5 6번을 합쳤다가 3번을 했다가 갑자기 안 되는 걸 써놓고 이거 테스트하는 거 아니고, 실제 테스트하는 데이터도 틀린 경우도 되게 되게 많아요. 대표적인 예를 제가 하나만 들어 드릴게요. 얼마 전에 저희 쪽 라이브러리에서 부동소수점으로 계산을 하는 게 정밀도가 떨어질 수밖에 없잖아요? 그 오차가 별로 맘에 들지 않았어요. 오차를 안 만들고도 저희 시스템에서 특정 부분에서는 고정 소수점, 그러니까 정수죠? 엄밀하게 얘기하면. 고정소수점부터 정수를 처리하니까. 그 정수 타입으로 계산을 할 수 있는 경우가 있었어요. 그래서 그거를 하는 C#의 구조체를 만들기 시작을 했습니다. 그래서 만들고 나서 이거는 굉장히 데이터 드리븐이기 때문에, 얘를 구현하고 나서 이제 유닛 테스트를 넣기 시작하고 그걸 어느 프로그램에 작성을 시작을 했어요. 그래서 유니테스트를 작성하는 도중에 여러 가지가 있는데, 이 사람이 일단 한 2가지를 크게 테스트하고 넘어간 것들이 있어요. 하나가 뭐였냐면 어쨌든 간에 우리는 부동 소수점이 아니라 고정 소수점인데, 그 고정 소수점에서 int를 사용하기 때문에 어쨌든 간에 범위가 있을 수밖에 없거든요? 그 범위를 넘어가는 계산을 해서 오류가 난다던가 이런 유닛 테스트를 다 했어야 됐어요. 그래서 그 범위를 되게 애매하게 적용을 해서 부동 소수점에서 0.99 이렇게까지 가면은 그때는 범위 에러가 나는데, 그걸 테스트를 안 하고 0.32 정도 가면 오류가 안 나는데 그것만 테스트하고 넘어간 게 하나 있어요. 그거는 아주 명백하진 않아요. 왜냐면 int의 자료형을 정확히 알고 범위를 고민하고 해야 될 수는 있으니까 그거는 오케이 해줄 수 있어요. 그 다음이 뭐였냐면 이 부동소수점에서 .ToString을 하는 함수가 있어요. 우리는 폼에 복잡할 거 없어요. 우리 내부에 쓰는 문자열 폼에서 하나뿐이니까. 하라고 했는데 여러 가지 문자열 자료를 가지고 테스트를 했어요. 근데 여전히 버그가 있어요. 버그가 뭐였냐면 소수점 부분이 0일 때 우리 스펙에 따르면 '소수점 부분은 언제나 2자리로 출력한다'였거든요? 근데 0일 때 그냥 .ToString을 그냥 한 다음에 붙여 나갔고, 그게 한 자리로 출력이 돼요. 근데 그거는 유닛 테스트에 미리 박아두면 할 수 있는 거거든요? "야 3.00 넣어. 그리고 .ToString 해봐. 실제 3.00 나오는지 확인만 하면 되는 거잖아?" 근데 그 테스트는 없어요. 그 대신 소수점이 언제나 12 46 33 이런 식으로 언제나 2자리, 아니면 01, 그러니까 언제나 두 자리를 찍힐 수 있는 상황밖에 없는 거예요. 근데 이거 자체가 부동 소수점을 열심히 하다 보면 굉장히 흔한 부분이고, 이런 테스트 케이스 열심히 작성하다 보면 '과연 내가 여기서 뭐가 깨졌을까?'라는 고민을 할 수밖에 없거든요? 그 재현 과정을 작성하다 보면? 그런 것들이 안 되기 때문에 이런 문제들이 생기지 않나? 생각했어요.그래서 그때 그 개발자한테 처음으로 시켰던 건 "당신은 테스트를 일단 작성하지 말고, 그냥 개발자도 찾는 버그가 있으니까 버그 보고 할 때 말로 한 줄 짤막하게 하지 말고 이제부터 버그 리포트를 쓰기 시작하세요."라고 시켰어요. 실제 쓰기 시작했더니 버그 재현 과정들을 굉장히 못 작성하는 문제들이 있었어요. 템플릿을 줬음에도 불구하고 어떤 버그가 이렇게 하면 된다는데 실제 재현이 안 되고 어떤 버그가 재현이 안 된다고 하는데, 그건 딴사람이 썼던 재현 과정이었고 '이거는 좀 더 정보가 필요하다' 이렇게 태그를 달고 넘어갔는데 제가 어느 날 가서 그것도 그대로 해봤거든요? 돼요, 잘돼요. 실제로 재현이 돼요. 그래서 이게 문서를 이해하는 능력이 모자라거나, 아니면 기본 상식이 남들하고 조금 다른 곳에 있어서 a라고 쓰여 있는 거를 a—라고 읽는지 모르겠지만, 그래서 자기 객관화가 부족하면 자기 방식대로만 쓰고 남은 이해를 못 하니까 역시 문제가 생길 수 있겠죠?
그래서 이건 여러 썰을 푼 거고, 최종적으로 드리고 싶은 말은 정말 내가 회사에서 테스트를 많이 작성을 해야 되는 회사고 잘하는 프로그래머를 뽑고 싶다고 하면 경력직은 QA로 돌리는 법은 되게 애매하긴 해요 사실. 그건 말 좀 말이 안 되고, 신입이라던가 co-op 아니면 인턴으로 들어왔다가 정규직으로 전환하는 과정이 있으신 분들이라면 QA로 한몇 달은 돌려 보세요. 돌려보면서 그걸 잘 작성하는지, 잘 작성을 못하면 훈련을 시켜보고 그거를 훈련을 시킨 다음에 주니어 프로그램을 전환을 하면 테스트를 많이 작성하는 환경에서는 훨씬 괜찮은 테스트를 작성하는 주니어들을 채용할 수 있을 거라고 저는 생각을 해요. 아니면 회사에서 내부적으로 테스트 작성을 굉장히 이상하게 한다거나, 전혀 쓸데없는 걸 하는 사람들이 있다? 그러면은 개발자가 버그를 보고하는 경우들도 있으니까 그때마다 QA 템플릿에 잘 맞게 보고서를 제대로 작성해서 올리라는 식으로 하시면 아마 그 사람 훈련에도 도움이 될 거예요. 좋은 얘기 많이 했죠? 포프였습니다.