¿Cuántas veces os habéis preguntado a qué nos dedicamos el equipo de QA? hacer fallar una app, persecución y caza del bug, urdir una campaña inquisidora contra el trabajo de nuestros developers…¡nada de eso! Con este artículo queremos desmontar mitos, acercar y dar a conocer qué papel juega QA en el desarrollo de software.
En este post, os hablamos de las Pruebas funcionales y la Metodología que utilizamos para llevarlas a cabo.
¿Qué son las Pruebas funcionales?
Grosso modo, el test funcional prueba “lo que el sistema hace”. Estas pruebas se definen a partir de funciones o características que nos vendrán dadas por el funcional.
Desde ENCAMINA trabajamos las pruebas funcionales confeccionando de forma reglada y estructurada, un compendio de éstas que tendrá como propósito corroborar que todo desarrollo funciona cumpliendo las especificaciones funcionales y requisitos del cliente. Este conjunto de pruebas se definirá en forma de casos de prueba, conformando el Test Plan o Plan de prueba del cual hablaremos más adelante.
¿Cómo trabajamos?
El procedimiento que aplicamos en QA para el desarrollo de un proyecto, viene definido por las una serie de fases que iremos detallando a continuación:
Análisis del funcional.
Para detallar, paso a paso, cómo realizamos las pruebas, debemos comenzar explicando la vital importancia de conocer el documento funcional del proyecto. El equipo de QA debemos conocer muy de cerca qué vamos a probar, y qué resultado esperamos de cada prueba. Siendo así, entenderemos que la relación de QA con el funcional debe ser siempre muy estrecha y su estudio, por consiguiente, un paso ineludible para comenzar a definir pruebas.
Plan de prueba
Una vez conocemos a fondo los requisitos funcionales de un proyecto definiremos, de forma minuciosa, los casos de prueba. Casos de prueba en torno a cada requisito especifico, cada proceso, cada diseño, cada ventana, cada botón, etc.
¿Qué es un caso de prueba?
Entendemos el caso de prueba como la condición establecida sobre cada uno de los aspectos y funcionalidades del aplicativo que determinará su corrección, siempre en base a las pautas que dicte el funcional.
Para cada caso de prueba debemos definir la sección en la que se lleva a cabo, descripción de la acción, y finalmente su resultado deseado.
Toda esta información en torno a la prueba puede detallarse en el mismo nombre del caso, aplicando la siguiente nomenclatura:
Documentos. Comprobación de acceso a documento del listado. Click sobre el documento. Se abre el detalle del documento
No obstante, siempre que se requiera, podremos profundizar en el detalle de caso mediante la cumplimentación de Steps (Actions&Expected Result); una de las facilidades que nos brinda MTM (Microsoft Test Manager).
Además, siguiendo en MTM, de poder incluir un resumen de su propósito, y las condiciones necesarias para poder llevar el caso a cabo. Detallando una Descripción, Datos necesarios y Precondiciones.
Todo este detalle, tan a fondo, que gira en torno a cada uno de los casos de prueba, nos guiará el camino a seguir a la hora de probar un desarrollo sin dar pie a que nada se escape y deje de ser probado.
Por otra parte, trabajar aplicando este estándar aporta otras ventajas de peso, por ejemplo permitir a cualquier persona; inclusive ajena del proyecto, poder conocer a fondo en qué consiste cada prueba, lo cual facilitaría en gran medida su labor en caso de tener que ejecutarlas. Esto es de gran utilidad, ya que hace posible que quien ejecute las pruebas, no tenga que ser necesariamente el autor del test plan.
¿Qué estructura sostiene esos casos que conforman el plan?
Ahora que ya conocemos la “última partícula indivisible” en el testing; el test case, comprenderemos como a partir de su definición iremos vertebrando nuestro Plan de prueba.
Los casos definidos dentro del plan deben proporcionarnos una cobertura transversal a toda funcionalidad presente en el proyecto, es decir; que toda funcionalidad o servicio que preste el aplicativo, se encuentre provista de pruebas que aseguren el resultado esperado, asegurando un funcionamiento óptimo y sin lugar a errores.
El plan de pruebas se estructura distribuyendo cada uno de los casos definidos por Suites, o agrupaciones de pruebas, según funcionalidad o sección del bloque desarrollado.
Conjunto de suites dentro de un test plan 
Test cases dentro de un suite
Pase del plan de prueba
Una vez tenemos definido el plan de prueba, procederemos a ejecutarlo, es decir; a comprobar como cada una de esas pruebas cumple, y nos devuelve el resultado esperado que hemos previsto.
No podemos terminar este punto sin citar la automatización de pruebas. La automatización es una metodología alternativa, en la que la ejecución de test y obtención de resultados se lleva a cabo de manera automática. Para ello en ENCAMINA nos valemos del Coded UI testing; del que hablaremos en otra ocasión.
Reporte y ciclo de errores
Siempre que el resultado de una prueba no concuerde con el resultado esperado, estaremos siendo testigos de la reproducción de un “bug”.
La ejecución de cada una de las pruebas se lleva a cabo reportando, de forma inmediata al equipo de Desarrollo, aquellos “bugs” que vayamos registrando.
Para ello nos apoyamos de nuevo en la herramienta MTM (Microsoft Test Manager), y en la trazabilidad que nos aporta. MTM hace posible el feedback de QA con el equipo de Desarrollo. Puesto que todo desarrollador del proyecto tiene acceso y puede consultar en el repositorio de bugs de la plataforma TFS (Team Foundation Server), toda la información pertinente a los mismos para así poder repararlos.
No es necesario añadir, que cuando detallemos un bug debemos hacerlo con el mayor detalle posible, de manera que cuando llegue a desarrollo pueda interpretar en que consiste exactamente el error.
Bug fixing
Sobre el reporte de bugs debemos añadir que el feedback es bidireccional entre QA y Desarrollo.
En el momento en que un desarrollador repara un error, se dispondrá a cambiar el estado del bug en TFS. Este cambio de estado informará, mediante notificación, al compañero de QA responsable. Nosotros (QA), una vez conscientes de la reparación del bug, comprobaremos que el error no sigue reproduciéndose, para seguidamente cambiar su estado a Cerrado.
Conclusión
Vamos a concluir, recalcando que el principal objetivo de las pruebas funcionales no es otro que presentar un producto de calidad y libre de errores. En ENCAMINA consideramos la realización de pruebas como un gran aporte de valor al producto, valiéndonos de ellas para asegurar que cumplimos con los requisitos establecidos. Para ello se definen casos de prueba entorno a cada diseño, cada ventana, cada botón, cada requisito especifico, cada proceso etc., que, vertebrando un robusto Plan de prueba, nos garantiza una cobertura en pruebas transversal a nivel de proyecto. Es decir, que toda funcionalidad desarrollada se encuentre provista de test que aseguren el cumplimento del resultado esperado.
Por otra parte, invertir en testing funcional supone, además de una garantía en la calidad del producto, un ahorro en la solución de posibles errores encontrados en fases tardías en el desarrollo de software; puesto que aquellos defectos encontrados y solventados durante la fase de pruebas supondrán un ahorro en tiempo, dinero y una reducción en los riesgos.
Insistir en que la realización de pruebas no asegura que no se produzcan defectos en fase posteriores, pero sí que se den menos o sean de menor peso económico 😉
¡Suscríbete a nuestras RRSS!
