Hay muchos argumentos tontos sobre el significado de estos términos, pero si te enfocas en qué preguntas estás tratando de responder con cada fase y las respondes, entonces estarás bien. Recuerde, un buen control de calidad consiste en responder las preguntas correctas. Si no sabes qué pregunta estás respondiendo, probablemente estés perdiendo el tiempo.
No todas las organizaciones de ingeniería hacen lo mismo, y la mía en realidad difiere bastante de esto, pero creo que esta es la respuesta que está buscando.
Pruebas unitarias: ¿Funciona el código como el desarrollador lo espera? Generalmente automatizados, también pueden ejecutarse manualmente para garantizar que se registre el código de calidad. Por lo general, estos son ejecutados por los desarrolladores y / o cuando se está creando la compilación.
- ¿Cuál es el mejor software para medir FPS?
- ¿Qué tan grande fue una hazaña de ingeniería de Linux cuando se lanzó por primera vez en 1991?
- ¿Cómo se hizo Isha Bansal tan buena en la codificación?
- ¿Cuál es el software de código abierto más complejo jamás escrito?
- ¿Alguien podría decir detalles completos sobre el patrón de colocación y los documentos de Prime Focus Technologies?
Pruebas de aceptación: ¿La construcción es estable / completa para ejecutar pruebas más complicadas? Estos a menudo están automatizados, ya que tienden a fallar a menudo cuando el desarrollo piensa que están hechos, pero la realidad no está de acuerdo. Son pruebas muy simples.
En el mundo de la consultoría, la “aceptación” en realidad se refiere a las pruebas realizadas como parte del traspaso entre los consultores y la empresa que los contrató. Son las pruebas “finales” ejecutadas antes de que un proyecto pueda considerarse entregado (aunque a menudo el trabajo continúa por un tiempo después)
Pruebas funcionales: ¿ Funciona una unidad de funcionalidad determinada como se espera? Estos están más involucrados, tienden a enfocarse en casos de uso.
Prueba del sistema: (me refiero a esto como pruebas de integración) ¿Funciona bien la construcción con todos los puntos de integración? Esto puede significar simplemente probar una compilación en un entorno similar a la producción, o si un producto interactúa con varios otros sistemas, se probarán esos puntos de integración.
Pruebas de rendimiento: el producto funciona como se esperaba. Divido esto en tres términos más específicos: Carga, Capacidad y “Rendimiento”
Pruebas de carga: ¿Cuál es la X máxima que puede hacer un sistema? (Cuántos pedidos por minuto, o páginas vistas por segundo, etc.). Esto descubre los cuellos de botella de su sistema para que puedan abordarse para aumentar la capacidad.
Pruebas de capacidad : dado el entorno de producción, ¿a qué carga comenzará a sufrir el rendimiento del sistema? (es decir: a 2300 páginas vistas por segundo, los tiempos de carga de la página son inferiores a 1 segundo. A 2500 páginas vistas por segundo, los tiempos de carga de la página son 3 o más segundos). Esto le indica dónde está su punto de ruptura antes de que necesite hacer pruebas de carga para aumentar la capacidad.
Pruebas de rendimiento: ¿qué tan receptivo es el sistema?
Pruebas de usabilidad : los usuarios finales encuentran el producto intuitivo, divertido, interesante, agradable, etc. Por lo general, los usuarios finales o grupos focales pueden observar cómo los usuarios descubren cómo lograr un objetivo. Esto generalmente se realiza después de completar la prueba funcional.
Pruebas de localización : ¿Funciona el sistema como se esperaba cuando lo utilizan personas en países extranjeros? (Traducción, formatos de fecha, moneda, etc.). Esto suele suceder después de que se pasan las pruebas funcionales para evitar tener que volver a localizar las páginas después de que se hayan solucionado los errores de funcionalidad.
Pruebas negativas: cuando el sistema encuentra condiciones inesperadas, ¿las maneja bien? (por ejemplo: direcciones de correo electrónico no válidas, juegos de caracteres no ASCII, campos vacíos, cadenas largas, etc.). En mi opinión, estas pruebas deberían ser parte de las pruebas funcionales y del sistema. Algunas organizaciones hacen esto más tarde para que puedan centrarse en la usabilidad sin distraerse con los casos de esquina.
Pruebas de penetración / seguridad: ¿es seguro el sistema? Estos a menudo toman la forma de suites de pruebas automatizadas de terceros para detectar fallas de seguridad comunes (por ejemplo: inyección sql), pero también puede ser más explícito donde se prueba la validación de back-end.
