Sandra Berenice Ruiz Eguino

Modelos de Calidad para Prueba de Software

sg — Thu, 07 Jan 2021 20:48:52 +0000

Modelos de Calidad para Prueba de Software sg Thu, 01/07/2021 - 14:48

Publicado en

SG #23

Prueba de Software

Autor

Constituyentes Fundamentales de los Modelos de Calidad Especializados en Prueba de Software

En la edición agosto-octubre 2008 mencionamos que los modelos de calidad (MC) deben proporcionar un marco de referencia tanto para diagnosticar las capacidades de una organización, como para diseñar y ejecutar planes de mejora. Dijimos que los MC deben ser completos, consistentes y objetivos, y que deben proporcionar una manera rápida de obtener una evaluación inicial de capacidades.

También comentamos que los MC, incluidos los especializados en prueba de software, suelen tener una estructura matricial como la figura 1, e hicimos un muy breve análisis de varios de ellos. Ahora profundizaremos en la estructura de los modelos especializados en prueba de software (MCEP).

Elementos fundamentales de un MCEP

Haciendo un análisis de nuestra experiencia en consultoría, diagnosticando y ayudando a mejorar organizaciones de prueba, y de lo publicado en la literatura especializada, vemos que las áreas listadas abajo son de las más relevantes y comunes a una proporción significativa de (MCEP):

Proceso de prueba
Estrategia de pruebas
Punto de arranque de las pruebas
Métricas
Personal del área de pruebas
Posición en el organigrama del área de prueba
Comunicación y reportes
Administración de defectos
Administración del testware
Infraestructura tecnológica para probar

CMMI y MoProSoft no incluyen este núcleo, razón por la cual no nos fue útil en nuestros esfuerzos por mejorar las capacidades de prueba de software, como comentamos en el número antepasado.

Es también común que los MCEP midan los avances en cuatro ó cinco niveles. Varios de ellos utilizan subniveles, lo que en la práctica resulta de mucha utilidad, porque los pasos de mejora pueden ser más pequeños y detallados.

Los MCEP deben tomar en cuenta, tanto el caso de que la organización de prueba se encuentre dentro de una empresa de desarrollo de software, como el de que forme parte de una empresa especializada en prueba o calidad. Igualmente deben mostrar diferencias entre los casos en que se prueba software convencional, de aquéllos en que lo que se evalúa, si es software crítico (aquél en el que si falla, alguien se muere).

Figura 1. Estructura matricial.

Aplicación de esos elementos

En nuestra experiencia en los diagnósticos y ayuda a mejorar organizaciones de pueba hemos encontrado útil comenzar a abordar las áreas del MCEP antes mencionadas, en el orden que muestra la siguiente figura, prestando atención primero a áreas de capas interiores para luego, sin dejar de trabajar en esas, comenzar a abordar las de la siguiente capa exterior.

Figura 2. Áreas en capas.

Lo vemos así, porque es muy común encontrar organizaciones de prueba con fuertes carencias en la definición de su proceso, en el diseño de una estrategia que combine adecuadamente técnicas de prueba, y en la administración de los defectos que se detectan, lo que dificulta mucho avanzar con paso firme. Podemos considerar estas primeras áreas como asépticas.

Una vez cubiertos los fundamentos anteriores podemos ocuparnos también de que el equipo de pruebas tenga una posición adecuada en el organigrama (en particular, buscando que no dependa de un directivo responsable de entregar en tiempo y forma, desarrollos de software, para evitar la situación de ser “juez y parte”); de que cuente con el personal suficiente en cantidad (aproximadamente 25% del total de los recursos asignados al desarrollo de software) y en calidad (selección y entrenamiento apropiados); de que se administre adecuadamente los insumos y productos de las pruebas (y evitar estar probando una versión no actual del software); y de que se cuente con un laboratorio de pruebas adecuado.

En una tercera fase podemos trabajar también en recabar y explotar sistemáticamente métricas; en que las pruebas comiencen más temprano en el ciclo de desarrollo; y en que las labores y los resultados de las pruebas resulten de utilidad a un grupo mayor de roles en la organización.

Un aspecto muy importante a considerar al diseñar el plan de mejora es la recuperación de la inversión, lo que induce la pregunta: ¿cuál es la secuencia de pasos que más conviene para la organización en sus circunstancias particulares?

Continuaremos con estos temas en el próximo número.

Invitación

En marzo tendremos como invitado en e-Quallity a un experto internacional, con quien ofreceremos pláticas sobre temas relacionados con los MCEP en el D.F., Monterrey y Guadalajara. Si tienes interés en asistir, escribe a contact@e-quallity.net con el encabezado “Plática con Expertos”.

Bio

Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-fundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software

Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

Probando APIs

sg — Fri, 19 Sep 2014 19:05:35 +0000

Probando APIs sg Fri, 09/19/2014 - 14:05

Publicado en

SG #45

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

Como bien sabemos, las pruebas de software se han convertido en una etapa imperdonable dentro del ciclo del desarrollo de software, ya sea que se trate de software de aplicación o software de sistemas.

La estrategia, el enfoque, y herramientas para realizar las pruebas pueden variar cuando se trata de probar APIs. Sin embargo hay algunas técnicas que pueden igualmente ser aplicables al llevar a cabo un proyecto de testing que implique contar con una GUI (Graphic User Interface) o cuando no se cuenta con ella, sino sólo con una serie de funciones, métodos, procedimientos que requieren ser llamados.

Y justo para adentrarnos un poco más en este tema, vale la pena considerar algunos conceptos esenciales, sólo para asegurar que estemos dentro de un mismo contexto.

Partamos de que una API (Application Programming Interface) o Interfaz de Programación de Aplicaciones, es una colección de funciones, procedimientos o métodos que están disponibles para ser ejecutados por otras aplicaciones de software; su fin principal es ofrecer acceso a ciertos servicios y proveer de cierta capacidad de comunicación entre componentes de software. Facilitan la vida a los desarrolladores ya que pueden beneficiarse de la funcionalidad de una API, evitando así el tener que volver a programar dicha funcionalidad desde cero. Se utilizan de forma muy común en las llamadas bibliotecas. Ejemplos: Microsoft Win32 API, OpenGL, OpenCL, CORBA, Microsoft Framework .NET, Google Web API’s, API de Twitter, API de Facebook, API REST.

API Testing

Entendamos éste como el proceso de someter metódicamente a evaluación, las llamadas o ejecuciones de dichos métodos, procedimientos o funciones a través de aplicaciones de software externas que ejercitarían diversas técnicas para simular el uso de dichas APIs con diversas y creativas variantes en los parámetros de las mismas, así como configurando pre-condiciones especiales en el ambiente, interactuando con bases de datos, dispositivos, archivos, etcétera, a fin de evidenciar errores.

Al igual que ocurre en un proyecto de testing para evaluar cualquier otro tipo de software, se requieren las típicas fases de:

Iniciación -> Planeación -> Ejecución y Control -> Cierre

Entendiendo que, dentro de dichas etapas del proyecto, igualmente requeriríamos llevar a cabo algunas de las actividades básicas, como:

Análisis: entendimiento de funcionalidad y comportamiento esperado, conocer estructura y parámetros, valor de retorno esperado.
Diseño y aplicación de técnicas de pruebas: clases de partición de equivalencias, valores al límite, condición negativa, prueba funcional básica-camino feliz, etcétera.
Identificación de dependencias y características de interoperabilidad.
Diseño de pruebas: elaboración de scripts/casos de prueba –comúnmente a través de lenguajes de scripting, aunque también se pueden efectuar pruebas manuales.
Preparación de ambiente.
Preparación de datos de prueba: identificación de parámetros de entrada y valores esperados de retorno.
Ejecución de pruebas.
Reporte, administración y seguimiento de incidencias/defectos.
Obtención y análisis de métricas.

Preparación de ambiente para probar APIs

Probar una API es diferente en ciertos aspectos, dado que para empezar, muy rara vez pudiera llegar a ocurrir que se tenga una GUI. Pro esto no significa que no haya que preparar algún ambiente de pruebas.

Como ya lo decíamos, son importantes tanto 1) la preparación de los artefactos y ambiente donde correrán las pruebas, así como 2) la configuración propiamente de la aplicación.

En el primero de los casos, podríamos considerar:

Configuraciones de base de datos.
Creación de scripts automatizados para las pruebas.
Creación de queries si se pretende a través de ellas realizar consultas o modificar datos.
Arrancar el servidor.

En el segundo de los casos, podría requerirse:

Preparación de diversas combinaciones de parámetros para las llamadas a funciones.
Creación de ciertos objetos, previo a las llamadas a la API.
Crear las condiciones iniciales bajo las cuales se pretende realizar las diversas formas de llamadas a las APIs (de forma directa, mediante algún evento o en respuesta a alguna excepción).

Técnicas para probar APIs

Se ponen a consideración las siguientes técnicas, de entre las cuales incluso existen algunas que pueden ser también empleadas en el testing convencional, ya sea incluso manual o automatizado. En el testing de APIs, particularmente se pueden considerar como base para el diseño de los scripts/caso de prueba, las siguientes:

1) Selección de parámetros y valores de retorno. Consiste en ejercitar las llamadas a funciones/métodos de la API aplicando una creativa selección de parámetros y generación de valores de retorno que evalúen éstas mediante la variación no sólo de los valores empleados sino en las formas de llamarlos (con vacíos, null, uno, dos o más parámetros, diversos tipos de parámetros distintos al tipo esperado), la secuencia en las llamadas también puede ejercitarse.

2) Condición negativa. Se recomienda validar los mecanismos para el manejo de errores y excepciones, ejercitando con diversos casos posibles que puedan evidenciar ya sea una incorrecta o ausente validación. La API debiera seguir funcionando ante una inesperada o incorrecta forma de llamada, por ejemplo: ante una lectura incorrecta de un archivo o corrupción de éste, intento de lectura de un archivo no abierto previamente, intento de uso de un dispositivo inaccesible, valores de entrada incorrectos en alguna llamada, o nombres de funciones, procedimientos, métodos inexistentes.

3) Valores al límite. Se requiere ejercitar la API realizando llamadas a funciones donde se evalúe que éstas funcionan adecuadamente ante parámetros de entrada que contemplan valores no sólo en los límites máximo y mínimo permitidos, sino además, al menos en: (N-1); 0; N; (N+1).

Se sugiere un mayor rigor cuando el caso lo amerite, considerando los siguientes posibles escenarios: (LInf-1); LInf; (LInf+1); 0; N; (LSup-1); LSup; (LSup+1) donde LInf es el límite inferior y LSup el límite superior.

Por ejemplo, considerando un parámetro de entrada cuyo valor debe ser un entero entre 10 y 50, se recomendaría probar la función con los siguientes parámetros:

Func(10-1); Func(10); Func(10+1); Func(0); Func(30); Func(50-1); Func(50); Func(50+1)

4) Clases de partición de equivalencias. Como ya lo explicaba en un artículo de la edición 41 de SG [1], esta técnica de pruebas de caja negra permite establecer una relación entre los elementos de un conjunto de valores que comparten cierta característica o propiedad que los representa. Esto permite reagrupar dichos elementos en clases de equivalencia válidas y clases inválidas (grupos de elementos similares) cuyos valores revelarían el mismo error si todos fueran empleados en varias pruebas. La ejemplaridad de dichos valores de entrada permite limitar la cantidad de datos a usar en las pruebas.

5) Prueba Funcional Básica (happy path). Consiste en probar el flujo básico, en este caso, considerando llamadas a funciones de la API cuyo resultado genere los resultados esperados ejecutando cada función o método también en la secuencia “normal”. Ejemplo:

Inicializar();
Configurar (20,1,1);
CargarDatos();

6) Modificación de recursos accedidos por la API. Se sugiere evaluar las llamadas a la API que impliquen modificar ciertos recursos, como: modificación de registros, eliminar ciertos procesos, insertar, actualizar, remover datos de una base de datos, etc. Y una vez que se efectúen dichas tareas, asegurarse que efectivamente sean realizadas como se esperaba.

Recordemos que una de las características importantes de la calidad externa del software que pretende probarse en las API’s es la interoperabilidad, es decir, “la habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada”[2]. Teniendo esos requisitos de interoperabilidad en mente, así como el resto del comportamiento funcional de la API y el software que hará uso de ellas, se deberá planear la adecuada cobertura para obtener las métricas objetivo del proyecto.

Referencias

[1] B. Ruiz. “Preparación y Gestión de Datos de Prueba” SG Software Guru #41. http://sg.com.mx/revista/41/preparacion-y-gestion-datos-prueba

[2] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary.

Bio

Sandra Berenice Ruiz Eguino es Directora de Operaciones de e-Quallity. Ha participado como Consultora Senior en proyectos de mejora de organizaciones de Prueba de Software; cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Software testing: retrospectiva y tendencias

sg — Tue, 08 Jul 2014 00:07:18 +0000

Software testing: retrospectiva y tendencias sg Mon, 07/07/2014 - 19:07

Publicado en

SG #44

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

Si nos dieran la oportunidad de introducirnos a la utópica máquina del tiempo, y vivir hacia atrás los acontecimientos que han marcado pauta en la industria del Testing, comprobaríamos que en estos últimos diez años se han dado pasos importantes (particularmente en México), entre los cuales bien vale la pena mencionar:

Mayor madurez de las empresas al considerar aplicar formalmente esfuerzos de pruebas dentro de su ciclo de desarrollo de software.

Incremento en la capacitación formal en Pruebas de Software.

Profesionalización del Testing, convirtiendo a quienes lo ejercen, en especialistas capacitados y certificados en modelos, metodologías y herramientas propiamente de Pruebas.

Mayor independencia del área de Pruebas.

Paulatino incremento de partidas presupuestales designadas exclusivamente a Testing. Aún sigue faltando mayor poder de convencimiento hacia áreas como Finanzas y Dirección, quienes justamente piden evidencias contundentes del Retorno de la Inversión.

Han surgido en el mercado infinidad de herramientas de pruebas para abordar la evaluación de aspectos funcionales, estructurales, performance, automatización, así como la administración de las pruebas, etc.

El desarrollo del Testing ha propiciado una madurez respecto a la generación de documentación técnica útil del producto (a diversos niveles, pero sí se ha advertido una mayor motivación por generarla, a fin de apoyar a otros procesos).

Se ha venido incrementando el servicio de terciarizarización de las Pruebas, en esquemas como el sourcing de personas, o mediante el surgimiento de fábricas de pruebas externas; aunque muchas organizaciones grandes crean sus propios centros de pruebas, requiriendo en su lugar otro tipo de servicios externos, como la capacitación y certificación de personas.

Las organizaciones se preocupan más por el cumplimiento de estándares de calidad, o se han visto en la necesidad de hacerlo ya sea por procedimientos o regulaciones formales, o por verse inmersas dentro de una red global donde sus aplicativos requieren reflejar una mayor calidad, por cuestiones de competitividad.

Ahora bien, imaginemos tener una bola de cristal, en la cual al ver las predicciones sobre el Testing muy probablemente veríamos muchas de las vertientes que desde la actualidad identificamos como relevantes y que sin duda seguirán teniendo un gran auge:

Mobile Testing. Como sabemos, la gran penetración de dispositivos móviles en el mundo, ha originado el crecimiento desmedido de las apps, abriendo así un universo de posibilidades de crecer en pericia, creación de herramientas especiales, adiestramiento y manejo de las mismas, etc. A pesar de los huecos existentes en el tipo de herramientas y métodos específicos para probar aplicaciones móviles, se sigue vislumbrando un crecimiento importante del Testing en estos dispositivos, en los diversos sectores, según respuestas de 1500 encuestados en el mundo. Ver Figura 1.

Testing en la nube. A pesar de los “pros” y “contras”, esta tendencia podría mantenerse dados los flexibles esquemas que aparentemente pueden resultar muy beneficiosos para las organizaciones desarrolladoras, e incluso para las proveedoras de servicios de Testing. Sin embargo, el crecimiento puede seguir siendo lento aún en el ámbito mundial (ver Figura 2), pues entre otros aspectos, tal vez seguirá pesando la cuestión de la seguridad.

Agile Testing. La adopción de metodologías ágiles en el desarrollo de software seguirá creciendo, por lo que una parte crucial del éxito de dichos proyectos será determinar cómo integrar de forma efectiva a equipos de pruebas que venían desarrollando su actividad en apego a metodologías tradicionales, buscando obtener el mejor provecho de ambos enfoques.

Device Testing. Este es otro más de los rubros que apunta hacia desarrollarse fuertemente, derivado del desmedido incremento de dispositivos controlados por software, y de los tantos que estarán interconectados intercambiando información con aplicaciones en internet (al Internet de las Cosas le queda mucho camino por recorrer).

Infraestructura del Testing. La labor de preparación de múltiples y más complejos ambientes, también seguirá siendo tema de relevancia para las organizaciones que requieren probar software bajo diversas plataformas, con cargas masivas de datos, requiriendo en muchos casos de virtualización de ambientes, a fin de contar con los elementos lo más parecidos a un ambiente de producción, sin que se detenga el ritmo de ejecución por afectaciones en los datos o por la falta de respuesta de sistemas externos que pueden perfectamente ser simulados.

Pruebas de Seguridad. No sólo ante el boom de las aplicaciones para móviles ha surgido la gran necesidad de llevar a cabo este tipo de pruebas, sino también el resto de las aplicaciones requieren un especial esfuerzo y foco; pero en definitiva, es ante la gran demanda de uso de aplicaciones para smartphones y demás dispositivos móviles, que las organizaciones estarán requiriendo dar a sus usuarios mayor protección a sus datos, realizando intercambio de información y transacciones seguras, sean del tipo que fueran. He aquí el gran reto para los especialistas en Security Testing.

Los caminos del pasado, recorridos están. Los nuevos pasos, hay que darlos y de manera firme para seguir haciendo frente y con efectividad, a los nuevos retos que tenemos. Por ello tanto estudiantes, profesionistas de Pruebas, empresas, todos hemos de abordar dichas tendencias si queremos realmente aportar a la calidad del mundo de aplicaciones de software que día a día se siguen desarrollando.

Mejores Prácticas en Pruebas de Usabilidad para Web Móvil

lasr21 — Tue, 22 Apr 2014 04:55:05 +0000

Mejores Prácticas en Pruebas de Usabilidad para Web Móvil lasr21 Mon, 04/21/2014 - 23:55

Publicado en

SG #43

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

Seguramente tendrán un buen contexto respecto a la existencia de estándares, marcos de referencia, guías, buenas prácticas, etc., que continuamente se publican en el mundo con el fin de definir criterios y pautas que apoyen a los desarrolladores de sitios web, para brindar una buena experiencia al cada vez más creciente grupo de usuarios de dispositivos móviles.

W3C (World Wide Web Consortium), es una comunidad internacional donde sus integrantes trabajan en conjunto para desarrollar estándares web. Está dirigida por Tim Berners-Lee, creador de URL (Uniform Resource Locator), HTTP (HyperText Transfer Protocol) y HTML (Hyper Text Markup Language), que son las principales tecnologías sobre las que se basa la web. Esta comunidad ha liberado —entre otros importantes estándares y documentos— las Mobile Web Application Best Practices (disponibles en distintas versiones, la más reciente es la de Diciembre de 2010).

En las pruebas de software para dispositivos móviles, resulta muy conveniente considerar dichas recomendaciones, ya que al implementarlas se busca no sólo lograr la mayor calidad posible y satisfacer a los usuarios actuales, sino ampliar el mercado de las empresas dado que ya una parte considerable de la población utiliza su smartphone o tablet como mecanismo principal para encontrar información, productos, entretenimiento, soluciones, etcétera.

Sabemos que en lo referente a web móvil, los ratings de las aplicaciones están a la vista de cualquiera, por lo tanto, sería difícil ocultar una pobre calidad, que incluso pudiera ser una de las principales razones de su poco éxito.

En vista de lo anterior, enfocaremos el contenido de la presente entrega en mostrar algunos de los aspectos de usabilidad para web móvil, que se sugiere tener presentes entre nuestra lista de pruebas imperdonables. Es decir, sería deseable que nuestros checklist, escenarios o casos de pruebas, contemplen entre otros, los siguientes elementos para buscar el éxito de nuestras aplicaciones móviles.

A) Evaluar si el contenido es tan flexible como para ser utilizado con una gran variedad de dispositivos. Ello permitirá alcanzar un mayor número de usuarios y obtener más satisfacción de su parte. Considerar las diferentes plataformas, sistemas operativos, tamaños de pantalla, etc.

1) Evaluar coherencia temática. El contenido desde una URI refleja la misma información al usuario, sin importar qué dispositivo móvil utilice.

2) Capacidades/características. Verificar que se aprovechen al máximo las características de los dispositivos móviles, para proveer una mejor experiencia de uso.

3) Deficiencias en la implementación. Asegurarse que se hayan tomado medidas adecuadas para evitar problemas en la implementación.

4) Pruebas. Cerciorarse que las pruebas realizadas se efectúen tanto en emuladores, como sobre varios modelos de dispositivos móviles reales.

B) Evaluar el apego a estándares web buscando garantizar una mayor interoperabilidad. La diversidad de modelos y opciones disponibles en dispositivos móviles, no debiera convertir en un caos la experiencia del usuario debido a arbitrariedades en sus formas de operar.

5) Etiquetado válido. Asegurar la creación de documentos de contenido válidos de acuerdo a las gramáticas formales disponibles.

6) Compatibilidad de formato. El contenido enviado por la aplicación móvil debe ser en un formato compatible con el dispositivo.

7) Uso de hojas de estilo. Se sugiere el uso de hojas de estilo para las maquetas y presentación de contenido.

8) Estructura. Uso de las funciones del lenguaje de etiquetado para definir la estructura lógica del documento.

9) Mensajes de error. Asegurarse de que los mensajes de error realmente faciliten el regresar al contenido anterior, siendo lo suficientemente informativos.

C) Evaluar posibles problemas de diseño. Los cuales pudieran hacerse más evidentes, entre otras cosas, debido a pantallas y teclados pequeños. Es necesario verificar que se esté evitando el uso de:

10) Tablas anidadas.

11) Gráficos para el espaciado.

12) Marcos.

13) Mapas de imagen.

14) Ventanas emergentes. (Se sugiere evitar el uso de éstas y si se cambia de ventana, informar al usuario).

D) Identificar consideraciones o limitantes tecnológicas dependientes de funciones que solo estén disponibles en ciertos dispositivos móviles.

15) Fuentes. Usar las de mayor compatibilidad posible.

16) Cookies. No depender de la existencia de éstas.

17) Compatibilidad de tablas. Asegurarse de que si se usan tablas es porque son compatibles con los dispositivos.

18) Objetos o Scripts. No debe haber una dependencia de los objetos o scripts integrados.

19) Colores. Asegurarse de que la información mostrada por medio de colores, también sea comprensible sin color.

E) Evaluar la calidad en la Navegación.

20) Barra de Navegación. Asegurarse de proporcionar una barra de navegación reducida y que esté concentrada en la parte superior de la página.

21) Navegación. Revisar que los mecanismos de navegación sean consistentes entre las páginas.

22) Identificar destino de cada vínculo. Revisar que cada link tenga claramente identificado un destino.

23) Teclas de acceso rápido. Designar teclas de acceso rápido a los links y funciones más utilizadas.

24) URIs: Cerciorarse que sean lo más cortas posible.

25) Balance. Asegurarse de que haya un balance entre contar con demasiados vínculos en una página y hacer que el usuario vaya de un sitio a otro hasta llegar a lo que busca.

F) Evaluar posibles problemas de compatibilidad relacionados a colores, imágenes, estilo, pantalla. Es cierto que elementos como éstos pueden facilitar el destacar cierto contenido, pero a veces pueden propiciar errores debido a las características de pantalla, contrastes de color, formato, etc., de los diversos dispositivos.

26) Re-dimensión de imágenes. Asegurar que se redimensionen las imágenes en el servidor, si tienen un tamaño intrínseco.

27) Gráficos grandes. Verificar que no se empleen imágenes que no pueden ser mostradas en el dispositivo (grandes o con gran resolución), excepto para información crítica que de otro modo se perdería.

28) Legibilidad de la imagen de fondo. Verificar que el contenido siga siendo legible en el dispositivo al emplear imágenes de fondo.

29) Contraste de color. Verificar que la combinación de color del primer plano y el color de fondo proporcionan un contraste adecuado.

30) Scrolling. Revisar que el desplazamiento entre la página se limite a una sola dirección, a menos que sea indispensable también el desplazamiento secundario.

31) Límite de tamaño de página. Verificar que el tamaño de toda la página sea apropiado a las limitaciones de memoria del dispositivo.

32) Tamaño de las hojas de estilo. Uso de hojas de estilo pequeñas.

G) Evaluar los posibles problemas relacionados a retrasos y tiempos de espera en la red.

33) Actualización automática. Verificar que la página no se actualice automáticamente, a menos que se haya informado al usuario y éste tenga forma de desactivarla.

34) Caché. Cuidar que en las respuestas HTTP se proporcione información de caché.

35) Recursos externos. Verificar que se mantenga al mínimo el vínculo a recursos externos.

H) Evaluar que el diseño facilite la introducción de datos, evitando al máximo el uso de teclado u otros métodos monótonos de manejar en dispositivos móviles.

36) Reducción de uso del teclado.

37) Evitar al máximo la introducción de texto.

38) Existencia de un orden de tabulación.

39) Existencia de selección por default.

40) Modo de entrada por default.

41) Etiquetado de controles. Verificar que se asignen adecuadamente etiquetas a todos los controles de formularios.

42) Posición de controles. Verificar que las etiquetas estén colocadas adecuadamente respecto a los controles que correspondan.

I) Evaluar que la información proporcionada a los usuarios de dispositivos móviles sea lo más limitada y sintetizada posible.

43) Título de la página. Asegurarse que el título de la página es corto pero descriptivo.

44) Claridad. Hacer uso de un lenguaje claro y simple.

45) Adecuado. Verificar que el contenido es adecuado para su uso en el contexto móvil.

46) Limitación. Evaluar que el contenido esté limitado a lo que el usuario ha solicitado.

47) Material principal. Asegurarse que el contenido o material principal de la página se ubique antes del material que no lo es.

48) Tamaño usable de la página. Verificar que se divida en porciones usables pero de tamaño limitado.

Estas son las buenas prácticas de la versión más reciente publicadas por el W3C; una buena combinación entre las anteriores y las siguientes, seguramente nos permitirán generar pruebas más completas sobre nuestros sitios y aplicaciones web para móviles (se evita el detalle por cuestión de espacio):

1. Uso escaso de cookies.

2. Uso apropiado de las tecnologías de almacenamiento del lado del cliente para datos locales.

3. Replicar datos locales.

4. No Ejecutar datos JSON (Notación de objetos JavaScript) no confiables.

5. Asegurarse que el usuario es informado sobre el uso de la información personal y de dispositivos.

6. Habilitar inicio de sesión automático.

7. Utilizar compresión de transferencia.

8. Minimizar aplicaciones y tamaño de datos.

9. Evitar redirecciones.

10. Optimizar las solicitudes de red.

11. Minimizar recursos externos.

12. Agregar imágenes estáticas dentro de Sprites.

13. Incluir imágenes de fondo en línea en hojas de estilo CSS.

14. Recursos caché Referencias Recursos Fingerprinting.

15. Datos caché AJAX.

16. No enviar información de

cookies innecesariamente.

17. Mantener razonable el tamaño del DOM (Document Object Model).

18. Optimizar el tiempo de inicio para la aplicación.

19. Minimizar la latencia percibida.

20. Diseño para métodos de interacción múltiple.

21. Preservar el enfoque en actualizaciones de páginas dinámicas.

22. Uso de identificadores de fragmento para manejar las vistas de la aplicación.

23. Hacer de los números de teléfono un “Click-to -Call “.

24. Garantizar flujos de texto de párrafo.

25. Garantizar la consistencia de estado

entre dispositivos.

26. Considerar las tecnologías específicas para móviles para iniciar aplicaciones web.

27. Uso del elemento Meta Viewport para identificar tamaño deseado de la pantalla.

28. Preferir Server-Side Detection cuando sea posible.

29. Utilice Client-Side Detection cuando sea necesario.

30. Utilice Clasificación de dispositivos para simplificar la adaptación del contenido.

31. Soportar una variante No-JavaScript si es el caso.

32. Ofrecer a los usuarios una variedad

de interfaces.

Vale la pena revisar además, las herramientas que nos ayudan de forma automática a evaluar muchas características de usabilidad y accesibilidad de este tipo de aplicaciones, y apoyarnos en algunas que el mismo W3C proporciona disponibles en: www.w3c.org/QA/Tools

Como ejemplo, el “MobileOK checker”, realiza varias pruebas en una página web para determinar qué tan amigable es en su versión móvil. Las pruebas realizadas se encuentran definidas en la especificación “mobileOK Basic Tests 1.0”. Una página web es considerada mobileOK una vez que pasa todas las pruebas (documentadas en su totalidad y disponibles para su análisis en la sección de Ayuda). Si se desea validar contenido específico como hojas de estilo CSS, o para encontrar links rotos, etc., hay otro tipo de validadores y herramientas que proporciona el mismo W3C, todas muy útiles para los fines que hemos venido mencionando.

Bio

Es Directora de Operaciones de e-Quallity. Ha participado como Consultora Senior en proyectos de mejora de organizaciones de Prueba de Software; cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Preparación y Gestión de Datos de Prueba

sg — Mon, 23 Sep 2013 03:40:23 +0000

Preparación y Gestión de Datos de Prueba sg Sun, 09/22/2013 - 22:40

Publicado en

SG #41

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

Si bien es cierto pareciera tan común, no siempre recibe el foco adecuado de entre la lista de tareas predefinidas en el plan de pruebas. Por lo general, creemos que llegada la fase de ejecución de pruebas, se nos podrán ocurrir datos lo suficientemente útiles para ejecutar nuestros casos de prueba sin mayor problema; sin embargo, lo “suficientemente útiles” se queda corto cuando se tiene la expectativa de detectar esos defectos que han sido inyectados desde etapas tempranas del desarrollo del software; de modo que, más bien debiéramos buscar preparar datos lo “suficientemente correctos” para cada prueba, de manera que alcancemos una mayor eficiencia en nuestros ciclos de ejecución.

Test Data Management es el proceso de crear/preparar y utilizar adecuadamente datos de prueba “realistas” para propósitos distintos de los de producción; por ejemplo, para su uso por áreas de Desarrollo, Testing, Capacitación, etcétera (ver Figura 1). Y como Datos de Prueba podemos considerar todas aquellas entradas con las que es alimentado el sistema para ser operado en períodos de evaluación, ya sea que se introduzcan como datos directamente alimentados desde la interfaz de usuario, desde archivos precargados en distintos formatos (xml, .jpeg, etc.), registros tomados desde las tablas de la base de datos, archivos de configuración, archivos de datos generados por el mismo sistema que servirán de entrada para algún otro proceso, así como también datos que ya deben existir en el sistema para que dichos casos de prueba puedan realmente ejecutarse.

Figura 1. Subconjuntos de datos de pruebas para distintos propósitos.

¿En qué tipos y/o niveles de pruebas de software conviene dedicar como tarea específica la de Data Preparation?

Pruebas funcionales manuales
Pruebas funcionales automatizadas
Pruebas de performance
Pruebas de seguridad
Pruebas para aplicaciones web, de escritorio, móviles, etc.
Pruebas a nivel unitario, de sistema, de integración de sistemas, a nivel de aceptación de usuarios, etc.

Existen muchos problemas que se pueden evitar si realizamos una adecuada preparación de datos de prueba, algunos de ellos son:

Detener o retrasar la etapa de ejecución de pruebas debido a datos inadecuados o insuficientes.
Cobertura incompleta en el proyecto de pruebas.
Reportar defectos inválidos a causa de una incorrecta configuración/preparación de datos (errores humanos).
Dejar de detectar defectos potencialmente graves, importantes y/o urgentes.
Existencia de datos ya procesados (y no administrados correctamente) en fases de prueba previas, que dificultan o entorpecen la ejecución actual.
Manejo inadecuado de datos de producción que pudieran propiciar problemas legales (privacidad, seguridad).

En prácticamente todos los casos, es importante cuidar la integridad referencial de la información manejada, dadas las relaciones de ciertos registros que se requiere sean utilizados en diversos módulos de la aplicación a probar. Por ejemplo, si queremos probar un escenario que implica validar las reglas de negocio para determinar los
cargos automáticos mensuales que se aplicarán a aquellos clientes de un banco que han solicitado un crédito de auto, es preciso emplear datos de prueba tales que a su vez estén relacionados a otros datos de prueba previamente registrados desde otros escenarios, de modo que dicho cliente exista, tenga asociada una cuenta, esté activo, tenga saldo disponible para aplicarle el cargo, etc.

Como podemos ahora imaginar, hay situaciones en las que la preparación de datos puede resultar una tarea sencilla, más habrá muchos otros casos en los cuales dicha actividad se convierte en todo un reto, dado que,
no sólo el volumen de datos sino la criticidad de la información a manejar para las pruebas, son de gran peso, tratándose de aplicaciones grandes (que manejan datos complejos y a gran escala) y cuya fuente pudiera requerir
ser una “copia” de datos de producción. Copia de la cual se requerirá enmascarar ciertos
datos/valores a fin de no incurrir en problemas de seguridad o faltas a la privacidad.

Para casos como éste último, donde la preparación manual de datos resultaría ineficiente, existen herramientas especializadas en manejo de datos de prueba, que de alguna manera presentan ciertas ventajas significativas:

Optimizar/agilizar esfuerzos de Testing.
Manejar distintas versiones de datos.
Parametrizar y enmascarar datos para evitar su uso inadecuado en las pruebas.
Generan de forma escalable sub-conjuntos de datos de BDs acorde a las necesidades.
Permiten la extracción de un subconjunto de datos de pruebas desde varias tablas de diversas BD’s e incluso desde diversos DBMS’s (Oracle, DB2, SQL server, Informix, etc.).
Cargan grandes volúmenes de datos de ambientes pre-producción o producción con relativa facilidad.
Proveen de características y habilidades para “refrescar” los datos de prueba de manera eficiente y confiable.
Facilidad para editar los datos y forzar condiciones de error.

Por otro lado, en lo que respecta a la preparación manual de datos de prueba, dada la limitación de espacio, abordaremos a continuación sólo la técnica de Clases de equivalencia o Particiones de Equivalencia, la cual se recomienda utilizar al momento de diseñar y ejecutar casos de prueba:

Es una estrategia de pruebas de Caja Negra, empleada para reducir metódicamente la cantidad enorme (infinita) de casos de prueba posibles, a un conjunto más pequeño, pero con una efectividad equivalente.
Una clase de equivalencia o partición de equivalencia, es un conjunto de casos de prueba con cuyos valores o datos de entrada se prueba lo mismo; es decir, el empleo de cualquier dato perteneciente a dicha clase, revela el mismo error, reduciendo así la cantidad posible de casos de prueba a diseñar/ejecutar.
La razón de que bajo esta técnica se requiere probar sólo con un dato representativo de cada partición o clase, es porque asumimos que con cualquiera de los datos de prueba de dicho subconjunto que utilicemos,
obtendremos los mismos resultados. De igual manera ocurrirá cuando se evidencie una falla.

¿Cómo utilizar las clases de equivalencia para la definición y preparación tanto de los casos de prueba, como de los datos de prueba que en éstos deberemos emplear?

Identificar las Clases de equivalencia. Identificar todas las clases, identificar/clasificar las clases válidas e inválidas, rango de valores válidos.
Identificar los casos de prueba: Diseñar casos de prueba hasta cubrir todas las clases válidas. Diseñar casos de prueba que cubran clases inválidas (En función de los recursos).

Ejemplo: Ver Tabla 1.

Tabla 1. Ejemplo de identificación de clases de equivalencia.

El ejemplo anterior, aunque simple, refleja cómo a partir de ciertos campos de entrada, como aquí el contenido de Calif (Calificación), pueden desprenderse diversas combinaciones de pruebas, dada la variedad de clases de equivalencia que podrían surgir, si la regla de negocio estipula que se realizarán ciertas acciones si dicho dato de entrada está entre 0 y 10, o si está específicamente entre 6 y 7, o bien entre 8 y 10, o completamente fuera de dicho rango (ya sea hacia arriba o hacia abajo).

La tarea de identificación de clases de equivalencia (válidas e inválidas) se vuelve más interesante cuando intervienen diversas entradas, para las cuales se contemplarían datos de prueba diversos, relacionados entre sí, pues ello generará un mayor número de combinaciones.

La calidad de los datos de prueba, impacta directamente en la calidad de los resultados del proyecto de Testing, razón por la que bien vale la pena dedicar un esfuerzo especial, e incluso a veces un equipo especial para poder replicar las condiciones adecuadas que permitan cubrir los requerimientos de datos de prueba especificados en los escenarios y/o datos de prueba diseñados para evaluar nuestras aplicaciones. Otra buena razón, es que los testers mostrarán mayor productividad en las etapas de ejecución, en la medida que sea más eficiente el proceso
de creación, mantenimiento y gestión de sus datos de pruebas.

Bio

Outsourcing del Servicio de Prueba de Software

lasr21 — Fri, 17 Aug 2012 17:56:59 +0000

Outsourcing del Servicio de Prueba de Software lasr21 Fri, 08/17/2012 - 12:56

Publicado en

SG #37

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

Cuando las organizaciones se enfrentan a la imperante necesidad de contar con sistemas de software para sustentar su operación, se encuentran ante la disyuntiva de si deben utilizar aplicaciones de software existentes en el mercado y configurarlas a los procesos específicos de la empresa, o bien si deben contratar del desarrollo de sistemas de software “a la medida”. En cualquiera de estos casos, la expectativa siempre será contar con sistemas de alta calidad, que cumplan con las especificaciones de los usuarios y demuestren un rendimiento y confiabilidad adecuados. En ambos casos debemos tener en perspectiva la necesidad de probar dicho software. Para resolver esto, incluso podemos subcontratar a una empresa que provea el servicio de outsourcing de prueba de software. En este artículo mencionaré algunos de los aspectos que considero de mayor importancia al subcontratar este tipo de servicio.

Elementos a considerar

La prueba de software es un servicio que podría considerarse altamente “tercerizable” y “exportable” dada la naturaleza del mismo, donde la objetividad y la especialización deben estar presentes. Profundicemos sobre los elementos relevantes a contemplar:

Objetividad. Se refiere a poder obtener un juicio imparcial sobre los resultados de las pruebas. En lo posible, debemos evitar que quienes evalúen el software sean los mismos que los desarrollaron, ya que serían juez y parte.

Especialización. Quien provea este servicio debe contar con capacitación formal en prueba de software, conocer metodologías, técnicas y herramientas en esta disciplina para buscar la garantía de un trabajo profesional.

Reducción de riesgos. La tercerización de la prueba debe darnos elementos que nos permitan reducir tangiblemente los riesgos, tanto en el proceso de desarrollo como en la implantación y uso del software que se desarrollará.

Apoyo en la mejora de procesos internos. La interacción entre los testers especializados y los futuros usuarios del software, debe evidenciar áreas de oportunidad en la definición de los procesos de negocio, contribuyendo a la estandarización y documentación de los mismos.

Obtención de métricas. Un buen proveedor de pruebas debe poder generar métricas que permitan evaluar con datos concretos y tangibles la calidad del producto probado.

Métricas para evaluar a proveedores. Aún cuando la prueba está enfocada en medir la calidad del producto de software, implícitamente debieran generarse datos que permitan obtener información de valor respecto a la eficiencia del personal y los procesos empleados para la construcción del software.

Apoyo a implantación exitosa con usuarios. Una buena metodología de prueba debe contemplar una fase de pruebas de aceptación de usuarios, durante la cual estos utilizarán el software acompañados de testers especializados.

Ventajas y desventajas

Para implantar de forma exitosa el outsourcing de pruebas dentro de una organización, será importante analizar las características de la misma. Sin embargo, también vale la pena partir de ciertas premisas para tomar las decisiones que puedan ser más acertadas a las propias necesidades. A continuación se destacan algunos puntos:

Una empresa que no está especializada en pruebas de software es altamente probable que no tenga procesos y metodologías para realizar esta labor. Contratar a un proveedor especializado le permitirá tener acceso a dichos procesos de forma efectiva sin tener que hacer una gran inversión.

Ligado al punto anterior, una empresa especializada en pruebas seguramente contará con algunas de las herramientas necesarias para realizar de forma eficiente muchas de las tareas de la prueba de software. La contratación de un proveedor de estas características podría dar acceso a dichas herramientas sin necesidad de invertir en la adquisición y capacitación de las mismas.

El reclutamiento y selección de testers puede ser todo un dolor de cabeza para las áreas de recursos humanos de empresas no especializadas en prueba dadas las características particulares de los perfiles requeridos.

El dominio de aplicación puede ser factor que desmotive la subcontratación de la prueba. Existen dominios sumamente especializados y/o complejos para los cuales la curva de aprendizaje puede ser grande. La eficiencia de la prueba podría verse mermada por un desconocimiento de dicho dominio por parte del proveedor. En este caso se podría buscar un proveedor que ya tuviera el dominio o bien se podrían desarrollar uno o más proveedores que cubran todas las necesidades de prueba de la organización. Algo que se debe considerar es que si el servicio de prueba es “tercerizado” y la empresa que subcontrata no está preparada para asignar un trabajo continuo a los testers, esto podría generar tiempos muertos que impacten en los costos del servicio. Cabe resaltar que este problema se presenta de igual forma cuando se tiene un equipo de pruebas interno.

Cuando la prueba es subcontratada, el manejo de la comunicación e interacción entre testers y desarrolladores debe ser tomada en cuenta. Suele suceder que el equipo de desarrollo vea al equipo de pruebas como un “enemigo”, lo cual entorpece la interacción y empobrece los resultados obtenidos.

Posibles esquemas de contratación

Antes de contratar un servicio de outsourcing de prueba, es importante conocer distintos esquemas posibles de contratación:

Por persona, con metodología del cliente. Las organizaciones que ya cuentan con una práctica de prueba de software con una alta madurez, lo que requieren en realidad es que se le provea personal que sea capaz de asimilar rápidamente sus procesos y brindar resultados en el corto plazo. La asignación de tareas y administración de los testers es responsabilidad del contratante.

Por persona, con metodología del proveedor. Cuando una empresa no tiene procesos de prueba maduros y requiere este servicio por periodos prolongados de tiempo, lo indicado sería contratar a un proveedor que funcione como su área de pruebas. En este tipo de esquema el proveedor es responsable de asignar las tareas y administrar a los testers.

Por proyecto. El proveedor proporciona un equipo para abordar un proyecto por un tiempo determinado. En este esquema la empresa que contrata no se preocupa por la cantidad de gente involucrada en su proyecto, lo importante es que se obtengan ciertos resultados en el tiempo establecido.

Una variante para cada uno de los esquemasmencionados anteriormente es que la gente se provea en las instalaciones del cliente o en las instalaciones del proveedor. En el primer caso el cliente debe contar con la infraestructura suficiente para acomodar a todo el personal subcontratado y, dependiendo del acuerdo, en algunas ocasiones equipar a los testers. En el segundo caso es importante que el proveedor y/o el cliente cuenten con infraestructura de telecomunicaciones que permitan una interacción eficiente entre los testers y el resto del equipo. Se podría llegar incluso a un esquema híbrido donde se tenga, por ejemplo, un líder en instalaciones del cliente y el resto del equipo en las instalaciones del proveedor.

Si bien es cierto que el outsourcing de cualquier servicio de TI se vuelve un reto desde el momento mismo en que hay que voltear a ver con lupa lo que cada proveedor ofrece, bien vale la pena empezar a desarrollar los procedimientos internos necesarios para agilizar esta tarea, dado que en el corto y/o mediano plazo los beneficios podrán marcar la diferencia. En el caso específico de la “tercerización” del servicio de prueba de software, la exigencia debe focalizarse en obtener una reducción significativa de los riesgos de liberar aplicaciones de software inmaduras pero sin perder de vista los elementos de experiencia, especialización, objetividad, ética, flexibilidad y sobre todo calidad.

Bio

Sandra Berenice Ruiz Eguino es Directora de Operaciones de e-Quallity, además ha participado como Consultora Senior en proyectos de mejora de organizaciones de Prueba de Software. Cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Los retos de un tester de videojuegos

lasr21 — Fri, 06 Jul 2012 00:16:17 +0000

Los retos de un tester de videojuegos lasr21 Thu, 07/05/2012 - 19:16

Publicado en

SG #36

Prácticas

Autor

Sandra Berenice Ruiz Eguino

A diferencia de lo que todos podríamos juzgar, ser probador de videojuegos no es un rol que implique tareas triviales, pueden ser disfrutables hasta cierto punto, pero de ninguna manera tan simples como para pensar que sólo se requiere de pasar horas y horas jugando.

Son sin duda indispensables ciertas habilidades y atributos, además de conocimientos y especialización en ciertas áreas, como es el caso por ejemplo de aquellos Testers que específicamente se enfocan en el área de “Localización” de videojuegos.

Si las compañías que los desarrollan, no probaran de forma exhaustiva y adecuada, definitivamente “pondrían en juego” no sólo las jugosas ganancias que las miles de copias de un producto específico colocado en el mercado global les pudiera generar, sino toda una reputación que se ha venido forjando mediante la aceptación de cada versión de productos que sus más asiduos seguidores están dispuestos a adquirir, por ello es que se toman tan en serio el proceso de probar arduamente cada nuevo producto antes de liberarlo al mercado. Los seguidores no perdonan, máxime cuando tienen medios masivos como las redes sociales, mediante los cuales pueden literalmente “destrozar” o desacreditar un producto en específico que no hubiese cumplido con sus expectativas de calidad.

Ciertamente, de la población joven es de donde más probadores de videojuegos surgen, quizás en cierta medida porque es ese segmento a quien más le ha tocado vivir el “boom” de esta industria tan rentable.

Características de un tester de videojuegos

Evaluar la calidad de software de videojuegos va desde probar su funcionalidad hasta ser un experto traductor, además de ser un experto “localizador de videojuegos”. Aún para cada caso resulta de gran importancia contar con al menos las siguientes características:

Tener amplia experiencia jugando diversos tipos de videojuegos (en distintas plataformas).
Sensibilidad lingüística.
Saber más de un idioma.
Ser una persona etica.
Saber trabajar en equipo.
Tener gran flexibilidad de horario.
Tener pasión por la industria de los videojuegos.
Tener como lengua nativa aquella en la que se “localizará” un videojuego.
Tener capacidad de organización.
Comunicarse adecuadamente con otros equipos (especialmente con los desarrolladores).
Tener experiencia (deseable) en programación y diseño.

Definitivamente, aún cuando el probar la funcionalidad y la “jugabilidad” de un videojuego, puede implicar realizar ciertas actividades de un proceso normal de pruebas funcionales de cualquier tipo de software, ya que igualmente existe una planeación, diseño de pruebas, ejecución, monitoreo, reporte de “bugs”, obtención de métricas y seguimiento a correcciones, pueden presentarse ciertas modalidades o adaptaciones dentro del proceso típico de pruebas, ya que hay que categorizar de forma distinta ciertos elementos de lo contrario los tiempos para probar y corregir pueden resultar ser más limitados, la dinámica de liberar nuevas versiones corregidas puede variar, pues en este sector en especial resulta muy costoso detectar los defectos de forma tardía, los materiales o documentación fuente con que en cada caso se cuente pueden ser también restrictivos desde cierto punto de vista. Por ejemplo, quienes se encargan de realizar traducciones, usualmente no cuentan con la versión original del juego completo, sino que reciben muchas de las veces sólo los textos originales en documentos, pero sin tener el contexto completo con imágenes u otros elementos que les ayudarían a efectuar mejores adaptaciones de diálogos. Esto en la mayoría de los casos, se debe al nivel de confidencialidad que las empresas desarrolladoras exigen para evitar que puedan efectuarse reproducciones piratas masivas de las versiones beta de videojuegos a que los Testers tienen acceso, o bien, a que puedan revelar a personas cercanas ciertos secretos que pueden resultar cruciales para el juego que se encuentran probando. Ciertamente existen varias medidas que pueden tomarse, como convenios estrictos de confidencialidad, sin embargo no siempre resultan ser el mejor de los candados.

Entre los errores más comunes a los que se enfrentan los testers de videojuegos se encuentran:

Bajo rendimiento.
Glitches.
Errores de instalación.
Malas traducciones.
Manejo incorrecto de sesiones.
Errores de adaptación cultural.
Baja calidad en los textos.
Errores de terminología del juego.
Manejo incorrecto de personajes y musicalización.
Errores de plataforma.
Errores de estándares.
Problemas físicos en las consolas o hardware requerido.
Errores de concordancia en voces de personajes.
Reflejo inadecuado de expresiones según el contexto del diálogo.
Manejo inadecuado de teclas, botones, limitaciones para manipular zonas de la pantalla.
Errores de usabilidad en general.

También pueden presentarse errores de lógica o aspectos que van desde el movimiento hasta los efectos de física que dan mayor realismo a las escenas (según sea el juego del que se trate), problemas en interacción de los personajes y el desarrollo mismo de la historia del videojuego. Algunos errores de programación pueden incluso generar congelamiento del juego bajo ciertas circunstancias, o errores en el control de los “scores” de cada jugador, por ejemplo, en juegos de competencias o deportes, errores de performance si mientras se juega teniendo activas descargas de películas, música, videos en internet o se tienen abiertos otros programas, el juego pierde dinamismo.

Entre estos recién listados, y tantos otros tipos de problemas, los Testers de videojuegos se enfrentan a otros retos que, en su gran mayoría, tienen que ver con aspectos de “localización”, entendiéndose dicho término como “la preparación y/o adaptación de un videojuego para ser utilizado en varias localidades del mundo, lo cual va mucho más allá de efectuar una simple traducción de lenguaje, sino que abarca además otros aspectos como: lingüística, cultura, diferencias en hardware y software, diferencias en cuestiones legales, identificación con iconografía y musicalización locales, idiosincrasia, etc.” Definitivamente el humor de un norteamericano no será el mismo al de un mexicano, al igual que habrá frases o palabras que de un país o región a otra puedan resultar ofensivas los personajes, frases de moda locales, entre esos y otros muchos aspectos deben cuidarse como parte de la “localización” de un videojuego.

A continuación se mencionan algunos otros importantes retos de esta área:

Apoyar a la organización a mantener bajos los costos de traducción:

Ya sea mediante la reutilización de términos y frases ya traducidas, con el fin no sólo de traducirlos una sola vez, sino de además mantener una consistencia en el empleo de dichos términos.
Reducir la cantidad de contenido en materiales como manuales, instructivos, archivos “Read me”, etc.
Acortar las explicaciones, descripciones y diálogos mientras sea posible, dejando los mensajes claros pero con menos palabras (no recortarlo demasiado si esos mensajes además serían grabados en voz, ya que podrían encimarse los diálogos).
Emplear el menor número posible de actores de doblaje, interpretando cada uno a varios personajes.
Apoyar para mantener en tiempo y forma la infraestructura necesaria para probar los videojuegos, entre esta infraestructura podemos encontrar computadoras, monitores especiales, televisiones, consolas y/o hardware especiales para las pruebas, tarjetas de memoria, dispositivos para grabación, videos o aparatos DVD’s grabadores, cables especiales, discos duros, mandos y conexiones rápidas. Cualquier falla que pueda retrasar los tiempos de liberaciones establecidos, se traduce en pérdidas económicas.

Llevar a cabo una real preparación para la localización de un videojuego:

Si el contenido del juego será traducido a varios idiomas, es indispensable contar dentro del equipo de pruebas con un guionista de excelente nivel de inglés, por ser éste uno de los idiomas más utilizados en diferentes regiones y dado que originalmente el material fuente pudiera estar desarrollado en dicho idioma.
Realizar comprobación de gramática, comprobación de coherencia de términos, comentarios adecuados, identificar posibles malentendidos, bromas y/o modismos que no aplicarían en otros idiomas.
Revisar longitudes de diálogos, especialmente los de la pantalla, a fin de identificar que no excedan las longitudes máximas posibles, ya que en algunos idiomas se requiere de más palabras para traducir lo mismo.

Evaluar el adecuado de doblaje y grabación de audio.

El tester tiene una labor importante también en este proceso de probar los doblajes efectuados por los actores, ya que debe detectar gran cantidad de inconsistencias y errores ocasionados por la dificultad que esta tarea conlleva, desde problemas por entonaciones inadecuadas ante expresiones de júbilo, enojo o cualquier otra emoción que sin tener el contexto completo pueden pasar desapercibidas.

Si implica tantos costos, tiempo, esfuerzo ¿por qué invertir en “localizar un videojuego”?

Por la sencilla razón de que las organizaciones dedicadas al desarrollo de éstos, vislumbraron que es una importante estrategia para incrementar la cantidad de copias de videojuegos vendidas en cada región/país. El realizar versiones especialmente adaptadas para cada territorio (tal como se haría para el caso de los doblajes en las películas), se traduciría en mayores ingresos que definitivamente retornarían la inversión en el corto plazo.

Es tan dinámico el ritmo con que se avanza en el mundo de los videojuegos, que si bien es cierto existen herramientas de software para llevar a cabo procesos de traducción/localización, existen tantas alternativas como queramos ver, todas orientadas a expandir aún más el alcance de este tipo de productos de software, y a final de cuentas, para los usuarios finales lo realmente importante será que puedan permanecer ininterrumpidamente jugando, sin problemas de calidad en los mismos que les impidan romper nuevos récords.

Bio

Complementando CMMi con TMMI: Analizando el retorno de la inversión

Anonymous — Mon, 19 Sep 2011 18:41:38 +0000

Complementando CMMi con TMMI: Analizando el retorno de la inversión Anonymous Mon, 09/19/2011 - 13:41

Publicado en

SG #33

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

A propósito del fuerte impulso a la capacitación y certificación de organizaciones e individuos en nuestro país, vale la pena poner en perspectiva los logros obtenidos, por ejemplo, en áreas de mejora de procesos de software, donde la meta es alcanzar cierto nivel de madurez ya sea en Moprosoft o CMMI.

En el caso de éste último, abundaremos particularmente sobre algunos elementos que apoyarían en el análisis del retorno de la inversión, desde el punto de vista de las pruebas, a través de la aplicación de un proceso basado en algún Modelo Especializado en Pruebas como TMMi (Test Maturity Model integration), el cual podría visualizarse como una opción natural para cubrir principalmente las áreas de Validación y Verificación contempladas en el nivel 3 de CMMI.

Recordando que en Diciembre del 2010 se liberó finalmente la versión 3.1, versión ya completa, de TMMi es muy reciente su liberación y por ende las empresas no podían certificarse en TMMi, pues al no estar completamente definido (faltaban por desarrollar los niveles 4 y 5), tampoco existía un proceso formal para realizar assessments. Sin embargo esas posibilidades están cada vez más cerca.

Para aquellas organizaciones que han optado por buscar la mejora de sus procesos de prueba basándose en TMMi, les hago énfasis en la importancia de que luego de realizar un assessment, un consultor los ayude a trazar un plan de mejora tomando en consideración no sólo aspectos técnicos sino también el retorno de la inversión que ese plan requerirá. Esto hará más rentable y viable el esfuerzo de mejora de procesos.

Aún cuando TMM (Testing Maturity Model) ha sido su principal fuente, TMMi se basa además en aspectos de CMMI y en estándares internacionales tal como el de la IEEE[3], entre otras fuentes, incluso una parte importante de la terminología de pruebas empleada se basa en el ISTQB.

Como ya hemos comentado anteriormente, el modelo TMMi se basa en una estructura de 5 niveles que son:

Inicial. No existe como tal un proceso definido para pruebas, éstas son concebidas como parte del debugging. La organización no cuenta con un entorno estable para el soporte de los procesos.

Administrado. Las pruebas se convierten en un proceso administrado y claramente independiente del debugging. Considera las siguientes áreas clave: políticas y estrategia de prueba, planeación de prueba, monitoreo y control de prueba, diseño y ejecución de prueba, ambiente de prueba.

Definido. Las pruebas se encuentran totalmente integradas en el ciclo de vida de desarrollo del software, dejando de representar una fase aislada posterior a la codificación. Considera: organización de prueba, programa de entrenamiento para prueba, ciclo de vida de prueba, prueba no funcional, revisiones de pares (peer review).

Medido. En este nivel, las pruebas ya son un proceso perfectamente definido y medible. Aquí entran áreas como: medición de prueba, evaluación de la calidad del software y revisiones de pares avanzada.

Optimizado. La organización es capaz de llevar un control sistemático de costos y efectividad del proceso de pruebas, es capaz de continuar mejorando sus procesos. Se apoya en áreas como prevención de defectos, optimización del proceso de prueba, y control de calidad.

La relación de TMMi con CMMI hace a este modelo especializado en pruebas especialmente interesante para aquellas empresas que cuentan con cierto nivel de madurez en CMMI y que desean ya sea subcontratar las pruebas o bien, implantar su propio proceso basados en TMMi.

Como bien sabemos, entre algunas de las áreas de proceso que habría que implantar para alcanzar por ejemplo, el nivel 3 de CMMI, se encuentran primordialmente la de Verificación y la de Validación, (e incluso la de Integración de Producto), las cuales podrían alcanzarse mediante el desarrollo de un proceso basado en algún Modelo Especializado en Pruebas, como TMMi, el cual a su vez debiera contemplar la definición de métricas de producto.

Estas métricas que se obtienen de las pruebas pueden ser de gran utilidad para medir el retorno de la inversión (trátese de la inversión hecha para implantar tanto un modelo de mejora de desarrollo o uno especializado en pruebas). Es decir, podemos contar con elementos que nos lleven a definir cuánto tiempo nos llevará recuperar lo invertido en mejorar nuestros procesos de desarrollo. Para ello debemos conocer:

¿Cómo estamos?
¿Qué tanto nos cuesta hacer las cosas como las hemos venido haciendo?
¿Qué problemas tenemos y cuánto tiempo y costo nos implica resolverlos?
¿Cuánto esfuerzo hay que aplicar para corregir problemas (re-trabajo)?
¿Quienes cometen más errores?
¿Cuánta capacitación necesitamos para mejorar?

Por otro lado, como resultado de la evaluación de varios productos de software que realizamos durante los concursos llevados a cabo en 2007 y 2008 sobre productos de software mexicanos, mostramos en ediciones anteriores, cómo el no probar adecuadamente incrementa los costos de mantenimiento, lo cual a su vez merma las utilidades y dificulta la inversión en otros rubros estratégicos para las organizaciones.

Es importante por lo tanto, poner especial énfasis en las métricas de pruebas, de manera que podamos realizar las actividades necesarias para bajar costos, mejorar la productividad, mejorar la calidad del software y los procesos que permitieron desarrollarlo, asegurando así un notorio retorno de la inversión en el corto plazo.

Algunos ejemplos de métricas de pruebas que pudieran ser de utilidad son:

Cantidad de defectos potenciales.

Problemas en requerimientos, diseño, documentación, inadecuada corrección de defectos, errores en planes de pruebas, en casos de prueba.

Densidad de defectos

Densidad = Cantidad de defectos / tamaño del software (ya sea que se mida en líneas de código, puntos de función, etc.)

Cantidad de defectos removidos

Por etapa en la que fueron removidos- antes o después de las pruebas, durante el deployment, etc.
Por causa raíz (código, base de batos, ambiente, datos de prueba, etc.)
Eficiencia en la remoción de defectos
Tasa de remoción de defectos por desarrollador/por período
Tasa de remoción de defectos por ciclo de prueba
Tiempos de respuesta en la corrección de defectos
Cantidad de defectos por severidad (1. Muy Alta, 2.Alta, 3.Media, 4.Baja, 5.Mejora)
Cantidad de defectos por desarrollador
Cantidad de defectos pospuestos

Comportamiento del producto comparando resultados de pruebas regresivas y progresivas

Esfuerzo empleado en remoción de defectos y costos asociados (correcciones, re-trabajo, análisis de defectos, etc.)
Cantidad y costo de errores que pasan a producción
Ahorros estimados en mantenimiento

Una expectativa natural al implantar un modelo como CMMI, es que permita mejorar el proceso de desarrollo, y que implícitamente mejore además la calidad del producto. Sin embargo, aún cuando esto pareciera tener cierta lógica, no siempre ocurre así. Quizás en buena medida porque el principal objetivo oculto que ciertas organizaciones persiguen, no se focaliza en obtener una mejora como tal de sus procesos, sino simplemente en obtener mejores credenciales para vender. Lo cual no es precisamente malo, pero sí nos debiera llevar a evaluar qué tan bien estamos aplicando nuestras estrategias corporativas, en relación a lo que buscamos en el mediano y largo plazo.

Por lo anterior, se esperaría entonces que la aplicación sistemática de un Modelo de Calidad Especializado en Pruebas, contribuya en alto grado a la mejora de calidad de un producto de software; y si este modelo de pruebas (TMMi) a su vez es uno que contiene áreas y prácticas alineadas a las manejadas por el modelo de desarrollo que nosotros o nuestros clientes hemos adoptado (CMMI), nos allanará el camino, incluso aún cuando se trate de la aplicación de algún proceso de pruebas basado en su modelo predecesor TMM, o hasta en algún otro modelo de pruebas que maneje áreas semejantes.

Bio

Sandra Berenice Ruiz Eguino es Consultora de e-Quallity en proyectos de mejora de organizaciones de Prueba de Software. Cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, y Directora de Operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, donde realizó sus estudios de Maestría en Ciencias Computacionales.

Pruebas de usabilidad en sitios web

Anonymous — Sun, 22 Aug 2010 19:56:19 +0000

Pruebas de usabilidad en sitios web Anonymous Sun, 08/22/2010 - 14:56

Publicado en

SG #29

Prueba de Software

Autor

La usabilidad se ha convertido en un factor importante de diferenciación en las aplicaciones de software. Como usuarios, cada vez le damos un mayor peso a este elemento. Las pruebas de usabilidad se vuelven cada vez más importantes, a medida que los usuarios buscan mayor satisfacción respecto a facilidad de uso, navegabilidad, adaptabilidad, simplicidad, estética.

¿Qué entendemos por usabilidad?

Si bien es cierto que el término “Usabilidad” no tiene una validez como tal según la Real Academia de la Lengua Española, es ya bastante conocido dentro del medio de TI.

De acuerdo con lo señalado en el estándar ISO/IEC 25010 dentro del cual se identifican características de la calidad del software entre las cuales se encuentra la usabilidad, ésta se define como: “la capacidad de un producto de software para ser entendido, aprendido, utilizado y atractivo hacia el usuario, cuando se usa bajo condiciones específicas”. Es decir que la usabilidad comprende a su vez una serie de atributos del software relacionados con el esfuerzo necesario para su uso, y la valoración individual de tal uso; los atributos que se mencionan tienen que ver con el aprendizaje, la comprensión, la operatividad, y lo atractivo del software.

Al igual que el aspecto funcional, la usabilidad se debe considerar desde el inicio de cualquier proyecto de desarrollo de software. Intentar hacerlo solamente hacia el final del proyecto puede traer graves consecuencias ya que implicará modificar si no todos, sí una gran parte del diseño de interfaces del sistema.

Pruebas de usabilidad

Al igual que con otros aspectos, es importante probar para validar el nivel de usabilidad que muestra un producto de software.

Las pruebas de usabilidad se suelen llevar a cabo observando a las personas mientras tienen bajo uso el producto a probar, y a su vez este grupo de personas es seleccionado considerando ciertas características, según las condiciones que se desean valorar, categorizándolos por ejemplo como usuarios expertos, medios o inexpertos.

Las métricas de usabilidad suelen parecer subjetivas, pues requieren de un juicio individual que dependerá de las circunstancias, del objeto a evaluar o las condiciones bajo las cuales es usado en su valoración. Sin embargo, existen estándares internacionales, normas, guías de comportamiento respecto a los cuales evaluar, así como parámetros que brindan una pauta sobre qué tan “usable” o no es un aplicativo web.

Es deseable (mas no indispensable) contar con un laboratorio de usabilidad para llevar a cabo este tipo de pruebas especiales. El inconveniente es el alto costo que esto puede representar por el equipo que debe montarse para registrar/grabar en video (preferentemente) las actividades de los usuarios y con diferentes cámaras, a fin de ubicarlas desde diversos ángulos, asegurando poder captar las reacciones del usuario durante su experiencia de uso del sistema.

Aspectos de usabilidad a evaluar

Para llevar a cabo pruebas de usabilidad, será importante establecer algunas guías clave que permitan orientar el rumbo del ingeniero de pruebas, permitiéndole capturar información relacionada con aspectos como los que describimos a continuación.

Facilidad de aprendizaje: es deseable que la interfaz sea simple, con funcionalidades accesibles y bien definidas, en general fácil de aprender y de utilizar; asegurarse de que se utilizan guías de estilo, que permitirán alcanzar la consistencia del look & feel del sistema; los usuarios deben ser capaces de trabajar en el sitio web la primera vez sin ningún tipo de ayuda o aprendizaje previos; aAsegurarse que se subrayen los hipervínculos y se maneje el estándar azul como el color para los enlaces no visitados; validar que en las barras de navegación el diseño sea lo suficientemente claro como para que el usuario sepa dónde hacer clic; cuidar que no se utilicen los fondos oscuros y los colores llamativos (a menos que sea la función u objetivo primordial de la página web), evitar además subrayar las palabras, puesto que un usuario podría confundirlas con hipervínculos.

Accesibilidad: validar que sea incluido el manejo de las combinaciones con el comando ALT en las imágenes para hacer los sitios web más accesibles a los usuarios con capacidades diferentes; asegurarse de incluir orden tabular entre los campos para facilidad de navegación durante la selección ó captura obligada de datos; se recomienda que la página web maneje combinaciones de color tales que la lectura no sea difícil, y cuidar el uso de colores rojos y verdes para ayudar a los usuarios daltónicos; asegurarse sobre el uso de alto contraste y fuentes bastante legibles a fin de ayudar a los que tienen menor capacidad visual; validar que se permita al usuario controlar tipo y tamaño de las fuentes para una lectura más cómoda; el sitio web deberá ofrecer contenido alternativo si las funciones de los scripts, applets y plugins no son accesibles.

Flexibilidad: asegurarse que el usuario no tenga que intercalar continuamente entre las acciones de hacer clic y escribir; validar que al usuario se le solicite escribir lo menos posible, máxime cuando existen otras alternativas como un botón de selección o un enlace, lo cual puede además evitar la captura incorrecta de datos.

Tiempo de respuesta: considerar que el tiempo máximo de descarga de una página no sobrepase el máximo aceptable de acuerdo al tipo de operación, considerando una velocidad de conexión promedio de los usuarios.

Reducción de la carga cognitiva: asegurarse de contar con páginas ligeras en contenido no sobrecargándolas con demasiado texto; validar que el usuario pueda acceder a cualquier página en la menor cantidad posible de clics de ratón, preferentemente menos de tres.

Recuperabilidad: asegurarse de considerar los errores del usuario; el sistema debiera incluir una retroalimentación apropiada para informar al usuario y que éste pueda tomar las acciones correspondientes; asegurarse que la página web no sólo muestre mensajes de error útiles, sino que permita al usuario saber dónde está ubicado dentro del sistema, mostrando rutas de navegación.

Buena Imagen y Estética: asegurarse que el sitio web brinda un entorno agradable, a través del cual se facilite el entendimiento de la información presentada.

Métodos de prueba para evaluar la usabilidad
Existe una gran variedad de métodos para evaluar la usabilidad de un sistema de software, o en este caso un sitio web. Entre los más comunes están los siguientes:

Observación en un entorno controlado centrándose en tareas concretas y removiendo la influencia de factores externos.
Observación y análisis de la interacción que lleva a cabo el usuario con ciertos módulos del sistema, con colaboración consciente del usuario.
Observación en el entorno natural.
Evaluación de la estética en general del sistema y en particular de todas las pantallas.
Grabación automática de ciertos escenarios en la interacción usuario-máquina (usualmente grabación en video dentro de un laboratorio con cámaras estratégicamente colocadas).
Entrevistas elaboradas especialmente sobre el uso de un sitio web en particular.
Logging automático en las aplicaciones para el análisis de duración de sesiones y patrones de acciones repetitivas.
Comparación con estándares de diseño y normas.
Uso de “expertos” para evaluar.
Aplicación de cuestionarios.

Tips finales

Finalmente, para cerrar esta entrega, vale la pena mencionar que, al momento de evaluar la experiencia de usuario durante la navegación en sitios web, resulta conveniente considerar, además de los ya referidos métodos y aspectos de Usabilidad, una serie de tips o “lemas” interesantes enunciados por Brad Myers:

Si se ve diferente, debe hacer algo diferente.
Si se ve igual, debería hacer lo mismo.
Es más importante dar poder al usuario, no acelerar el “sistema”.
No sobrecargar los “buffers” del usuario.
Cada acción debería tener una reacción.
Todos cometemos errores, pero todos los errores deberían poder corregirse.
Entre más se hace algo, más fácil debería ser convertirse en experto.
Consistencia, consistencia, consistencia.
El usuario debe estar de buen humor al terminar.
Nada debiera dejarse simplemente “para explicarse en el manual”.
“Bonito/simpático” no son buenos adjetivos para un sistema.
El color es información.
Un gramo de buen diseño vale kilos de soporte técnico.

Referencias

N. Bevan. "Quality in use: meeting user needs for quality", Journal of Systems and Software, Vol 49, Issue 1.
B. Myers. Overview of HCI Design and Implementation.

Bio

Luis Vinicio León Carrillo es Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-fundador. lleon@e-quallity.net

Sandra Berenice Ruiz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba de software. A lo largo de su trayectoria profesional ha actuado como ingeniero de pruebas, líder de proyecto, administradora de proyectos de pruebas, y Directora de Operaciones. Ha sido profesora de la UAG, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.