Casos prácticos del Ingeniero de Desarrollo BANRED

Ud ha terminado el desarrollo y está listo para entregar a QA; pero recibe un pedido del PM que le dice: "el Banco quiere un cambio pequeñísimo, ¿lo puedes poner antes de pasar a QA?

• Lo hace de inmediato y actualiza los fuentes

• Le contesta que el alcance está cerrado y no se puede

• Solicita que se actualice el Requerimiento Funcional y comenta que este cambio implica volver a probar y ya no podemos entregarlo a QA como se había planificado

• Solicita que le pidan a su jefe el cambio y que también le convoquen a QA para que aprueben el cambio emergente y excepcionar la documentación del último cambio

Estás en la reunión de entendimiento y tienes varias dudas, ¿qué haces?

• Preguntas y pides clarificaciones todas las veces necesarias

• Le comienzas a preguntar a otro compañero que de seguro sabe la respuesta

• Mejor no preguntas por el que dirán de ti por tener tantas dudas

• Anota las preguntas porque sabes que cuando te lo envían, seguro te contestan las dudas.

Vas a iniciar un cambio que es muy sencillo, sólo debes declarar una nueva variable, ponerle un valor fijo y en un solo fuente. Tu compañero de célula, pidió el mismo fuente para un requerimiento que se entrega el día de mañana, ¿qué haces?

• Le solicitas el fuente al compañero de célula y comienzas el cambio.

• Le solicitas al Administrador del Gitlab el fuente de producción.

• Solicitas una reunión para socializar que harás el cambio sobre el fuente actualizado del requerimiento anterior.

• Haces el cambio para probarlo y después pasas los cambios al fuente de producción.

Estás desarrollando un nuevo microservicio exclusivo que será utilizado sólo para una función en específico sin tener diferentes valores en las variables, ¿qué haces?

• Declaras constantes con los valores fijos que sabes no van a cambiar

• Declaras variables locales y le asignas los valores en el momento de ejecución

• Defines las variables en el docker-compose para que en el futuro se pueda usar otros valores

• Escribes el código para registrar los valores en las tablas de parametrización de la Base de Datos

Estamos en la etapa inicial de un requerimiento muy importante para la empresa; pero a pesar de que la reunión quedó claro la explicación, todavía no hay un Requerimiento Funcional, ¿qué hacemos?

• Iniciamos los desarrollos porque esto es muy importante para la empresa

• Solicitamos un correo indicando que no tenemos Requerimiento Funcional y avanzo

• Elaboramos en Desarrollo el Requerimiento Funcional con lo entendido y ese lo usamos como documentación

• Solicitamos el requerimiento funcional para asegurarnos que que el alcance comprende el 100% del pedido y lo hacemos de manera formal a través de un correo electrónico o como corresponda.

Entregamos un requerimiento a QA para su certificación y justo para terminar la certificación se presentó una novedad que se resuelve fácilmente encerando una variable al inicio y nos piden no impactar las fechas de salida a Producción, ¿qué hacemos?

• Converso con el Ing. de Certificación y hacemos el cambio en el ambiente de QA para luego regularizar el fuente.

• Elevo el caso a mi Coordinador para que me autorice cambiarlo directamente en QA y ganar tiempo.

• Solicito una sesión con todos para explicar el cambio y confirmar que debo volver a probar y generar un cambio en un fuente para QA.

• Siendo que este error no lo detecté, hago el cambio rápido, lo compilo y le propongo al Ing. de Certificación probar en el ambiente de QA y así ahorramos el tiempo de las pruebas técnicas.

Durante la reunión de Entrega a Producción, nos indican el equipo de Base de Datos que debemos usar una ruta diferente de ejecución de los scripts por tener un RAC en producción con 2 nodos diferentes y nos pide la PM no impactar los tiempos, ¿qué hacemos?

• Considerando que el cambio es sólo una ruta del archivo a ejecutar, se propone aplicar el cambio directo al fuente y no impactar los tiempos.

• Considerando no quedar mal con el cliente, se sugiere hacer el cambio de la ruta sin hacer pruebas y se recomienda tampoco certificar.

• Se procede a realizar el cambio, probarlo y pasarlo nuevamente a QA para que allí se vuelva a versionar el script y se hagan pruebas de regresión.

• Se solicita nos formalicen el nuevo pedido, se hace notar en la reunión que es algo que recién nos piden y mientras tanto se analiza el cambio. Se indica que sin la formalidad no podemos pasar nada nuevo a QA porque la certificación fue cerrada.

En cada entrega a QA se explica a través de una reunión el cambio y lo que se está entregando; pero si tenemos una actualización de algún fuente sólo se debe pedir mover el nuevo fuente y no es necesario ninguna explicación porque ya se le dijo verbalmente al Ing. de Certificación la novedad que se corrije. ¿Verdadero o Falso?

• VERDADERO

• FALSO

Answer explanation

Como DESARROLLO debemos hacer todo lo posible en entregar con calidad, es decir: en la fecha planificada y que considere todo el Alcance solicitado sin novedades en QA ni menos incidentes en Producción.

Todo cambio por mínimo que sea, debe llevar su explicación cuando se solicite el paso del o los fuentes. La explicación debe incluir el número de la novedad de QA que se va a cerrar, el soporte sobre el nuevo pedido (si fuera el caso) y una breve explicación de lo que incluye el cambio para cada fuente.

Nos asignan un requerimiento con un alcance bien definido, lo desarrollamos y probamos para entregarlo a QA con toda la documentación bien organizada. Se versiona en QA sin ninguna novedad y cuando ya llevan el 70% de la certificación, el cliente solicita un nuevo cambio. Nos hacen el pedido y luego de aplicar el cambio, ¿qué debemos hacer?

• Crear un nuevo guión para volver a probar el requerimiento y dependiendo del cambio, confirmar el alcance de las pruebas que incluso podría ser el mismo tiempo de las pruebas unitarias anteriores.

• Hacemos unos cuantos escenarios de pruebas y si todo sale bien, lo paso a QA. No es necesario adjuntar nada porque anteriormente se había entregado completa la documentación

• Volver a probar el mismo guión que anteriormente habíamos usado y en la documentación pasamos el resultado del guión anterior puesto que todos los escenarios salieron como exitosos

• No es necesario volver a probar porque el cambio era puntual y no afecta a ninguna funcionalidad, sólo se solicita que nos muevan el fuente para que QA pueda versionar el cambio.

¿Cuál es el objetivo de unas pruebas unitarias sobre un desarrollo de Software?

• Que todos los escenarios probados salgan exitosos

• Que cumplamos al menos el 90% de resultados exitosos

• Que probemos sólo casos puntuales y pasar a QA en la brevedad posible

• Encontrar errores porque si una prueba no los encuentra, es porque se está probando mal.