Catro de cada cinco solicitantes de control de calidade queren aprender a traballar con probas automatizadas. Non todas as empresas poden cumprir estes desexos dos probadores manuais durante as horas de traballo. Wrike realizou unha escola de automatización para empregados e deuse conta deste desexo de moitos. Participei nesta escola precisamente como estudante de QA.
Aprendín a traballar con Selenium e agora soporta de forma independente un certo número de autotests sen practicamente axuda externa. E, a partir dos resultados da nosa experiencia conxunta e das miñas conclusións persoais, tentarei derivar a propia fórmula da escola de automatización máis ideal.
A experiencia de Wrike na organización dunha escola
Cando se fixo patente a necesidade dunha escola de automatización, a súa organización recaeu en Stas Davydov, o responsable técnico da automatización. Quen máis que el pode explicar por que se lles ocorreu esta iniciativa, se conseguiron resultados e se lamentan o tempo dedicado? Dámoslle a palabra:
— En 2016, escribimos un novo marco para as probas automáticas e fixémolo para que se fixera doado escribir probas: apareceron pasos normais, a estrutura fíxose moito máis comprensible. Ocorréusenos unha idea: hai que implicar a todos os que queiran escribir novas probas e, para facilitar a súa comprensión, creamos unha serie de charlas. Colectivamente elaboramos un plan de temas, cada un dos futuros profesores colleu un para si e elaborou un informe sobre el.
— Que dificultades tiveron os alumnos?
— Principalmente, por suposto, arquitectura. Houbo moitas preguntas sobre a estrutura das nosas probas. Nos comentarios, escribiuse moito sobre este tema e tivemos que realizar conferencias adicionais para explicalo con máis detalle.
-¿O colexio pagou?
- Si, definitivamente. Grazas a ela, moita xente participou nas probas de redacción e, de media, no hospital, todo o mundo comezou a comprender mellor o que son os autotest, como se escriben e como se lanzan. A carga dos enxeñeiros de automatización tamén diminuíu: agora recibimos moitas veces menos solicitudes de axuda para analizar probas, xa que os probadores e desenvolvedores comezaron a xestionar isto eles mesmos en case todas as situacións. Pois ben, hai varias vantaxes internas para o departamento: adquirimos experiencia en presentacións e conferencias, grazas á cal algúns enxeñeiros de automatización xa conseguiron facer presentacións en congresos, e tamén recibimos un potente conxunto de vídeos e presentacións para a incorporación de novos chegados.
No meu propio nome, engadirei que a comunicación entre os nosos departamentos simplificouse a un nivel francamente ridículamente sinxelo. Por exemplo, agora practicamente non teño que pensar en que casos e en que nivel de atomicidade automatizar. Como resultado, todas as partes interesadas están a coidar plenamente a cobertura das probas, que está en constante crecemento. Ninguén lles esixe o imposible aos demais.
En xeral, o impacto no traballo dos equipos é definitivamente positivo. Quizais os compañeiros que lean este artigo tamén estean pensando en facer algo semellante? Entón o consello será sinxelo: paga a pena se as probas automatizadas son unha prioridade para ti. A continuación, falaremos dunha cuestión máis complexa: como organizar todo isto o máis correctamente posible, para que os custos de todas as partes sexan mínimos e a saída sexa máxima.
Consellos de organización
A escola foi útil, pero, como admitiu Stas, houbo algunhas dificultades, polo que foi necesario organizar conferencias adicionais. E foi como un estudante recente comparándome -en ignorancia e eu mesmo- agora que formulei os seguintes pasos para crear, na miña opinión, a forma ideal de ensinar aos probadores a comprender as probas automatizadas.
Paso 0. Crea un dicionario
Por suposto, este paso é necesario non só para o control de calidade. Non obstante, quero facelo explícito: a base de código de automatización debe manterse nunha forma lexible. Linguaxes de programación - non menos importante idiomas, e desde isto podes comezar a túa inmersión.
Aquí tes unha captura de pantalla dunha vista de tarefas cos nomes dos elementos. Imaxinemos que estás probando taskview como unha caixa negra e nunca viu Selenium na túa vida. Que fai este código?
(Spoiler: a tarefa elimínase a través do resto en nome do administrador, e despois vemos que hai un rexistro diso no fluxo).
Só este paso achega as linguas QAA e QA. É máis fácil para os equipos de automatización explicar os resultados dunha execución; os probadores manuais teñen que gastar menos esforzo na creación de casos: poden ser menos detallados. Aínda así, todos se entenden. Recibimos as vitorias mesmo antes de comezar o adestramento real.
Paso 1. Repita frases
Sigamos o paralelismo coa lingua. Cando aprendemos a falar de pequenos non partimos da etimoloxía e da semántica. Repetimos "mamá", "mercar un xoguete", pero non entramos inmediatamente nas raíces protoindoeuropeas destas palabras. Así está aquí: non ten sentido mergullarse nas profundidades das características técnicas dos autotests sen tentar escribir algo que funcione.
Parece un pouco contraintuitivo, pero funciona.
Na primeira lección, paga a pena dar unha base sobre como escribir autotests directamente. Axudamos a configurar o ambiente de desenvolvemento (no meu caso, Intellij IDEA), explicamos as regras de linguaxe mínimas que son necesarias para escribir outro método nunha clase existente utilizando os pasos existentes. Escribimos con eles unha ou dúas probas e dámoslles deberes, que eu formatearía así: do mestre partiu unha rama, pero lle quitaron varias probas. Só quedan as súas descricións. Pedimos aos probadores que restauren estas probas (non a través de show diff, por suposto).
Como resultado, quen escoitou e fixo todo poderá:
- aprender a traballar coa interface do contorno de desenvolvemento: creando ramas, teclas de acceso rápido, commits e push;
- dominar os conceptos básicos da estrutura da linguaxe e das clases: onde inserir inxeccións e onde importar, por que se necesitan anotacións e que tipo de símbolos se atopan alí, ademais de pasos;
- comprender a diferenza entre acción, esperar e comprobar, onde usar que;
- observa a diferenza entre as probas automáticas e as comprobacións manuais: nas probas automáticas podes tirar dun ou outro controlador en lugar de realizar accións a través da interface. Por exemplo, envíe un comentario directamente ao backend en lugar de abrir unha vista de tarefas, seleccionar a entrada, escribir texto e facer clic no botón Enviar;
- formular preguntas que serán contestadas no seguinte paso.
O último punto é moi importante. Estas respostas pódense dar facilmente antes de tempo, pero é un principio de ensino importante que as respostas sen preguntas formuladas non se lembran e non se usan cando finalmente se necesitan.
O ideal sería que neste momento un enxeñeiro de automatización do equipo de control de calidade lle asignase a tarefa de escribir un par de probas na batalla e lle permitise subcomprometerse na súa rama.
Que non dar:
- un coñecemento máis profundo da funcionalidade do contorno de desenvolvemento e da propia linguaxe de programación, que só será necesario cando se traballe con ramas de forma independente. Non se lembrará, terás que explicalo dúas ou tres veces, pero valoramos o tempo dos enxeñeiros de automatización, non? Exemplos: resolver conflitos, engadir ficheiros a git, crear clases desde cero, traballar con dependencias;
- todo o relacionado con xpath. En serio. Hai que falar diso por separado, unha vez e moi concentrado.
Paso 2. Analizando a gramática
Lembremos a captura de pantalla da vista de tarefas do paso #0. Temos un paso chamado checkCommentWithTextExists. O noso probador xa entende o que fai este paso e podemos mirar dentro do paso e descompoñelo un pouco.
E dentro temos o seguinte:
onCommentBlock(userName).comment(expectedText).should(displayed());Onde está onCommentBlock
onCommonStreamPanel().commentBlock(userName);Agora aprendemos a dicir non "mercar un xoguete", senón "mercar un xoguete na tenda Detsky Mir, situada no armario azul do terceiro andel dende a parte superior". É necesario explicar que sinalamos un elemento secuencialmente, a partir de elementos máis grandes (fluxo -> bloque con comentarios dunha determinada persoa -> esa parte deste bloque onde se atopa o texto especificado).
Non, aínda non é hora de falar de xpath. Só ten que mencionar brevemente que todas estas instrucións son descritas por eles e a herdanza pasa por elas. Pero hai que falar de todos estes emparejadores e camareiros, que se relacionan especificamente con este paso e son necesarios para entender o que está a pasar. Pero non te sobrecargues: o teu estudante pode estudar as afirmacións máis complexas por si mesmo máis tarde. O máis probable é que debería, waitUntil, displayed();, exist();, not(); debería ser suficiente.
O deber é obvio: unha rama na que se eliminou o contido de varios pasos que son necesarios para un determinado número de probas. Deixa que os probadores os restauren e faga que a carreira volva ser verde.
Ademais, se o equipo de probas non só ten novas funcións no seu traballo, senón tamén algunhas correccións de erros, podes pedirlle que escriba inmediatamente probas para estes erros e que os libere. O máis probable é que xa se describisen todos os elementos; só poden faltar un par de pasos. Este será o adestramento perfecto.
Paso 3. Inmersión total
O máis completo posible para un probador que vai seguir desempeñando as súas funcións directas. Finalmente, temos que falar de xpath.
En primeiro lugar, deixemos claro que todos estes enCommentBlock e comentarios son descritos por eles.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"A orde da historia é moi importante. En primeiro lugar, tomamos calquera xpath existente e mostramos como a pestana de elementos contén un e só un elemento. A continuación, falaremos da estrutura: cando necesitas usar WebElement e cando necesitas crear un ficheiro separado para un novo elemento. Isto permitirache comprender mellor a herdanza.
Débese indicar explícitamente que un único elemento é a vista de tarefas completa, que contén un elemento fillo - o fluxo completo, que contén un elemento fillo - un comentario separado, etc. Os elementos fillos están dentro dos elementos pai tanto na páxina como na estrutura do marco de proba automática.
Neste punto, o público debería ter entendido firmemente como se herdan e que se pode introducir despois do punto en onCommentBlock. Neste punto, explicamos todos os operadores: /, //, ., [] etc. Engadimos coñecementos sobre o uso á carga @class e outras cousas necesarias.
Os estudantes deben entender como traducir xpath deste xeito. Para consolidar - iso é certo, deberes. Eliminamos as descricións dos elementos, deixamos que restauren o traballo das probas.
Por que este camiño en particular?
Non debemos sobrecargar a unha persoa con coñecementos complexos, pero debemos explicar todo á vez, e este é un dilema difícil. Este camiño permitiranos facer primeiro que os oíntes fagan preguntas e non entendan algo e as respondan no momento seguinte. Se falas de toda a arquitectura, cando se analice o tema dos pasos ou xpath, as partes máis importantes dela xa se esquecerán debido á súa incomprensibilidade.
Non obstante, algúns de vostedes probablemente poderán compartir a súa experiencia sobre como se pode optimizar aínda máis o proceso. Estarei encantado de ler suxestións similares nos comentarios!
Fonte: www.habr.com