고정 헤더 영역
상세 컨텐츠
본문
728x90
TDD는 테스트 주도 개발을 말한다.
코드마다 유닛테스트 코드를 작성해서 테스트 자동화를 하고 소스 수정시에 테스트 코드를 통과시켜 오류를 줄이자는것.
(사실 아직까지 TDD를 실행하는 업무 환경에서 일해보질 못했다. 그런 업무환경에서 일할 수 있다면 좋겠다는 생각이 든다. 새로운 것을 배우는건 언제나 즐거우니까~ ^*^)
TDD가 이슈화 되면서 난 기획도 QA 리스트가 주도하는 기획을 했으면 좋겠다는 생각이 들었다.
프로젝트를 진행하다 보면 기획자와 개발자는 참 자주 부딪힌다.
그렇게 부딪히는 이슈 중에는 기획자의 의도와 개발자의 이해가 다른경우, 기획자의 요구가 제대로 구현되지 않은 경우 등등이 등장한다.
최근 우리 회사에서는 개발된 성과물에 QA를 진행하는데, 이게 참 난감하다.
기획서에 명시되어 있지 않았던 항목들이 QA에 버젓이 올라오는 일은 다반사고, 심지어는 기획이 변경되기도 한다.
개발자 입장에서는 심히 짜증이 나게 되는 상황.
그런데 기획자는 또 기획자 나름대로 이건 당연한거 아니냐고 묻는 상황이 연출되곤 한다.
당연하다.
당연하다는 말처럼 무서운게 있을까 싶어지는 상황이다.
그러다 보니 이런 생각이 들었다.
기획자가 페이지 기획을 할때 QA에서 테스트 할 항목을 미리 리스트로 적는 QA시트를 함께 작성하면 어떨까?
예를 들어 글 작성 페이지를 기획한다면 글 작성 페이지의 구성을 기획함과 동시에 QA시트에 글 작성페이지가 구현됬을때 테스트 할 항목들을 작성해두는 것이다.
제목에 몇글자까지 들어가는지 테스트 하겠다던가, 필수항목 테스트는 어떤 값들을 진행하겠다는 목록을 작성해서 기획서와 함께 넘겨주면 개발자는 기획서를 봄과 동시에 QA에서 테스트 당할 항목들을 확인해서 해당 항목을 구현한다.
구현 후 QA담당자는 QA에서 작성된 시트에 있는 항목이 제대로 구현되었는지 목록을 확인해나가면 된다.
QA시트를 작성하다 보면 막연하게 작성되는 기획페이지는 줄어들 것이고, 개발자 또한 명시적으로 어떤 동작이 구현되어야 하는지 한눈에 보며 개발을 진행할 수 있다.
또한 QA 시트에 있는 항목들을 유닛 테스트 코드로 작성해 두고 구현시 테스트를 진행하면 제품의 품질도 보장하는 효과가 나게된다.
물론 이렇게 기획서 쓸려면 기획서 하나 쓰는데 소요되는 시간이 엄청날거라고 실무 기획자들은 얘기할거라고 생각한다.
(실제로 상사에게 이 아이디어를 얘기하자 기획팀의 업무가 얼마나 많은지 아냐고 내게 일장 연설을 해주셨다. ㅋㅋ)
TDD를 얘기할때 개발자들이 하는 얘기와 닮아있지 않은가~
기획 - 개발 - 테스트 - 제품 출시
프로젝트는 보통 이렇게 굴러간다.
그리고 뒤에 운영이 붙는다.
두리뭉실 ~ '대충 이러 이러한거 되게 만들어 주세요.' 라는 고객의 요구를 시작으로 작업하던 프로그래밍은 그 문제점이 가시화 되어 앞에 요구분석과 기획 설계 단계가 붙었다. 그리고 각 개발자의 역량에 따라 엄청난 편차를 보이는 개발 결과물의 품질을 높이고 오류를 줄이기 위해 TDD를 도입하려 하고 있다.
그렇다면 당연히 모호~한 기획서와 씨름하다가 테스트 단계에서 왕창 추가되는 이슈에 깔려죽는 사태를 예방할 수 있는 이런 방법이 도입되어야 하지 않을까?
많은 사람들이 TDD가 귀찮지만 최종적으로는 제품 출시 후 운영시에 생기는 문제점과 악순환을 예방하기 위한 좋은 방법임을 인정하고 있다.
QA 시트를 작성하면서 기획서를 쓰는것이 물론 매우 귀찮고 시간도 많이 소요되겠지만 QA 시트를 작성하면서 기획서에서 누락된 로직도 확인이 가능하고 QA 진행시에는 사용자 입장에서의 테스트를 보기 때문에 구현 후 QA시에 등장해서 개발자를 당황케 하는 사용자 편의를 위한 기능들을 기획단계에서 미리 포함하게 할 수 있다.
개발자는 당연히 초기 기획에서 명시되어 있는 기능을 모두 감안하여 설계를 진행하게 되므로 개발 후에 심하게는 구조를 뒤집어 엎어야 하는 사태를 조금이나마 미연에 방지할 수 있다는 이점이 있다.
지금은 이런 얘기가...무슨 말도 안되는 오지랖이냐는 구박을 들을지 모르겟으나, 언젠가 TDD가 테스트 주도 개발 뿐만이 아니라 테스트 주도 기획으로도 해석되는 날이 있길 기대해 본다.
코드마다 유닛테스트 코드를 작성해서 테스트 자동화를 하고 소스 수정시에 테스트 코드를 통과시켜 오류를 줄이자는것.
(사실 아직까지 TDD를 실행하는 업무 환경에서 일해보질 못했다. 그런 업무환경에서 일할 수 있다면 좋겠다는 생각이 든다. 새로운 것을 배우는건 언제나 즐거우니까~ ^*^)
TDD가 이슈화 되면서 난 기획도 QA 리스트가 주도하는 기획을 했으면 좋겠다는 생각이 들었다.
프로젝트를 진행하다 보면 기획자와 개발자는 참 자주 부딪힌다.
그렇게 부딪히는 이슈 중에는 기획자의 의도와 개발자의 이해가 다른경우, 기획자의 요구가 제대로 구현되지 않은 경우 등등이 등장한다.
최근 우리 회사에서는 개발된 성과물에 QA를 진행하는데, 이게 참 난감하다.
기획서에 명시되어 있지 않았던 항목들이 QA에 버젓이 올라오는 일은 다반사고, 심지어는 기획이 변경되기도 한다.
개발자 입장에서는 심히 짜증이 나게 되는 상황.
그런데 기획자는 또 기획자 나름대로 이건 당연한거 아니냐고 묻는 상황이 연출되곤 한다.
당연하다.
당연하다는 말처럼 무서운게 있을까 싶어지는 상황이다.
그러다 보니 이런 생각이 들었다.
기획자가 페이지 기획을 할때 QA에서 테스트 할 항목을 미리 리스트로 적는 QA시트를 함께 작성하면 어떨까?
예를 들어 글 작성 페이지를 기획한다면 글 작성 페이지의 구성을 기획함과 동시에 QA시트에 글 작성페이지가 구현됬을때 테스트 할 항목들을 작성해두는 것이다.
제목에 몇글자까지 들어가는지 테스트 하겠다던가, 필수항목 테스트는 어떤 값들을 진행하겠다는 목록을 작성해서 기획서와 함께 넘겨주면 개발자는 기획서를 봄과 동시에 QA에서 테스트 당할 항목들을 확인해서 해당 항목을 구현한다.
구현 후 QA담당자는 QA에서 작성된 시트에 있는 항목이 제대로 구현되었는지 목록을 확인해나가면 된다.
QA시트를 작성하다 보면 막연하게 작성되는 기획페이지는 줄어들 것이고, 개발자 또한 명시적으로 어떤 동작이 구현되어야 하는지 한눈에 보며 개발을 진행할 수 있다.
또한 QA 시트에 있는 항목들을 유닛 테스트 코드로 작성해 두고 구현시 테스트를 진행하면 제품의 품질도 보장하는 효과가 나게된다.
물론 이렇게 기획서 쓸려면 기획서 하나 쓰는데 소요되는 시간이 엄청날거라고 실무 기획자들은 얘기할거라고 생각한다.
(실제로 상사에게 이 아이디어를 얘기하자 기획팀의 업무가 얼마나 많은지 아냐고 내게 일장 연설을 해주셨다. ㅋㅋ)
TDD를 얘기할때 개발자들이 하는 얘기와 닮아있지 않은가~
기획 - 개발 - 테스트 - 제품 출시
프로젝트는 보통 이렇게 굴러간다.
그리고 뒤에 운영이 붙는다.
두리뭉실 ~ '대충 이러 이러한거 되게 만들어 주세요.' 라는 고객의 요구를 시작으로 작업하던 프로그래밍은 그 문제점이 가시화 되어 앞에 요구분석과 기획 설계 단계가 붙었다. 그리고 각 개발자의 역량에 따라 엄청난 편차를 보이는 개발 결과물의 품질을 높이고 오류를 줄이기 위해 TDD를 도입하려 하고 있다.
그렇다면 당연히 모호~한 기획서와 씨름하다가 테스트 단계에서 왕창 추가되는 이슈에 깔려죽는 사태를 예방할 수 있는 이런 방법이 도입되어야 하지 않을까?
많은 사람들이 TDD가 귀찮지만 최종적으로는 제품 출시 후 운영시에 생기는 문제점과 악순환을 예방하기 위한 좋은 방법임을 인정하고 있다.
QA 시트를 작성하면서 기획서를 쓰는것이 물론 매우 귀찮고 시간도 많이 소요되겠지만 QA 시트를 작성하면서 기획서에서 누락된 로직도 확인이 가능하고 QA 진행시에는 사용자 입장에서의 테스트를 보기 때문에 구현 후 QA시에 등장해서 개발자를 당황케 하는 사용자 편의를 위한 기능들을 기획단계에서 미리 포함하게 할 수 있다.
개발자는 당연히 초기 기획에서 명시되어 있는 기능을 모두 감안하여 설계를 진행하게 되므로 개발 후에 심하게는 구조를 뒤집어 엎어야 하는 사태를 조금이나마 미연에 방지할 수 있다는 이점이 있다.
지금은 이런 얘기가...무슨 말도 안되는 오지랖이냐는 구박을 들을지 모르겟으나, 언젠가 TDD가 테스트 주도 개발 뿐만이 아니라 테스트 주도 기획으로도 해석되는 날이 있길 기대해 본다.
728x90
