{"id":2059,"date":"2023-10-12T14:20:05","date_gmt":"2023-10-12T12:20:05","guid":{"rendered":"https:\/\/ittester.sk\/sin-categorizar\/caso-de-prueba\/"},"modified":"2024-07-23T18:02:25","modified_gmt":"2024-07-23T16:02:25","slug":"caso-de-prueba","status":"publish","type":"post","link":"https:\/\/ittester.sk\/es\/pruebas-manuales\/caso-de-prueba\/","title":{"rendered":"Caso de prueba: \u00bfqu\u00e9 es un caso de prueba y c\u00f3mo escribirlo?"},"content":{"rendered":"<div class=\"wp-block-aioseo-table-of-contents\"><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-obsah\">Obsah<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-co-je-to-testovaci-pripad\">\u010co je to testovac\u00ed pr\u00edpad?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-atributy-testovacieho-pripadu\">Atrib\u00faty testovacieho pr\u00edpadu<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-ako-napisat-dobre-testovacie-pripady\">Ako nap\u00edsa\u0165 dobr\u00e9 testovacie pr\u00edpady?<\/a><\/li><\/ul><\/div>\n<p>Las pruebas de software y aplicaciones incluyen la verificaci\u00f3n de sus requisitos funcionales y no funcionales. Para validar estos requisitos, los probadores de software deben crear casos de prueba eficaces utilizando diversas t\u00e9cnicas de dise\u00f1o de pruebas de caja blanca\/pruebas de caja negra.<\/p>\n\n<p>En este texto hablaremos en detalle de los casos de prueba, sus distintos atributos y tipos.  <\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-obsah\">\u00cdndice<\/h2>\n\n<ol class=\"wp-block-list\">\n<li>\u00bfQu\u00e9 es un caso de prueba?<\/li>\n\n\n\n<li>Atributos de los casos de prueba<\/li>\n\n\n\n<li>\u00bfC\u00f3mo escribir buenos casos de prueba?<\/li>\n<\/ol>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-co-je-to-testovaci-pripad\">\u00bfQu\u00e9 es un caso de prueba?<\/h2>\n\n<p>Un caso de prueba es un conjunto de condiciones para evaluar una caracter\u00edstica concreta de un producto de software con el fin de determinar su conformidad con los requisitos de la empresa.<\/p>\n\n<p>El caso de prueba contiene supuestos, valores de entrada y resultados esperados en una forma documentada que abarca diferentes escenarios de prueba.<\/p>\n\n<p>Una vez creados los casos de prueba a partir de los requisitos, el trabajo de los probadores consiste en ejecutarlos. Los probadores leen todos los detalles del caso de prueba, realizan los pasos de la prueba y luego marcan el caso de prueba como aprobado o suspenso en funci\u00f3n del resultado esperado y real.<\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-atributy-testovacieho-pripadu\">Atributos del caso de prueba<\/h2>\n\n<p>Veamos los distintos atributos de un caso de prueba que lo componen y lo hacen m\u00e1s fiable, claro y conciso, evitando o reduciendo as\u00ed cualquier tipo de redundancia.<\/p>\n\n<ol class=\"wp-block-list\">\n<li><strong>TestCaseId<\/strong> &#8211; identificador \u00fanico del caso de prueba. Se trata de un campo obligatorio que identifica de forma \u00fanica el caso de prueba, por ejemplo TC_01.<\/li>\n\n\n\n<li><strong>Resumen de la<\/strong> prueba &#8211; Un resumen inequ\u00edvoco del caso de prueba. Este campo es opcional. Normalmente, los casos de prueba tienen un campo \u00abResumen de la prueba\u00bb o un campo \u00abDescripci\u00f3n\u00bb.<\/li>\n\n\n\n<li><strong>Descripci\u00f3n<\/strong> &#8211; Descripci\u00f3n detallada del caso de prueba. Este campo define la finalidad del caso de prueba, por ejemplo verifica que el usuario puede conectarse con un nombre de usuario y una contrase\u00f1a v\u00e1lidos.<\/li>\n\n\n\n<li><strong>Prerrequisito o condici\u00f3n previa<\/strong> &#8211; Conjunto de <strong>requisitos previos<\/strong> que deben cumplirse antes de poder realizar los pasos de la prueba. Por ejemplo, al probar la funcionalidad de una aplicaci\u00f3n tras el inicio de sesi\u00f3n, podemos tener un campo de precondici\u00f3n que diga \u00abEl usuario debe haber iniciado sesi\u00f3n en la aplicaci\u00f3n\u00bb.<\/li>\n\n\n\n<li><strong>Pasos de la<\/strong> prueba &#8211; Pasos detallados para ejecutar un caso de prueba. Este es el campo m\u00e1s importante del caso de prueba. El probador debe esforzarse por que los pasos de la prueba sean claros e inequ\u00edvocos, de modo que otra persona pueda seguirlos mientras se realiza la prueba.<\/li>\n\n\n\n<li><strong>Datos<\/strong> de prueba &#8211; el valor de los datos de prueba utilizados en el caso de prueba. Por ejemplo, al probar la funci\u00f3n de inicio de sesi\u00f3n, el campo de datos de prueba puede contener el valor real del nombre de usuario y la contrase\u00f1a que se utilizar\u00e1n durante la ejecuci\u00f3n de la prueba.<\/li>\n\n\n\n<li><strong>Resultado<\/strong> esperado &#8211; El resultado esperado en el que marcamos la prueba como superada. Seg\u00fan los pasos de prueba realizados y los datos de prueba utilizados, llegamos al resultado esperado, por ejemplo el usuario debe conectarse correctamente y navegar hasta la p\u00e1gina de inicio.<\/li>\n\n\n\n<li><strong>Resultado<\/strong> real: el resultado real despu\u00e9s de realizar los pasos de la prueba. Este campo s\u00f3lo se rellena durante la ejecuci\u00f3n de la prueba. En este campo escribimos el resultado real observado durante la ejecuci\u00f3n del caso de prueba.<\/li>\n\n\n\n<li><strong>Resultado de<\/strong> la prueba: el estado de aprobado\/no aprobado de la prueba. En funci\u00f3n del resultado esperado y del resultado real, el caso de prueba se marca como satisfactorio o no satisfactorio.<br\/>Adem\u00e1s del valor pasa\/no pasa, tambi\u00e9n podemos tener otros valores, como Aplazado, cuando un caso de prueba se marca para una ejecuci\u00f3n posterior por alg\u00fan motivo. Bloqueado cuando la ejecuci\u00f3n del caso de prueba est\u00e1 bloqueada por alg\u00fan otro motivo en la aplicaci\u00f3n.<\/li>\n\n\n\n<li><strong>Estado de automatizaci\u00f3n<\/strong> &#8211; Identificador de automatizaci\u00f3n: si la aplicaci\u00f3n est\u00e1 automatizada o no. Se trata de un campo opcional que s\u00f3lo se utiliza cuando tenemos automatizaci\u00f3n en el proyecto.<\/li>\n\n\n\n<li><strong>Fecha<\/strong> &#8211; La fecha en que se realiz\u00f3 la prueba. Este campo ayuda a realizar el seguimiento de diferentes iteraciones a lo largo de m\u00faltiples ciclos de ejecuci\u00f3n de pruebas.<\/li>\n\n\n\n<li><strong>Ejecutado por<\/strong>: nombre de la persona que ejecuta el caso de prueba. Este campo ayuda cuando varios miembros del equipo est\u00e1n trabajando en una actividad de ejecuci\u00f3n de pruebas.<\/li>\n<\/ol>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-ako-napisat-dobre-testovacie-pripady\">\u00bfC\u00f3mo escribir buenos casos de prueba?<\/h2>\n\n<ol class=\"wp-block-list\">\n<li><strong>T\u00e9cnica de dise\u00f1o de pruebas<\/strong><\/li>\n<\/ol>\n\n<p>Sigue la t\u00e9cnica de dise\u00f1o de pruebas que sea m\u00e1s adecuada para tu organizaci\u00f3n o las necesidades espec\u00edficas de tu proyecto, como &#8211; el <a href=\"https:\/\/ittester.sk\/es\/pruebas-manuales\/analisis-de-valores-limite\/\" rel=\"ugc\" title=\"an&#xE1;lisis de umbrales\">an\u00e1lisis de umbrales<\/a>, la distribuci\u00f3n de clases de equivalencia, las pruebas de tablas de decisi\u00f3n, etc. Esto garantizar\u00e1 que se apliquen normas y pr\u00e1cticas bien documentadas en el desarrollo de los casos de prueba.<\/p>\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li><strong>Pruebas claras y concisas<\/strong><\/li>\n<\/ol>\n\n<p>Resumen del caso de prueba, descripci\u00f3n, pasos de la prueba, resultados esperados, etc. debe redactarse de forma clara y concisa. Deben ser f\u00e1cilmente comprensibles para las distintas partes implicadas en las pruebas.<\/p>\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li><strong>Nomenclatura uniforme<\/strong><\/li>\n<\/ol>\n\n<p>Para mantener la coherencia entre los casos de prueba, debemos seguir una nomenclatura uniforme y un conjunto de normas al escribir los casos de prueba.<\/p>\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li><strong>Casos de prueba b\u00e1sicos\/at\u00f3micos<\/strong><\/li>\n<\/ol>\n\n<p>Haz que los casos de prueba sean lo m\u00e1s b\u00e1sicos posible. Por tanto, un caso de prueba debe probar s\u00f3lo una unidad de funcionalidad, sin combinar ni solapar varias partes comprobables.<\/p>\n\n<ol class=\"wp-block-list\" start=\"5\">\n<li><strong>No dejes lugar a la ambig\u00fcedad<\/strong><\/li>\n<\/ol>\n\n<p>Escribe casos de prueba con un conjunto claro de instrucciones. {homepageURL}Por ejemplo &#8211; en lugar de \u00abAbrir p\u00e1gina de inicio\u00bb, escribe &#8211; \u00abAbre la p\u00e1gina de inicio &#8211; http:\/\/www. .com en tu navegador y pulsa intro\u00bb.<\/p>\n\n<ol class=\"wp-block-list\" start=\"6\">\n<li><strong>Sin requisitos previos<\/strong><\/li>\n<\/ol>\n\n<p>Cuando escribas casos de prueba, no asumas ninguna funcionalidad, requisito previo o estado de la aplicaci\u00f3n. En su lugar, asigna casos de prueba a los documentos necesarios, como &#8211; SRS, documentos de casos de uso, etc.<\/p>\n\n<ol class=\"wp-block-list\" start=\"7\">\n<li><strong>Evita la redundancia<\/strong><\/li>\n<\/ol>\n\n<p>No repitas los casos de prueba, pues supone una p\u00e9rdida de tiempo y recursos. Esto puede lograrse con casos de prueba bien planificados y categorizados.<\/p>\n\n<ol class=\"wp-block-list\" start=\"8\">\n<li><strong>Pruebas trazables<\/strong><\/li>\n<\/ol>\n\n<p>Utiliza una matriz de trazabilidad para asegurarte de que el 100% de la funcionalidad de la aplicaci\u00f3n en el \u00e1mbito de las pruebas est\u00e1 cubierta en los casos de prueba.<\/p>\n\n<ol class=\"wp-block-list\" start=\"9\">\n<li><strong>Garantizar la cobertura de los diferentes aspectos del software<\/strong><\/li>\n<\/ol>\n\n<p>Aseg\u00farate de que en los casos de prueba se cubren, adem\u00e1s de la funcionalidad, distintos aspectos del software sometido a prueba, como el rendimiento, la usabilidad, la robustez, etc. creando casos de pruebas de rendimiento y puntos de referencia, casos de pruebas de usabilidad, casos de pruebas negativas, etc.<\/p>\n\n<ol class=\"wp-block-list\" start=\"10\">\n<li><strong>Datos de la prueba<\/strong><\/li>\n<\/ol>\n\n<p>Los datos de prueba utilizados en las pruebas deben ser tan diversos y tan pr\u00f3ximos al uso en tiempo real como sea posible. Si tienes datos de prueba diversos, podr\u00e1s elaborar casos de prueba m\u00e1s fiables.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un caso de prueba es un conjunto de condiciones para evaluar una caracter\u00edstica concreta del software con el fin de determinar su conformidad con los requisitos.<\/p>\n","protected":false},"author":8,"featured_media":2061,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[40],"tags":[],"class_list":["post-2059","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pruebas-manuales"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2059","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/comments?post=2059"}],"version-history":[{"count":2,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2059\/revisions"}],"predecessor-version":[{"id":2439,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2059\/revisions\/2439"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/2061"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=2059"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=2059"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=2059"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}