b'\n_START_ARTICLE_\nCalidad de software\n_START_SECTION_\nCalidad de software\n_START_PARAGRAPH_\nSon caracter\xc3\xadsticas propias del software, aquellas que tu quieres controlar y asegurar. El software es un producto inmaterial que no se fabrica, tampoco se degrada f\xc3\xadsicamente, pero s\xc3\xad se desarrolla. El software puede tener errores e incidencias, pero no son similares a las de cualquier equipo de car\xc3\xa1cter f\xc3\xadsico._NEWLINE_La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detr\xc3\xa1s, debido a que la calidad tradicional tiene varias d\xc3\xa9cadas de historia, mientras que la calidad de software tiene entre 50 y 30 a\xc3\xb1os de haber surgido._NEWLINE_El software necesita ser actualizado.\n_START_SECTION_\nCertificaci\xc3\xb3n del software\n_START_PARAGRAPH_\nEs consecuencia del proceso de aseguramiento de la calidad, pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica, son los procedimientos para construir un software de calidad. Los procedimientos deben ser correctos y estar en funci\xc3\xb3n de la normalizaci\xc3\xb3n (ISO 9000, CMMI, Moprosoft, etc.).\n_START_SECTION_\nNormativa ISO 9000\n_START_PARAGRAPH_\nPone a disposici\xc3\xb3n de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, se audita el sistema. Si los resultados son positivos, se emite la certificaci\xc3\xb3n, y cada cierto tiempo se tiene que renovar. La certificaci\xc3\xb3n es costosa, como consecuencia de los costes que ocasionan la lejan\xc3\xada y el tiempo de duraci\xc3\xb3n de proceso (aprox. 6 meses). Finalmente se certifican la empresa, y la metodolog\xc3\xada para el desarrollo de la aplicaci\xc3\xb3n.\n_START_SECTION_\nMedici\xc3\xb3n del software\n_START_PARAGRAPH_\nEn el software, lo que se mide son atributos propios del mismo, se descompone un atributo general en otros m\xc3\xa1s simples de medir, a veces se mide bien o mal, ya que la descomposici\xc3\xb3n del atributo gen\xc3\xa9rico de calidad en otros sub-atributos, se torna irreal, se mide con datos estad\xc3\xadsticos no avalados, es imposible decir que la medici\xc3\xb3n se hace en forma correcta._NEWLINE_El concepto de medida va de m\xc3\xa1s a menos, va de lo general a lo concreto, y lo concreto es asociado a la m\xc3\xa9trica, esta combinaci\xc3\xb3n te dar\xc3\xada el nivel de calidad, o seguridad de tu producto. Las ciencias bien estructuradas, se basan en medidas bien tomadas con base en la matem\xc3\xa1tica.\n_START_SECTION_\nTests unitarios\n_START_PARAGRAPH_\nEsta es una tarea normalmente en exclusiva de los desarrolladores. Pero sin ella los bugs se propagan como una plaga._NEWLINE_Los tests unitarios son la primera barrera de control contra posibles bugs. Son la base del test driven development, si se quisiera seguir ese proceso. Agilizan el trabajo al poder cambiar partes del c\xc3\xb3digo y comprobar los fallos r\xc3\xa1pidamente. Son ejemplos para los nuevos desarrolladores que se a\xc3\xb1adan al proyecto._NEWLINE_Algunas ideas contrarias a los tests unitarios, se basan en que un buen dise\xc3\xb1o, o una buena planificaci\xc3\xb3n, arregla muchos m\xc3\xa1s problemas que los detectados por este tipo de tests. Aunque el dise\xc3\xb1o sea fant\xc3\xa1stico, no puedes asegurar que el c\xc3\xb3digo funciona sin estos tests, y depender\xc3\xadas de otras pruebas a m\xc3\xa1s alto nivel.\n_START_SECTION_\nTests de integraci\xc3\xb3n\n_START_PARAGRAPH_\nLos tests de integraci\xc3\xb3n, son los que verdaderamente comprueban que el sistema est\xc3\xa1 funcionando. Unen partes del sistema y comprueban que encajan sin problemas. Son la base del behaviour driven development, junto con los tests funcionales. Los tests unitarios no tienen en cuenta elementos tan importantes como los accesos, la base de datos, o peticiones de red. No son suficiente para comprobar que el comportamiento es correcto._NEWLINE_Gracias a este tipo de tests podemos encontrar bugs directamente en los pull requests, sin necesidad de pasar regresivos relacionados con esa parte del producto. Hacen que el sistema sea fiable, pudiendo confiar en las partes protegidas por estos tests, ya que tendr\xc3\xa1n el comportamiento deseado al ser llamados por otros componentes. Adicionalmente, protegen a los grupos de desarrolladores, para que el c\xc3\xb3digo de otros componentes no les sorprenda de formas desagradables._NEWLINE_Al utilizar un lenguaje como gherkin, para escribir este tipo de pruebas, se consigue adem\xc3\xa1s una documentaci\xc3\xb3n extra sobre el funcionamiento del sistema. Pudiendo hallar r\xc3\xa1pidamente, qu\xc3\xa9 est\xc3\xa1 cubierto por los tests, y qu\xc3\xa9 no.\n_START_SECTION_\nTests funcionales\n_START_PARAGRAPH_\nSon un paso m\xc3\xa1s all\xc3\xa1 de los tests de integraci\xc3\xb3n, y tratan de probar el sistema como lo har\xc3\xada un usuario. Aqu\xc3\xad entra especialmente la automatizaci\xc3\xb3n de interfaces gr\xc3\xa1ficas. Son las pruebas funcionales que m\xc3\xa1s mantenimiento necesitan, y las m\xc3\xa1s lentas._NEWLINE_Sin embargo, los beneficios son similares a los anteriores tipos de pruebas. Protegen contra interfaces fallidas, y quitan trabajo a la hora de hacer pruebas manuales. Son especialmente \xc3\xbatiles al configurarlos y prepararlos, para ser ejecutados en todos los entornos en los que se distribuye o se ejecuta la aplicaci\xc3\xb3n. Por ejemplo, en los diferentes navegadores soportados, si la interfaz a probar fuera un entorno web._NEWLINE_Sin este tipo de tests estamos condenados a probar manualmente las interfaces, pudiendo dejarnos en el tintero posibles combinaciones. Suelen ser los mejores para las peque\xc3\xb1as suites de smoke tests.'