제목이 다 나와 있습니다. 회사의 일부 직원은 자동화 된 테스트가 "쉽고"COM 및 UI 테스트를 작성하는 데 "하루가 걸린다"고 생각합니다. 이에 대응하기 위해 무엇을 할 수 있습니까?
참고 : 자동화를 홍보하는 방법에 대해서는 묻지 않습니다. 그것은 문제가 아닙니다. 자동화 된 테스트 및 프로세스가 항상 홍보되고 요청되고 있습니다. 문제는 일부 개인이 자동화가 "쉬운"것이 아니라 "빠르지"않다는 것을 이해하지 못한다는 것입니다.
제목이 다 나와 있습니다. 회사의 일부 직원은 자동화 된 테스트가 "쉽고"COM 및 UI 테스트를 작성하는 데 "하루가 걸린다"고 생각합니다. 이에 대응하기 위해 무엇을 할 수 있습니까?
참고 : 자동화를 홍보하는 방법에 대해서는 묻지 않습니다. 그것은 문제가 아닙니다. 자동화 된 테스트 및 프로세스가 항상 홍보되고 요청되고 있습니다. 문제는 일부 개인이 자동화가 "쉬운"것이 아니라 "빠르지"않다는 것을 이해하지 못한다는 것입니다.
답변:
제 역할에서 저는 특히 개발 프로젝트에서 많은 "x는 쉬워요"사람들을 만났습니다. 제 생각에는이 세 가지 이유가 있습니다.
1) 그들은 자신이 말하는 것을 실제로 이해하지 못하지만 마치 소리처럼 들리는 것을 매우 좋아합니다.
2) 그들은 두 권의 책을 읽었으며 그들이 무엇을 이야기하는지 알고 있다고 생각합니다.
3) 마지막으로 사람들은 컴퓨터가 빠르기 때문에 컴퓨터가 빠른 테스트를 수행한다고 가정합니다.
이 문제를 해결하는 확실한 방법은 정기적으로 사용자를 참여시키는 것입니다. 프로젝트를위한 커뮤니케이션 전략이 중요합니다. 비 기술적 인 사용자에게 자동화 된 테스트의 기능을 설명하는 것은 쓸데없는 일이지만 관련된 프로세스를 인식하게합니다. 도움이 될 수 있습니다. 다음 번에 문서, 워크샵 또는 친절한 채팅을 통해이 작업을 수행 할 수 있습니다.
나는 심지어이 "x는 쉬운"사람들 중 가장 큰 BA 싱글을 보았고 단순히 부서에서 하루를 보내도록 초대했습니다. "내가 무슨 말을하는지 모르겠다. 내가 틀렸다고 생각한다."
소프트웨어는 사물을 자동화하는 사업입니다.
우리는 지루하고 반복적이며 노동 집약적 인 작업을보다 쉽게하기 위해 소프트웨어를 작성합니다. 우리는 보고서 작성, 데이터 수집, 다른 사람과의 의사 소통 등을 자동화하는 소프트웨어를 작성합니다. 자동화 된 테스트 작성은 실제로 다른 소프트웨어가 예상 한대로 작동하도록 소프트웨어를 작성하는 것입니다.
동료가 소프트웨어 작성이 어렵고 시간이 걸린다는 것을 이해하면 더 많은 소프트웨어를 작성하는 것이 힘들고 시간이 걸린다는 것을 쉽게 알 수 있습니다. 자동화의 모든 이점을 무료로 얻는 것이 좋지만, 항상 그렇듯이 나중에 혜택을 얻으려면 작업을 미리해야합니다.
그들이 이해하지 못한다면, 가르치는 일이나 이력서를 연마하는 일을해야합니다.
writing software is hard and takes time
. 작은 명령 줄 앱을 작성하는 것이 빠릅니다. 스카이 넷 IA를 작성하는 것은 어렵습니다. 그러한 일반적인 말을한다고해서 아무도 설득 할 수는 없습니다.
대부분의 직원은 회사의 "전면"(고객-주주 이해 관계자 대면) 또는 "백업"( "실제"작업이 수행되는)에서 시간을 보냅니다. 이 두 기능은 거의 반대입니다. (그리고 둘 다 일한 사람은 거의 없습니다). 결과적으로 두 그룹 사이에 종종 오해가 있습니다.
예를 들어 "정면"사람들을 교육하는 가장 좋은 방법은 하루 중 몇 명을 "뒤로"보내는 것입니다. 그들이 "...의 삶에서 하루"를 마쳤다면, 하루에 무엇을 할 수 있는지, 그리고 자동화 된 테스트를 실행하는 데 더 많은 시간과 노력이 필요한 이유에 대해 더 현실적인 아이디어를 갖게 될 것입니다. 마찬가지로 "뒤로"사람들은 "앞"에서 하루나 이틀의 혜택을 볼 수 있습니다.
"부자가되는 방법"에서, 존 폴 게티 (John Paul Getty, 당시의 거물)는 그러한 "교차 훈련"을 옹호했습니다. 그의 관점에서 볼 때, 제품을 제조 한 조립 라인에서 시간을 보낸 세일즈맨은 훨씬 더 나은 판매 작업을 수행 할 것이며, 고객과 하루를 보낸 엔지니어는 "디버깅"작업을 더 잘 수행 할 것입니다.
문제는 일부 개인이 자동화가 "쉬운"것이 아니라 "빠르지"않다는 것을 이해하지 못한다는 것입니다.
나는 당신의 전제에 동의하지 않습니다.
단위 테스트, 통합 테스트 또는 UI 테스트에 관계없이 자동화 된 테스트의 큰 지지자입니다. 자동화 된 테스트를 구현할 수있는 유용한 도구가 많이 있습니다.
다음 예제를 기반으로 자동 테스트와 수동 테스트를 비교해 보겠습니다.
웹 응용 프로그램에서 브라우저를 사용하여 기존 사용자의 "비밀번호 변경"기능을 테스트하십시오.
수동 테스트 :
쉬운? 실제로는 아닙니다. 그 과정에서 많은 함정이 있습니다.
빠른? 제 수동 작업 시간이 걸립니다.
이제 자동 테스트 를 작성해 보겠습니다 .
쉬운? 아니! 우리는 도구를 연구하고, 구현하고, 테스트에서 일부 버그를 수정해야했습니다.
빠른? 아니! 수동 테스트보다 시간이 오래 걸립니다.
그러나 여기에는 큰 차이가 있습니다. 향후 테스트의 경우 목록의 마지막 글 머리 기호 인 테스트 자체 만 작성하면됩니다 . 추가 연구를 위해 모든 연구 및 초기화 스크립트를 수행 할 필요는 없습니다.
테스트를 작성한 후에는 쉽게 시작할 수 있습니다. 몇 초 안에 (또는 데이터베이스와 웹 응용 프로그램을 시작하는 데 몇 분이 걸리는 경우) "비밀번호 변경"루틴이 작동하는지 작동하지 않는지 확인할 수 있습니다. 버그가 있으면 수정 한 후 테스트를 다시 실행 하십시오. 버그가 수정되었는지 즉시 확인할 수 있습니다. 빠르고 쉬운 .
자동화 된 테스트 작성은 처음에는 쉽지도 빠르지 않지만 실행은 쉽습니다.
그리고 이것이 투자 된 시간이 돌아 오는 지점입니다.
일반적으로 테스트는 쉽지 않으며 그렇게해서는 안됩니다. Boeing 또는 Mercedes가 제품을 엄격하게 테스트하지 않으면 소송으로 인해 파산되거나 품질이 좋지 않은 품목을 판매하는 사업이 중단됩니다. 운전대가 조각으로 떨어지거나 떨어지지 않을 것임을 알고 시간당 70 마일로 차를 운전하겠습니까?
사람들이 누구인지 또는 그 이유를 이해하지 않고 사고 방식에 대처하는 방법을 제안하는 것은 매우 어렵습니다. 대부분의 관리자와 이사는 비용을 생각하고 생산 된 내용에 따라 판단됩니다. 이 기준을 사용하면 시험 시간을 정당화하기가 매우 어렵습니다. 이런 경우라면이 과제를 장기적으로 유익한 것으로 제시 할 수있는 방법을 찾아야합니다.
소프트웨어가 실현 가능하지 않다고해서 우리가 작동하지 않는 시스템의 영향에 대해 생각하지 않고 도망 갈 수있는 것은 아닙니다. 아마존은 자동화 된 테스트를 거쳤으며 웹 사이트 / 서비스의 비용 영향에 대해 너무 잘 알고있는 사람들이 있다고 확신합니다.
2 +2 = 4는 모두가 이해하는 가장 간단한 코드 중 하나입니다. 그리고 당신은 쉽게 이해하는 방법을 볼 수 있습니다. 그러나 이것이 "쉬운"방정식이라는 의미는 아닙니다. 간단한 방정식에 도달하는 데 필요한 추상화 수준은 매우 복잡합니다. 소프트웨어 및 소프트웨어 테스트 방법론에서도 마찬가지입니다. 코드 조각이 필요한 추상화 수준에는 많은 작업이 필요합니다.
모범 사례는 클래스와 객체를 재사용하지만 시간과 노력을 투자하기 위해서는이 상태에 도달하는 것이 필요 하다는 것은 사실입니다 .
이 질문에는 두 가지 측면이 있습니다.
당신 편에서, 당신은 당신이 잘하고 있다고 생각하는 것처럼 보이고, "자동화가 쉽다"그룹은 그들이 무엇을 말하는지 모른다고 생각합니다.
그들이 말한 바에 따르면 자동화 테스트는 오랜 시간이 걸리는 것을 볼 수 있습니다.
이 거리에서 우리는 조금만 가면 누가 "옳은지"또는 "누군가"인지 알 수 없습니다.
자동화를 다루는 방법은 쉬운 사고 방식
그들과 대화하십시오. 더 나은 방법에 대한 아이디어를 정직하게 요청하십시오. 참여하고 참여하도록하십시오. 그들이 실제로 긍정적 인 것을 제공하는지 알아내는 유일한 방법입니다. 어쩌면 그들은 가치있는 공헌을 할 수도 있고, 승리 / 승리를 달성 할 수 있습니다.
프로그래밍 및 자동화 된 테스트의 작동 방식에 대한 실제 아이디어 나 생산성 향상 방법에 대한 현실적인 아이디어가 없다면 적극적으로 참여하여 수행 방식 및 시간을 표시 할 수 있습니다. 그들의 의견 / 아이디어에 대해 감사하며 겸손하고 긍정적으로 행동하십시오. 그들이 한 말에 대해 생각해보십시오. 그들의 제안이 당신을 위해 다른 사고 방식을 유발할 수 있습니다. 그렇다면 의견을 보내주십시오. 겸손하고 긍정적 인 태도로 승리를 거둘 수도 있습니다.
대화 하기 전에 테스트를 구축, 실행 및 관리하는 방법에 대해 생각하십시오. 어떤 프레임 워크를 사용하고 있습니까? 더 나을 수있는 다른 사람들이 있습니까? "표준"상용구가 있습니까? 테스트를보다 자동화 할 수 있습니까? 무엇이 당신을 뒤로 잡고 있습니까?