Aseguramiento de la Calidad

Diferencia entre un Software Test Engineer y Software Quality Engineer

Tedi Aseguramiento de la Calidad , , , , , , , , , 2 Comments

Estaba dando una vuelta por los mensajes pendientes en los grupos de LinkedIn y me encontré uno especialmente interesante en el grupo de Test Republic, donde Annamariale Chandran (Senior Engineer) explicaba las diferencias entre un STE (Software Test Engineer) y un SQE (Software Quality Engineer). Podéis leer el debate completo aquí.

El tema no tendría mayor importancia si no fuese porqué muy a menudo ambos puestos (y responsabilidades) se confunden. Y es que todavía cobra mayor criticidad cuando las expectativas dentro de la organización no están claras respecto a ambos perfiles. En la mayoría de empresas se contratan STE, esperando que estos ejecuten el rol de SQE y esto entraña diferentes peligros. El mas importante: los STE precisan de un gran conocimiento sobre el aplicativo a probar, mientras que los SQE han de ser grandes conocedores del ciclo de vida de desarrollo de los productos.

A continuación podéis encontrar un pequeño resumen de las expectativas que deben cumplir ambos roles:

Software Test Engineer (STE)

  • Objetivo: Verificar y validar que el producto cumple con las especificaciones.
  • Entregables: Análisis del producto en lo que se refiere a los unidades  desarrolladas (componente, sub-sistema, sistema, aplicativo, …) y resultados de las ejecuciones de pruebas.

Software Quality Engineer (SQE)

  • Objetivo: Verificar que el producto es desarrollado conforme a los procesos definidos, así como la revisar e implementar cambios en los procesos.
  • Entregables: Análisis de las desviaciones en los procesos del proyecto e identificación de oportunidades de mejora.

Obviamente estas dos definiciones admiten modelados específicos a cada organización y pueden adaptarse a escenarios mas complejos o cambiantes.

Métricas de calidad en el código

Tedi Aseguramiento de la Calidad , , , Comment
Ilustracion de las metricas de calidad

Aunque es una viñeta bastante graciosa, en algunos casos puede caerse en la tentación de pensar que somos tan buenos desarrollando nuestros propios productos que éstos ni tan solo tendrán defectos.

Y esto es lo que pasa después de la revisión de un mal código (con defectos importantes): se termina reaccionando bajo alarmas.

Métodos de entrevista y el modelo de madurez CMM

Tedi Aseguramiento de la Calidad , , , , 2 Comments
Uno de los grandes errores que comentemos a menudo es no preparar las entrevistas. No me refiero a las entrevistas de trabajo, sino a aquellas que sirven para evaluar el desempeño interno de la organización. Probablemente este fallo tiene bastante que ver con la importancia que damos al tiempo de nuestros colegas dentro de la empresa. Aunque podemos volver a cruzarnos por el pasillo con la persona que hemos entrevistado, en ese momento ya no existirá el entorno necesario para la actividad que queremos acometer: entrevistar a un compañero. Por lo tanto, primer punto: el tiempo de la gente es oro.
¿Por qué querríamos entrevistar a una persona que trabaja con nosotros? Por mil y un motivos. Por ejemplo, para evaluar el desempeño de las actividades conjuntas, obtener propuestas, revisar la satisfacción y un largo etcétera. Todo esto, obviamente, partiendo de la base de que absolutamente cualquier persona dentro de la organización debe tener voz y voto -sobre diferentes temas- y se deben atender las propuestas por doquier que aparezcan. Luego ya tendremos tiempo de evaluarlas.

En el caso que nos ocupa, vamos a ver una propuesta-guión sobre una posible entrevista a un empleado de la organización, entorno a la evaluación de la madurez CMM de la empresa. Es cometido de esta actividad preparar una guía de entrevistas para ser utilizadas dentro del plan de mejoras en el marco de desarrollo de nuevas aplicaciones, ejerciendo como adjunto al Director de SI de un gran banco internacional.

Nota: No se incluyen los tiempos de planteamiento y respuesta destinados a cada cuestión -que serían de gran utilidad- ya que dependerán en gran medida del caso particular.

Plantilla para la entrevista

  • Nombre del entrevistado:
  • Organización / Responsabilidad:
  • Fecha / Lugar:
  • Teléfono / e-mail:
  • Información adicional:
  1. Presentación [Añadiendo puntos a tratar y transmitir durante la presentación y motivo de la entrevista]
  2. ¿Cuál es su responsabilidad dentro de la organización?
  3. Desde su punto de vista, ¿la organización planifica y detalla los requerimientos que implican el desarrollo e implantación de nuevas oportunidades tecnológicas?
  4. ¿Cree que existe un control satisfactorio sobre los procesos derivados de los proyectos y sus actividades?
  5. ¿Se estructura en el tiempo la ejecución de los proyectos de desarrollo?
  6. ¿Cuál es el criterio de selección a la hora de contratar sus proveedores?
  7. ¿De qué modo se controla y organiza la evolución del desarrollo del software?
  8. ¿Existe modelo de testeo del software en fases de desarrollo tempranas?
  9. ¿Podría explicarme el modo de operación de la empresa frente a la asignación de responsabilidades y tareas?
  10. ¿Cree que su empresa se basa en el modelo de una organización por procesos?
  11. ¿Qué formación ha recibido por parte de su empresa?
  12. ¿De qué modo se gestiona e integra el desarrollo de software en su empresa?
  13. ¿Existe un plan de ingeniería de producto aplicada al desarrollo de software?
  14. ¿Las revisiones de entre desarrolladores es una práctica habitual?
  15. ¿De qué modo se revisan y contabilizan los procesos?
  16. ¿Existe un departamento encargado de la gestión de Calidad del software?
  17. Si existe tal departamento, ¿cuál es su ámbito de actuación?
  18. ¿Cuál cree que es la capacidad de su empresa para incorporar nuevas tecnologías y adaptarse a ellas?
  19. ¿Se revisan periódicamente los procesos establecidos, aplicando una mejora continua?
  20. ¿De qué modo se revisan y gestiona la prevención de fallos y errores?
  21. ¿Qué cambios o mejoras sugiere?
  22. ¿Cree que debería revisarse la metodología o enfoque de alguna de las áreas vinculadas al desarrollo?
  23. ¿De qué modo piensa que pueden ser excepcionalmente valiosas sus aportaciones en la empresa?
  24. ¿Le gustaría plantear alguna sugerencia o idea?
  25. Resumen de las ideas y compromisos derivados de la entrevista.
  26. Datos de contacto para posibles sugerencias o información adicional.
  27. Transmisión del valor que supone la entrevista y la información presentada por el entrevistado y agradecimiento.
Espacio adicional:
  • Impresiones:
  • Documentos de referencia:
  • Otras formas de contacto:
  • Temas pendientes:
  • Compromisos (Action Items):
  • Otra información y desarrollo de respuestas extensas o acotaciones:
Recursos adicionales
– Capability Maturity Model [http://en.wikipedia.org/wiki/CMMI]
– CMMS [http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview05.pdf]

La usabilidad no es cosa de otros

Tedi Aseguramiento de la Calidad , Comment

La definición más simplista de usabilidad, rápidamente nos puede llevar a pensar en el la coherencia cuando utilizamos interfaces, o en un sentido más amplio, sistemas de información. La ISO/IEC propone en dos de sus normas, las siguientes definiciones:

ISO/IEC 9126:

«La usabilidad se refiere a la capacidad de un software de ser
comprendido, aprendido, usado y ser atractivo para el usuario, en
condiciones específicas de uso»

ISO/IEC 9241:

«Usabilidad es la eficiencia y satisfacción con la que un
producto permite alcanzar objetivos específicos a usuarios específicos
en un contexto de uso específico»

Parece sencillo. ¿Por qué las empresas no se emplean a fondo para conseguir productos más usables? Básicamente podemos decir que si lo hacen, pero no siempre con garantías de éxito. Los orígenes de estos problemas pueden ser muy dispares y acorde al producto.

En líneas generales, la estrategia de negocio y la cultura de la organización tienen mucho que decir sobre los problemas de usabilidad de sus productos. Algunas errores comunes:

  • No conocer el producto o tener una visión limitada de su alcance.usabilidad
  • No conocer a los usuarios.
  • No conocer los diferentes escenarios en los que se utilizará el producto.
  • Tratar a los usuarios como expertos.
  • Dejar que los desarrolladores establezcan las pautas de usabilidad.
  • No invertir suficientes recursos en testear el producto.
  • Quitar importancia a los problemas de usabilidad.
  • Pretender adaptar los usuarios al producto.
  • No establecer el ROI en usabildad.

Como podemos ver, la mayoría de incidencias residen en la pasividad o en la valoración de la importancia de generar productos usables, tanto en cifras de negocio como en satisfacción de los usuarios.

Durante el ciclo de gestación del producto, resulta especialmente interesante incidir en la usabilidad en las primeras fases del desarrollo. Obviamente, esto no siempre es posible, con lo cual una buena opción sería trazar pruebas de usabilidad a medida que avance el mismo.

Una estrategia por fases de madurez, de entre muchas, podría ser:

  1. Test funcional/de usabilidad.
    • Especialmente utilizando técnicas de caja negra.
    • Se incide en lo que el producto “debe” hacer, comprobando la usabilidad del mismo.
  2. Casos de test de usuario.
    • Reproducción del comportamiento y entorno de los usuarios.
    • Ejecución de workflows reales completos.
  3. Dogfooding.
    • Integramos el producto en nuestro día a dia. Somos los propios usuarios; nos enfadamos, entra en juego el
      stress, en lugar de leer los mensajes le damos siempre a aceptar, no
      esperamos más de 5 segundos para hacer la siguiente acción e incluso lo
      golpeamos.
  4. Earlybirds, test de betas.
    • Se proporciona el producto -todavía en fase de desarrollo- a usuarios finales para que lo integren en sus flujos de trabajo.

Cuantas más pruebas cruzadas hagamos mejor. Ya sea dogfooding, earlybirds, betas o tests especificos. Quien tiene un amigo, tiene un tester :)

Tres enlaces interesantes sobre usabilidad:

Jakob Nielsen

Alzado.org 

Nosolousabilidad.es 

Ingeniería de la coherencia

Tedi Aseguramiento de la Calidad , , , Comment

¿Por qué a menudo obviamos la realidad y nos empeñamos en seguir las reglas? En un mundo perfecto, los axiomas marcarian las mejores decisiones para cada situación. Sin embargo, todos sabemos que no es así; podemos aplicar un gran número de teoremas particulares, rompiendo básicamente todas las reglas.

Aun así, nos empeñamos en seguir las reglas que marca el mercado, los negocios y la tecnología. Podemos empezar por la imagen de marca. Como empleados aceptamos el marketing personal de la empresa, confiamos ciegamente en sus apuestas y las defendemos a capa y espada.

Seguimos… no nos gusta Windows pero es lo que «debemos» utilizar. Preferimos un 4×4 pero algo nos dice que venir a trabajar con un deportivo es más cool.  Generamos ideas. Queremos ponerlas en práctica y confiamos en la uniformidad de pensamientos. ¡Está claro! 2+2=4… pero alguien pensará que que son 4.00, o 4,00, o cuatro, incluso 4.0.

Extrapolamos y llegamos a pensar que el producto en el que trabajamos es realmente sencillo de utilizar, sus defectos son imperceptibles y el cliente un ingeniero especializado en 20 disciplinas. Seamos coherentes, todos los productos tienen fallos y no siempre su interfaz es amigable. No todos los productos son rentables. A veces incluso antes de lanzar un producto, la mayoría de las personas involucradas en su desarrollo son conscientes del fracaso. ¿Quién pone el punto de coherencia?