![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA1.png\")
<\/p>\n<\/p>\n
\u00bfCu\u00e1ntas veces os hab\u00e9is preguntado a qu\u00e9 nos dedicamos el equipo de QA<\/strong>? hacer fallar una app,\u00a0 persecuci\u00f3n y caza del bug, urdir una campa\u00f1a inquisidora contra el trabajo de nuestros developers\u2026\u00a1nada de eso!\u00a0Con este art\u00edculo queremos desmontar mitos, acercar y dar a conocer qu\u00e9 papel juega QA en el desarrollo de software.<\/strong><\/p>\n En este post, os hablamos de las Pruebas funcionales<\/strong> y la Metodolog\u00eda <\/strong>que\u00a0<\/strong>utilizamos para llevarlas a cabo.<\/p>\n <\/p>\n Grosso modo, el test funcional prueba \u201clo que el sistema hace\u201d. Estas\u00a0pruebas\u00a0se definen a partir de funciones o caracter\u00edsticas\u00a0que nos vendr\u00e1n dadas por el funcional.<\/p>\n Desde ENCAMINA trabajamos las pruebas funcionales confeccionando de forma reglada y estructurada, un compendio de \u00e9stas que tendr\u00e1 como prop\u00f3sito corroborar que todo desarrollo funciona cumpliendo las especificaciones funcionales<\/strong> y requisitos del cliente<\/strong>. Este conjunto de pruebas se definir\u00e1 en forma de casos de prueba, conformando el Test Plan<\/strong> o Plan de prueba<\/strong> del cual hablaremos m\u00e1s adelante.<\/p>\n 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\u00f3n:<\/p>\n An\u00e1lisis del funcional.<\/strong><\/p>\n Para detallar, paso a paso, c\u00f3mo 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\u00e9 vamos a probar<\/strong>, y qu\u00e9 resultado esperamos<\/strong> de cada prueba. Siendo as\u00ed, entenderemos que la relaci\u00f3n de QA con el funcional debe ser siempre muy estrecha y su estudio, por consiguiente, un paso ineludible para comenzar a definir pruebas.<\/p>\n Plan de prueba<\/strong><\/p>\n Una vez conocemos a fondo los requisitos funcionales de un proyecto definiremos, de forma minuciosa, los casos de prueba<\/strong>. Casos de prueba en torno a cada requisito especifico, cada proceso, cada dise\u00f1o, cada ventana, cada bot\u00f3n, etc.<\/p>\n \u00bfQu\u00e9 es un caso de prueba?<\/strong><\/p>\n Entendemos el caso de prueba como la condici\u00f3n establecida sobre cada uno de los aspectos y funcionalidades del aplicativo que determinar\u00e1 su correcci\u00f3n, siempre en base a las pautas que dicte el funcional.<\/p>\n Para cada caso de prueba debemos definir la secci\u00f3n en la que se lleva a cabo<\/strong>, descripci\u00f3n de la acci\u00f3n<\/strong>, y finalmente su resultado deseado<\/strong>.<\/p>\n Toda esta informaci\u00f3n en torno a la prueba puede detallarse en el mismo nombre del caso, aplicando la siguiente nomenclatura:<\/p>\n No obstante, siempre que se requiera, podremos profundizar en el detalle de caso mediante la cumplimentaci\u00f3n de Steps (Actions&Expected Result); una de las facilidades que nos brinda MTM (Microsoft Test Manager).<\/p>\n Adem\u00e1s, siguiendo en MTM, de poder incluir un resumen de su prop\u00f3sito, y las condiciones necesarias para poder llevar el caso a cabo. Detallando una Descripci\u00f3n, Datos necesarios y Precondiciones.<\/p>\n Todo este detalle, tan a fondo, que gira en torno a cada uno de los casos de prueba, nos guiar\u00e1 el camino a seguir a la hora de probar un desarrollo sin dar pie a que nada se escape y deje de ser probado.<\/p>\n Por otra parte, trabajar aplicando este est\u00e1ndar aporta otras ventajas de peso, por ejemplo permitir a cualquier persona; inclusive ajena del proyecto, poder conocer a fondo en qu\u00e9 consiste cada prueba, lo cual facilitar\u00eda 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.<\/p>\n Ahora que ya conocemos la \u201c\u00faltima part\u00edcula indivisible\u201d en el testing; el test case, comprenderemos como a partir de su definici\u00f3n iremos vertebrando nuestro Plan de prueba.<\/strong><\/p>\n 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 \u00f3ptimo y sin lugar a errores<\/strong>.<\/p>\n El plan de pruebas se estructura distribuyendo cada uno de los casos definidos por Suites<\/strong>, o agrupaciones de pruebas<\/em>, seg\u00fan funcionalidad o secci\u00f3n del bloque desarrollado.<\/p>\n Pase del plan de prueba<\/strong><\/p>\n 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.<\/p>\n No podemos terminar este punto sin citar la automatizaci\u00f3n de pruebas. La automatizaci\u00f3n es una metodolog\u00eda alternativa, en la que la ejecuci\u00f3n de test y obtenci\u00f3n de resultados se lleva a cabo de manera autom\u00e1tica. Para ello en ENCAMINA nos valemos del Coded UI testing<\/strong>; del que hablaremos en otra ocasi\u00f3n.<\/p>\n \u00a0<\/strong>Reporte y ciclo de errores<\/strong><\/p>\n Siempre que el resultado de una prueba no concuerde con el resultado esperado, estaremos siendo testigos de la reproducci\u00f3n de un \u201cbug\u201d.<\/p>\n La ejecuci\u00f3n de cada una de las pruebas se lleva a cabo reportando, de forma inmediata al equipo de Desarrollo, aquellos \u201cbugs\u201d que vayamos registrando.<\/p>\n Para ello nos apoyamos de nuevo en la herramienta MTM (Microsoft Test Manager)<\/strong>, y en la trazabilidad que nos aporta.\u00a0 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\u00f3n pertinente a los mismos para as\u00ed poder repararlos.<\/p>\n No es necesario a\u00f1adir, 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.<\/p>\n Bug fixing<\/strong><\/p>\n Sobre el reporte de bugs debemos a\u00f1adir que el feedback<\/em> es bidireccional<\/em> entre QA y Desarrollo.<\/p>\n En el momento en que un desarrollador repara un error, se dispondr\u00e1 a cambiar el estado del bug en TFS. Este cambio de estado informar\u00e1, mediante notificaci\u00f3n, al compa\u00f1ero de QA responsable. Nosotros (QA), una vez conscientes de la reparaci\u00f3n del bug, comprobaremos que el error no sigue reproduci\u00e9ndose, para seguidamente cambiar su estado a Cerrado.<\/p>\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<\/strong>. En ENCAMINA consideramos la realizaci\u00f3n de pruebas como un gran aporte de valor al producto, vali\u00e9ndonos de ellas para asegurar que cumplimos con los requisitos establecidos. Para ello se definen casos de prueba entorno a cada dise\u00f1o, cada ventana, cada bot\u00f3n, cada requisito especifico, cada proceso etc., que, vertebrando un robusto Plan de prueba, nos garantiza una<\/strong> cobertura en pruebas transversal a nivel de proyecto<\/strong>. Es decir, que toda funcionalidad desarrollada se encuentre provista de test que aseguren el cumplimento del resultado esperado.<\/p>\n Por otra parte, invertir en testing funcional supone, adem\u00e1s de una garant\u00eda en la calidad del producto, un ahorro en la soluci\u00f3n de posibles errores<\/strong> encontrados en fases tard\u00edas en el desarrollo de software; puesto que aquellos defectos encontrados y solventados durante la fase de pruebas supondr\u00e1n un ahorro en tiempo, dinero y una reducci\u00f3n en los riesgos.<\/p>\n Insistir en que la realizaci\u00f3n de pruebas no asegura que no se produzcan defectos en fase posteriores, pero s\u00ed que se den menos o sean de menor peso econ\u00f3mico \ud83d\ude09<\/p>\n <\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" \u00bfCu\u00e1ntas veces os hab\u00e9is preguntado a qu\u00e9 nos dedicamos el equipo de QA? hacer fallar una app,\u00a0 persecuci\u00f3n y caza del bug, urdir una campa\u00f1a inquisidora contra el trabajo de nuestros developers\u2026\u00a1nada de eso!\u00a0Con este art\u00edculo queremos desmontar mitos, acercar … Continue reading \u00bfQu\u00e9 son las Pruebas funcionales?<\/h2>\n
\u00bfC\u00f3mo trabajamos?<\/h2>\n
![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA2.png\")
Documentos. Comprobaci\u00f3n de acceso a documento del listado. Click sobre el documento. Se abre el detalle del documento<\/p>\n![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA3.png\")
<\/p>\n![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA4.png\")
<\/p>\n\u00bfQu\u00e9 estructura sostiene esos casos que conforman el plan?<\/h2>\n
![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA5.png\")
Conjunto de suites dentro de un test plan ![\"QA](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/11\/QA6.png\")
Test cases dentro de un suite<\/p>\nConclusi\u00f3n<\/h2>\n