how effectively prepare test bed
Retos y mejores prácticas de configuración del entorno de prueba / banco de pruebas:
En varias ocasiones, los probadores encuentran que sus defectos son rechazados por problemas ambientales o se encuentran constantemente replicando los defectos por razones similares. Si bien abrir la mayor cantidad de defectos debe ser sin duda uno de los puntos de referencia personales para cada evaluador, la mayoría de los probadores también deben enfatizar en tener la mayor cantidad de defectos válidos.
¿Cómo se logra esto?
Aparte de otros aspectos como planificar una variedad de escenarios de prueba y comprender la línea de pedido a fondo, una Se debe invertir una buena cantidad de tiempo en configurar el banco de pruebas o el entorno de prueba. . En segundo lugar, a pesar de tener una cantidad estimada para la planificación de casos de prueba, los evaluadores también deben enfocar sus energías en creando datos de prueba efectivos .
Personalmente, al ser parte del proceso de auditoría, he observado que la mayor cantidad de defectos válidos se encuentran cuando se ha invertido una buena cantidad de esfuerzo en crear el banco de pruebas o el entorno de prueba de una manera correcta y cuando el probador tiene un comprensión del tipo de entorno necesario.
Además, el tipo de datos de prueba suministrados al entorno de prueba puede exponer algunas fallas muy serias en el código / función bajo prueba que pueden afectar severamente la calidad del producto.
Este artículo habla sobre lo que implica exactamente el banco de pruebas: es un proceso de dos pasos de configuración del entorno de prueba y configuración de datos de prueba:
Parte 1) La primera parte del artículo discutirá el proceso general de configuración del entorno de prueba , los problemas de configuración que enfrentan con mayor frecuencia las pruebas y las sugerencias que se deben tener en cuenta al crear un banco de pruebas en lugar de estos desafíos.
Parte 2) Habiendo dicho tanto con respecto al banco de pruebas colectivamente en este artículo, valió la pena arrojar algo de luz sobre el Mantenimiento del entorno de prueba aspectos también. La última parte del artículo analiza la segunda parte de la configuración del banco de pruebas, que incluye los datos de prueba, el enfoque para configurarlo y algunos Técnicas de gestión de datos de prueba .
Con un “big bang” constante en el desarrollo y las pruebas de software, existe un enfoque cada vez mayor en la adopción de diversas metodologías para hacer que el proceso general de Garantía de Calidad sea transparente, eficiente y adecuado.
Se llevan a cabo varias auditorías de calidad en todas las organizaciones para garantizar que el desempeño del equipo de prueba pueda evaluarse adecuadamente y tenga resultados medibles con las métricas identificadas en la inicialización del ciclo de prueba. Estos resultados permiten identificar dónde se encuentra un equipo en particular en términos de garantizar una calidad óptima para el software que prueban.
Estos informes también ayudan al equipo a comprender las oportunidades de mejora en función de las observaciones realizadas durante la auditoría.
No hace falta mencionar que una métrica muy obvia para cualquier equipo de prueba sería con respecto al número total de defectos abiertos frente al número de defectos válidos . De ahí que una de las preguntas que obviamente surgen es: ¿Cuál es la base para intentar descubrir algún defecto? Dicho de otra manera, ¿cuál es la base sobre la que se puede encontrar un defecto?
La respuesta es unánime: configuración del banco de pruebas y / o del entorno de prueba. Hay puntos de referencia de calidad establecidos dentro de los equipos para reducir los defectos que son rechazados como un error de configuración de prueba / error de usuario, configuraciones no válidas o, en algunos casos, los defectos que surgen como escapes de un equipo en particular debido a configuraciones no disponibles, configuraciones no probadas.
Empecemos analizando más de cerca la definición de un banco de pruebas o un entorno de pruebas.
Lo que vas a aprender:
¿Qué es un banco de pruebas y un entorno de prueba?
En un sentido muy genérico, un banco de pruebas podría definirse como un tipo de entorno de desarrollo en el que los implementadores de código o módulos tienen la libertad de probar sus módulos sin ninguna perturbación del equipo de pruebas, en un confinamiento absoluto.
Sin embargo, un banco de pruebas no solo es específico de un equipo de desarrollo. Desde la perspectiva de un equipo de prueba o un evaluador, dado que el banco de pruebas no es más que una plataforma identificada para las pruebas de software / productos, también se le llama indistintamente entorno de prueba.
Cualquier banco de pruebas o entorno de prueba debería configurarse de acuerdo con el objetivo de prueba identificado para la aplicación / producto / software bajo prueba. En determinadas situaciones, un banco de pruebas sería la recopilación del entorno de prueba y los datos de prueba con los que opera.
Componentes de un entorno de prueba
Cualquier prueba tendría sus requisitos de entorno de prueba específicos, pero en un sentido muy amplio, cualquier banco de pruebas / entorno de prueba comprenderá el hardware, el software y las piezas de red para admitir la configuración requerida como mínimo para conducir y realizar la prueba en particular. .
Es un hecho bien conocido que los problemas ambientales consumen una cantidad razonable de tiempo de un evaluador, lo que a su vez afecta la productividad y los programas de prueba. Aunque el tipo de desafíos varía para todos y cada uno de los equipos de prueba, algunos de ellos pueden ser comunes.
Algunos desafíos clave que se enfrentan comúnmente son:
# 1) Entorno remoto
Los activos o entornos de prueba se ubican en su mayoría geográficamente en sitios remotos para los equipos. Este es uno de los desafíos más comunes para los equipos de prueba, como en el caso de cualquier problema que pueda surgir relacionado con el hardware, firmware, software, redes, etc.
Los equipos que consumen los activos deberían depender en gran medida de los equipos de soporte en la ubicación donde están presentes los activos.
En la misma línea, si algún activo necesita una actualización de firmware o una actualización de compilación, nuevamente el equipo de prueba puede necesitar el apoyo de los equipos de soporte que poseen el entorno abriendo tickets de soporte. Esto también puede acaparar un tiempo de prueba considerable y retrasar los programas, especialmente en casos de diferencias de zona horaria.
# 2) Uso combinado entre equipos
La mayoría de las veces, los equipos de desarrollo y prueba utilizan los mismos activos ambientales. Aunque la norma general define que los entornos de desarrollo, prueba y producción deben estar separados, en realidad este escenario ideal rara vez se logra. Se vuelve extremadamente costoso para las organizaciones adquirir recursos separados para cada equipo.
Por lo tanto, la mayoría de las organizaciones exigen el uso común del entorno entre el desarrollo y la prueba. Sumado a esto, si los recursos de desarrollo y prueba compiten por el uso de los mismos activos al mismo tiempo, se genera caos y desacuerdos entre los miembros.
# 3) Planificación ineficaz del uso de recursos para la integración
En algunos casos para escenarios que necesitan un prueba de extremo a extremo donde hay una integración de dos o más componentes para funcionar juntos, nuevamente puede haber un requisito para tener el uso común de recursos entre los equipos de prueba. La planificación ineficaz con respecto al uso contribuye en gran medida a que el entorno se vuelva inestable, además de los conflictos entre equipos.
El efecto más evidente de esto es que un problema que se advierte una o dos veces en particular puede producir un comportamiento completamente diferente en las siguientes ejecuciones para el mismo escenario. Si ya se ha abierto un defecto para esto, hay muchas posibilidades de que el desarrollo no lo acepte como un candidato válido para una solución.
# 4) Configuración de prueba compleja
La configuración del banco de pruebas o del entorno de prueba a veces es demasiado compleja. Esto planteará varios desafíos, ya que el equipo de prueba necesitará las habilidades necesarias para comprender las configuraciones necesarias. A veces hay una falta de base de conocimientos disponible para que el evaluador pueda generar la configuración requerida.
En tales casos, los probadores pueden inducir un error en el banco de pruebas configurándolo incorrectamente. Esto tendría un gran impacto en el caso de prueba y los resultados que produce.
# 5) Elaborar tiempo de configuración
En otras ocasiones, para cada caso de prueba, la configuración de la prueba puede ser demasiado elaborada en cada caso de prueba identificado. Esto podría deberse a una amplia variedad de tecnologías coexistentes que deben acoplarse o varios componentes para trabajar juntos en casos de pruebas de integración.
En estos casos, cada uno de los componentes tiene que estar funcionando perfectamente para asegurar resultados consistentes, ya que un componente puede formar parte del siguiente.
Mejores prácticas para configurar un entorno de prueba
Hemos echado un vistazo a la descripción general de los desafíos a los que se enfrenta un evaluador antes o al comenzar la ejecución de la prueba. La mayoría de nosotros nos hemos enfrentado a uno o más de estos problemas en algún momento durante los hitos de nuestro proyecto. Estos desafíos han existido y posiblemente seguirán existiendo en diversos grados porque no existe una situación idealista.
Dado que los desafíos de configuración son parte integral del trabajo de un evaluador y son inevitables, aquí hay algunas sugerencias sobre cómo preparar de manera efectiva la configuración para la prueba. Esto podría ayudar a minimizar los defectos que pueden originarse por problemas de configuración.
Consejo n. ° 1) Entender el Pruebe los requisitos a fondo y edúcate
preguntas y respuestas de la entrevista de prueba de base de datos para experimentados
¡Empiece siempre por lo básico y lo más obvio! Cuando el equipo de desarrollo implementa un documento de especificaciones o un documento de caso de uso, el paso invariable para el equipo de prueba es comprender los requisitos de la línea de pedido y luego preparar un documento de caso de prueba que detalle los casos de prueba.
Mientras se lleva a cabo la planificación de la prueba, es el mejor práctica para incluir también la información detallada del entorno de prueba en el documento del caso de prueba. No hay que adivinar el hecho de que el evaluador pasará algún tiempo analizando qué entorno de prueba puede ser necesario y, en consecuencia, las configuraciones necesarias.
Esto se puede lograr hablando con el equipo de desarrollo / arquitectos para construir una buena base de conocimientos. Esto no solo ahorraría algo de tiempo en el ciclo de ejecución, sino que también ayudará al evaluador a distribuir su tiempo de ejecución de manera efectiva entre pruebas simples y complejas.
Personalmente, un buen resultado de esto es que muchos de nosotros descubrimos problemas de configuración (que inherentemente evitarían la ejecución de pruebas consistentes) al comienzo del ciclo, lo que nos dio tiempo para canalizar y adquirir la ayuda necesaria para solucionar esos problemas, por lo tanto no extender el ciclo de prueba más allá de períodos inaceptables.
Otro impacto positivo que esto tendría es que esto mejoraría enormemente el conocimiento del equipo de prueba y evitaría defectos innecesarios. Aunque esta práctica resume casi todas las prácticas que son inherentemente necesarias para hacer frente a los desafíos de configuración de prueba mencionados anteriormente, aún vale la pena mencionar los otros consejos.
Consejo n. ° 2) Comprobando la conectividad
Otro punto de control muy importante es asegurarse de que los recursos o activos que desea utilizar para las pruebas sean accesibles. En caso de que el sistema deba ejecutarse integrado con otras máquinas, verifique su conectividad entre sí mediante ping o telnet.
Además, si los sistemas necesitan interactuar entre sí y están detrás de cortafuegos, asegúrese de que puedan autenticarse a través de estos cortafuegos mediante las Opciones de seguridad básicas (BSO) y comprobar también si hay proxies. En caso de que observe que algunas máquinas no son accesibles o necesitan autenticación BSO, se pueden presentar las solicitudes de servicio adecuadas para cumplir con el requisito al equipo de soporte.
Esto es particularmente útil cuando el entorno se encuentra en ubicaciones remotas y también evitará escaladas con respecto a las máquinas y sistemas. En caso de que el equipo de prueba requiera acceso a cualquier recurso o repositorio, esto ayudaría a determinar proactivamente el mismo.
Consejo n. ° 3)Comprobando la red y / o el almacenamiento
Esto es casi una extensión del consejo anterior y necesitaría una cierta verificación más con mayor profundidad técnica. Asegúrese de que la prueba que necesita tenga el ancho de banda necesario y si su prueba necesita una conexión a Internet. Además, asegúrese de encontrar una forma de verificar que la topología de red entre sistemas y recursos sea correcta.
En segundo lugar, si su objetivo de prueba implica la necesidad de almacenamiento, asegúrese de que haya almacenamiento y conectividad de red. En general, es responsabilidad del administrador tener esto en su lugar, sin embargo, también es un gran valor agregado tener algún conocimiento funcional y funcional del mismo.
Consejo # 4) Compruebe el hardware y el software necesarios, las licencias
Muchas veces sucede que los probadores comienzan la ejecución en los sistemas sin verificar el hardware y el software necesarios que pueden ser necesarios. Como resultado de esto muchas veces, un evaluador se da cuenta casi durante el ciclo de prueba de que cierta funcionalidad está disponible solo en un nivel superior de hardware o software / firmware.
En ese momento, el probador marcará un bloqueador en su esfuerzo de prueba, lo que consume un tiempo de prueba considerable. Por lo tanto, es una práctica invaluable tener un punto de control para tomar nota del hardware y software que se necesita previamente.
Muchas veces puede haber tiempo de inactividad involucrado en la actualización del hardware / software, que se reduce a Consejo 1 donde un probador debe participar en la planificación proactiva con respecto al hardware. Es posible que parte del software requiera licencias que pueden requerir aprobaciones y acciones del equipo legal. Al ser esta una acción impulsada por el proceso, nuevamente podría tomar varios días en completarse, lo cual debe planificarse.
Consejo n. ° 5)Navegadores y versiones
Las pruebas que haces tienen que reflejar lo que hará un usuario final . Podría estar probando en un navegador particular en las últimas versiones de todos los navegadores. Por lo tanto, es obligatorio identificar los diferentes tipos de navegadores que se utilizarían para las pruebas e instalarlos en su propia configuración de prueba local.
En segundo lugar, también identifique qué versiones de navegadores deben utilizarse para realizar pruebas. Una buena práctica sería comenzar con un navegador de la versión anterior, asegurando así la compatibilidad con versiones anteriores y luego actualizar a la última versión.
Consejo n. ° 6)Planificación del uso del entorno de prueba.
Dado que el equipo de prueba nunca tendrá la situación de tener sus propios recursos, sistemas y activos de prueba, uno de los hitos principales en la planificación de la prueba es tener un uso eficaz de los recursos de prueba.
algoritmo de clasificación de combinación de c ++
Esto es particularmente necesario cuando más de un equipo tiene que acceder al mismo conjunto de recursos debido a un escenario de un extremo a otro que consta de dos o más componentes que trabajan juntos, o una situación en la que la configuración de la prueba es demasiado elaborada o compleja para ser replicada. muy fácilmente y podría haber varios miembros dentro del mismo equipo con sus propios objetivos de prueba con la misma configuración.
Una buena práctica sería elaborar un enfoque de tiempo compartido mediante el cual un determinado equipo o persona lo use para la primera mitad y las personas restantes para la segunda mitad. Puede haber algún momento intermedio que sea común en el que cada uno de ellos pueda ejecutar pruebas independientes que no obstaculicen al otro.
Hacer esto no solo reducirá el caos y los conflictos dentro de los miembros, sino que también asegurará la estabilidad conductual del entorno durante más tiempo.
Consejo # 7)Herramientas de automatización y sus configuraciones
Como sabemos, cada elemento de línea en prueba tendrá algunas pruebas repetitivas que serán parte del ciclo de regresión que deberá automatizarse. El equipo de prueba debe identificar qué tipo de automatización le gustaría realizar y las herramientas necesarias para ello.
Aunque esto no es necesario que forme parte de la preparación del entorno, aún lo enumeraría como una mejor práctica para identificar y configurar las herramientas de automatización en consecuencia. Esto dependería completamente de la discreción del evaluador cuando quiera realizar esta actividad, ya que este no es un factor obligatorio para garantizar la preparación de la prueba.
Conclusión
Estos consejos y trucos pueden formar un buen criterio y huella para garantizar la preparación del entorno de prueba para las pruebas. Sin duda, cada equipo se enfrenta a su propio conjunto único de desafíos y los consejos anteriores se pueden adaptar y personalizar para satisfacer sus propias necesidades respectivas.
De hecho, la fuente para anotar todo este esqueleto de consejos proviene de una de mis asignaciones en la que enfrenté problemas de configuración muy complejos y me tomó casi un año incluso comenzar a probar.
Aunque las limitaciones en el entorno de prueba estaban fuera de mi control, sentí que muchos de esos problemas podrían haberse informado antes si hubiera aplicado estos consejos. Lo he estado aplicando para cada tarea que se me presenta desde entonces y este esqueleto me ha ayudado mucho a encontrar proactivamente problemas de configuración y canalizar mis esfuerzos para resolverlos.
Sobre el Autor: Este artículo está escrito por Sneha Nadig. Trabaja como líder de pruebas con más de 7 años de experiencia en proyectos de pruebas manuales y de automatización.
En la parte 2 de este artículo, veremos el proceso de configuración y mantenimiento del entorno de prueba y sugerencias de administración y preparación de datos de prueba. Mientras tanto, no dude en publicar sus consultas de preparación del banco de pruebas en los comentarios.
Lectura recomendada
- Cómo realizar pruebas posteriores al lanzamiento de manera eficaz y minimizar el impacto del lanzamiento en los clientes activos
- ¿Cómo se decide qué defectos son aceptables para que el software entre en funcionamiento?
- Cómo preparar y entregar una excelente presentación de pruebas de control de calidad al equipo
- Proceso de gestión de defectos: cómo gestionar un defecto de forma eficaz
- Las 9 mejores ideas para que los probadores utilicen su tiempo de banco de manera efectiva
- Liderazgo en pruebas: responsabilidades de los líderes de pruebas y cómo gestionar el equipo de pruebas de forma eficaz
- Cómo planificar y gestionar proyectos de prueba de forma eficaz (consejos)
- Proceso de clasificación de defectos y formas de manejar Reunión de clasificación de defectos