경로 의존성이라는 것이 있다.
이와 관련된 기사를 우선 읽어 보도록 하자.
내가 이 경로 의존성에 대해 처음 접하게 된 것은 EBS의 '지식채널 e'를 통해서였다.
그 뒤로 난 테스트를 할 때 경로 의존성에 대해 한번 더 생각해 보게 되었다.
경로 의존성은 테스트를 수행할 때 뿐만 아니라 컨설팅을 할 때도 가장 큰 제약 중의 하나로 작용된다.
그리고 나 자신도 알게 모르게 수용해 버리고 마는 많은 것들이 있다.
'한국 웹의 불편한 진실'과 '소프트웨어 누가 이렇게 개떡같이 만든 거야'라는 책을 읽으면서 나는 다시 한번 경로 의존성에 대해 생각해 보게 되었다.
일전에 썼던 '표준에 대한 단상'이나 'YES!!! Man을 거부해라'도 같은 맥락의 글이었다.
기술적인 표준에 관련된 경로 의존성을 깨뜨리기는 거의 불가능에 가깝다.
하지만 우리가 매너리즘에 빠지게 되는 많은 부분에서 경로 의존성의 극복은 의지의 문제이다.
많은 테스터들이 매너리즘에 빠진다.
항상 똑같은 테스트만 반복하다 보니 신선미나 독창성을 잃어버린다.
이것은 외국이나 국내나 사정이 별반 다르지 않다.
3년 이상 제대로 된 테스터 경력자를 구하기란 하늘의 별따기와 같다.
극소수의 테스터들도 관리자로 전향하면서 더 이상 경험이나 전문성과는 거리가 멀어져 버린다.
이것은 회사나 조직이 테스터에게 제대로 된 커리어 패스 하나 제시해 주지 못하기 때문이기도 하다.
하지만 매일 매일 똑같은 제품, 똑같은 테스트 케이스 수행을 하는 것에 대해서 "그거 원래 그런거야!! 바꿀 필요 없어!!"라는 주문에 과감히 "No"라고 외쳐보자.
테스팅의 범위는 무궁 무진하다. 아직까지 국내에서 테스팅이 진출할 범위는 무궁무진하다. 스스로 기회를 만들고 스스로 발전해 가는 테스터가 가득했으면 하는 바램이다.
최근 나는 UX 진영이나 웹표준 진영에 꾸준히 참석하고 있다. 이 영역은 전통적으로 아키텍쳐와 개발자의 영역이다. 난 아직까지 이 진영의 모임에서 테스터를 본 적이 없다.
나날이 UX나 웹 표준의 중요성이 증대되는 것에 반해 테스트를 수행해야 할 사람들은 이것에 아직까지 그렇게 큰 관심이 없는 듯 하다.
난 심지어 UX 진영에서 사용성 테스트는 아키텍쳐가 하는 것이고 테스트 진영에서 얘기하는 사용성 테스트는 우리가 하는 사용성 테스트와는 틀리다. 테스터가 왜 사용성 테스트에 관심을 가지는가? 라는 얘기도 들은 적이 있다.
하지만 난 그런 의견에 전적으로 반박한다. 아키텍쳐가 수행한 사용성 테스트 역시 검증해야 할 필요가 있다. 왜냐하면 그들도 사람이고 그들도 실수를 할 것이며 그렇다면 그것도 결함이 될 것이다.
테스터가 누구인가? 결함을 제거하고 예방하는 사람들이다. 그렇다면 그들이 하는 일을 알아야 할 필요가 있다.
자기 자신과 회사와 조직이 매너리즘에 빠지지 않도록 노력하자. 주변에 경로 의존성에 따라 정체된 부분을 살펴보자.
그리고 그것을 극복할 수 있도록 노력하고 연습하자.
그러고 보면 테스터는 참 할 것도 많다.
이와 관련된 기사를 우선 읽어 보도록 하자.
2007년 8월 17일 ... 경로 의존성이란 어떤 기술이나 제품의 발전이 그 결과 이상으로 발전되어온 과정의 구체적인 내용과 형식에 영향을 받는다는 것이다. ...
내가 이 경로 의존성에 대해 처음 접하게 된 것은 EBS의 '지식채널 e'를 통해서였다.
그 뒤로 난 테스트를 할 때 경로 의존성에 대해 한번 더 생각해 보게 되었다.
경로 의존성은 테스트를 수행할 때 뿐만 아니라 컨설팅을 할 때도 가장 큰 제약 중의 하나로 작용된다.
그리고 나 자신도 알게 모르게 수용해 버리고 마는 많은 것들이 있다.
'한국 웹의 불편한 진실'과 '소프트웨어 누가 이렇게 개떡같이 만든 거야'라는 책을 읽으면서 나는 다시 한번 경로 의존성에 대해 생각해 보게 되었다.
일전에 썼던 '표준에 대한 단상'이나 'YES!!! Man을 거부해라'도 같은 맥락의 글이었다.
기술적인 표준에 관련된 경로 의존성을 깨뜨리기는 거의 불가능에 가깝다.
하지만 우리가 매너리즘에 빠지게 되는 많은 부분에서 경로 의존성의 극복은 의지의 문제이다.
많은 테스터들이 매너리즘에 빠진다.
항상 똑같은 테스트만 반복하다 보니 신선미나 독창성을 잃어버린다.
이것은 외국이나 국내나 사정이 별반 다르지 않다.
3년 이상 제대로 된 테스터 경력자를 구하기란 하늘의 별따기와 같다.
극소수의 테스터들도 관리자로 전향하면서 더 이상 경험이나 전문성과는 거리가 멀어져 버린다.
이것은 회사나 조직이 테스터에게 제대로 된 커리어 패스 하나 제시해 주지 못하기 때문이기도 하다.
하지만 매일 매일 똑같은 제품, 똑같은 테스트 케이스 수행을 하는 것에 대해서 "그거 원래 그런거야!! 바꿀 필요 없어!!"라는 주문에 과감히 "No"라고 외쳐보자.
테스팅의 범위는 무궁 무진하다. 아직까지 국내에서 테스팅이 진출할 범위는 무궁무진하다. 스스로 기회를 만들고 스스로 발전해 가는 테스터가 가득했으면 하는 바램이다.
최근 나는 UX 진영이나 웹표준 진영에 꾸준히 참석하고 있다. 이 영역은 전통적으로 아키텍쳐와 개발자의 영역이다. 난 아직까지 이 진영의 모임에서 테스터를 본 적이 없다.
나날이 UX나 웹 표준의 중요성이 증대되는 것에 반해 테스트를 수행해야 할 사람들은 이것에 아직까지 그렇게 큰 관심이 없는 듯 하다.
난 심지어 UX 진영에서 사용성 테스트는 아키텍쳐가 하는 것이고 테스트 진영에서 얘기하는 사용성 테스트는 우리가 하는 사용성 테스트와는 틀리다. 테스터가 왜 사용성 테스트에 관심을 가지는가? 라는 얘기도 들은 적이 있다.
하지만 난 그런 의견에 전적으로 반박한다. 아키텍쳐가 수행한 사용성 테스트 역시 검증해야 할 필요가 있다. 왜냐하면 그들도 사람이고 그들도 실수를 할 것이며 그렇다면 그것도 결함이 될 것이다.
테스터가 누구인가? 결함을 제거하고 예방하는 사람들이다. 그렇다면 그들이 하는 일을 알아야 할 필요가 있다.
자기 자신과 회사와 조직이 매너리즘에 빠지지 않도록 노력하자. 주변에 경로 의존성에 따라 정체된 부분을 살펴보자.
그리고 그것을 극복할 수 있도록 노력하고 연습하자.
그러고 보면 테스터는 참 할 것도 많다.
댓글
댓글 쓰기