Pruebas: probablemente la parte más infravalorada del desarrollo de aplicaciones

¿Por qué debería pagarte para probar tu propio trabajo?

Esta es una pregunta que he escuchado mucho a lo largo de los años al discutir los presupuestos de prueba con los clientes. Para los no iniciados, suena como una pregunta justa. Sin embargo, cualquier persona involucrada en el desarrollo de software sabe cuán complejas y lentas pueden ser las pruebas. La prueba es, de hecho, una de las partes más importantes de cualquier proyecto de desarrollo de software.

Una gran plataforma de comercio electrónico es algo increíblemente complejo con millones de líneas de código, gigabytes de datos y muchos puntos de integración. Hay tantas partes móviles interconectadas; tantos eslabones en la cadena que es muy fácil que algo salga mal. La aplicación se utilizará de millones de maneras diferentes a través de una multitud de navegadores en numerosos dispositivos móviles y de escritorio. El proyecto de desarrollo habrá durado al menos 6 meses con muchas personas diferentes trabajando en él. El número de áreas y escenarios que se pueden probar es casi ilimitado. ¡Es un milagro que algo funcione!

Las pruebas se pueden dividir en varias áreas diferentes, pero es importante tener en cuenta cada área de prueba. Cada proyecto es un poco diferente; a algunos clientes les gusta hacerse cargo de gran parte de las pruebas, a otros les gusta subcontratarlas, mientras que otros esperan que su desarrollador lo haga todo. Las pruebas tampoco son una entidad fija; puedes hacer muchas pruebas y puedes hacer un poco. Cuanto más pruebe, más eliminará el riesgo del proyecto, pero más tiempo llevará y más costará.

Examen de la unidad

Una prueba unitaria es aquella que prueba pequeñas "unidades" de código para garantizar que funcionen como se espera. Por ejemplo, cuando se envía un formulario, debe guardar los detalles ingresados ​​en una tabla de base de datos. Es una prueba independiente que, específica y únicamente, garantiza que la unidad funcione como se espera. Usando una verdadera metodología de desarrollo basada en pruebas, un desarrollador primero escribirá una prueba antes de crear cualquier código para que el código pueda considerarse completo solo cuando pase la prueba. En la práctica, las pruebas unitarias solo se utilizan en algunas áreas clave de la aplicación para garantizar que las funciones principales funcionen como se espera. Si bien las pruebas unitarias pueden reducir la probabilidad de que ocurran problemas funcionales, también pueden aumentar el tiempo de desarrollo.

Prueba de humo

Probablemente escuchará a su agencia de desarrollo hablar mucho sobre las pruebas de humo. Una prueba de humo es un subconjunto pragmático de casos de prueba que cubren los viajes y funciones clave del usuario a lo largo de su aplicación. Como mínimo, se debe esperar que su desarrollador realice pruebas de humo antes de entregarle algo para UAT.

Pruebas de interfaz de usuario

La prueba de la interfaz de usuario (UI) puede ser algo muy complejo y lento. La amplia gama de dispositivos móviles, tabletas y computadoras de escritorio, sistemas operativos y navegadores que se utilizarán para acceder a un sitio web significa que es casi imposible probar exhaustivamente cada combinación de forma manual. Debido a la gran cantidad de variaciones diferentes que deben cubrirse, las pruebas de interfaz de usuario son un candidato perfecto para las pruebas automatizadas. Las herramientas de prueba automatizadas pueden seguir un viaje programado a través de su sitio web y probar si se logran los resultados esperados. También pueden grabar cada viaje para que cada uno pueda reproducirse. Aunque este método no es perfecto, puede reducir significativamente la cantidad de problemas importantes de interfaz de usuario que puede enfrentar un sitio web.

Algunos servicios de prueba de terceros, como Bug Finders, ofrecen un servicio de colaboración colectiva en el que se utilizan cientos de evaluadores humanos independientes de todo el mundo para probar un sitio web y se les paga cuando encuentran un problema. Este enfoque puede ser una forma relativamente rentable de probar su aplicación en cientos de combinaciones de dispositivo/plataforma/navegador. Es normal que un ciclo de prueba genere alrededor de 200 problemas. El desafío a menudo consiste en categorizar y priorizar los problemas para que pueda concentrar sus recursos en abordar los más importantes. Cada sitio web tendrá una acumulación constante de problemas de bajo nivel que es poco probable que se resuelvan.

Pruebas de regresión

Las pruebas de regresión son una parte extremadamente importante del desarrollo continuo. Está diseñado para probar si algún cambio en una parte de la aplicación ha causado un problema en otra parte. Por ejemplo, un cambio en una función de JavaScript utilizada para validar el formulario de contacto podría afectar potencialmente a los formularios utilizados en el proceso de pago. Debido a la naturaleza compleja de cualquier plataforma de comercio electrónico, los problemas de regresión no son infrecuentes, por lo que diseñar un plan de prueba de regresión sólido es vital para garantizar que la experiencia de sus usuarios no se vea afectada negativamente por estos problemas.

UAT

La prueba de aceptación del usuario (UAT) es una parte fundamental de cualquier proyecto de desarrollo e implica que el cliente lleve a cabo una prueba completa de la plataforma antes de su puesta en marcha. UAT es el proceso que veo subestimado con mayor frecuencia. También es la parte de un proyecto que es la primera en sufrir cuando los plazos son ajustados. Sin embargo, es probable que esto conduzca a una mayor tasa de fallas. Para cualquier creación de un nuevo sitio web, le recomendamos que planifique al menos 2 meses de UAT. Su sitio web de comercio electrónico es solo una parte de cualquier negocio de comercio y el proceso de extremo a extremo que involucra búsqueda, pago, gestión de pedidos, pago, envío, servicios al cliente, finanzas y todas las demás partes de la cadena deben ser probado

UAT a menudo se confunde o se fusiona con SIT (Prueba de integración del sistema), donde probará específicamente la integración entre múltiples sistemas. SIT es parte de las pruebas de extremo a extremo que garantizan que todas las partes de la cadena funcionen correctamente juntas.

Un buen UAT implica la creación de casos de prueba y planes de prueba. Estos generalmente toman la forma de un conjunto de scripts (un script es un conjunto de tareas para ejecutar) que un probador manual ejecutará y aprobará o fallará la prueba según el resultado. No es inusual que un plan de prueba de UAT de extremo a extremo incluya más de 500 casos de prueba.

La A en UAT es una de las razones por las que es tan importante. Al final del proceso UAT, generalmente se considerará que ha aceptado la solicitud, por lo que es importante que la haya probado exhaustivamente para asegurarse de que funciona exactamente de la manera que esperaba. Esto no significa que los errores no descubiertos no estarán cubiertos por la garantía, pero si hay una funcionalidad que no funciona de la manera que esperaba, esto debe ser recogido en UAT. La otra razón por la que es tan importante es que es la última oportunidad de resolver los problemas antes de que se publique. Es probable que cualquier error y problema afecte negativamente la experiencia del usuario.

UAT requiere mucho esfuerzo por parte del cliente, algo que a menudo se subestima. Algunos clientes usan agencias de pruebas externas para apoyarlos durante la UAT, lo que puede reducir significativamente el riesgo de un proyecto en el que el cliente no tiene la mano de obra para llevar a cabo la UAT de manera efectiva.

Pruebas de seguridad

A veces me sorprende mucho cómo algunos minoristas no se toman las pruebas de seguridad lo suficientemente en serio. No es inusual encontrar que el minorista no sabe cuándo realizó por última vez una prueba de penetración en su plataforma web. Estos son generalmente los que aún no han sido atacados por un ciberataque (o aún no saben que han sido atacados). En el clima actual en el que el delito cibernético continúa creciendo en frecuencia y sofisticación, y especialmente con GDPR en el horizonte en Europa, las pruebas de seguridad son cada vez más importantes. Todas las plataformas web de comercio electrónico deben someterse a pruebas de penetración por parte de un tercero especialista al menos una vez al año, pero idealmente dos veces al año. También es recomendable que su aplicación sea analizada en busca de vulnerabilidades utilizando un software especializado como Nessus de forma regular. En Envoy, tendemos a escanear las plataformas web de nuestros clientes semanalmente para garantizar que las vulnerabilidades de las aplicaciones se detecten rápidamente. Como mínimo, debe realizar análisis de seguridad de la aplicación antes de cada lanzamiento a producción. No es bueno esperar 6 meses hasta la próxima prueba de penetración cuando haya introducido una nueva vulnerabilidad en la aplicación.

Pruebas de rendimiento

Las pruebas de rendimiento generalmente se usan para determinar cuánto tráfico, solicitudes de página, usuarios simultáneos y volumen de pedidos puede manejar su sitio web. Es un proceso más difícil de lo que imagina, ya que, para probar con precisión, debe imitar el comportamiento real del usuario y, como sabrá, los usuarios reales hacen muchas cosas diferentes. Lo mejor que puede hacer es imitar los viajes de sus usuarios clave, como buscar, agregar a la cesta y pagar. Idealmente, desea realizar pruebas de carga en su entorno de producción en lugar de un entorno de prueba, ya que le dará una imagen mucho más real, pero también es probable que esto desconecte su plataforma en algún momento durante la prueba.

La mayoría de los minoristas tienden a realizar pruebas de carga una vez al año, normalmente antes de los períodos de mayor actividad comercial, como el Black Friday o Navidad. El problema que esto puede ocasionar es que, desde la última prueba anual, es posible que se hayan realizado una gran cantidad de cambios en la aplicación, algunos de los cuales pueden haber tenido un impacto incremental en el rendimiento. Si una prueba de carga anual muestra una caída en el rendimiento en comparación con el año anterior, es muy difícil determinar qué cambio o cambios durante el último año han contribuido a esa caída en el rendimiento. Es posible que esto tampoco le dé suficiente tiempo para resolver los problemas de rendimiento antes de que comience el pico de negociación.

Para contrarrestar esto, es recomendable realizar evaluaciones comparativas de rendimiento antes de cada nueva publicación de código. No es necesario realizarlas en un entorno de producción, siempre que cada prueba se realice en el mismo entorno, ya que el objetivo es determinar si el rendimiento ha aumentado o disminuido en relación con la última versión. Este enfoque permite a los equipos de desarrollo comprender de dónde provienen los aumentos o disminuciones en el rendimiento. Esto, por supuesto, lleva tiempo y, por lo tanto, aumentará el tiempo y los costos de desarrollo.

Si bien la lista anterior no es exhaustiva, puede ver que el alcance de las pruebas dentro del desarrollo de software puede ser muy amplio y complejo. Cada tipo de prueba requiere tiempo y esfuerzo, y no debe asumir que todo se realiza de forma estándar sin cargo adicional. Las empresas con un fuerte enfoque en las pruebas asignarán hasta el 40% del tiempo de cualquier proyecto a las pruebas, lo que puede ser una cantidad muy sorprendente. Las buenas pruebas pueden reducir el riesgo de un proyecto y pueden pagarse por sí mismas a largo plazo, ya que generarán menos errores, un mejor rendimiento y una mejor experiencia general para sus clientes.