how improve test release process
Veamos el proceso típico involucrado en la entrega de software desde la 'fase de desarrollo' hasta la 'fase de prueba' para un lanzamiento exitoso de software sin errores para producción / cliente .
Las empresas de software pasan por alto o omiten estos procesos, lo que da como resultado una gestión de prueba deficiente y, por lo tanto, una ' calesa 'Versiones de software para el cliente, lo que conduce a' clientes insatisfechos ”.
Aunque el equipo de pruebas ha dedicado mucho tiempo y esfuerzo a todos y cada uno de los lanzamientos , cuando el software lanzado no tiene la calidad definida o comparada o no cumple con los criterios esperados, no solo afectará la reputación de la empresa con los clientes, sino que también desmotivará y desmoralizará al equipo del proyecto, lo que es más importante, al equipo de pruebas en su conjunto. .
Si forma parte de un equipo de pruebas en este escenario, puede seguir pensando 'cómo mejorar mis capacidades de prueba y hay alguna manera mejor de superar esta situación'.
Quiero dar algunos consejos y sugerencias, basados en mi experiencia con varios equipos de prueba involucrados en aplicaciones de software y lanzamientos de productos empresariales con múltiples dominios y plataformas y con múltiples marcos de prueba, en cómo mejorar los procesos de lanzamiento de prueba , lo que simplificará su vida profesional como ingeniero de pruebas o administrador de pruebas para ofrecer software de clase mundial.
Lo que vas a aprender:
- Proceso de lanzamiento de prueba
- Mejora del proceso de lanzamiento de prueba:
- Gestionar y controlar el contenido de la versión de prueba
- Plantilla de informe de lanzamiento de muestra:
- Conclusión:
- Lectura recomendada
Proceso de lanzamiento de prueba
La siguiente tabla ofrece una descripción general de un proceso de lanzamiento de prueba con tres fases universales como Entrada, Proceso y Salida.
¿Qué es la prueba de regresión con ejemplo?
| APORTE | PROCESO | PRODUCCIÓN |
|---|---|---|
| 7 | ¿La lista de verificación de revisión de código se ha actualizado y está disponible en VSS? | |
| Proceso anterior Desarrollo | El proceso comienza con • Instalación del software publicado en el servidor de pruebas | Necesidades del próximo proceso • Software que pasó las pruebas de humo / cordura |
| Información / Referencia de documentos • Documento de requisitos del usuario • Especificaciones de requisitos de software • Plan de pruebas unitarias • Estándares de codificación • Lista de verificación de revisión de código • Plan de Desarrollo • Plan de garantía de calidad • Asignación de tareas • Paquete de trabajo • Cronograma del proyecto • Plan de proyecto • Plan de gestión de la configuración • Plan de gestión de Riesgos. | Subprocesos • Preparación de casos de prueba para todas las unidades • Desarrollo y pruebas unitarias • Manejo de procedimientos de no conformidad • Implementación del Plan de Gestión de la Configuración. • Implementación del plan de gestión de riesgos • Seguimiento del progreso del proyecto • Corrección de errores y revisiones | Necesidades internas del cliente • Compilación de software con número de versión • Informe de lanzamiento • Documento de casos de prueba / conjunto de pruebas • Planificación de la ejecución de pruebas • Matriz de trazabilidad • Datos de prueba |
| Verificación de entrada entrante • ¿Se revisan y aprueban los documentos del proyecto? • ¿Están disponibles las normas de codificación y la lista de verificación de revisión del código como referencia? • ¿Tarea asignada y paquete de trabajo actualizado? • ¿Se revisan y aprueban las especificaciones funcionales, el plan de desarrollo y el plan de calidad? • ¿El plan de gestión de riesgos tiene mitigación y contingencia para manejar el riesgo? • ¿Efectividad del cronograma del proyecto para entregar el producto a tiempo? | Especificación de proceso • Los casos de prueba unitaria deben constar de todos los criterios de entrada y salida • Cumplimiento del código con estándares de codificación • El NCP debe manejarse de acuerdo con las Directrices. • Los pasos de gestión de la configuración deben adherirse al plan de gestión de la configuración. • El manejo de riesgos debe adherirse al plan de gestión de riesgos • Las pruebas de humo pasan todas las características y funcionalidades principales | Necesidades del cliente externo • Software libre de errores |
| Procesos de apoyo • Asignación de recursos humanos / hardware / software / • Mantenimiento de averías de hardware • Capacitación para miembros del equipo | El proceso termina con • Ejecución de pruebas de humo / cordura en la compilación publicada | Parámetros de eficiencia • Cada unidad debe aprobar la primera ronda de pruebas. • Tareas a completar según el cronograma del proyecto • La prueba de humo debe pasarse antes de la liberación • Probar la pasión del equipo por probar el software |
Cada equipo de pruebas debe crear un único Lista de Verificación para lanzamiento de software, según el dominio y la plataforma del software y la metodología de gestión de proyectos (como Agile Scrum, etc.) y según el marco de prueba manual / automatizado, para aceptar la compilación publicada, antes de comenzar la ejecución de la prueba para ahorrar tiempo y esfuerzo.
Este es uno de los parámetros de eficiencia más importantes en la fase de lanzamiento de prueba.
Mejora del proceso de lanzamiento de prueba:
1) Revise el informe de lanzamiento para la nueva funcionalidad, personalización / modificación de la funcionalidad existente, correcciones de errores de la compilación anterior, que decidirán comenzar a ejecutar la Prueba de humo o Prueba de cordura o una combinación de ambas.
2) Revisa la actualización Documentos de prueba según la nueva funcionalidad y las correcciones de errores, si aún no se actualizó. Normalmente, durante el ciclo de vida del desarrollo de software, el equipo de pruebas actualiza estos documentos en función de las reuniones semanales regulares de revisión del proyecto.
3) Revise la compilación de software en el repositorio de configuración se actualiza para el número de compilación, número de versión, etiquetado o comentado con el nombre de la versión según los estándares definidos en el plan del proyecto. Además, asegúrese de que la compilación se compile e instale correctamente en el servidor de prueba.
4) Programe una reunión de revisión rápida del proyecto después del lanzamiento para discutir los pros y los contras de la versión publicada, los errores conocidos y la funcionalidad crítica, etc., para evitar errores de comunicación y para revisar los requisitos importantes del cliente. Evite estrictamente cualquier comunicación oral entre los equipos de desarrollo y prueba, ya que tiene un gran impacto en la calidad del lanzamiento del software.
5) Asegúrese de que la herramienta de seguimiento de errores esté configurada correctamente , para el equipo de prueba asignado y el equipo de desarrollo del proyecto, los números de versión y compilación del software, así como los módulos / funcionalidad del software, que ayudarán a registrar los errores de manera eficiente. De lo contrario, se debe derivar al gerente de proyecto o al gerente de pruebas con una prioridad alta.
6) Devolver la compilación al equipo de desarrollo sin ningún compromiso, si la construcción falla en las pruebas de humo o cordura. Estrictamente, las pruebas no deben continuar cuando el sistema falla en las pruebas de humo. Esto ahorrará mucho tiempo y esfuerzo y mejorará la calidad del software lanzado en las versiones posteriores.
7) Programe el lanzamiento del proyecto el 1S tDía de la semana lo que ayudará al director de pruebas a planificar el próximo ciclo de pruebas en función de la estabilidad de la construcción y también a enviar un informe de prueba rápido al director del proyecto que aumentará la calidad del software con mucha antelación. Si el equipo de desarrollo programa el lanzamiento del proyecto para el viernes, el fin de semana se puede utilizar para cualquier deslizamiento, así como cualquier problema de compilación en un marco de compilación manual o automatizado.
8) Asegúrese de que los probadores estén capacitados adecuadamente en el dominio lo que ayudará al equipo de pruebas a cumplir con el calendario de pruebas y reunir tiempo para la siguiente ronda de pruebas. Además, el equipo de pruebas debe estar capacitado y tener la exposición a la tecnología requerida como Scripting y SQL si el proyecto exige boxeo blanco.
9) Evite la asignación de probadores en varios proyectos ya que afecta en gran medida la calidad de la ejecución de la prueba en tiempo real. En la práctica, incluso los probadores experimentados pasan por alto las características y la funcionalidad, además de omitir los casos de prueba asumiendo que algunos casos de prueba nunca fallan, cuando están sobrecargados de trabajo o asignados a múltiples proyectos con fechas límite.
10) Aprecio que el equipo de pruebas tenga pasión ya que los probadores no deberían trabajar para el 'Día' o comentar 'Llámalo un día'. Cuando el software tiene múltiples módulos y el funcionalista está total o parcialmente integrado o interrelacionado, los probadores deben tener la pasión por escribir / ejecutar los casos de prueba con una gran cobertura y matriz de trazabilidad, apuntando a la calidad del software / producto final. Porque incluso un problema estético es un 'error' y se cuenta como '1 error'.
11) Asegúrese de que la instalación del software sea fácil y directa ya que ayuda al equipo de pruebas a reinstalar el software cuando sea necesario en lugar de esperar a que el administrador de desarrollo o un administrador de instalación haga el mismo trabajo, lo que matará innecesariamente el tiempo de prueba disponible. Por ejemplo, aunque la instalación basada en Windows es fácil, pero cuando involucra varios servidores web y redes de área amplia en un entorno de prueba de varios niveles, los probadores pueden tardar horas en instalar el software. Si el cubiertas de prueba de software e instalación, desinstalación , parches o actualizaciones de software, es más probable que se discuta en detalle el proceso de ejecución de los casos de prueba con el equipo de pruebas.
12) Asegúrese de que las herramientas automatizadas estén disponibles con licencia por un marco de pruebas de automatización . La ejecución de casos de prueba en un marco automatizado es fácil en comparación con un escenario de prueba manual, siempre que las herramientas automatizadas estén configuradas correctamente y tengan licencia para múltiples usuarios. Especialmente, cuando el plan de prueba implica pruebas de rendimiento y carga además de la ejecución regular de casos de prueba y las pruebas de regresión, los evaluadores deben cubrir la ejecución de casos de prueba en múltiples entornos como múltiples servidores, múltiples navegadores, múltiples usuarios, etc.
13) Asegúrese de que las máquinas fantasma estén configuradas para la prueba antes de iniciar la ejecución de la prueba. Las máquinas fantasma son máquinas con diferentes entornos de prueba. Por ejemplo, se puede planificar un software de aplicación web para probarlo en múltiples entornos como Windows 7 y Access DB o Windows 2008 y SQL Server o Windows 8 y Oracle o Mainframe y DB2, etc., con todos los navegadores como Chrome, Firefox, Internet Explorer. , Safari etc., Algunas 'pruebas del sistema' incluso requiere formatear completamente el disco duro e instalar un software nuevo o actualizar el software existente con parches y actualizaciones, etc.
14) Evite implementar las nuevas funciones / solicitud de cambio deteniendo la ejecución de la prueba y volviendo a lanzar el software para indicar la fase de prueba nuevamente. Esta es una muy mala práctica en muchas organizaciones de software según los requisitos comerciales para satisfacer a los clientes externos o al menos para satisfacer las demandas del comité de dirección de gestión o, a veces, los equipos de ventas / marketing. Aunque las solicitudes de cambio de los clientes siempre se fomentan en un entorno de proyecto 'ágil', deben planificarse e implementarse correctamente antes de la publicación del software para el equipo de pruebas.
Gestionar y controlar el contenido de la versión de prueba
La gestión y el control del contenido de la versión de prueba es más importante para cualquier software de TI o incluso para cualquier entorno de software que no sea de TI, que se muestra en la siguiente figura.
- Los gerentes de proyecto y / o el comité de dirección del proyecto depende de la autoridad de la matriz de la organización, es responsable de seleccionar el contenido de todos y cada uno de los lanzamientos.
- Una vez que se identifiquen y aprueben los errores y / o las nuevas funciones y la solicitud de cambio de los clientes, el equipo de desarrollo lo implementará, lo cual debe ser informado a las partes interesadas del proyecto antes de que comience el desarrollo / implementación.
- Según la versión final implementada, el equipo de pruebas actualizará los documentos relacionados y se preparará para las pruebas en consecuencia.
- El equipo de pruebas comenzará las pruebas de humo / cordura según los requisitos definidos en el informe de lanzamiento.
- Una vez aprobada la Cordura, el equipo de pruebas comenzará la ejecución de la prueba según el cronograma y las tareas asignadas, a saber, pruebas funcionales, pruebas no funcionales, pruebas de seguridad, pruebas del sistema, pruebas de rendimiento, pruebas de carga, pruebas de aceptación del usuario, etc.
- Una vez que se complete la primera ronda del ciclo de prueba, los informes de prueba se enviarán a todas las partes interesadas y al gerente del equipo de desarrollo para planificar la próxima iteración de la ejecución de la prueba.
- Dependiendo del estado de los informes de prueba y de la gravedad y complejidad de los errores, se planificará un ciclo completo de una segunda ronda de ejecución de pruebas o pruebas de regresión junto con las pruebas de aceptación del usuario.
- Después de completar los ciclos de ejecución de prueba planificados, los informes de prueba se enviarán a todas las partes interesadas del proyecto para las características, la funcionalidad y las correcciones de errores aprobados / fallidos / perdidos.
Plantilla de informe de lanzamiento de muestra:
Nota : La plantilla de muestra de MS Word para el informe de lanzamiento también está disponible para descargar a continuación.
Encuentre debajo un ' Informe de lanzamiento de muestra ”Que cubre los aspectos principales del proceso de lanzamiento, lo que hace que la vida profesional de todo el equipo del proyecto sea mucho más feliz que nunca.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
#1 Alcance
Navegación GPS para XYZ Company Limited se lanzará para pruebas internas. La versión publicada es 1.0.7, el número de lanzamiento es 14.0 y el número de compilación 105.25.03. Esta versión de software incluye las nuevas funciones y las principales correcciones de errores de la versión anterior. La prueba de humo se pasa de la fase de desarrollo, pero se requiere una prueba de humo y cordura antes de pasar a la prueba de regresión.
# 2) Referencias
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Descripción de la versión
Esta versión es una versión controlada de navegación GPS y contiene las siguientes características y funcionalidades.
Las funciones marcadas con * son nuevas en esta versión.
Las siguientes funciones no se han implementado en esta versión.
1. Módulo 1
1.1 Característica 1
1.1.1 Funcionalidad 1
# 4) Gestión de la configuración
Estamos utilizando Visual Source Safe como herramienta de gestión de la configuración. La compilación está disponible en la siguiente ruta.
Enlace interno: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Enlace externo: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Instrucciones y pasos de instalación
Proporcione la información detallada para la instalación de la compilación al equipo de QA / Testing.
# 6) Problemas / errores solucionados
El estado de los errores se actualiza en el sistema de seguimiento de defectos.
# 7) Problemas / errores a solucionar
#8) Entregables
# 9) Errores / problemas conocidos
# 10) Lista de verificación de versiones
| Sl.No/ | Descripción | Y / N |
|---|---|---|
| 1 | ¿Se han verificado todos los archivos en Visual Source Safe? | |
| 2 | ¿Se ha colocado la etiqueta en la carpeta adecuada en VSS según los estándares internos? | |
| 3 | ¿Es la versión identificable como versión 'externa' / 'interna' en VSS? | |
| 4 | En los comentarios, ¿se ha mencionado la versión en VSS? | |
| 5 | En los comentarios, ¿se ha mencionado una breve descripción en VSS? | |
| 6 | El código ha sido revisado y los problemas de revisión del código están registrados en Clear Quest. | |
| 8 | ¿Se ha preparado y revisado el documento de prueba unitaria? | |
| 9 | ¿Casos de prueba unitarios ejecutados y los resultados actualizados para el estado? | |
| 10 | ¿El documento de caso de prueba unitario actualizado está disponible en VSS? | |
| 11 | ¿Se han resuelto / cerrado todos los problemas de Clear Quest para este lanzamiento? | |
| 12 | ¿Todas las tareas del paquete de trabajo completadas y actualizadas en VSS? | |
| 13 | ¿Se ha realizado y aprobado la prueba de humo? |
=> Descargar: Haga clic aquí para descargar la plantilla de informe de lanzamiento de muestra en formato MS Word.
Conclusión:
Cómo mejorar el proceso de publicación de pruebas de forma continua
Consejo n. ° 1) Configure un equipo de ingeniería de versiones que se encargará de los factores críticos del mantenimiento de las versiones y compilaciones de software y será responsable de los sistemas de gestión de configuración de software centralizados.
Consejo n. ° 2) Motivar y apreciar a los equipos de proyecto por seguir el proceso involucrado en el ciclo de vida del desarrollo de software, el ciclo de vida del desarrollo de productos y el ciclo de vida de las pruebas de software. Podemos definir el proceso, pero hasta que sea seguido por las personas involucradas, no sirve de nada definir el proceso.
Consejo n. ° 3) Estime el esfuerzo de prueba basado en las experiencias y la historia previa. Escribir casos de prueba es totalmente diferente a ejecutar lo mismo. Los evaluadores deben comprender qué probar, cómo probar y cuándo probar; de lo contrario, los esfuerzos dedicados al ciclo de prueba se desperdician, aunque se hayan realizado varias rondas del ciclo de prueba.
Consejo # 4) Por último, si es posible y factible, automatice la fase de prueba utilizando algunas herramientas de prueba aceptadas universalmente. El uso de herramientas de construcción automatizadas y herramientas de prueba automatizadas reduce los esfuerzos de prueba en más del 50%, mejora la calidad del software y garantiza el 100% de calidad si el marco de automatización está diseñado correctamente.
Consejo n. ° 5) Por último, pero no menos importante, el lanzamiento de prueba no es solo un trabajo, es un arte de hacer que la vida de todos los interesados en un proyecto sea fácil y más cómoda.
Sobre el Autor: Balu A. es un profesional de TI tecno-funcional experimentado con más de dos décadas de experiencia en software de TI y una década de experiencia en gestión de proyectos y pruebas en la entrega de aplicaciones empresariales y soluciones de movilidad en todos los dominios que utilizan tecnologías Microsoft, Oracle, Java y Mobile. Él es básicamente un líder con pasión por promover a las personas para que se conviertan en líderes con la actitud correcta y le encanta trabajar en un entorno orientado a procesos y cree que los procesos mejoran la eficiencia, la calidad y la productividad de los empleados.
Ensiguiente tutorial, aprenderemos - Cómo Mejore la eficiencia de los casos de prueba.
Háganos saber sus pensamientos / consultas en los comentarios a continuación.
¡Tenga una versión de software según el proceso!
¡Complete las pruebas según lo programado con gran productividad y esfuerzo!
¡Intente lograr una entrega de software sin errores y de calidad garantizada!
Si te gusta este artículo, ¡considera compartirlo con tus amigos!
Lectura recomendada
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Trabajo de asistente de control de calidad de pruebas de software
- ¿Qué es Monkey Testing en las pruebas de software?
- Elegir las pruebas de software como carrera
- Prueba de software Escritor de contenido técnico Trabajo autónomo
- Ejemplo de informe de errores
- Flujo de proceso de control de calidad de pruebas de software prácticas (requisitos para la publicación)