Un desarrollo completo del ciclo de vida del software (SDLC) abarca una amplia gama de procesos de desarrollo de la implementación. Esto significa la prueba de control de calidad como el artículo que se liberan en el mercado debe ser abierta de errores. Algunos piensan que se debe realizar sólo después de que el artículo ha sido completamente desarrollado, sin embargo, este mito tiene que ser desacreditado, ya que es imprescindible para realizar pruebas de control de calidad en cada fase del SDLC. En el escena actual de negocios altamente competitivo, la mayoría de las compañías eligen optar por las pruebas de software offshore, ya que tienen numerosos metas de negocio para centrarse en. Hay algunos tipos comunes de pruebas es decir, pruebas unitarias, pruebas funcionales, pruebas automatizadas, Las pruebas de rendimiento, La prueba de aceptación, Las pruebas del sistema, las pruebas de Cross Platform etc Algunas de las técnicas más recientes pruebas de una práctica generalizada son Pruebas de caja negro, Pruebas de caja blanca, pruebas exploratorias, Pruebas de caja gris, etc Un mayor número de dispositivos de pruebas también están ampliamente disponibles. Por ejemplo, dispositivos como JMeter, Solex, TPTP Eclipse, LoadRunner, Microsoft Application Center Test, WAPT, OpenSTA, etc WAST están disponibles para Pruebas de rendimiento. Además, dispositivos como Junit, DBUnit NUnit, HttpUnit, etc AspUnit puede ser utilizado para las pruebas unitarias, entretanto que las dispositivos como Mercury Quality Center, Jira, Bugzilla, Rally, Trac, Director de prueba, etc Seapine se emplean para la gestión de errores. Ahora bien, si hablamos de las pruebas de automatización, hay tres mayordes categorías de dispositivos como dispositivos comerciales (Mercury QTP, WinRunner), dispositivos de código abierto (selenio, Watir) y scripts personalizados (Perl, Java u otros lenguajes de programación). Ahora la pregunta que debe haber surgido en su mente por ahora es que ?¿Cuándo se debe de pruebas de control de calidad se realiza en un programa? Bueno, la respuesta a esta pregunta es que debe ser ejecutado desde el origen de un programa ya que no sólo ayuda a que el equipo de desarrollo se cuenta acerca de las tribulaciones y algunos otros problemas, sino que también conduce a la instalación efectiva del ámbito de prueba y, finalmente, gestión de yerros eficaz y rápida sin yerros la versión del artículo. De hecho, la prueba real se lleva a cabo una vez que el plan de pruebas está absolutamente documentado y revisado de acuerdo con la documentación de diseño. Ahora bien, si echamos un vistazo a las técnicas de control de calidad variada, estos beneficios implican la conceptualización de , que prevé que el artículo final, la probabilidad de ratificar los cálculos de carga, pruebas de exactitud basada en, lo que confirma los fundamentos de conexión, etc * Funcionalidad Exactitud Correcto Interoperabilidad Conformidad Seguridad * Fiabilidad Madurez Paciente a yerros Recuperabilidad * Usabilidad Comprensibilidad Aprendabilidad Operatividad Atractiva * Eficiencia Tiempo de respuesta Recursos Utilización * Mantenibilidad Analizable Cambiable Estabilidad Comparable Ante la necesidad de un consenso acerca de los fundamentos que determinan la calidad del software, ISO desde hace tiempo creo estándares en este sentido. El primero es el ISO 9126, originalmente publicado en 1991 y posteriormente revisado en 2001. Posteriormente desarrolló el estándar ISO/IEC 25010: SQuaRE (Software Product Quality Requirements and Evaluation), que fuese publicado en 2011 y viene a ser el reemplazo de ISO 9126. Como ya se explicó en el artículo de la Dra. Hanna Oktaba ?SQuaRE: Modelo actualizado de las características de calidad? publicado en SG #29, este modelo evalúa la calidad desde dos perspectivas: la calidad del artículo como tal (calidad interna), y la calidad de el uso del software (externa). Cada perspectiva estima variadas características, y a su vez cada característica puede tener una o más subcaracterísticas. Características y subcaracterísticas de calidad interna: Adecuación funcional:  funcionalidad adecuada, funcionalidad correcta, funcionalidad completa. Confiabilidad:  madurez, disponibilidad, tolerancia a fallos, recuperabilidad. Eficiencia de rendimiento:  tiempo de respuesta, utilización de recursos, capacidad. Operabilidad:  reconocimiento de funcionalidad adecuada, facilidad de uso, facilidad de aprendizaje, protección contra yerros de usuario, accesibilidad, estética de la interfaz de usuario. Seguridad:  confidencialidad, integridad, no rechazo, responsabilidad, autenticidad. Compatibilidad:  interoperabilidad, capacidad de coexistencia. Mantenibilidad:  modularidad, reusabilidad, capacidad de ser analizado, capacidad de ser modificado, capacidad de ser verificado/probado. Transmisibilidad/Portabilidad: instalabilidad, adaptabilidad, reemplazabilidad. Características y subcaracterísticas de calidad externa: Satisfacción de uso: utilidad, confianza, placer, comodidad. Seguridad de uso: mitigación de riesgos económicos, mitigación de riesgos para el usuario, mitigación de riesgos ambientales. Flexibilidad de uso: cobertura del contexto, flexibilidad. Efectividad de uso. Eficiencia de uso.