Menú

¿Cómo se decide qué defectos son aceptables para que el software entre en funcionamiento?

how do you decide which defects are acceptable

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Software Go-Live es siempre un gran evento para cualquier producto de software. Es importante estar absolutamente seguro de que todo funciona y de que estamos lanzando software de calidad a los usuarios .

Un producto malo, prematuro, inestable o difícil de usar puede causar muchas pérdidas económicas y también puede hacer que el usuario pierda la confianza en la propia marca.

A menudo, escuchamos que las pruebas deben realizarse hasta que cumplamos con los criterios de salida. También escuchamos que los defectos deben arreglarse a un nivel aceptable.

Si bien estas son pautas que suenan muy bien, son vagas.

criterios-software-go-live

Para ser más especifico:

  • ¿Qué porcentaje de defectos son aceptables para que el software entre en funcionamiento?
  • ¿Cómo decide los defectos abiertos con los que el software puede empezar a funcionar?
  • Qué tipos de defectos son más serios que los demás?

Lectura recomendada => ¿Cuándo dejar de realizar pruebas?

¿Alguna vez ha tenido estas preguntas? Entonces, este artículo te ayudará a responderlas. Sigue leyendo ...

El software complejo no está libre de defectos y es una historia de gallina y huevo sobre el cierre de defectos con respecto al software en funcionamiento.

Cuanto más corrija los defectos, más probabilidades hay de que se haya inyectado un nuevo defecto al cerrar el defecto. Asi que,

  • ¿Cómo decide el alcance de los defectos y el tipo de defectos con los que puede comenzar a vivir?
  • ¿Cómo establece la línea base del software que se implementará para la puesta en funcionamiento?
  • ¿Cómo hacen los coordinadores de UAT la llamada a empezar o no?
  • ¿Con qué parámetros se debe juzgar el software?
  • ¿Cómo respondemos? ¿Es el software apto para su uso y aportará valor a las partes interesadas?

La puesta en producción es un hito importante tanto para el cliente como para el proveedor, ya que normalmente está vinculado a los hitos de pago. Ambos tienen la misma responsabilidad de garantizar que los grandes proyectos de transformación tengan éxito.

Mi experiencia muestra que los clientes quieren una buena relación calidad-precio y tienen una criterio de salida para que UAT entre en funcionamiento.

Dichos criterios de salida definirían más o menos el alcance aceptable de los problemas en todas las áreas de la aplicación, tales como:

  1. Funcional
  2. Rendimiento y carga
  3. Usabilidad
  4. Seguridad
  5. Integración con sistemas externos
  6. Informes
  7. Migración de datos

Creo que cada uno de estos tipos de defectos debe explicarse con más detalle. Y eso es exactamente lo que haremos ahora:

cómo convertir un video de youtube en un archivo wav

# 1. Defectos funcionales:

Si el software se crea según las especificaciones proporcionadas por el cliente, debe cumplir los requisitos. Cualquier desviación se registra como defectos funcionales.

Defectos funcionales luego se clasifican según severidad y prioridad .

Las siguientes son consideraciones importantes:

  • Los defectos de alta gravedad y prioridad suelen ser los que afectarían el uso diario del software. Estos tipos de defectos son los que deben corregirse antes de que entremos en funcionamiento. Sin excepciones.
  • A veces, los defectos funcionales se clasifican como solicitudes de cambio, ya que no formaban parte de los requisitos dados originalmente. Estos CR, que son imprescindibles para que las empresas funcionen después de la puesta en marcha, también son imprescindibles para su implementación.
  • Los coordinadores de la UAT realizan la clasificación de los defectos y la priorización de los defectos funcionales en colaboración con los usuarios comerciales y los analistas comerciales. Por lo general, el cliente tiene un criterio de salida de cuánto% de defectos pueden estar abiertos para la puesta en funcionamiento.

# 2. Defectos de rendimiento y carga:

Defectos de funcionamiento son importantes a tener en cuenta para la puesta en marcha y más si el software va a ser utilizado por usuarios externos.

Si el software es lento para un número determinado de usuarios, los usuarios evitarían usar el software, ya que lleva mucho tiempo cargarlo. Los usuarios tienden a trasladarse al sitio de la competencia si el software es muy lento y, por lo tanto, pierden negocios.

A veces, las partes de la aplicación que no están orientadas al cliente también pueden afectar el rendimiento.

Por ejemplo: Si hay un proceso por lotes que se ejecuta al final de cada día y si el tiempo de respuesta de la aplicación se ve afectado mientras esto sucede, el rendimiento del lote también es un factor a considerar.

  • El rendimiento generalmente se mide en términos de tiempo de respuesta de las pantallas para renderizar y estar disponibles para los usuarios mientras haya un cierto número de usuarios concurrentes en el sistema.
  • Las pruebas de rendimiento se realizan utilizando herramientas como LoadRunner , WebLoad , Neoload etc.
  • El rendimiento del software con una carga determinada y con una carga futura prevista generalmente se documenta en el contrato y debe demostrarse antes de la puesta en funcionamiento.
  • Las pantallas o partes de la aplicación que los usuarios utilizan menos se aplazan para las evaluaciones después de la puesta en marcha.
  • El rendimiento también depende del tipo de hardware y de las condiciones de la red en las que se implementa el software.
  • Las pruebas de rendimiento se realizan durante UAT en el hardware especificado utilizando herramientas de rendimiento y sus defectos se rastrean de una manera similar a la de los defectos funcionales. También se les da prioridad y se llega a un consenso sobre el cumplimiento de los criterios de salida para la puesta en marcha.
  • Por lo general, las pruebas de rendimiento y carga en UAT se realizan después de que los usuarios comerciales completan la UAT funcional y se alcanza un criterio de salida aceptable para defectos funcionales.

# 3. Defectos de usabilidad:

El software creado debe ser fácilmente utilizable por los usuarios finales utilizando diferentes teclas de acceso rápido, atajos, el número mínimo de navegación de pantalla, paginación, etc. El software debe ser inteligente e intuitivo.

Si hay demasiados movimientos de la página antes de pasar a la pantalla correspondiente, los usuarios suelen mostrar menos interés en utilizar el software.

  • Las pautas de usabilidad se crean antes de que se cree el software. El software debe cumplir con estas pautas.
  • También puede haber restricciones de herramientas al crear el software que deben superarse inteligentemente antes de que los usuarios finales puedan utilizar el software.
  • Con un software altamente utilizable, un usuario final puede ingresar datos hasta 5 veces más que el software normal.
  • La apariencia del software debe ser nítida y también los problemas legales deben resolverse antes de la puesta en funcionamiento.
  • Muchas veces se designa a un consultor de usabilidad para garantizar una experiencia de uso fluida a los usuarios.
  • La documentación que debe enviarse con la aplicación de software también debe cumplir con estrictas pautas de usabilidad, ya que pueden usarse legalmente.
  • Los defectos de usabilidad registrados por probadores UAT / probadores externos también se priorizan como defectos funcionales y de rendimiento y deben cumplir con los criterios de salida para la puesta en funcionamiento.

# 4. Defectos de seguridad:

Seguridad del software es un tema candente ya que la aplicación de software puede ser pirateada y los datos confidenciales del cliente pueden ser robados en poco tiempo.

Por lo tanto, un software confiable no debería permitir que ni siquiera un hacker muy competente ingrese a la aplicación sin los privilegios adecuados.

  • Las pruebas de seguridad se realizan en UAT con entradas específicas en el software para garantizar que no sea pirateable.
  • Las pruebas de seguridad las realizan piratas informáticos legales que intentan piratear el software para comprobar si es vulnerable.
  • Todos los defectos de seguridad deben cerrarse antes de que el sistema entre en funcionamiento.
  • La seguridad también significa inicio de sesión y roles y privilegios para varios usuarios (externos e internos) para usar diferentes secciones de las aplicaciones y también para crear y aprobar datos.

# 5. Integración con sistemas de software externos:

Por lo general, una aplicación de software que se implementará en el sitio del cliente tiene que interactuar con cualquier software existente que ya exista allí.

Por ejemplo: Con el sistema de impresión, tienen en uso o podrían ser sistemas externos como una aplicación de facturación o sistemas de pantalla de datos. La aplicación de software que se implementa debe integrarse sin problemas con estos sistemas externos. Todas las entradas y salidas de estos sistemas deberían funcionar sincrónicamente. La tecnología actual abarca aplicaciones móviles y diferentes plataformas de software que la aplicación tiene que ser compatible con .

La verificación de la interconexión del sistema externo debe realizarse extensamente durante las etapas del sistema y UAT. Debería ser imprescindible en los criterios de salida que deberían cumplirse antes de la puesta en funcionamiento.

# 6. Informes:

Los informes de la aplicación de software son una forma fundamental de mostrar que los datos dentro de la aplicación se corresponden.

Por ejemplo: todos los datos relacionados con la facturación deben coincidir en los saldos de crédito y débito.

  • Todos los datos del software deben conciliarse. Esta conciliación de datos dentro del software se muestra a través de informes y deben estar funcionando según lo previsto.
  • Esto es especialmente cierto si la migración de datos de un sistema antiguo a un sistema nuevo es la intención principal de la versión actual.

# 7. Migración de datos:

Si se reemplaza un sistema antiguo por uno nuevo, los datos del sistema antiguo se trasladan al nuevo (después de que se llega a una fecha límite mediante el uso del nuevo sistema). Los datos migrados deben ser compatibles por el nuevo sistema como se define durante la recopilación de requisitos.

Es posible que no todos los datos antiguos estén disponibles en el nuevo sistema; sin embargo, una instantánea de los datos antiguos podría estar disponible en el nuevo sistema. Estos datos deben estar disponibles según lo acordado.

Nota : La lista de arriba no es exhaustiva. Dependiendo del tipo de aplicación, puede haber más cosas que deba validar o no todo lo anterior podría ser aplicable. Por lo tanto, una comprensión profunda del software, el propósito comercial, las expectativas del usuario y las dependencias arquitectónicas o de hardware es imprescindible para desarrollar criterios de salida completos.

Un ejemplo de criterios de salida para la puesta en marcha:

Este es solo un ejemplo. Puede variar de un proyecto a otro.

  • El 100% de los defectos de Prioridad 1 están cerrados (Severidad Crítica y Prioridad 1)
  • El 90% de los defectos de prioridad 2 se cierran (gravedad alta y prioridad 2) con una solución alternativa lógica disponible para el resto del 10% de los defectos. Y se dispone de un plan para cerrar el resto del 10% de los defectos.
  • La implementación de producción y la lista de verificación de cordura están listas.
  • El equipo de soporte de producción se ha formado y está listo para cerrar tickets.
  • El 70% de los defectos de prioridad 3 están cerrados y existe un plan para cerrar el resto del 30% de defectos bajos.

Algunos puntos a tener en cuenta:

  • Todas las definiciones de gravedad y prioridad se deciden durante las reuniones de negocios entre el cliente y el proveedor al inicio del programa.
  • Después de que se registran todos los defectos de UAT y se cierran todos los demás defectos, los coordinadores de UAT y los patrocinadores comerciales se reúnen para evaluar los defectos pendientes y abiertos. Si se resuelven todos los defectos necesarios para la puesta en marcha del día 1, los patrocinadores comerciales ven su preparación para la puesta en marcha y ponen el software en producción.

En conclusión

Esperamos que este artículo le haya brindado algunas ideas sobre algunas de las consideraciones importantes que se deben tener en cuenta para crear criterios de salida sólidos como una roca que protejan al software de posibles fallas en las producciones.

Sobre el Autor: Este es un artículo invitado de Krishnan Venkatraman. Tiene casi 18 años de experiencia en pruebas de software. Ha trabajado en muchos proyectos de pruebas de software grandes y complejos.

No dude en publicar sus consultas / comentarios a continuación.

Lectura recomendada

^