menu_superior

Pruebas de Humo. Smoke Test

Uno de los problemas más importantes con los que nos solemos encontrar a la hora de afrontar un proyecto o servicio de testing es la escasez de tiempo disponible para llevar a cabo el plan de pruebas. Esta carencia es común en casi todas las actividades humanas ya que en toda actividad planificada pueden surgir retrasos que desvien la duración prevista.

Aún en el caso que nuestra planificación sea razonable y esté dentro de unos margenes normales de desviación, hay factores que pueden dar al traste con ella. Os presento algunos de los más habituales:

  • Situar el testing al final de la cadena. El aplicativo que se está construyendo va a acumulando retrasos a medida que surgen imprevistos en las fases previas y cuando podemos empezar a probar no hay margen para hacer todas las pruebas necesarias (o previstas), así que el plan de pruebas se acorta y la calidad del software se resiente.
  • Repetir muchas veces el ciclo de resolución de defectos. Se encuentra un defecto, se reporta, se soluciona, se reprueba y vuelve a salir este mismo defecto u otro nuevo. Estos ciclos acaban rompiendo la planificación ya que es imposible saber cuántos defectos se encontrarán y cuantas veces hay que reprobar.
  • Probar software inestable, que tiene defectos graves y que impide hacer pruebas en profundidad por que cada vez que empezamos a ejecutar un caso de prueba tenemos que reportar un defecto.

Seguro que a vosotr@s se os ocurren más circunstancias que hacen que la actividad de testing tenga más riesgos a la hora de cumplir la planificación…

Una posible solución a este problema son las pruebas de humo. Las pruebas de humo reciben este nombre por que se hacen para comprobar que no “sale humo” del software a las primeras de cambio, es decir, que un ciclo corto y de pruebas muy ligeras el sistema no detecta errores graves que van a impedir el desarrollo previsto del plan de pruebas.

La dinámica de estas pruebas es muy sencilla y relativamente breve. Normalmente elegimos un conjunto de funcionalidades significativas, no hace falta que sean todas las de la aplicación, y hacemos varias pasadas por cada una de ellas. No es es necesario que la cobertura sea amplia, ni forzar los límites, basta con hacer una navegación pasando por las pantallas correspondientes verificando que el comportamiento es el esperado. No es muy diferente de lo que hacemos cuando instalamos un aplicativo nuevo y no sabemos como funciona o cuando tememos que una actualización nos haya estropeado un software que funcionaba bien: abrimos la aplicación, nos logamos, comprobamos los menús, si hay información del perfil verificamos que sea correcta, hacemos alguna consulta, pasamos pantallas fijándonos en que cuadran bien en la resolución que tenemos, hacemos alguna operación (preferiblemente que tenga vuelta atrás y no dañe la consistencia de los datos), etc. En resumidas cuentas, bicheamos para asegurarnos que, al menos en la superficie, la aplicación soportará la ejecución del plan de pruebas.

Las pruebas de humo ponen de manifiesto que el software no está lo suficientemente estable para afrontar un ciclo de pruebas y son un paso previo a la ejecución del plan de pruebas diseñado por los analistas. En ningún caso supone que haya una validación funcional o técnica de la aplicación, simplemente es un trámite que hay que superar para que la oficina de pruebas acepte esa aplicación.

Seguramente volveré a escribir de este tema cuando trate aspectos de las metodologías ya que forman parte de las buenas prácticas que creo que hay que seguir para garantizar la eficiencia de la actividad de pruebas.

, ,

  • Gterrera

    Estimado Pedro, gracias por el artículo y te cuento que me sirvió como disparador para generar otro, asi después no solo lo estaré publicando en mi blog (haciendo referencia a éste como corresponde) sino además lo estaré publicando como ‘debate’ dentro del grupo de discusión que administro también en la red linkedin (TESTING & QA)

    Te mando un fuerte abrazo y seguiré tus post.

    Saludos desde Argentina, Buenos Aires
    Gustavo
    webmaster@testingbaires.com

    • pedrosebblog

      Muchisimas gracias Gustavo! Tu también me has disparado ideas por que no se me había ocurrido postear en los grupos de linkedin en los que estoy. A partir de ahora también incluiré un link.

      Saludos

  • Pingback: Pruebas de Humo. Smoke Test | TestingBaires()

  • Pingback: pedrosebastianmingo.com - Nueva categoría: Automatización de Pruebas()

  • Luis

    Muy buenas ando haciendo un proyecto de carrera sobre automatizacion de pruebas a una pagina Web creada por mi.

    Uso para ello Selenium , Eclipse para lanzar test Junit.

    Tengo una duda grande, hay muchas clases de pruebas Software (caja blanca/negra,unitarias,funcionales,regresion….). Pero que tipos de pruebas estan orientadas a las paginas Web…??

    Gracias , muy buen post.