Pruebas de Humo (Smoke Test)

Owned by Ely
may 31, 2022
2 min read

El Smoke Test es muy usado (casi siempre) luego de hacer un Deployment a un ambiente de desarrollo.

Primero, se termina el Deployment a QA.

Ahí se reúne el team de QA y procede a correr un Smoke Test.

  1. Deben primero crear una tarea en el Gestor de Incidencia para trackear el tiempo que se consumirá por eso (como los task que ven en las US), en este caso se crea un Test Plan con nombre de "Smoke Test bla bla" siguiendo una nomenclatura.

    1. un ejemplo de nomenclatura simple es:

      1. "Release <#versiondelsistema> | Sprint # | Smoke Test | Componentes del Smoke"

  2. Luego de crear el Test Plan del Smoke, se agrupa los escenarios de pruebas a testear con el gestor de incidencia:

    1. Si usas JIRA con Xray, creas un TX y agregas los Test Scenarios del Smoke que quieres correr ahora.

    2. Si usas Azure DevOps, creas un Test Suite basado en Query para tomar los Test Scenarios del Smoke para correr.

Hay varias maneras de correr un Smoke:

  • Manual

  • Automatizado (con Webdriver o full API)

  • Manual y Automatizado (con full API)

  • Full API testing (es más común y por excelencia) (a veces lo hacen los Dev o los TAE)

  1. Si se hace Manual,

    1. se debe distribuir al equipo QA, asignándoles componentes independientes para probar.

  2. Cuando se termina el Smoke, se le avisa al Project Manager y a todo el team los resultados del Smoke:

    1. Se realiza un Test Criteria para decir si el ambiente es estable o no, esto lo deberían definir los managers.

      1. Si es estable, se procede con las pruebas que estaban (ya sea Testing de US o una Regressión)

      2. Si NO es estable, se puede hacer un rollback o tratar de fixear el bloqueante con otro Deployment.