Hermit Under the Cliff

이직한 회사에서 입사전 개인 정보를 입력하는 단계에서 명패 문구를 적으라고 해서 조금 고민을 하다가 "해치지 않아요" 로 결정을 했습니다. 조금은 까칠해 보이는 저의 인상에 대한 오해를 풀 문구이기도 하였지만 자동화 엔지니어 측면에서도 다른 QA들에게 해가 되지 않는다는 그런 뜻도 있습니다. QA 조직내에서 자동화 구현을 하면서 지내온 시간들 중 가장 자주 들었던 말 중 하나가 "그래서 얼마까지 줄일 수 있는데?" 라는 윗 분들의 말과 "그러면 우리 일 없어지는 거에요?" 라는 동료들의 농담 섞인 말이었습니다. 물론 장난스러운 말로 "내가 다 자동화 해버려서 너님을 쓸모없게 만들어버리겠어!" 라는 말을 안해본 것은 아니지만 테스트 자동화의 목적은 리소스를 줄이고, 이에 따른 비용을 줄이는데에만 있지 않습..

BDD (Behavior Driven Development) 는 아래와 같이 Given, When, Then 을 이용하여 사용자 시나리오를 정의하는 것에서 부터 출발합니다. 이러한 사용자 시나리오를 바탕으로 Cucumber 등의 프레임워크를 이용해서 TDD에 사용될 Test case들을 만드는 등의 형태로 많이 설명이 됩니다. 개발과는 한발짝 떨어진, User Level의 End to End test를 하는 QA 입장에서 이런 BDD 방법론을 개발팀을 설득해서 도입하는 것 이전에 테스트에 도입을 할 만한 방안이 없을까 고민을 해 봅니다. User Level의 End to End Test의 경우 자동화된 테스트에서 Cucumber 등을 이용하여 BDD 형식을 도입을 하더라도 들인 시간 대비 얻는 이점이 그..

회사 생활을 하다보면 Top-Down 방식으로 위에서 부터 내려오는 일들이 참 많습니다. 하지만 실제 일을 직접하는 입장에서는 이 탑다운으로 꽂히는 일이 반갑지 않고, 오히려 업무에 방해가 되는 경우도 있습니다. 실제 업무를 진행하는 사람들이 필요에 의해서 개선활동을 하고 이것이 Bottom-Up이 되어 하나의 문화를 만들어 가는것, 말은 정말 아름답지만 그렇게 쉽지만은 않습니다. (현실은, 개선아이디어 하나씩 제출해! 우리팀이 제일 꼴찌야!!) 테스트 자동화에 대해서 - 특히 QA 조직에서 - Top-Down으로 내려오는 지시중 하나가 테스트 자동화를 적용해서 얼마의 리소스를 줄여라. 이런 식인 경우가 많죠. 최악의 경우는 위에서 내려오는 숫자에 맞추려고 의미도 없는 숫자의 자동화 테스트 개발을 해서 ..

테스트만 전문적으로 하는 QA조직내에서의 테스트 자동화 업무로 밥을 벌어먹고 산지가 어느새 10년이 훌쩍 넘어버렸습니다. 다행히 나이만 먹은게 아니라 이 일을 계속해서 해나가면서 어느정도 통찰력이라는 것이 생기긴 하였습니다. 개발 조직내에서의 테스트 자동화는 그래도 요즘 개발 방법론에 따라서 Uint test, Integration test, System test 등을 잘 하고 있는 조직들도 있고 이런 것들을 하려고 노력하고 있는 곳들도 많이 있습니다. 빌드 시스템을 자동화하면서 CI/CD를 구축하거나 DevOps를 도입하거나 하는 식으로 자동화 테스트에 대한 요구와 필요성이 점점 대두되고 있는 느낌입니다. 하지만 QA조직에서는 (제 좁은 경험일지는 모르겠으나) 자동화 테스트의 인기가 개발 조직보다는 덜..