Pilares del Software Testing

Qué es el Testing y por qué es necesario

Hacer testing es llevar a cabo una investigación sobre un producto de software para garantizar su calidad y detectar posibles fallos. Es la manera de contrastar si el resultado cumple con los requisitos técnicos que se especificaron para llevarlo a cabo.

A esos requisitos se les llama de muchas maneras, te pongo una tablita para no volvernos locos:

requisitos técnicos = especificaciones técnicas = technical requirements = software requirements = business requirements

En la industria del software podemos distinguir tres grandes roles:

El programador (software developer): la persona que escribe el código.

El business analyst: a veces se le llama por otros nombres como project manager o product owner, por motivos que no vienen al caso, pero básicamente es la persona que escribe y organiza los requisitos técnicos que debe tener un software.

El tester: también llamado QA o Testing engineer, es la persona que revisa el resultado de los programadores, informa de posibles fallos e intenta anticiparse a posibles problemas en el software.  

Aunque el tester tenga ese papel de guardián de la calidad del producto, todo el equipo es en cierta medida responsable de la calidad. Esto es algo que aprendió la industria IT a base de cabezazos, porque el testing, a lo largo de la historia, ha sido bastante infravalorado. Por suerte, esto empezó a cambiar hace años.

Hoy por hoy, el testing es una pieza fundamental en el desarrollo de software, ya que las empresas han entendido la importancia y el coste de detectar errores a tiempo (cuanto antes, mejor), porque no es lo mismo que se detecte un bug cuando el producto está en pre-producción a detectarlo cuando ya está en el mercado. Y para muestra, un botón:

bug-cost

Qué es el Software Development Life Cycle (SDLC)

El SDLC es una forma de llamar a las diferentes etapas por las que pasa un software desde su concepción hasta su entrega al cliente final. Esas etapas se detallan en un plan de acción bien definido, donde cada miembro del equipo tiene su papel.

Estas son las típicas etapas del ciclo de vida de un software:



maintenance

DEPLOYMENT

PLANNING

SDLC

TESTING



DESIGN

IMPLEMENTATION

Fase de planning

En esta fase se decide qué vamos a construir. Es fundamentalmente responsabilidad del product owner.

Fase de design

Aquí es cuando se recaban business requirements, se ponen en orden y se diseña la arquitectura del software y la UI. Aquí se implica todo el equipo.

Fase de implementation

Aquí es cuando los developers construyen la app o el software mediante código.

Fase de testing

En esta fase se comprueba si lo que han construído los developers se ajusta a lo definido previamente en los business requirements, porque no olvidemos que el código lo construyen personas, y por tanto, siempre habrá errores, porque somos humanos, no máquinas. Por eso los testers son imprescindibles.

Para comprobar que todo se ajusta a lo definido, los testers crean y ejecutan pruebas (en inglés, test cases).

Fase de deployment

Aquí es cuando llevamos nuestro código a producción, es decir, lo hacemos público para el cliente final, que podrá ver así el resultado en forma de, por ejemplo, una página web o una app

Fase de maintenance 

Es posible, por no decir seguro, que nuestro software necesite un cierto mantenimiento a lo largo de tiempo para que siga manteniéndose operativo y actualizado. De eso va esta fase, que, una vez que el software está en producción, nunca acaba. 

🍕

Veamos un ejemplo de todo esto en el mundo físico que nos sirva como equivalente en el mundo IT: una receta de cocina.



maintenance

Asegurarte de que les ha gustado y mejorar lo necesario para la próxima vez

DEPLOYMENT

Servirla a tus invitados

PLANNING

¿Qué vamos a cocinar? Una pizza

PIZZA

DEVELOPMENT

LIFE CYCLE

TESTING

Comprobar que no se haya quemado y que los ingredientes estén bien cocinados



DESIGN

¿Qué ingredientes necesitamos? Agua, harina, aceite, mozzarella y albahaca.

 ¿Cuánto tiempo de preparación necesitamos? varios días

IMPLEMENTATION

1. hacer masa y dejar reposar

2. extender masa y añadir los ingredientes

3. meter al horno a 250º

La definición del SDLC tiene más años que Matusalén, y en los años 90 se creó una manera nueva de llevarlo acabo. Antes, cada etapa del SDLC podía durar semanas, meses e incluso años, y no se pasaba a la siguiente fase hasta que la anterior se había cerrado por completo. 

Esto conducía a desvíos gigantes entre las expectativas y el producto final. Por eso, en los 90 se creó una metodología ágil (en inglés, agile methodologies), que respetaba completamente el SDLC, pero lo ejecutaba en periodos muy cortos de tiempo (entre 1 y 4 semanas). Pero esto es material para otro post 😁.

Actividades de testing

Ya sabemos lo que hace un tester, ahora vamos a ver a grandes rasgos cómo lleva a cabo su trabajo. 

Un tester está involucrado en (casi) todas las fases del SDLC y se encarga tanto de planear y definir tests hasta ejecutarlos y sacar conclusiones de estos. Sí, has leído bien, un tester, sobre todo en empresas que trabajan con agile, participa en la mayoría de las fases del SDLC, porque es vital que a la hora de crear los business requirements, tanto los testers como los programadores sepan exactamente lo que van a construir y probar.

1

Test planning

Un documento donde el tester define qué va a probar y cómo va a hacerlo. Ahí se identifica el scope (= ámbito) de la prueba, qué funcionalidades (en inglés, features) se van a probar, en qué environments, etc.

2

Test specification

Aquí el tester crea test cases basados en la fase anterior de planificación. 


No debemos confundir los test cases con los bug reportsUn test case es un escenario determinado que el tester se imagina que puede llevar a cabo el usuario del software. Por ejemplo, si tenemos un página para iniciar sesión, el tester debe analizar (con los business requirements a mano) qué se supone que el usuario puede y no puede hacer.


Como tester se me ocurren varios escenarios que podrían ocurrir y que por tanto deberíamos probar:

 

  • intentar iniciar sesión con usuario y contraseña correctos
  • intentar iniciar sesión con usuario y contraseña incorrectos
  • intentar iniciar sesión con algún campo vacío

Un test case tiene una estructura determinada para facilitar su lectura: título, descripción, pre-condiciones, pasos, estado y resultado esperado.

3

Test execution

Aquí el tester ejecuta los test cases basados en la fase anterior, cuyo objetivo principal es comprobar si los resultados coinciden con lo esperado. Por ejemplo, si creo un test para comprobar que un botón cambia de color cuando hacemos clic sobre él, y lo que sucede al hacer clic es que no cambia de color, el resultado esperado no coincidiría con el resultado real. 


Cuando se da este caso, el tester toma nota y crea un documento para informar del error (en inglés, un bug report), y lo deriva a quien deba encargarse de resolverlo. 


En esta fase es muy importante trabajar con prioridades, ejecutando los tests más importantes primero.

4

Test completion

Aquí todos los tests que el tester había planeado ejecutar ya se han ejecutado y se han sacado las conclusiones pertinentes. Si los tests más cruciales han sido satisfactorios, el tester da el visto bueno para pasar el software a producción.

Qué es un bug y cómo informar sobre uno

Un bug (por lo que más quieras, ¡no lo pronuncies con "u"! Una simple "a" basta) es un fallo en el software, cualquier tipo de error que suponga que nuestro software no funcione como esperado

Los bugs en el código son la cosa más común del mundo, y mientras los humanos seamos los que escribimos código en lugar de las máquinas, los bugs están garantizados 😁. 

Todo el equipo es responsable de generar un código lo más libre de bugs posible, y el trabajo del tester es localizar los bugs lo más antes posible en el proceso del desarrollo del software

Existen varios tipos de bugs, pero esta es una de las clasificaciones más comunes:

Visuales (visual bugs): imágenes cortadas, textos mal alineados, colores que no coinciden con el diseño, etc.

Funcionales (functional bugs): relacionados con el funcionamiento del software. Por ejemplo, si al hacer clic en un botón, no pasa nada o me redirige a la página incorrecta.

De rendimiento (performance bugs): relacionados con la velocidad de carga y otros aspectos del rendimiento del software.

Sea cual sea el tipo de bug, la labor del tester es localizarlo, redactar un bug report (un informe) dando detalles del bug y ponerlo en conocimiento del equipo para que se puedan encargar de resolverlo. Una de las herramientas más populares para redactar bug reports es JIRA. Yo la uso y me parece una maravilla. 

Un bug report tiene esta estructura típica:

TÍTULO DEL BUG

resumen/descripción del bug

  • pasos a seguir para reproducir el bug
  • resultado deseado (expected result)
  • resultado actual (actual result)

responsable (asignee)

informante (reporter)

estado

PRIORIDAD

archivos adjuntos (screenshots, vídeos)

Lo que debe caracterizar un bug report es su simplicidad. Nada de enrollarnos como las persianas. Debemos ser concisos y ponernos en el lugar de la persona que va a leer el report y encargarse de resolver el fallo. Lo último que quiere esa persona es ponerse a leer rollazos. 

Para mí, esta es una de las soft skills más importantes de un tester: la capacidad de síntesis.

💡 Un truquito para escribir títulos concisos y relevantes es pensar en el actual result primero. De ahí puedes sacar un buen título.

El ciclo de vida de un bug (bug life cycle)

Hablemos de la vida de un bug. Un bug nace cuando se descubre y muere cuando el programador lo arregla. Por el camino pasa por distintas fases, que cambian un poco según la empresa, pero en general serían:

1

🐛 nuevo bug

Creamos un informe como el de arriba y el bug es asignado a un programador. El estado pasa de "to do" a "active".

TO DO  --> ACTIVE

si el programador considera que el bug no tiene razón de ser, cambia su estado a "closed" y aquí acabaría el ciclo de vida de este bug ⚰ 

2

👷‍♀️ bug en proceso de resolución 

El programador resuelve el bug y lo pasa al siguiente estado, "ready for testing".
ACTIVE  --> READY FOR TESTING

3

🧪 testing in progress

El bug pasa al tester, quien se encarga de verificar si aún existe (si lo puede reproducir), o si efectivamente el programador lo ha arreglado. Si aún existe, el bug da un paso atrás en su estado y vuelve al paso 2, y si está arreglado, lo movemos a su último estado: closed.
READY FOR TESTING   --> TESTING IN PROGRESS

4

⚰ bug cerrado 

Fin de la vida del bug. Normalmente es el tester quien pasa el bug a este estado, pero a veces también el product owner puede querer comprobar que todo esté resuelto.

TESTING IN PROGRESS  -->  CLOSED

Tipos de tests

Existen muchas maneras de clasificar las pruebas que pueden hacerse. Las clasificaciones más comunes son:

Black-box testing

White box testing

  • En este tipo de tests, el tester no ve el código que hay detrás del software, sino que tiene una visión limitada, exactamente como tendría el usuario final
  • El tester se limita a probar la UI
  • Visión alrededor de la "caja"
  • ejemplo: state transtion testing
  • Esta modalidad es mucho más técnica porque el tester tiene que examinar cómo se comporta el código cuando le pedimos que haga algo
  • El tester se enfoca en ver qué hay detrás de la UI de nuestro software
  • Visión dentro de la "caja", por ejemplo, usando las developer tools de Chrome

Functional testing

Non-functional testing

  • unit testing
  • integration testing
  • smoke testing
  • sanity testing
  • regression testing
  • performance testing
  •  stress testing
  • security testing

Esto es como dividir personas en "bajas versus altas" o "rubias versus morenas". Habrá personas que entren dentro de la categoría de "bajas" pero también dentro de "rubias". Pues con los tipos de tests pasa igual, un test puede ser black-box y funcional.

Cómo desarrollar una mentalidad de tester

Ya he hablado un poco de ellas más arriba, pero las soft skills de un tester son tan importantes como las habilidades técnicas (en inglés, hard skills), y difieren un poco de las soft skills de un programador. Las que yo destacaría serían: 

  • curiosidad ante todo. Sé Mister Preguntón / Miss Preguntonita. Pregúntalo todo.
  • vergüenza pa' robar. Enlazado con el punto anterior: no tengas vergüenza de preguntar nada que te llame la atención o de dar tu opinión.
  • compañerismo. Los programadores son tus aliados, no tus contrincantes. Jugáis en el mismo equipo, el que va a construir y entregar un producto de la máxima calidad posible.
  • capacidad de síntesis y de comunicación de los temas en el tono adecuado.

THE END!

¡Y con esto terminamos esta introducción al software testing! Espero que hayas aprendido algo nuevo 😊.  Si te queda alguna duda, ¡nos vemos en los comentarios!

Sobre la autora de este post

Soy Rocío, una abogada reconvertida en programadora. Soy una apasionada de aprender cosas nuevas y ferviente defensora de que la única manera de ser feliz es alcanzando un equilibrio entre lo que te encanta hacer y lo que te saque de pobre. Mi historia completa, aquí. 

Otros artículos que pueden interesarte

Cómo aprendí a programar cuando estaba «programada» para ser de letras
[tcb-script src="https://player.vimeo.com/api/player.js"][/tcb-script]A nadie le gusta su trabajo. Eso es lo que me decía a mí misma cuando conseguí mi primer[...]
Guía de iniciación al data binding en Angular
¿Qué es el databinding?El databinding es la forma que tiene Angular para permitirnos mostrar contenido dinámico en lugar de estático (en inglés, hardcoded). Podríamos[...]
Claves para entender Angular – Qué es y cómo se utiliza
Angular es un framework creado por Google que nos permite construir Single Page Applications (SPA, por sus siglas en inglés).Frameworks¿Pero qué es[...]
Si crees que este post puede serle útil a alguien, por favor, ¡compártelo!:

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Esta web utiliza cookies para asegurar que se da la mejor experiencia al usuario. Si continúas utilizando este sitio se asume que estás de acuerdo. más información

Los ajustes de cookies en esta web están configurados para «permitir las cookies» y ofrecerte la mejor experiencia de navegación posible. Si sigues usando esta web sin cambiar tus ajustes de cookies o haces clic en «Aceptar», estarás dando tu consentimiento a esto.

Cerrar