Los enfoques de desarrollo en los últimos diez años han sufrido cambios importantes, los requisitos para los probadores (QA, QE, ingenieros de calidad) también han cambiado. Pero no todos los evaluadores están listos para pasar a un nivel completamente nuevo. Ayer fue posible salir de la calle para ingresar a la profesión. Para convertirse en un especialista solicitado hoy, debe ser ingeniero.
Al comenzar una carrera, se mostró una presentación en los cursos que corroboraba la necesidad de realizar pruebas. La firma de la diapositiva decía: "Cuanto antes encuentre un error en el ciclo de vida del producto, más barato será su solución". Las tasas de pruebas son más bajas que para los programadores. Contratamos probadores → aseguramos la calidad y ahorramos en desarrollo. Beneficio!
Los probadores eran cazadores de insectos. Los programadores escriben funciones, se está preparando una versión, la versión pasa por la etapa de control de calidad. En ese momento, el probador "se puso el sombrero" de un usuario real y comenzó a ejecutar escenarios típicos. Se creía que una persona sin antecedentes técnicos sería adecuada para este puesto.
La velocidad de desarrollo de proyectos modernos ha aumentado. Apareció el concepto de CI / CD. Nadie se sorprende con los proyectos de lanzamiento diario. Las empresas se dieron cuenta de que los controles manuales no son escalables. Los probadores se dedicaron a la automatización de las pruebas de aceptación utilizando Selenium o marcos similares. El cambio en el interior está oculto, si solo la interfaz permanece con los localizadores necesarios.
Y así fue. Para los gerentes, la automatización de pruebas está asociada con una habilidad: trabajar con Selenium. En busca de una bala de plata, vieron en él la respuesta a todas las preguntas. El mercado se ha ajustado a la demanda.
Hemos estado buscando la automatización del control de calidad para probar los servicios web durante mucho tiempo. Revisé un par de cientos de currículums y realicé docenas de entrevistas. Si para resumir las impresiones, se pueden distinguir tres problemas principales, que a menudo impiden que uno contrate a una persona.
1. Los evaluadores no tienen idea de la arquitectura del proyecto.
Aquí, por arquitectura, me refiero a una descripción de alto nivel de las interacciones de los componentes del sistema. Convencionalmente, a través de qué "canalizaciones" fluyen los datos, dónde se almacenan y cómo se utilizan.
Durante la entrevista, el candidato puede objetar, dicen, no necesitamos conocimientos de arquitectura. Trabajamos con una caja negra. ¿Por qué cuidar la estructura interna?
No creo que con este enfoque el ingeniero presente todos los escenarios de prueba posibles. Si conoce la estructura interna del producto y lee el código, puede evitar la duplicación de pruebas en los niveles altos de la pirámide de prueba.
Variante piramidal de Martin Fowler
En las pruebas de caja negra, existe la misma trampa que en la seguridad a través de la oscuridad . No puede confiar únicamente en este tipo de pruebas. El producto puede cumplir los requisitos establecidos, al tiempo que incluye una gran cantidad de errores ocultos. Entonces, por analogía con la seguridad a través de la oscuridad, la única garantía de calidad será nuestra ignorancia de cómo se organiza el sistema en su interior.
La ventaja de las pruebas de caja negra es que las pruebas son independientes de la implementación. Wow Pero esta restricción artificial no debería interferir con la comprensión del interior. Cuando el probador sabe cómo funciona el producto:
- Ante un error, es capaz de localizar el problema y no construir hipótesis.
- En la discusión de una nueva característica, está listo para dar su opinión, porque entiende cómo la nueva característica se integra con los componentes existentes.
Malevich agita por probar la caja negra
Probablemente el mismo amor por la caja negra condujo al segundo problema.
2. Los probadores no entienden lo que sucede dentro del navegador
A menudo hay una situación en la que un candidato cuyo selenio se indica como la herramienta principal en el currículum no comprende cómo funcionan el navegador y el protocolo HTTP. La prueba de dichos automatizadores es principalmente la creación de scripts con acciones del usuario. Un enfoque superficial que crea restricciones innecesarias.
La mayoría de los solicitantes mencionan ejemplos de códigos HTTP y tipos de solicitudes HTTP. La siguiente pregunta es a menudo desconcertante.
Hay una página de inicio de sesión. El usuario ingresa los datos correctos para la autorización y hace clic en el botón de inicio de sesión. ¿Qué está pasando en el navegador en este momento? ¿Por qué las acciones posteriores con el sitio no requieren una nueva autorización?
Si el evaluador no respondió a estas preguntas, se desliza una duda sobre su competencia. Esto sugiere que el candidato:
- no puede probar un producto sin una interfaz de usuario;
- No sabe cómo usar las Herramientas para desarrolladores en un navegador;
- No estoy acostumbrado a descubrir la causa del error (frontend o backend).
Será más fácil para el desarrollador corregir el error si se describe con detalles técnicos.
3. Actitud negligente hacia el código de prueba
"Mi código no entrará en producción, ¿por qué preocuparse por la calidad?"
Veo esto como un intento de dividir los sandboxes. Dejemos que los desarrolladores se encarguen de la limpieza del código, pero nosotros podemos.
¿Recuerda que en el modelo en cascada después del desarrollo hubo una etapa de verificación? Durante el tiempo de la metodología Waterfall, la responsabilidad de la calidad se transfirió al departamento de pruebas. No condujo a nada bueno. Los programadores no pensaron en la disponibilidad de la función, esperando que QA informara problemas. El ping-pong entre departamentos condujo a una desaceleración en el desarrollo. Este es el precio por compartir la responsabilidad.
Con la llegada de Agile, los equipos se han consolidado. Falta "nosotros" y "ellos". El equipo es responsable del resultado final. Y dado que las prácticas de ingeniería se han vuelto comunes, los requisitos para el código de prueba deben presentarse de la misma manera que para el código del producto.
Para abandonar a los candidatos, enviamos una tarea de prueba sin fecha límite:
Java http://todomvc.com/examples/react/
Lista de errores comunes
Complicaciones adicionales
Un montón de abstracciones, envoltorios sobre clases y código repetitivo dentro de las pruebas.
Los métodos de prueba se hacen lo más cortos posible. Las funciones de ayuda y la separación de la configuración de las acciones en los objetos y las comprobaciones ayudarán en esto.
Violación de convenciones para nombrar clases, métodos, variables
CamelCase mezclado con guiones bajos. Entonces no lo usan ahora. Linter y sugerencias IDE guardar.
Rutas de asistencia de código duro
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
El clásico "funciona en mi máquina".
Almacenamiento de archivos binarios dentro del repositorio.
Hay git-lfs para resolver este problema.
Falta de consistencia en los métodos.
En una solución, el candidato describió métodos para eliminar y marcar "hecho" de esta manera:
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
En el primer método, el texto de la tarea se transmite, en el segundo, el índice de la lista. Usar tal API es doloroso.
System.out.println() para iniciar sesión
No proporciona información de respaldo en qué clase ocurrió el evento.
Usando Thread.sleep
Para resolver este problema hay una biblioteca de agilidad . Ayuda a agregar retroalimentación a la expectativa del cumplimiento de la condición necesaria.
Excepciones generales en lugar de asert
Ejemplo: una prueba agrega varios elementos a la lista de tareas y marca todos los elementos como completados. La idea es que, en caso de problemas, el método findElement devolverá una NoSuchElementException y la prueba NoSuchElementException . Si luego mira los resultados de la ejecución de la prueba, NoSuchElementException será engañoso: no está claro si la prueba realmente cayó o el código de la curva de prueba. Es necesario utilizar un asert con un claro mensaje de error en caso de falla de la prueba.
Abuso de Acerts Bertic
afirmar verdadero o afirmar falso se utiliza para todo en una fila:
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
Es mejor usar asirEquals aquí para tener contexto cuando la prueba falla.
No hay parametrización para ejecutar pruebas
Ejemplo: la URL del sitio para la prueba está clavada en el código.
También deberíamos mencionar trabajar con git . Muy a menudo, la tarea se envió en una sola confirmación. Escribir mensajes de compromiso comprensibles y dividir una gran tarea en varios por separado es una habilidad necesaria, especialmente en el trabajo en equipo.
Conclusiones
Los problemas descritos anteriormente son mi experiencia personal e impresiones después de las entrevistas. Según las observaciones, la experiencia del candidato no se correlaciona con el número de brechas. Evite los probadores homeopáticos, invierta tiempo en bombear habilidades técnicas de los empleados. Los probadores tienen algo que aprender de los desarrolladores y viceversa. Que la fuerza venga con aquellos que construyen cultura de ingeniería y nadan contra la corriente.
Me alegraría estar equivocado y contento si todo es diferente en su empresa contratada.
UPD 11/02/20 : En el seminario web "Retrato de un probador", comparto mi opinión sobre cómo veo la profesión desde adentro.
- ¿Por qué una empresa necesita probadores?
- El papel del probador en el equipo.
- Prueba manual VS automatizada
- Aspectos atractivos de la profesión y el precio de la experiencia.
- Habilidades duras / blandas necesarias
- Errores en el currículum de profesionales novatos
- Devops en pruebas
- Crecimiento profesional