학교로 돌아가서: 자동화된 테스트를 처리하기 위해 수동 테스터를 교육하는 방법

QA 지원자 5명 중 4명은 자동화된 테스트 작업 방법을 배우고 싶어합니다. 모든 회사가 근무 시간 동안 수동 테스터의 이러한 요구를 충족할 수 있는 것은 아닙니다. Wrike는 직원들을 위한 자동화 학교를 열었고 많은 사람들의 이러한 열망을 실현했습니다. 저는 바로 이 학교에 QA 학생으로 참여했습니다.

나는 Selenium으로 작업하는 방법을 배웠고 이제는 사실상 외부 도움 없이 특정 수의 자동 테스트를 독립적으로 지원합니다. 그리고 우리의 공동 경험 결과와 개인적인 결론을 바탕으로 가장 이상적인 자동화 학교에 대한 공식을 도출하려고 노력할 것입니다.

Wrike의 학교 조직 경험

자동화 학교의 필요성이 분명해지자 자동화 학교의 조직은 자동화 기술 책임자인 Stas Davydov에게 넘어갔습니다. 그가 왜 이 계획을 생각해 냈는지, 결과를 얻었는지, 보낸 시간을 후회하는지 설명할 수 있는 사람은 누구입니까? 그에게 바닥을 줍시다:

— 2016년에 우리는 자동 테스트를 위한 새로운 프레임워크를 작성하여 테스트 작성이 쉬워지도록 만들었습니다. 일반 단계가 나타나고 구조가 훨씬 더 이해하기 쉬워졌습니다. 우리는 아이디어를 내놓았습니다. 새로운 테스트를 작성하려는 모든 사람을 참여시키고 더 쉽게 이해할 수 있도록 일련의 강의를 만들었습니다. 우리는 공동으로 주제 계획을 세웠고, 미래의 강사들은 각자 하나씩 주제를 선택하여 이에 대한 보고서를 준비했습니다.

— 학생들은 어떤 어려움을 겪었나요?

— 물론 주로 건축이죠. 테스트 구조에 대한 많은 질문이 있었습니다. 피드백 중에 이 주제에 관해 많은 글이 쓰여졌고, 더 자세히 설명하기 위해 추가 강의를 해야 했습니다.

— 학교는 성과를 거두었나요?

- 네, 물론이죠. 그녀 덕분에 많은 사람들이 테스트 작성에 참여했고 평균적으로 병원에서는 모든 사람들이 자동 테스트가 무엇인지, 어떻게 작성되고 어떻게 실행되는지 더 잘 이해하기 시작했습니다. 자동화 엔지니어의 부담도 감소했습니다. 이제 테스터와 개발자가 거의 모든 상황에서 이 문제에 스스로 대처하기 시작했기 때문에 테스트 분석에 대한 도움 요청을 훨씬 더 적게 받았습니다. 글쎄, 부서에는 몇 가지 내부 이점이 있습니다. 일부 자동화 엔지니어가 이미 컨퍼런스에서 프레젠테이션을 할 수 있었고 신규 입사자를 위한 강력한 비디오 및 프레젠테이션 세트를 받은 덕분에 우리는 프레젠테이션 및 강의 경험을 얻었습니다.

저를 대신하여 부서 간의 의사소통이 터무니없을 정도로 쉬운 수준으로 단순화되었다는 점을 덧붙이겠습니다. 예를 들어, 이제 어떤 사례와 어떤 수준의 원자성을 자동화할지 고민할 필요가 거의 없습니다. 그 결과, 모든 이해관계자들이 지속적으로 성장하고 있는 테스트 커버리지에 만전을 기하고 있습니다. 누구도 다른 사람에게 불가능한 것을 요구하지 않습니다.

일반적으로 팀 작업에 미치는 영향은 확실히 긍정적입니다. 아마도 이 글을 읽고 있는 동료들도 비슷한 일을 해볼 생각을 하고 있지 않을까? 그렇다면 조언은 간단할 것입니다. 자동화된 테스트가 우선순위라면 그만한 가치가 있습니다. 다음으로, 더 복잡한 질문에 대해 이야기하겠습니다. 이 모든 것을 가능한 한 정확하게 구성하여 모든 당사자의 비용을 최소화하고 출력을 최대화하는 방법입니다.

정리 팁

학교는 유용했지만 Stas가 인정했듯이 몇 가지 어려움이 있었기 때문에 추가 강의를 준비해야했습니다. 그리고 나는 무지한 나 자신과 나 자신을 비교하는 최근 학생으로서 테스터가 자동화된 테스트를 이해하도록 가르치는 이상적인 방법을 만들기 위해 다음 단계를 공식화했습니다.

0단계. 사전 만들기

물론 이 단계는 QA에만 필요한 것은 아닙니다. 그러나 저는 이를 명시적으로 밝히고 싶습니다. 자동화 코드베이스는 읽을 수 있는 형식으로 유지되어야 합니다. 프로그래밍 언어 - 적어도 언어, 여기에서 다이빙을 시작할 수 있습니다.

다음은 요소 이름이 포함된 작업 보기의 스크린샷입니다. 당신이 taskview를 블랙박스로 테스트하고 있고 평생 동안 Selenium을 본 적이 없다고 상상해 봅시다. 이 코드는 무엇을 합니까?

(스포일러 - 관리자를 대신하여 나머지 작업을 통해 작업이 삭제된 후 스트림에 이에 대한 기록이 있는 것을 볼 수 있습니다.)

이 단계만으로도 QAA와 QA 언어가 더 가까워집니다. 자동화 팀이 실행 결과를 설명하기가 더 쉽고, 수동 테스터는 사례를 만드는 데 더 적은 노력을 들이게 되어 덜 상세하게 만들 수 있습니다. 그래도 모두가 서로를 이해합니다. 실제 훈련이 시작되기도 전에 우리는 상금을 받았습니다.

1단계. 문구 반복

언어와의 병행을 계속합시다. 우리가 어릴 때 말하는 법을 배울 때 어원이나 의미론부터 시작하지 않습니다. 우리는 "엄마", "장난감 구입"을 반복하지만 이러한 단어의 원시 인도 유럽 어근에 즉시 들어 가지 않습니다. 그래서 여기 있습니다. 작동하는 것을 작성하지 않고 자동 테스트의 기술적 기능을 깊이 파고드는 것은 의미가 없습니다.
약간 반직관적으로 들리지만 작동합니다.

첫 번째 강의에서는 자동 테스트를 직접 작성하는 방법에 대한 기초를 제공하는 것이 좋습니다. 우리는 개발 환경(제 경우에는 Intellij IDEA) 설정을 돕고 기존 단계를 사용하여 기존 클래스에 다른 메서드를 작성하는 데 필요한 최소 언어 규칙을 설명합니다. 우리는 그들과 함께 하나 또는 두 개의 테스트를 작성하고 그들에게 숙제를 줍니다. 나는 다음과 같이 형식화할 것입니다: 브랜치가 마스터에서 분기되었지만 마스터에서 여러 테스트가 제거되었습니다. 그들의 설명만 남습니다. 우리는 테스터에게 이러한 테스트를 복원하도록 요청합니다(물론 show diff를 통하지 않음).

결과적으로 모든 일을 듣고 행한 사람은 다음과 같은 일을 할 수 있습니다.

1. 개발 환경 인터페이스 작업 방법 배우기: 브랜치, 단축키, 커밋 및 푸시 생성
2. 언어 및 클래스 구조의 기본 사항을 숙지합니다. 주입을 삽입할 위치와 가져올 위치, 주석이 필요한 이유, 단계 외에 거기에서 어떤 종류의 기호가 발견되는지.
3. 행동, 대기, 확인의 차이를 이해하고, 무엇을 사용할지;
4. 자동 테스트와 수동 검사의 차이점을 확인하세요. 자동 테스트에서는 인터페이스를 통해 작업을 수행하는 대신 하나 또는 다른 핸들러를 가져올 수 있습니다. 예를 들어 작업 보기를 열고, 입력을 선택하고, 텍스트를 입력하고 보내기 버튼을 클릭하는 대신 백엔드에 직접 의견을 보냅니다.
5. 다음 단계에서 답변할 질문을 공식화합니다.

마지막 요점은 매우 중요합니다. 이러한 답변은 미리 쉽게 주어질 수 있지만, 공식화된 질문이 없는 답변은 기억되지 않으며 최종적으로 필요할 때 사용되지 않는 것이 중요한 교수 원리입니다.

이때 QA 팀의 자동화 엔지니어가 그에게 전투에서 몇 가지 테스트를 작성하는 작업을 할당하고 그의 지점에 하위 커밋을 허용하는 것이 이상적입니다.

주지 말아야 할 것:

1. 개발 환경의 기능과 프로그래밍 언어 자체에 대한 심층적인 지식은 독립적으로 브랜치를 작업할 때만 필요합니다. 기억나지도 않고 두 번, 세 번 설명해야 하지만 우리는 자동화 엔지니어의 시간을 소중히 여기죠? 예: 충돌 해결, git에 파일 추가, 처음부터 클래스 생성, 종속성 작업;
2. xpath와 관련된 모든 것. 진지하게. 그것에 대해 별도로, 단번에 매우 집중적으로 이야기해야 합니다.

Step 2. 문법 자세히 살펴보기

0단계의 작업 보기 스크린샷을 기억해 봅시다. checkCommentWithTextExists라는 단계가 있습니다. 테스터는 이미 이 단계의 기능을 이해하고 있으므로 단계 내부를 살펴보고 조금 분해할 수 있습니다.

그리고 내부에는 다음이 있습니다.

onCommentBlock(userName).comment(expectedText).should(displayed());

onCommentBlock은 어디에 있나요?

onCommonStreamPanel().commentBlock(userName);

이제 우리는 "장난감을 사세요"라고 말하는 것이 아니라 "맨 위에서 세 번째 선반에 있는 파란색 캐비닛에 있는 Detsky Mir 매장에서 장난감을 사세요"라고 말하는 법을 배웁니다. 더 큰 요소(스트림 -> 특정 사람의 댓글이 있는 블록 -> 지정된 텍스트가 있는 이 블록의 부분)에서 순차적으로 요소를 가리킨다는 점을 설명할 필요가 있습니다.

아니요, 아직은 xpath에 대해 이야기할 때가 아닙니다. 이러한 모든 지침이 설명되어 있으며 상속이 이를 통해 진행된다는 점을 간략하게 언급하십시오. 하지만 우리는 이러한 모든 matcher와 waiter에 대해 이야기해야 합니다. 이들은 특히 이 단계와 관련되어 있으며 무슨 일이 일어나고 있는지 이해하는 데 필요합니다. 하지만 너무 많이 하지 마세요. 학생이 나중에 스스로 더 복잡한 주장을 공부할 수 있습니다. 아마도 should, waitUntil,display();,exist();, not();이면 충분할 것입니다.

숙제는 분명합니다. 특정 횟수의 테스트에 필요한 여러 단계의 내용이 제거된 분기입니다. 테스터가 이를 복원하고 실행을 다시 녹색으로 만들도록 하십시오.

또한 테스트 팀의 작업에 새로운 기능이 있을 뿐만 아니라 일부 버그 수정도 있는 경우 즉시 이러한 버그에 대한 테스트를 작성하고 릴리스하도록 요청할 수 있습니다. 대부분의 경우 모든 요소가 이미 설명되어 있으므로 몇 가지 단계만 누락되었을 수 있습니다. 이것은 완벽한 운동이 될 것입니다.

3단계. 완전 몰입

직접 업무를 계속 수행할 테스터를 위해 최대한 완벽하게 만듭니다. 마지막으로 xpath에 대해 이야기해야 합니다.

먼저, 이러한 onCommentBlock 및 주석이 모두 설명되어 있음을 분명히 하겠습니다.

총계 :

"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

이야기의 순서는 매우 중요합니다. 먼저 기존 xpath를 가져와 요소 탭에 요소가 하나만 포함되어 있는 방법을 보여줍니다. 다음으로 구조에 대해 이야기하겠습니다. WebElement를 사용해야 하는 경우와 새 요소에 대해 별도의 파일을 만들어야 하는 경우입니다. 이를 통해 상속을 더 잘 이해할 수 있습니다.

단일 요소는 전체 taskview이고 하위 요소(하위 요소를 포함하는 전체 스트림), 별도의 주석 등을 포함한다는 점을 명시적으로 명시해야 합니다. 하위 요소는 페이지와 자동 테스트 프레임워크 구조 모두에서 상위 요소 내부에 있습니다.

이 시점에서 청중은 어떻게 상속되는지, onCommentBlock에서 점 뒤에 무엇을 입력할 수 있는지 확실히 이해해야 합니다. 이 시점에서는 /, //, ., [] 등 모든 연산자를 설명합니다. 사용에 대한 지식을 로드에 추가합니다. @class 그리고 기타 필요한 것들.

학생들은 xpath를 이런 식으로 변환하는 방법을 이해해야 합니다. 통합하려면 - 맞습니다, 숙제입니다. 요소에 대한 설명을 삭제하고 테스트 작업을 복원하도록 합니다.

왜 이 특별한 경로가 있습니까?

복잡한 지식으로 사람에게 과부하를 주어서는 안 되지만, 모든 것을 한꺼번에 설명해야 하는데 이것이 어려운 딜레마이다. 이 경로를 통해 우리는 먼저 청취자가 질문을 하고 무언가를 이해하지 못하고 바로 다음 순간에 대답하게 만들 수 있습니다. 전체 아키텍처에 대해 이야기하면 단계 또는 xpath 주제가 분석될 때 가장 중요한 부분은 이해할 수 없기 때문에 이미 잊혀질 것입니다.

그러나 여러분 중 일부는 프로세스를 더욱 최적화할 수 있는 방법에 대한 경험을 공유할 수 있을 것입니다. 댓글에서 비슷한 제안을 기꺼이 읽어보겠습니다!

출처 : habr.com