Testing en la vida de un programador

¿Por qué los programadores necesitan pruebas?

Los próximos dos niveles estarán dedicados a las pruebas de la forma en que los programadores lo necesitan . Pero primero, averigüemos qué son las pruebas y por qué son necesarias.

En cuanto al software, podemos decir que la tarea de testing es comprobar que el programa:

• hace lo que tiene que hacer
• no hace lo que no debe hacer

El segundo punto, por cierto, no es menos importante que el primero, pero hablaremos de eso más adelante.

Comencemos con el primer punto. ¿Qué significa "el programa hace lo que se supone que debe hacer"?

Primero, alguien necesita hacer una lista de todos los casos de uso del programa. En segundo lugar, deben describir cómo debe funcionar el programa, cómo debe comportarse el usuario y qué resultados se esperan. No puedes continuar más.

Tan pronto como escribimos "cómo debe comportarse el usuario", la idea de escribir una buena documentación se vino abajo. Las personas no son máquinas, además, las personas muy a menudo se comportan con el software como les da la gana . Nadie comienza a familiarizarse con la tecnología estudiando las instrucciones. Es un hecho.

Por lo tanto, tenemos un dato nuevo: la peculiaridad del software es que tiene muchos escenarios de trabajo diferentes. Algunos de ellos son obvios, otros se pueden documentar, otros se pueden suponer, otros se pueden adivinar y el otro 50% ni siquiera se te ocurrirá.

Desde el punto de vista de un programador, la mayoría de los errores no son errores en absoluto. Un error es cuando un programa no funciona como debería o como se esperaba. Y hay muchas situaciones en las que no está claro cómo debe funcionar el programa, o escenarios que se contradicen entre sí...

Hay una cantidad infinita de escenarios, y siempre habrá casos en el producto en los que el programa no se comporte como se esperaba (el programador escribió el código solo para un par de docenas de escenarios). Por lo tanto, se puede argumentar que siempre hay errores en cualquier programa y que cualquier producto se puede mejorar infinitamente .

Después de eso, todo se reduce a la conveniencia. Primero, el programador corrige los errores más grandes, luego los errores más pequeños, y así sucesivamente. Y finalmente, llega una etapa en la que el dueño del producto cree que no es viable económicamente seguir trabajando en él.

Pero volvamos a los errores que todos reconocen como errores: el programa obviamente hace algo mal, se cayó, rompió algo, etc. Dichos errores se pueden dividir condicionalmente en 3 categorías: grandes, medianos y pequeños.

Y muy a menudo sucede que un programador está trabajando para corregir errores medianos o incluso pequeños, aunque todavía hay muchos problemas más serios en el proyecto. Simplemente no los encontró , así que está trabajando en los más grandes que conoce.

Por lo tanto, en cualquier proyecto debe haber probadores. Estas personas aprenden específicamente a mirar el producto desde diferentes ángulos. Para que puedas ver más escenarios del programa. Su tarea es encontrar errores y anotarlos (para no encontrar el mismo error varias veces).

La prueba es un proceso destinado a encontrar errores. Estos errores deben ser encontrados, descritos y priorizados. Solo después de la priorización de errores podemos hablar de un proceso efectivo de mejora del software.

Recuerde, el primer paso para resolver un problema es reconocer que existe un problema . No puedes corregir un error que no conoces.

Automatización de pruebas

Creo que todos estuvimos de acuerdo en que las pruebas son importantes, así que echemos un vistazo a las pruebas como programadores. ¿Cómo ven los programadores las pruebas? Los programadores automatizan el trabajo de otras personas. La última profesión en desaparecer será la de programador.

Automatizamos todos los procesos que encontramos. Por lo tanto, las pruebas deben automatizarse. ¿Y cómo automatizar la búsqueda de errores? Respuesta corta: no. Pero aquí nuevamente el hecho de que somos programadores viene en nuestra ayuda.

El proceso de desarrollo de software consiste en cambios constantes en el mismo. justo en el proceso de hacer cambios constantemente, los programadores muy a menudo rompen algo que funcionó bien hasta hace poco.

Y los testers, en lugar de buscar nuevos errores, nos vemos obligados a comprobar constantemente si hemos estropeado algo que lleva mucho tiempo funcionando bien. Las llamadas pruebas de regresión. Es este tipo de prueba el que puede y debe ser automatizado.

Aquí todo el software se puede dividir en dos partes:

• el programa interactúa con la persona
• programa interactúa con otro programa

La primera opción es más difícil de automatizar, requiere probadores automáticos especiales, también se les llama QA Automation o Software Test Engineer.

Pero la segunda opción puede y debe automatizarse de forma independiente. Si tiene una pieza de software que:

• funciona bien
• ya probado
• implementado como un módulo separado o bloque lógico
• sin planear cambiar
• otros módulos o programas dependen de él
• la falla funcional es costosa

Recomiendo tomarse el tiempo para escribir pruebas que capturen aspectos clave de su funcionalidad actual. Sería razonable asignar el 5% de su tiempo de trabajo para esto , o 1 día por mes.

No hay necesidad de escribir pruebas por el bien de las pruebas.

Nadie apoyará sus pruebas. No otros programadores, no usted mismo. Nadie hace eso. El 99% de todas las pruebas escritas son abandonadas y/o deshabilitadas. Si no puede escribir pruebas, no escriba. Escriba solo si no puede prescindir de ellos en absoluto.

Tipos de prueba

Cada programador, si no ha recibido una formación especial, podrá decir con sus propias palabras qué es el testing: comprobar si el programa hace lo que debería. Sin embargo, los profesionales en este campo distinguen áreas completas (tipos) de pruebas.

Todas las pruebas realmente giran en torno a la confiabilidad y disponibilidad del software, pero para comprender mejor la dirección de las pruebas, veamos algunos ejemplos.

Supongamos que está probando una tienda en línea típica. Luego, las áreas de prueba se pueden dividir en los siguientes tipos: prueba de rendimiento, prueba funcional, prueba de integración y prueba unitaria.

Si el propietario del sitio decide lanzar una campaña publicitaria seria, muchos usuarios visitarán el sitio al mismo tiempo. Bien puede ser que el sitio no se caiga, pero algunas de sus secciones pueden estar lentas o incluso dejar de funcionar.

Para evitar que esto suceda, debe identificar dichos problemas con anticipación y tomar medidas para eliminarlos. Esto se hace mediante pruebas de carga , o también se le llama prueba de rendimiento.

También puede probar cómo funciona su API de backend y probar cada función de la misma: registro, inicio de sesión, agregar al carrito, procesamiento de pagos, escrituras en la base de datos, etc. Todo debería funcionar de acuerdo con los TOR. En este caso, debe realizar pruebas funcionales .

Lo más probable es que su tienda en línea esté integrada con servicios de terceros: envío de cartas y SMS, sistemas de pago, chats de soporte en línea, recopilación de comentarios de los usuarios, sistemas de publicidad, etc. Para asegurarse de que todo esto funcione según lo previsto, debe realizar pruebas de integración . .

Finalmente, los productos complejos a menudo se dividen en módulos independientes. A partir de dichos módulos, puede ensamblar el producto final, como si fuera un constructor. Si está desarrollando un módulo de este tipo o interactuando con dichos módulos, deberá realizar pruebas unitarias .

Resumiendo, podemos decir que se necesitan pruebas funcionales para probar cada función individual del sitio. Integración: para probar la interacción de grandes módulos y sistemas de su producto. Modular: para probar un módulo separado, bueno, pruebas de rendimiento: para verificar el funcionamiento de su sitio bajo carga.

Puede haber incluso más tipos de pruebas: cuanto más complejo sea el producto, más aspectos de su desarrollo deben controlarse.