Prueba de funcionalidad: la funcionalidad de la aplicación (es decir, componentes de la GUI). según las especificaciones (por ejemplo, si hacemos clic en el botón "enviar", la aplicación debe mostrar ..... "cuadro de diálogo de confirmación")



Prueba de aceptación: prueba formal realizada para determinar si un sistema cumple con sus criterios de aceptación y, por lo tanto, si el cliente debe aceptar el sistema



Prueba de regresión: prueba de la aplicación para verificar si las características anteriores funcionan correctamente o no, después de agregar nuevas características a la aplicación.



Pruebas de estrés: la idea de las pruebas de estrés es encontrar el punto de ruptura para encontrar errores que hagan que esa ruptura sea potencialmente dañina.



Prueba de carga: esto es simplemente una prueba a la tasa de llegada de transacciones más alta en pruebas de rendimiento para ver la contención de recursos, bloqueos de bases de datos, etc.



Pruebas de recuadro negro: se enfoca en la funcionalidad del programa contra la especificación.



Prueba de caja blanca: se centra en los caminos de la lógica.



Pruebas unitarias: la escala de prueba más 'micro'; para probar funciones particulares o módulos de código. Normalmente lo realiza el programador y no los probadores, ya que requiere un conocimiento detallado del diseño y el código interno del programa. No siempre se hace fácilmente a menos que la aplicación tenga una arquitectura bien diseñada con código estricto; puede requerir el desarrollo de módulos de controlador de prueba o arneses de prueba.



Prueba de integración: prueba de partes combinadas de una aplicación para determinar si funcionan juntas correctamente. Las 'partes' pueden ser módulos de código, aplicaciones individuales, aplicaciones de cliente y servidor en una red, etc. Este tipo de prueba es especialmente relevante para el cliente / servidor y los sistemas distribuidos.



Prueba de integración incremental: prueba continua de una aplicación a medida que se agrega nueva funcionalidad; requiere que varios aspectos de la funcionalidad de una aplicación sean lo suficientemente independientes como para trabajar por separado antes de que se completen todas las partes del programa, o que los controladores de prueba se desarrollen según sea necesario; hecho por programadores o probadores.



Pruebas funcionales: pruebas de tipo caja negra orientadas a los requisitos funcionales de una aplicación; Este tipo de prueba debe ser realizado por probadores.



Pruebas del sistema: pruebas de tipo caja negra que se basan en especificaciones de requisitos generales; cubre todas las partes combinadas de un sistema.



Prueba de cordura: por lo general, un esfuerzo de prueba inicial para determinar si una nueva versión de software está funcionando lo suficientemente bien como para aceptarla para un esfuerzo de prueba importante. Por ejemplo, si el nuevo software está bloqueando los sistemas cada 5 minutos, empantanando los sistemas o destruyendo bases de datos, es posible que el software no esté en una condición lo suficientemente `` sensata '' como para justificar pruebas adicionales en su estado actual.



Pruebas de rendimiento: este término a menudo se usa indistintamente con las pruebas de 'estrés' y 'carga'. Idealmente, las pruebas de 'rendimiento' (y cualquier otro 'tipo' de pruebas) se definen en la documentación de requisitos o el control de calidad o los planes de prueba.



Pruebas de usabilidad: pruebas de 'facilidad de uso'. Claramente, esto es subjetivo y dependerá del usuario final o cliente objetivo. Se pueden utilizar entrevistas a usuarios, encuestas, grabaciones de video de sesiones de usuarios y otras técnicas. Los programadores y probadores generalmente no son apropiados como probadores de usabilidad.



Pruebas de instalación / desinstalación: Pruebas de procesos de instalación / desinstalación completos, parciales o de actualización.



Pruebas de seguridad: prueba de qué tan bien protege el sistema contra el acceso interno o externo no autorizado, daños intencionales, etc. puede requerir técnicas de prueba sofisticadas.



Prueba de compatibilidad: prueba de qué tan bien funciona el software en un hardware / software / sistema operativo / red / etc en particular. ambiente.



Pruebas ad-hoc: prueba de la aplicación de manera aleatoria.



Prueba alfa: prueba de una aplicación cuando el desarrollo está a punto de completarse; Se pueden hacer cambios menores de diseño como resultado de tales pruebas. Típicamente hecho por usuarios finales u otros, no por programadores o probadores.



Pruebas Beta: Pruebas cuando el desarrollo y las pruebas se completan esencialmente y los errores y problemas finales deben encontrarse antes del lanzamiento final. Típicamente hecho por usuarios finales u otros, no por programadores o probadores.