La clasificación de pruebas es el área donde se define las estrategias que pueden usarse para probar el software. En un extremo, puede esperarse hasta que el sistema esté completamente construido y luego realizar las pruebas sobre el sistema total, con la esperanza de encontrar errores. Este enfoque, aunque es atractivo, simplemente no funciona porque se debe tener una metodología que ayude a definir los enfoques que se quieren tener de la funciones de los aplicativos en los módulos esperados.
En el otro extremo, podrían realizarse pruebas diariamente, siempre que se construya alguna parte del sistema. Este enfoque, aunque menos atractivo para muchos, puede ser muy efectivo porque se reducen los tiempos para probar los aplicativos.
1. Estrategias de pruebas
Para la parte de prueba de un proyecto describe el enfoque y los objetivos generales de las tareas de prueba. Incluye las fases de prueba (unidad, integración y sistema) que se deben seguir y las clases de pruebas (función, rendimiento, carga, tensión) que se deben realizar.
La estrategia define:
Herramientas y técnicas de prueba que se deben utilizar.
Los requisitos de recursos se ven afectados por consideraciones especiales, o tienen implicaciones de planificación, como:
- probar todas las interfaces en sistemas externos (UX / UI)
- simular daño físico o amenaza a la seguridad
- Rendimiento de el sistema
- Componentes que lo conforma
- Posibles Mejoras
2.Niveles de pruebas
Pruebas funcionales
Se entiende como las Funcionalidades del Sistema cómo “lo que el sistema hace”.
Las Funcionalidades pueden estar descritas en las especificaciones de requerimientos, especificaciones funcionales, casos de uso e inclusive no estar documentadas.
Los casos de prueba se definen a partir de estas funciones o características, así como su interoperabilidad entre sistemas.
Consideran el comportamiento externo del sistema por lo que se consideran pruebas de caja negra.
Además de las pruebas sobre los módulos y funciones, pueden realizarse pruebas en áreas especializadas como Pruebas de Seguridad y Pruebas de Interoperabilidad.
Pruebas no funcionales de software
Su objetivo es probar los requerimientos no funcionales, incluyendo (sin limitarse a) pruebas de: Desempeño, Carga, Estrés, Usabilidad, Mantenibilidad, Confiabilidad y Portabilidad.
Los requerimientos no funcionales representan “cómo funciona el sistema” (en contraposición con las funcionalidades que definen “lo que el sistema hace”).
Las características no funcionales del software, se pueden medir de diversas maneras, por ejemplo por medio de tiempos de respuesta en el caso de pruebas de desempeño.
Pueden hacer referencias a modelos de calidad, como por ejemplo ISO 9126.
Consideran el “comportamiento externo” del sistema, en la mayoría de los casos son pruebas de caja negra.
Pruebas de la estructura ó arquictectura del Software
Las Pruebas Estructurales es el término usado por ISTQB para las pruebas de “Caja Blanca”.
Se realizan aplicando técnicas de pruebas estructurales y técnicas estáticas, en lugar de técnicas basadas en especificación.
Utiliza el concepto de “Cobertura” para definir la extensión con la cual la estructura ha sido cubierta por el conjunto de pruebas, expresado como un porcentaje del elemento probado.
Si la cobertura no es del 100%, se pueden diseñar pruebas adicionales.
Las pruebas estructurales se basan en la arquitectura del sistema, por ejemplo arquitectura de “Jerarquía de llamadas”.
Pruebas de regresión y re-prueba por cambios
Las Re-Pruebas son aplicadas después que un defecto es identificado y corregido, con la finalidad de verificar que el defecto ya no se está presentando.
Las Pruebas de Regresión se realizan sobre un componente ya probado, para verificar que no presenta nuevos defectos cuando se realiza una modificación después de dichas pruebas.
Deben buscarse nuevos defectos tanto en en el componente que se está probando cómo otros componentes afectados por el cambio.
Se necesita tener claridad de las piezas de software que resultan afectadas por el cambio.
Las pruebas deben ser repetibles si han de usarse para pruebas de confirmación y regresión.
Incluyen pruebas funcionales, no funcionales y estructurales.
Dado que las pruebas se ejecutan repetidas veces, las pruebas de regresión son candidatas a la automatización de pruebas por medio de herramientas.
Pruebas de mantenimiento
Aplicadas sobre sistemas que están operativos en ambiente de producción.
Se ejecutan como resultado de modificaciones, migraciones o desincorporación de software.
Las Pruebas de Modificaciones incluyen mejoras planificadas, correctivas o de emergencia, así como cambios en el entorno de sistema operativo, bases de datos, actualizaciones o parches.
Las Pruebas de Migración debe incluir pruebas operativas del nuevo entorno (Sistema operativo, base de datos, etc.) así como pruebas sobre el software modificado. Si existe migración y conversión de datos, también serán necesarias pruebas sobre estos.
Las Pruebas por Desincorporación incluyen pruebas de migración de datos o su archivo si se requieren largos períodos de retención.
Incluye también pruebas de regresión sobre las partes del sistema que no se están cambiando.
Pueden ser difíciles de realizar si las especificaciones están desactualizadas o no existen, o si no se cuenta con Testers con conocimiento del sistema.
3. Tipos de pruebas
Prueba alfa
Es el tipo de prueba más común utilizado en la industria del software. El objetivo de esta prueba es identificar todos los posibles problemas o defectos antes de lanzarlo al mercado o al usuario.
La prueba alfa se lleva a cabo al final de la fase de desarrollo de software, pero antes de la prueba beta. Aún así, se pueden hacer pequeños cambios de diseño como resultado de tales pruebas.
Alpha Testing se realiza en el sitio del desarrollador. Se puede crear un entorno de usuario virtual interno para este tipo de pruebas.
Pruebas de aceptación
Pruebas de aceptación
El cliente realiza una Prueba de aceptación y verifica si el flujo del sistema de extremo a extremo es según los requisitos comerciales o no y si es según las necesidades del usuario final. El cliente acepta el software solo cuando todas las características y funcionalidades funcionan como se espera.
Es la última fase de la prueba, después de la cual el software entra en producción. Esto también se llama Prueba de aceptación del usuario (UAT).
Pruebas ad-hoc
El nombre en sí sugiere que esta prueba se realiza sobre una base Ad-hoc , es decir, sin referencia al caso de prueba y también sin ningún plan o documentación para tal tipo de prueba.
El objetivo de esta prueba es encontrar los defectos y romper la aplicación ejecutando cualquier flujo de la aplicación o cualquier funcionalidad aleatoria.
Las pruebas ad-hoc son una forma informal de encontrar defectos y cualquier persona en el proyecto puede realizarlas. Es difícil identificar defectos sin un caso de prueba, pero a veces es posible que los defectos encontrados durante las pruebas ad-hoc no se hayan identificado utilizando los casos de prueba existentes.
Pruebas de accesibilidad
El objetivo de las Pruebas de accesibilidad es determinar si el software o la aplicación es accesible para personas discapacitadas o no.
Aquí, discapacidad significa sordo, daltónico, discapacitado mental, ciego, vejez y otros grupos discapacitados. Se realizan varias verificaciones, como el tamaño de fuente para discapacitados visuales, color y contraste para daltonismo, etc.
Pruebas Beta
Beta Testing es un tipo formal de Software Testing que realiza el cliente. Se realiza en el entorno real antes de lanzar el producto al mercado para los usuarios finales reales.
La prueba beta se lleva a cabo para garantizar que no haya fallas importantes en el software o el producto y satisfaga los requisitos comerciales desde la perspectiva del usuario final. La prueba beta es exitosa cuando el cliente acepta el software.
Por lo general, esta prueba la realizan los usuarios finales u otros. Es la prueba final que se realiza antes de lanzar una aplicación con fines comerciales. Por lo general, la versión Beta del software o producto lanzado está limitada a un cierto número de usuarios en un área específica.
Por lo tanto, el usuario final realmente utiliza el software y comparte los comentarios con la empresa. Luego, la compañía toma las medidas necesarias antes de lanzar el software a todo el mundo.
Pruebas de fondo
Cada vez que se ingresa una entrada o datos en la aplicación front-end, se almacena en la base de datos y la prueba de dicha base de datos se conoce como Prueba de base de datos o Prueba de back-end.
Existen diferentes bases de datos como SQL Server, MySQL y Oracle, etc. La prueba de base de datos implica la prueba de la estructura de la tabla, el esquema, el procedimiento almacenado, la estructura de datos, etc.
En la GUI de pruebas de back-end no está involucrado, los probadores están directamente conectados a la base de datos con el acceso adecuado y los verificadores pueden verificar fácilmente los datos ejecutando algunas consultas en la base de datos.
Puede haber problemas identificados como pérdida de datos, punto muerto, corrupción de datos, etc. durante estas pruebas de fondo y estos problemas son críticos para solucionar antes de que el sistema entre en funcionamiento en el entorno de producción
Pruebas de compatibilidad del navegador
Es un subtipo de Pruebas de compatibilidad (que se explica a continuación) y lo realiza el equipo de pruebas.
La prueba de compatibilidad del navegador se realiza para aplicaciones web y garantiza que el software pueda ejecutarse con la combinación de diferentes navegadores y sistemas operativos. Este tipo de prueba también valida si la aplicación web se ejecuta en todas las versiones de todos los navegadores o no.
Pruebas de compatibilidad con versiones anteriores
Es un tipo de prueba que valida si el software recientemente desarrollado o el software actualizado funciona bien con la versión anterior del entorno o no.
Las pruebas de compatibilidad con versiones anteriores verifican si la nueva versión del software funciona correctamente con el formato de archivo creado por una versión anterior del software; también funciona bien con tablas de datos, archivos de datos, estructura de datos creada por la versión anterior de ese software.
Si alguno de los programas se actualiza, debería funcionar bien sobre la versión anterior de ese software.
Prueba de caja negra
El diseño del sistema interno no se considera en este tipo de pruebas. Las pruebas se basan en los requisitos y la funcionalidad.
Aquí puede ver información detallada sobre las ventajas, desventajas y tipos de pruebas de caja negra .
Prueba de valor límite
Este tipo de prueba verifica el comportamiento de la aplicación a nivel de límite.
La prueba de valor límite se realiza para verificar si existen defectos en los valores límite. La Prueba de valor límite se utiliza para probar un rango diferente de números. Hay un límite superior e inferior para cada rango y la prueba se realiza en estos valores límite.
Si la prueba requiere un rango de prueba de números del 1 al 500, entonces la Prueba del valor límite se realiza en valores en 0, 1, 2, 499, 500 y 501.
Prueba de rama
Es un tipo de prueba de caja blanca y se lleva a cabo durante la prueba de la unidad. Prueba de rama, el nombre en sí sugiere que el código se prueba a fondo al atravesar cada rama.
Pruebas de comparación
La comparación de las fortalezas y debilidades de un producto con sus versiones anteriores u otros productos similares se denomina Prueba de comparación.
Pruebas de compatibilidad
Es un tipo de prueba en el que valida cómo se comporta y ejecuta el software en un entorno diferente, servidores web, hardware y entorno de red.
Las pruebas de compatibilidad aseguran que el software pueda ejecutarse en una configuración diferente, una base de datos diferente, diferentes navegadores y sus versiones. La prueba de compatibilidad es realizada por el equipo de prueba.
Prueba de componentes
En su mayoría, los desarrolladores lo realizan después de completar las pruebas unitarias. La prueba de componentes implica la prueba de múltiples funcionalidades como un código único y su objetivo es identificar si existe algún defecto después de conectar esas múltiples funcionalidades entre sí.
Pruebas de extremo a extremo
Similar a las pruebas del sistema, las pruebas de extremo a extremo implican la prueba de un entorno de aplicación completo en una situación que imita el uso en el mundo real, como interactuar con una base de datos, usar comunicaciones de red o interactuar con otro hardware, aplicaciones o sistemas si apropiado.
Particionamiento de equivalencia
Es una técnica de prueba y un tipo de prueba de caja negra. Durante esta Partición de equivalencia , se selecciona un conjunto del grupo y se recogen algunos valores o números para la prueba. Se entiende que todos los valores de ese grupo generan la misma salida.
El objetivo de esta prueba es eliminar los casos de prueba redundantes dentro de un grupo específico que genera la misma salida pero no ningún defecto.
Supongamos que la aplicación acepta valores entre -10 y +10, por lo que, utilizando la partición de equivalencia, los valores recogidos para la prueba son cero, un valor positivo, un valor negativo. Entonces, la partición de equivalencia para esta prueba es -10 a -1, 0 y 1 a 10.
Prueba de ejemplo
Significa pruebas en tiempo real. Las pruebas de ejemplo incluyen el escenario en tiempo real, también involucra los escenarios basados en la experiencia de los probadores.
Pruebas exploratorias
La prueba exploratoria es una prueba informal realizada por el equipo de prueba. El objetivo de esta prueba es explorar la aplicación y buscar defectos que existen en la aplicación.
A veces puede suceder que durante esta prueba los defectos mayores descubiertos puedan incluso causar una falla del sistema.
Durante las pruebas exploratorias, es aconsejable realizar un seguimiento de qué flujo ha probado y qué actividad realizó antes del inicio del flujo específico.
Se realiza una técnica de prueba exploratoria sin documentación ni casos de prueba.
Pruebas funcionales
Este tipo de prueba ignora las partes internas y se enfoca solo en la salida para verificar si cumple o no con el requisito. Es una prueba de tipo caja negra orientada a los requisitos funcionales de una aplicación. Para obtener información detallada sobre las pruebas funcionales, haga clic aquí .
Prueba de interfaz gráfica de usuario (GUI)
El objetivo de esta Prueba de GUI es validar la GUI según los requisitos comerciales. La GUI esperada de la aplicación se menciona en el Documento de diseño detallado y las pantallas de la maqueta de la GUI.
La prueba de GUI incluye el tamaño de los botones y el campo de entrada presente en la pantalla, la alineación de todo el texto, las tablas y el contenido de las tablas.
También valida el menú de la aplicación, después de seleccionar diferentes menús y elementos de menú, valida que la página no fluctúe y que la alineación permanezca igual después de pasar el mouse sobre el menú o submenú.
Prueba de gorila
Gorilla Testing es un tipo de prueba realizado por un probador y, a veces, también por el desarrollador. En Gorilla Testing, un módulo o la funcionalidad en el módulo se prueba exhaustiva y exhaustivamente. El objetivo de esta prueba es verificar la solidez de la aplicación.
Prueba de trayectoria feliz
El objetivo de Happy Path Testing es probar una aplicación con éxito en un flujo positivo. No busca condiciones negativas o de error. La atención se centra solo en las entradas válidas y positivas a través de las cuales la aplicación genera la salida esperada.
Pruebas de integración incremental
La Prueba de integración incremental es un enfoque ascendente para la prueba, es decir, la prueba continua de una aplicación cuando se agrega una nueva funcionalidad. La funcionalidad y los módulos de la aplicación deben ser lo suficientemente independientes como para probarlos por separado. Esto lo hacen programadores o probadores.
Instalar / desinstalar pruebas
Las pruebas de instalación y desinstalación se realizan en procesos de instalación / desinstalación completos, parciales o de actualización en diferentes sistemas operativos en diferentes entornos de hardware o software.
Pruebas de integración
Prueba de todos los módulos integrados para verificar la funcionalidad combinada después de la integración se denomina Prueba de integración .
Los módulos suelen 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 carga
Es un tipo de prueba no funcional y el objetivo de las pruebas de carga es verificar cuánta carga o carga de trabajo máxima puede manejar un sistema sin ninguna degradación del rendimiento.
Load Testing ayuda a encontrar la capacidad máxima del sistema bajo una carga específica y cualquier problema que cause la degradación del rendimiento del software. La prueba de carga se realiza utilizando herramientas como JMeter , LoadRunner, WebLoad, Silk performer, etc.
Prueba de mono
La prueba de Monkey la lleva a cabo un probador suponiendo que si el mono usa la aplicación, entonces, de qué manera la entrada aleatoria, Monkey ingresará los valores sin ningún conocimiento o comprensión de la aplicación.
El objetivo de Monkey Testing es verificar si una aplicación o sistema se bloquea proporcionando valores / datos de entrada aleatorios. Monkey Testing se realiza al azar y no hay guiones de casos de prueba y no es necesario
Monkey Testing se realiza de forma aleatoria y no hay guiones de casos de prueba y no es necesario tener en cuenta la funcionalidad completa del sistema.
Prueba de mutación
La prueba de mutación es un tipo de prueba de caja blanca en la que se cambia el código fuente de uno de los programas y verifica si los casos de prueba existentes pueden identificar estos defectos en el sistema.
El cambio en el código fuente del programa es muy mínimo para que no afecte a toda la aplicación, solo el área específica que tiene el impacto y los casos de prueba relacionados deberían poder identificar esos errores en el sistema.
Pruebas negativas
Los probadores que tienen la mentalidad de "actitud para romper" y utilizan las Pruebas negativas validan que si el sistema o la aplicación se rompen. Se realiza una técnica de prueba negativa utilizando datos incorrectos, datos no válidos o entradas. Valida que si el sistema arroja un error de entrada no válida y se comporta como se esperaba.
Pruebas no funcionales
Es un tipo de prueba para el cual cada organización tiene un equipo separado que generalmente se denomina equipo de prueba no funcional (NFT) o equipo de rendimiento.
Las pruebas no funcionales implican pruebas de requisitos no funcionales como pruebas de carga, pruebas de tensión, seguridad, volumen, pruebas de recuperación, etc. El objetivo de las pruebas NFT es garantizar si el tiempo de respuesta del software o la aplicación es lo suficientemente rápido según requisito de negocio.
No debería llevar mucho tiempo cargar ninguna página o sistema y debería mantenerse durante la carga máxima.
Pruebas de rendimiento
Este término a menudo se usa indistintamente con las pruebas de 'estrés' y 'carga'. Las pruebas de rendimiento se realizan para verificar si el sistema cumple con los requisitos de rendimiento. Se utilizan diferentes herramientas de rendimiento y carga para realizar esta prueba.
Pruebas de recuperación
Es un tipo de prueba que valida qué tan bien se recupera la aplicación o el sistema de fallas o desastres.
La Prueba de recuperación determina si el sistema puede continuar la operación después de un desastre. Suponga que la aplicación está recibiendo datos a través del cable de red y de repente ese cable de red se ha desconectado.
Algún tiempo después, conecte el cable de red; entonces el sistema debería comenzar a recibir datos desde donde perdió la conexión debido a que el cable de red está desconectado.
Pruebas de regresión
Probar una aplicación en su conjunto para la modificación en cualquier módulo o funcionalidad se denomina Prueba de regresión. Es difícil abarcar todo el sistema en las pruebas de regresión , por lo que, por lo general, se utilizan herramientas de pruebas de automatización para este tipo de pruebas.
Pruebas basadas en riesgos (RBT)
En pruebas basadas en riesgo , las funcionalidades o requisitos se prueban en función de su prioridad. Las pruebas basadas en el riesgo incluyen pruebas de funcionalidad altamente crítica, que tiene el mayor impacto en el negocio y en las que la probabilidad de falla es muy alta.
La decisión de prioridad se basa en la necesidad del negocio, por lo que una vez que se establece la prioridad para todas las funcionalidades, se ejecutan primero la funcionalidad de alta prioridad o los casos de prueba, seguidos de las funcionalidades de prioridad media y luego baja.
La funcionalidad de baja prioridad se puede probar o no según el tiempo disponible.
La prueba basada en el riesgo se lleva a cabo si no hay suficiente tiempo disponible para probar todo el software y el software debe implementarse a tiempo sin demora. Este enfoque es seguido solo por la discusión y aprobación del cliente y la alta gerencia de la organización.
Pruebas de cordura
Las pruebas de cordura se realizan para determinar si una nueva versión de software está funcionando lo suficientemente bien como para aceptarla para un esfuerzo de prueba importante o no. Si una aplicación se bloquea por el uso inicial, el sistema no es lo suficientemente estable como para realizar más pruebas. Por lo tanto, se asigna una compilación o una aplicación para solucionarlo.
Pruebas de seguridad
Es un tipo de prueba realizada por un equipo especial de evaluadores. Un sistema puede ser penetrado por cualquier forma de pirateo.
Las pruebas de seguridad se realizan para verificar cómo el software, la aplicación o el sitio web están protegidos contra amenazas internas y externas. Esta prueba incluye la cantidad de software seguro del programa malicioso, los virus y la seguridad y solidez de los procesos de autorización y autenticación.
También comprueba cómo se comporta el software ante cualquier ataque de piratas informáticos y programas maliciosos y cómo se mantiene el software para la seguridad de los datos después de dicho ataque de piratas informáticos.
Prueba de humo
Cada vez que el equipo de desarrollo proporciona una nueva compilación, el equipo de Software Testing valida la compilación y garantiza que no exista ningún problema importante.
El equipo de prueba se asegura de que la construcción sea estable y se lleve a cabo un nivel de prueba más detallado. Smoke Testing verifica que no exista un defecto de stop stop en la compilación, lo que evitará que el equipo de prueba pruebe la aplicación en detalle.
Si los evaluadores descubren que la funcionalidad crítica más importante se desglosa en la etapa inicial, entonces el equipo de prueba puede rechazar la compilación e informar en consecuencia al equipo de desarrollo. La prueba de humo se lleva a cabo a un nivel detallado de cualquier prueba funcional o de regresión.
Pruebas estáticas
La prueba estática es un tipo de prueba que se ejecuta sin ningún código. La ejecución se realiza en la documentación durante la fase de prueba.
Implica revisiones, tutoriales e inspección de los entregables del proyecto. La prueba estática no ejecuta el código en lugar de la sintaxis del código, se verifican las convenciones de nomenclatura.
La prueba estática también es aplicable para casos de prueba, plan de prueba, documento de diseño. Es necesario realizar pruebas estáticas por parte del equipo de pruebas ya que los defectos identificados durante este tipo de pruebas son rentables desde la perspectiva del proyecto.
Pruebas de estrés
Esta prueba se realiza cuando un sistema está estresado más allá de sus especificaciones para verificar cómo y cuándo falla. Esto se realiza bajo una gran carga, como poner un gran número más allá de la capacidad de almacenamiento, consultas complejas de la base de datos, entrada continua al sistema o carga de la base de datos.
Prueba del sistema
Bajo la técnica de Prueba del sistema , todo el sistema se prueba según los requisitos. Es una prueba de tipo caja negra que se basa en especificaciones de requisitos generales y cubre todas las partes combinadas de un sistema.
Pruebas unitarias
La prueba de un componente o módulo de software individual se denomina Prueba unitaria . Por lo general, lo realiza el programador y no los probadores, ya que requiere un conocimiento detallado del diseño y el código interno del programa. También puede requerir el desarrollo de módulos de controlador de prueba o arneses de prueba.
Pruebas de usabilidad
En Pruebas de usabilidad , se realiza una comprobación de facilidad de uso. El flujo de la aplicación se prueba para saber si un nuevo usuario puede entender la aplicación fácilmente o no, la ayuda adecuada documentada si un usuario se atasca en algún momento. Básicamente, la navegación del sistema se verifica en esta prueba.
Pruebas de vulnerabilidad
Las pruebas que implican la identificación de debilidades en el software, el hardware y la red se conocen como Pruebas de vulnerabilidad. Programas maliciosos, el hacker puede tomar el control del sistema, si es vulnerable a este tipo de ataques, virus y gusanos.
Por lo tanto, es necesario verificar si esos sistemas se someten a pruebas de vulnerabilidad antes de la producción. Puede identificar defectos críticos, fallas en la seguridad.
Prueba de volumen
Las pruebas de volumen son un tipo de pruebas no funcionales realizadas por el equipo de pruebas de rendimiento.
El software o la aplicación se somete a una gran cantidad de datos y las Pruebas de volumen verifican el comportamiento del sistema y el tiempo de respuesta de la aplicación cuando el sistema se encuentra con un volumen de datos tan alto. Este alto volumen de datos puede afectar el rendimiento del sistema y la velocidad del tiempo de procesamiento.
Prueba de caja blanca
White Box Testing se basa en el conocimiento sobre la lógica interna del código de una aplicación.
También se conoce como Glass box Testing. El software interno y el funcionamiento del código deben ser conocidos por realizar este tipo de pruebas. Bajo estas pruebas se basan en la cobertura de las declaraciones de código, ramas, rutas, condiciones, etc.
4.Conclusión
Los tipos de pruebas de software mencionados anteriormente son solo una parte de las pruebas. Sin embargo, todavía hay una lista de más de 100 tipos de pruebas, pero todos los tipos de pruebas no se utilizan en todos los tipos de proyectos. Así que he cubierto algunos tipos comunes de pruebas de software que se utilizan principalmente en el ciclo de vida de las pruebas.
Además, existen definiciones o procesos alternativos utilizados en diferentes organizaciones, pero el concepto básico es el mismo en todas partes. Estos tipos de pruebas, procesos y sus métodos de implementación siguen cambiando a medida que cambia el proyecto, los requisitos y el alcance.
Referencias
Tipos de pruebas de software definidos por el ISTQB
http://www.pmoinformatica.com/2012/07/5-preguntas-y-respuestas-sobre-istqb.html
ESTRATEGIAS DE PRUEBA PARA SOFTWARE
https://virtual.itca.edu.sv/Mediadores/stis/42estrategias_de_prueba_para_software.html
Tipos De Pruebas De Software: Diferentes Tipos De Pruebas Con Detalles
https://www.softwaretestinghelp.com/types-of-software-testing/
Comentarios