Hola Habr!
Decidí escribir mi opinión sobre si la automatización de las pruebas reemplazará a los mismos probadores. En primer lugar, porque con bastante frecuencia escucho una opinión similar entre el QA Junior, que solo está dando sus primeros pasos en las pruebas y ya teme que no haya logrado hacer algo.
Para ser justos, existe una opinión similar entre los niños mayores. Muy a menudo se cree que la automatización es casi la única forma de desarrollar un probador manual. Sobre todo esto y mucho más bajo el corte.
Un poco de aclaración antes de comenzar. Toda la discusión a continuación será sobre autotests funcionales. Estas son pruebas de IU, que no deben confundirse con las pruebas unitarias en este contexto. Estas últimas siempre han sido escritas y deberían ser escritas por desarrolladores, y donde esto no sea así es el tema de una discusión completamente diferente.Brevemente sobre la historia de la automatización.
He estado trabajando en pruebas durante bastante tiempo y he visto varias etapas en el desarrollo de la automatización de pruebas. Con su desarrollo, su actitud hacia ella también cambió. Veamos cómo fue e intentemos comprender: ¿a qué va todo esto?
En 2010, cuando estaba dando mis primeros pasos en el mundo de TI, no todos conocían una herramienta como Selenium. En ese momento, su primera versión estaba en uso, que se llamaba Selenium Remote Control.
Recuerdo cómo automatizamos nuestro primer proyecto en Selenium. Esta herramienta era bastante simple, podía hacer clic en elementos invisibles, a veces se equivocaba al encontrar localizadores e incluso al recibir texto de algunos elementos difíciles.
Todavía recuerdo que nuestro jefe los llamó "golpes". Al ver cómo nos sentamos y escribimos estas pruebas, lo dijo: nuevamente, ¿escribes tus golpes? Me gusta, no lo habría revisado y liberado con mis manos hace mucho tiempo.
Pero el tiempo pasó, Selenium se desarrolló, tenía nuevas oportunidades. Al principio hubo una segunda, y ahora su tercera versión. Apareció un estándar (los fabricantes de navegadores comenzaron a escribir los controladores ellos mismos), Selenium adquirió varios protocolos, adquirió competidores en el mercado y ahora casi cualquier persona que trabaje en TI lo sabe, independientemente de si pertenece al control de calidad.
En este momento hay muchas soluciones para probar la automatización de aplicaciones web y móviles.
Ahora ya no se trata solo de pinchazos, ahora la conversación promedio de RRHH a la posición de control de calidad se ve así (exagerada, por supuesto):
Buenas tardes Según tu currículum, no está claro. ¿Puedes escribir autotests?
"No, pero soy bueno en ..."
- * ya colgó *
Y si esta es una posición de liderazgo, entonces escuchará que les gustaría configurar primero la automatización, y solo luego contratar ingenieros de control de calidad. O no contratar. ¿Y si no lo haces? Bueno, esto es un ahorro. Incluso después de escribir todas las pruebas, sería despedido. Y los desarrolladores, cuando hagan todo ... Deje en el sitio un botón "Pagar aquí" y déjese caer al atardecer ... Algo me salió mal.
Por supuesto, con tales tendencias, surge la pregunta: ¿reemplazarán las pruebas manuales la automatización? ¿Y cuándo sucederá esto?
Autotests a través de los ojos de los desarrolladores.
Para responder a esta pregunta, primero vale la pena pensar, ¿y quién escribe autotests? Vi empresas en las que los propios desarrolladores escriben las pruebas automáticas. Y vi empresas donde los ingenieros de control de calidad escriben autotests. ¿Cuál crees que es la diferencia fundamental?
Me gustaría asumir que la diferencia está en el código. Como, ya que son desarrolladores, escriben mejor el código. Por lo tanto, sus pruebas son mejores. Pero esto no es del todo cierto.
La calidad del código es, sin duda, un parámetro importante, pero para los propios desarrolladores, las pruebas no son la ocupación principal. Y, por lo tanto, no pueden dedicarle mucho tiempo. Las pruebas se escriben a toda prisa y el código a menudo deja mucho que desear. Y esta es una situación normal, repito: no es en esto en lo que deberían dedicar una cantidad significativa de su tiempo de trabajo.
El código especialmente bueno no es lo más importante en las pruebas automáticas. Lo más importante es qué casos cubren estas pruebas automáticas. Y aquí el pensamiento de un especialista en control de calidad ya es significativamente diferente de cómo el desarrollador ve el producto.
Considera un ejemplo. Es necesario cubrir el registro en el sitio con pruebas automáticas. Está claro que, en primer lugar, cubriremos un caso positivo. Entramos, obtuvimos una calificación de cinco o seis campos de entrada, realizamos algunos pasos adicionales, como la confirmación por correo o SMS: la prueba está lista, ¡está genial!
Sostengo que el 90% de los desarrolladores que han caído en la responsabilidad de escribir autotests se detendrán allí. No describirán parte de los casos porque consideran que no son esencialmente diferentes del que ya está cubierto. Algunos simplemente no serán tomados en cuenta. De todos modos, "yo mismo escribí el código de producción, todo es confiable allí y para siempre".
Clases de equivalencia, valores límite, casos negativos: todo esto se mantiene al margen.
Enfoque de ingeniero de control de calidad
El ingeniero de control de calidad adopta un enfoque diferente. Tiene experiencia, una comprensión de los principios del diseño de pruebas, una cantidad de tiempo suficiente y, lo más importante, para buscar errores y verificar que es su responsabilidad directa. Además, la mayoría de las veces, estas personas simplemente están interesadas en verificar algo. ¿Qué pasa si tocas aquí fuera de turno? ¿Y si ingresa los datos aquí incorrectamente?
Es el enfoque que distingue al ingeniero de control de calidad del desarrollador. Y se forma no por la capacidad de automatizar las pruebas, sino por una forma de pensar. Un mal evaluador escribirá malas pruebas. En este caso, un buen probador encontrará más problemas con la verificación manual que uno malo con su montón de casos de prueba mal concebidos.
¿Qué conclusión me gustaría sacar de esto? Todo es muy sencillo. Un especialista en control de calidad es principalmente una comprensión de los principios de prueba y la experiencia de prueba que tiene una persona. Y no las herramientas que usa.
Por supuesto, solo ser un buen probador no es suficiente. Sin el conocimiento de las herramientas básicas como bash, Git, SQL, etc., es imposible trabajar de manera efectiva en cualquier empresa. Deben ser estudiados.
La automatización es la misma herramienta; por sí sola no es ni buena ni mala. No hará que su trabajo sea más efectivo simplemente porque lo recogió. Todavía necesita ciertas habilidades.
Bueno, ¿qué pasa con la verificación manual?
La verificación manual no irá a ninguna parte. De una forma u otra, cuando veamos una nueva característica o un producto completo frente a nosotros, lo estudiaremos con nuestras manos. Todavía tenemos que averiguar cómo funciona, qué casos considerar prioritarios y, en general, si funcionan ahora. ¿Cuál es el punto de apresurarse a escribir una prueba si el producto está roto?
Y así será siempre, con cada nueva característica o cambio introducido. Primero habrá un paso de verificación manual. Y solo entonces: cobertura o actualización de las pruebas a su alrededor.
¿Sería mejor si las pruebas manuales y la redacción de las pruebas automáticas fueran realizadas por un especialista o responsabilidades compartidas? No lo sé, ya depende de las características de cómo se construye el proceso en su empresa. En algún lugar será efectivo y, por lo tanto, beneficioso. Y en alguna parte, no.
Entonces, a la pregunta de si vale la pena estudiar la automatización de pruebas, respondo categóricamente que sí. El ingeniero de control de calidad debe estar familiarizado con la automatización. Por lo general, los especialistas con esta habilidad tienen más currículums y salarios, y se valoran más en el mercado. ¿Pero la automatización reemplazará la verificación manual y las pruebas manuales? Por supuesto que no.
Resumen
Así es como surgió este artículo. Compartí mi opinión y mi visión del tema. Estaré encantado de saber acerca de los suyos, ¡asegúrese de compartir los comentarios!
Y también un colega de Yandex desarrolló un curso en línea para aquellos que deseen sumergirse en la automatización de las pruebas móviles. Se puede encontrar información y enlaces en mi página de perfil. :)
Gracias por su atencion!