Cuales son las responsabilidades de un buen líder de testing?

El rol del líder de un equipo de Testing es liderar efectivamente a su equipo para cumplir con los objetivos del producto y poder entregar a tiempo el producto sin errores.

Dentro de sus responsabilidades se encuentran:

  • Identificar el alcance de las pruebas requeridas en función de los requisitos
  • Asignar recursos a los proyectos. Son responsables de estimar las personas necesarias para el equipo y los recursos que necesitan para llevar a cabo el Testing.
  • Definir el perfil de tester que el proyecto necesita.Definir, seguir y controlar el plan de calidad
  • Definir y revisar las estrategias de Testing.
  • Decidir sobre las herramientas a utilizar, este punto puede definirlo con el equipo
  • Aplicar procesos, procedimientos de mejora, métricas Establecer políticas y cultura de calidad en el proyecto y en la empresa.
  • Revisar semanalmente el progreso del proyecto
  • Asegurarse que su equipo dispone de las herramientas adecuadas para hacer su trabajo.Facilitar la comunicación.
  • Mitigar los riesgos. Debe definir un plan para los riesgos. En caso de que algo suceda y sobre pase su rol debe escalarlo rápidamente.
  • Garantizar que los procesos de calidad se siguen y se cumplen.

descarga (1)

  • Dirigen,guían y supervisan el análisis, diseño, implementación y ejecución de los casos de prueba.
  • Debe conocer el porcentaje de test cases corridos, fallados y pasados.
  • Durante el ciclo de prueba, supervise el progreso de la prueba evaluando constantemente el trabajo asignado a cada uno de los recursos y vuelva a equilibrarlos o reasignarlos según sea necesario.
  • Programar las pruebas para su ejecución y luego monitorear, controlar e informar sobre el progreso de la prueba, el estado de calidad del producto y los resultados de la prueba, adaptando el plan de prueba según sea necesario para ajustarse a las condiciones cambiantes.
  • Seguir los errores encontrados, en especial los críticos.
  • Antes de comenzar con la ejecución debe asegurarse de contar con un ambiente de pruebas limpio y en un lugar seguro, con Backus diarios y con acceso remoto por todos los miembros del equipo.
  • Definir que partes del producto puede ser automatizado, y cuando es el momento apropiado para comenzar con la misma.
  • Debe definir un plan, las herramientas a utilizar y solicitar la capacitación si es necesaria para el equipo.
  • Mantener reuniones diarias con el equipo para asegurarse que todos estén al tanto del progreso y de los errores encontrados. En caso de haber retrasos en el cumplimiento del cronograma revisar con el equipo donde se encuentran y que pueden enfrentar y esforzarse por resolverlos. Como también para detectarlo y poder hacer los ajustes correspondientes.
  • Enviar periódicamente el estado del proyecto a las partes interesadas y la gerencia
  • Estimar futuros proyectos de testing

 

La importancia del Analisis en el Testing

Si bien el analista tiene entre sus competencias analizar el negocio y proceso del cliente para así poder definir los requerimientos y funcionalidades del software, no solamente este puesto es el que se encarga de analizar los requerimientos del cliente. Un tester entre sus tareas también se incluyen el análisis.

Gran parte de las tareas del tester se centran:

  • Enteder las necesidades del cliente
  • Conocer la funcionalidad del software
  • Analizar los requirimientos del cliente
  • definir test cases y escenarios que cumplan con los requerimientos

Muchas veces durante el proceso de testing y creación de test cases el tester puede descubrir requerimientos que no están claramente definidos o ambiguos, en estas situaciones se ve en la obligación de comunicar esto y de ser necesario solicitar una actualización/mantenimuento de los requerimientos.

A su vez el tester tiene la posibilidad de analizar estos requerimientos con el desarrollador que es la persona que va a desarrollar la aplicación y así poder prevenir errores en la funcionalidad, siempre se recomienda que antes de que se escriba código haya un análisis en conjunto del desarrollador y tester, este análisis va a ser conducido por el tester.

En muchos casos el tester es el primero en identificar si hay inconsistencias o desactualización entre la funcionalidad del software y los requerimientos iniciales, la mayoría de las veces los cambios en los requerimientos no son claramente reflejados y solo son evidentes cuando un usuario nuevo o nuevo integrante del equipo empieza a trabajar con la aplicación. Pero si el tester tiene conocimientos de los requerimientos puede identificar claramente inconsistencias o que los requerimientos no fueron actualizados.

 

 

La Importancia de UX

En la actualidad la experiencia de usuario ha cobrado mucha relevancia, pero que es la experiencia de usuario? en pocas palabras es todo el conjunto de elementos que determinan el resultado de la interacción del usuario con una aplicación.  Para acercarnos a un resultado positivo, es importante conocer, comprender y satisfacer las necesidades, objetivos, expectativas, motivaciones y capacidades de nuestros usuarios.

Por lo cual debemos conocer al usuario y así desarrollar una aplicación que no solo satisfaga sus expectativas sino también las cumpla de la mejor forma por esto debemos adentrarnos en el mundo UX, que no es lo mismo que UI.

UX1

Uno de los errores comunes es confundir UX con UI, tengamos en cuenta que UI está enfocado al diseño, una aplicación puede estar muy bien diseñada y no ser funcional a los objetivos del usuario.

Por otro lado puede tener las funcionalidades implementadas de la mejor forma y de acuerdo a los requerimientos del usuario así como el diseño pero no ser usable para el usuario. Ahora tenemos otro concepto nuevo que es usabilidad, que es usabilidad?

Una de las aproximaciones a usabilidad es que todas las funcionalidades de la aplicación y/o página sean fáciles de identificar, esto es solo una de los ejemplos que refieren a funcionalidad.

Hasta ahora tenemos varios conceptos que están ligados a la Experiencia de Usuario

UX

UI + Funcionalidad + Usabilidad + …. + Plataforma + Contenido = UX

Y podemos seguir agregando elementos a la ecuación que va a resultar en la experiencia de usuario.

En la ecuación podemos ver que también está el contenido, este es otro punto a tener en cuenta, cuanto contenido mostramos al usuario y como se lo mostramos…de acuerdo a la aplicación o pagina web, y en este punto debemos tener en cuenta que no es lo mismo el contenido en una aplicación para móviles que el contenido de una página web.

Y así como agregamos contenido podemos seguir con más elementos, pero al final el resultado va a ser uno solo.

Depende de nosotros si este resultado es positivo o negativo. Y de las herramientas que usamos como QAs para obtener un resultado positivo.

Como QA, somos lo más cercano al usuario final. Conocemos los requerimientos, sabemos lo que el usuario espera de la aplicación y a su vez contamos con conocimiento adicional en tecnología que nos va a ayudar a tener una mejor aproximación a la hora de probar la aplicación en términos de experiencia de usuario.

Pero para tener esta aproximación tenemos que prepararnos y hacer uso de las diferentes herramientas con las que contamos como por ejemplo:

  • Análisis de los requerimientos
  • Entrevistas con el usuario
  • Uso de prototipos
  • Herramientas de prototípico
  • etc.

Si están interesados en adentrarse en UX desde el punto de vista de los QA, no se pierdan nuestro webinar de UX.

En este webinar podrás adentrarte en los lineamientos base para lograr un producto orientado al usuario, y te mostraremos las tendencias y estadísticas actuales que debes conocer para obtener una aplicación exitosa.

A continuación te presentamos algunos de los temas específicos que se expondrán:

  • Que es UX
  • Importancia UX en Testing
  • Diseño UX y UI
  • Aspectos a tener en cuenta en UX
  • Buenas Prácticas
  • Errores Comunes en UX

Versiones Beta, conviene testearlas?

Las versiones betas son publicadas para un público específico y son publicadas unas semanas antes del lanzamiento oficial para que el desarrollador y el tester puedan instalarlas y probar cómo funciona la aplicación en la nueva versión, para detectar la mayor cantidad de errores de manera temprana.

Como testers, es importante poder acceder a ellas y realizar las pruebas de la aplicación en distintos dispositivos con la nueva versión del sistema operativo.
Para instalar las versiones betas, hay que hacerlo desde el sitio web de Android o IOS, generalmente con una cuenta de desarrollo y se debe buscar la versión particular para cada dispositivo.

Si los cambios de versión son muchos o significativos, como pasó por ejemplo con el cambio a IOS9, es conveniente instalar la versión beta en varios modelos de dispositivos y realizar un buen testing de regresión. También es importante, realizar un testing de performance y de UI detallado.
Si los cambios son menores y no hay mucho tiempo para realizar una regresión, al menos hay que ejecutar un Smoke testing para corroborar que la aplicación funciona como se espera.

Una vez que la versión oficial esté disponible, se debe actualizar el dispositivo a esa versión y probar la aplicación ya en la versión oficial.

Un vistazo al testing de dispositivos móviles

En el caso de testear una aplicación en dispositivos móviles hay que tener en cuenta que el entorno es cambiante, dinámico.

También hay que considerar que los usuarios de celulares tienen características que los hacen especiales. suelen ser ansiosos, adictos a las redes, ocupados, distraídos, multitasking.

El usuario puede estar distraído o tener prisa, por lo que se debe probar que la estructura de navegación sea simple. También puede suceder que la tarea que está realizando el usuario sea interrumpida por pérdida de señal, por una llamada entrante, por una alarma o por una simple distracción.

Por lo tanto, la aplicación debería permitir recuperar el proceso en curso tras la interrupción.

android_crash

Las interrupciones son mucho más habituales de lo que uno podría pensar.

Al momento de realizar su plan de pruebas se debe agregar al testing funcional la verificación de los siguientes puntos:

  • Las interrupciones: se debe verificar: ¿Cómo funciona su aplicación hacer si el dispositivo recibe una llamada entrante, mensajes, alertas de aplicaciones, alerta de batería baja o cambio de aplicación?
  • Consumo de batería: Comprobar que la aplicación no consuma excesiva batería.
  • Localización: las lenguas con las palabras más largas o caracteres especiales son los más propensos a errores en la presentación visual.
  • Conectividad: se debe probar las distintas conexiones. Si se supone que la aplicación que se utilizará a través de una conexión lenta (como 2G, 3G, etc ) esta debe ser probada.
  • Uso real que da el usuario al dispositivo móvil. Las aplicaciones móviles deberían ser probadas en el momento en el que los usuarios las usen.
  • Configuración de usuario: Se deben testear las distintas configuraciones que el usuario puede tener establecida y que la aplicación utiliza, por ejemplo: no tener la cuenta de correo electrónico configurada en el dispositivo, alertas de notificación, Fecha y Hora, etc.
  • Testing de instalación: Verificar que la aplicación pueda ser instalada correctamente: WIFI, Bluetooth, Cable.
  • Testing de desinstalación: Verificar que la aplicación haya sido desinstalada exitosamente.
  • Las características de la aplicación: si su aplicación se adapta la interfaz para la orientación (horizontal o vertical), o apoya configuración local multilingüe u otro, estos deben ser considerados en el ámbito de pruebas.
  • Y lo más importante contar con múltiples dispositivos. Se debe tener un dispositivo por cada plataforma que la aplicación soporte y cada una debe ser probado.

Será importante tener un dispositivo con el último sistema operativo y uno o dos más con versiones anteriores, se debe asegurar que los usuarios no se enfrentarán a errores debido a los cambios introducidos.

google-nexus-6p

Emuladores vs Dispositivos reales

 

El reto más importante que nos enfrentamos a la hora de probar una mobile app es la diversidad de dispositivos móviles y versiones de sistemas operativos.

Contar con todos los dispositivos reales y versiones del sistema operativo es difícil de lograr, generalmente se suele sacrificar la cobertura del testing, definiendo combinaciones de dispositivo y sistema operativo hasta cierto punto, pero cuando se reduce el número de tipos de dispositivos que se prueba, se aumenta la posibilidad de que la aplicación no funcione en ciertos clientes potenciales.

La mejor manera de lograr el equilibrio es combinando el uso de dispositivos reales con emuladores.

Los dispositivos reales tienen la ventaja de contar con todas las limitaciones y peculiaridades presentes en el sistema operativo del cliente real. Sin embargo las pruebas con dispositivos reales pueden ser costosas.

Los emuladores, por otro lado, son relativamente fáciles de manejar. Puede cambiar los tipos de dispositivos simplemente cargar un nuevo perfil de dispositivo, y al instante ya se tiene un nuevo dispositivo que se presenta a su aplicación móvil o web nativa de la misma manera que el dispositivo real haría.

También son muy útiles en términos de usabilidad, y especialmente el diseño, incluyendo la entrada de datos, tamaño de la pantalla, el uso de botones, etc. Todo desde la comodidad de su propio ordenador portátil. Sin embargo, apuntando y haciendo clic con el ratón en un monitor de escritorio no es lo mismo que usar un dedo en una pantalla pequeña.

Smartphones and applications

La gran desventaja de los dispositivos emulados es que carecen de las peculiaridades, fallas y características que sólo el dispositivo real puede proporcionar, ya que los mismos se ejecutan en PCs con procesadores más potentes que un smartphone o tablet. Finalmente, un dispositivo emulado no es sensible a las condiciones ambientales que pueden afectar el comportamiento del dispositivo.

Afortunadamente, usted no está limitado a una selección para determinar la solución dispositivo adecuado para sus necesidades de pruebas móviles.

Un tercer enfoque es seleccionar una mezcla de ambos: usar emuladores y pruebas en dispositivos reales.

En este caso se sugiere comenzar a probar en un entorno emulado para aprovechar la velocidad y la diversidad que un emulador puede proporcionar. Y luego añadir dispositivos reales a su plan de pruebas para validar que las aplicaciones funcionen como se espera en el ambiente real que el usuario va a utilizar y certificar que se han cumplido todos los requisitos y objetivos de desarrollo.

Casos de Prueba y/o Escenarios

No existe una fórmula que funciona para todos los proyectos o en este caos para todas las aplicaciones, si bien hoy en día la mayoría de los equipos usan scrum en su proceso de desarrollo se mal interpreta al pensar que al ser una metodología ágil no es necesario escribir test cases, si bien las aplicaciones en el aspecto de desarrollo avanza rápidamente ya que al final de cada sprint tenemos un incremento en la aplicación, es mucho más importante asegurar la calidad de ese incremento. También es un realidad que los tiempos para crear test cases, automatizar y probar son cada vez menos, no podemos dejar de usar las herramientas que tenemos para asegurar calidad. La pregunta es creamos test cases o no? Si, toda herramienta que nos ayude a obtener un producto de calidad debe usarse, pero como dijimos antes no es necesario crear los test cases de manera tradicional.

Cuál es la diferencia entre un test case y escenarios?

Un test case es un conjunto de condiciones bajo las cuales se determina que una parte determinada de una aplicación funciona de acuerdo a los requerimientos, y para escribir un test case debemos tener precondiciones, paso a reproducir, resultado esperado, datos de prueba, etc. En cambio para escribir un escenario solo necesitamos saber que debe realizar la aplicación.

Tal vez una aproximación para entender la diferencia entre un test case y un escenario seria:

Test Case: Como debe probarse.

Escenario: Que se deber probar.

Después de dar una breve definición de los test cases, veamos la diferencia con un escenario. Los escenarios solo describen que debe hacer la aplicación, y pueden ser escritos en una línea o más y ser parte de un conjunto de escenarios como un checklist.

Cuando usar escenarios?

  • Cuando las reglas de negocio son complejas

Es más fácil pensar en el resultado esperando a un determinado flujo de acciones, que tener que escribir paso a paso y además es más efectivo en cuestiones de tiempo.

  • Cuando el sistema cambia de un momento a otro

Mantener los test cases involucra tiempo, durante el cual a veces esos mismos test case ya no útiles para el estado actual de la aplicación.

  • Cuando las diferentes combinaciones para probar una determinada aplicación son muchas

En este caso escribir la cantidad de test cases para probar una sola parte de la aplicación involucra mucho tiempo y nivel de detalle para diferenciar un test cases de otro.

  • Cuando no se puede reutilizar los test cases

Cuando se tiene por ejemplo una aplicación que interactúa con otras aplicaciones pero los pasos para ejecutar determinado test case no son los mismo, lo único que es igual es el resultado final.

Que se debe tener en cuenta a la hora de escribir escenarios

  • Entender el sistema/aplicación en la cual se está trabajando. EL propósito de la aplicación.
  • Identificar los escenarios más comunes
  • Pensar como el usuario final, el usuario final no piensa en paso o precondiciones, solo en resultados.

Test de Integración

En el proceso de testing de software tenemos varios tipos de pruebas. Y además estas pruebas se realizan en diferentes etapas del proceso de desarrollo de una aplicación.

Si estamos trabajando con metodologías agiles se van probando diferentes incrementos en la aplicación por separado incluso cuando trabajamos con metodologías tradicionales,  no podemos probar todas la aplicación al mismo tiempo y las interacciones entre los diferentes módulos. Primero se van probando por módulos, funcionalidades o secciones de una aplicación.

Una vez que se finaliza con las pruebas en los diferentes módulos, el siguiente paso es probar todos los módulos y diferentes funcionalidades juntas, a este testing en particular se le llama prueba de integración.

A lo largo de Test de integración se van probando en conjunto los diferentes modulos y sus interacciones. Estos modulos se van acomplando progresivamente en pares y/o conjuntos. Despues de cada acoplamiento se prueba la correcta integración.

Cada conjunto, parcial o total, debe verificar los requerimientos funcionales, de rendimiento y de seguridad definidos en las primeras etapas del ciclo de vida del software.

Integration-Test

Existen varios tipos de pruebas de integración. Los más comunes son:

  •  big bang: se acoplan todos los módulos de una sola vez, reduciendo la cantidad de pruebas (pero también dificultando la detección de posibles errores).
  • bottom-up: se prueban primero los componentes de bajo nivel y luego se avanza hacia los de mayor nivel.
  • Top-down: el enfoque es exactamente inverso al anterior.

Se puede utilizar cualquier método de los antes mencionados, pero lo más importante  es incluir las pruebas de integración ya que son de importancia crítica para el proceso de aseguramiento de calidad, sobre todo porque cada nuevo incrementa nos acerca al producto final.

No dejen de visitar nuestros cursos y talleres.

¡Atención! Arranca el curso “Introducción al Testing Mobile”

En Octubre inicia el curso “Introducción al Testing Mobile”. Este curso es una oportunidad para mejorar tus habilidades como tester y dar un paso más en tu carrera.

Todos los cursos dictados por Los Andes Training, se caracterizan por ser prácticos y dictados por profesionales con amplia experiencia en el tema.

Con nosotros aprenderás sobre metodologías y herramientas que se utilizan en importantes compañías.

El cursado es durante 6 sábados, las clases tienen una duración de 2.5 horas donde damos contenido teórico y práctico.

La modalidad es online y las clases son grabadas, por lo que si te perdiste alguna clase o quieres repasar algún tema puedes acceder a los videos. Las clases son en vivo,  o sea que vas a compartir tu experiencia con otros profesionales, y seguramente vas a aprender mucho de ellos, como así también sacarte todas las dudas que tengas.

Al final del curso entregamos certificado.

Si todavía te queda alguna duda, puedes consultar el temario acá

O puedes enviarnos un email a losandestraining@gmail.com

Severidad vs Prioridad

Una pregunta infaltable de entrevista técnica: Cuál es la diferencia entre severidad y prioridad?, pero que no todos saben responder.

Ambos son atributos de un bug, y al momento de reportar uno probablemente tengamos que asignarle un valor, o ambos, a alguno de estos atributos.

Empecemos por las definiciones:

Prioridad: El nivel de importancia (comercial) asignado a un elemento, por ejemplo, defecto

Severidad: El grado de impacto que tiene un defecto en el desarrollo u operación de un componente o sistema.

Para la Prioridad: Cuando te encuentras frente a un bug y tienes que reportarlo tienes que preguntarte: este error debería ser resuelto de inmediato? si la respuesta es sí, entonces el bug tiene prioridad “Urgente” o “Muy Alta”, esto va a depender de la escala que tu equipo haya definido en el sistema de seguimiento que estén utilizando.

En algunos equipos te vas a encontrar con que el responsable de asignar la prioridad es el líder de proyecto, algo lógico, porque la prioridad asignada a un bug puede llegar a cambiar la planificación del proyecto y las tareas ya asignadas a un desarrollador.

Pero la gran mayoría de las veces es el tester el encargado de hacerlo. Mi recomendación es que seas lo suficientemente crítico respecto al error, si es un error que afecta funcionalidades importantes del proyecto, entonces hay que darle una prioridad alta, sino seguramente es algo que puede resolverse más adelante, tal vez en otro sprint. Siempre es bueno también hablar con el desarrollador y preguntarle que piensa al respecto.

En cuanto a la Severidad, la severidad está relacionado al grado de impacto del defecto. Por lo tanto si una funcionalidad está rota, o si no puedes terminar de ejecutar un caso de prueba porque el flujo está roto, el bug tendrá severidad “Crítica”. Pero si por ejemplo nos encontramos un error ortográfico o una fuente incorrecta estos bugs son de tipo “Cosmético” o “Menor”.

A veces surgen confusiones respecto a la prioridad y la severidad, esto es porque, a veces se piensa que si un bug tiene Severidad Alta, indefectiblemente también tendrá Prioridad Alta. Esto no siempre es así, podría darse el caso de una funcionalidad rota y por los tanto el bug tendrá Severidad Alta, pero si dicha funcionalidad no es una funcionalidad crítica del sistema, podría ser en un flujo no muy importante para el negocio, entonces seguramente no vamos a tener urgencia en resolver el bug, por lo tanto su Prioridad será Baja.

 

Severidad

Screen Shot 2017-09-19 at 21.59.04

Prioridad

prioridad