Blog

Búsqueda 1: Analista QA Manual Sr

Las tareas y responsabilidades para la posición son:

1. Asegurar la calidad de los desarrollos y satisfacción del cliente
2. Revisar Documentación (Historias de Usuarios, CU, Diagramas, etc)
3. Analizar el impacto de los desarrollos.
4. Definir, actualizar y ejecutar casos de prueba / plan de prueba
5. Generar reportes y seguimiento de incidencias en los test ejecutados, interactuando con equipos de desarrollo repartidos por el mundo
6. Proponer e implementar mejoras en la metodología de desarrollo o tareas
7. Elaboración de métricas y/o alertas
8. Definir y ejecutar pruebas de performance

Análisis:
Para esta búsqueda -a mi entender-, el postulante deberá saber cómo manejar todo lo relacionado con el Tratamiento de Requerimientos para poder atender el punto (1), (2), (3) y (4). Imagino que sería deseable que tuviese experiencia en gestionar estos aspectos con alguna Herramienta ya que al no mencionarlo puede ser que no cuenten con ella y podría estar atendiendo el punto (6), para vincular el trabajo entre los desarrolladores, clientes y testers. El punto (2) también da lugar a pensar que el postulante debe tener conocimiento y experiencia en Proyectos Ágiles (scrum) para poder manejar el concepto de US y todo lo que eso conlleva más que nada en lo relativo a la carga de datos y extracción de los casos de prueba. Sabemos que no es lo mismo una US que un UC, ¿verdad?. Por otra parte, el punto (3) exige que el postulante entienda la forma de identificar dependencias para luego establecer la trazabilidad. En cuanto al punto (4), (5) y (7) para la gestión de los TC’s al estar participando en un proyecto ágil, lo recomendable sería usar por ejemplo una herramienta tipo Cucumber que permite el manejo de las US. Para ir cerrando el análisis de esta posición que están buscando, el punto (6) me lleva a pensar que para que el postulante pueda realizarlo, sin lugar a dudas cuánta más experiencia tenga en diferentes proyectos, mayor será el aporte que pudiera hacer al respecto, por lo tanto no es menor el factor de la cantidad y calidad de proyectos en los que haya participado. Finalmente, veamos el punto (8) relativo a definir y ejecutar pruebas de performance. Aquí es donde no me «cierra» el título del perfil que se está buscando ya que para efectuar este tipo de práctica es necesario contar con un conocimiento técnico específico puesto que son pocas las tareas «manuales» que se deben realizar. Creo que aquí no esta claro que pretenden del QA Manual respecto a las pruebas de performance. A ver, en principio el postulante debería contar con alguna herramienta que le permita entender la situación actual del proyecto sobre el cual habrá que llevar a cabo este tipo de testing, por ejemplo algo por el estilo.

Después o a partir de este checklist, deberá poder reconocer qué tipo de performance es el que hay que realizar y en qué instancia del proyecto, porque hay una clasificación importante a tener en cuenta.

• Load test (prueba de carga): El objetivo es simular el uso real del sistema. Para esto es necesario entonces hacer un análisis de la cantidad de usuarios que accederá y qué operaciones se ejecutarán.

• Stress test (prueba de estrés): El objetivo es encontrar el punto de quiebre del sistema. Entonces, se ejecutarán las operaciones más accedidas (típicamente) en forma incremental en cuanto a la cantidad de usuarios, hasta que el sistema caiga. De esta forma podremos analizar hasta qué cantidad de usuarios es capaz de soportar el sistema con la infraestructura en la que está instalado, y ver cuánto cuesta recuperar el funcionamiento normal luego de una caída.

• Soak test / endurance test (prueba de resistencia): Aquí el objetivo es probar por períodos más prolongados de tiempo. De esta forma intentamos encontrar otro tipo de problemas (esos que se manifiestan luego de cierta acumulación del problema, tal como un memory leak) y analizar cómo se comporta el sistema luego de estar en funcionamiento durante un tiempo.

• Throttle test: La idea es simular la carga limitando la velocidad de conexión de los usuarios virtuales (de todos o solo de un grupo) para analizar de esa forma cómo serán los tiempos de respuesta de esos usuarios que se conectan por redes de menor velocidad (3G, en zonas alejadas, a través de internet, etc.). Para esto se suelen usar speed simulators o traffic shapers, aunque algunas herramientas traen esta funcionalidad incorporada también.

• Peak test (pruebas de picos): El objetivo es analizar el comportamiento del sistema cuando este es expuesto a picos de intensidad mezclados con carga normal, viendo cómo se recompone luego de esa carga mayor. Este tipo de situaciones se dan en la realidad, por lo cual también es interesante analizar cómo se comporta el sistema ante estas situaciones.

• Scalability test (pruebas de escalabilidad): El objetivo es analizar cómo escala nuestro sistema. Por ejemplo, ver cuántos usuarios más podemos soportar si agregamos otro servidor de aplicaciones, o cuánto mejoran los tiempos si agregamos más CPU al servidor de base de datos. 

Conclusión: Este tipo de avisos son los que me hacen ver que el área de reclutamiento de rrhh no siempre la tienen del todo claro cuando publican una búsqueda laboral para nuestra área. No obstante, a grandes rasgos han definido bien el perfil del candidato que están buscando, salvo los aspectos destacados aquí.

Búsqueda 2: Analista QA

Experiencia mínima de 3 años desarrollándose como analista de testing.

Conocimientos y habilidades excluyentes:

• Issue-tracker
• Manejo de bases de datos (Toad, SQL, Oracle)
• Conocimientos básicos en html, css, php y javascript
• Experiencia en el testing de aplicaciones web
• Experiencia en testing de caja blanca
• Metodologías ágiles
• Muy buenas habilidades de trabajo en equipo, participativos y colaborativos

Conocimientos Deseables

• Repositorio de control de versionado (SVN, CVS)
• Enterprise Architect, RSA, Erwin o similares
• Experiencia práctica en automatización de pruebas (programación de scripts)

Análisis: En este caso, el perfil que buscan es netamente técnico ya que pretenden que ejecute testing de caja blanca. Sólo para repasar el alcance de esta técnica, el postulante debería confirmar hasta dónde pretenden que llegue, por ejemplo:

Dentro de las dinámicas:

• Pruebas de sentencia y cobertura.
• Pruebas de decisión y cobertura.
• Pruebas de condición y cobertura.
• Pruebas de cobertura de camino.
• SYLSC, secuencia lineal y salto de código
• Basadas en el flujo de datos

Dentro de las estáticas:

• Revisiones / Revisiones guiadas (walkthroughs)
• Análisis del flujo de control
• Análisis del flujo de datos
• Métricas compilador/analizador

Conclusión: Considerando lo analizado más los conocimientos deseables (Repositorios, EA, automatización, entre otros) el perfil que están buscando es «todo terreno» y el título de la búsqueda debería ser más claro.

Búsqueda 3: Analista Tester

Nos enfocamos en postulantes que sean estudiantes universitarios, de carreras tales como Ingeniería en sistemas y afines, que posean experiencia previa en posiciones similares.

Participará de las siguientes tareas:

• Definición de escenarios de pruebas, los cuales definen los circuitos de negocio y permiten validar la integración de las funciones propias de la aplicación.
• Ejecución de casos acorde a la complejidad de las soluciónes y sus interfaces según corresponda.
• Ejecución del Smoke Test y pruebas de integración
• Reporte de defectos y su seguimiento (JIRA entre otros).
• Ejecución de las Pruebas de Aceptación del Usuario (UAT’s) acorde a los objetivos establecidos.
• Generación de métricas de producto.
• Participación en las estimaciones de testing según corresponda.

Conocimientos Necesarios:

• Armado de Casos de Testing; Tecnicas de testing.
• Herramientas de Issue-Tracker.
• Modelado de Casos de Uso para la interacción con el área de Análisis Funcional.
• Conocimiento en herramientas de Seguimiento de Defectos.
• Conocimiento en herramientas de gestión documental y de gestión de configuraciones.
• Conocimiento plataforma Linux, Windows.
• Conocimiento consultas SQL.

Conocimientos deseable:

• Verificación y Validación del producto acorde a los procedimientos establecidos (practicas VAL&VER de CMMI).
• Base de datos PostgreSQL.

Análisis: Se define muy bien el alcance que pretenden del puesto, e incluso -algo que no es muy habitual- hacen énfasis en su participación para las estimaciones, tema que por lo general es motivo de varias discusiones ya que en muchas áreas no las manejan los testers sino que lo hacen miembros del área de desarrollo o responsables del proyecto. Otro tema también para destacar es que deberán participar en el entendimiento del modelado de casos de uso, área de conocimiento que también muchas veces se omite y todos sabemos lo importante que es. Algo que tal vez merece una cierta aclaración es el tema del UAT, donde el Tester no debería participar de manera activa sino pasiva, acompañando al usuario final, aunque a veces -y lo reconozco- hay proyectos en donde la participación del testers es mucho más que pasiva, ¿no es cierto?. Finalmente, un tema para tratar y no menor es el conocimiento deseable que buscan en cuanto a las prácticas VAL&VER de CMMi. En principio, la CMMi no nos rige, si vamos a hablar de estándares, sino que debemos seguir la guía de la TMMi, pero reconozco que la mayoría de las empresas no tiene conocimiento de este punto y somos nosotros quienes debemos difundirlo y llevarlo a la práctica. Ahora bien, para estar alineados con lo que requiere esta empresa, debemos pensar que el Modelo de Madurez de la Capacidad Integrado (Capability Maturity Model for Integration) es un modelo de procesos que contiene las mejores prácticas de la industria para el desarrollo, mantenimiento, adquisición y operación de productos y servicios. Que son prácticas que se aplican en todas las fases del desarrollo del producto utilizando las diferentes perspectivas que se van obteniendo del producto final, y que debemos entender las siguientes líneas:

Estrategia de validación

• SG1 La preparación para la validación es llevada a cabo.
• SP1.1 Seleccionar los productos y los componentes de producto a validar y los métodos de validación que serán usados.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la validación.
• SP1.3 Establecer y mantener procedimientos y criterios de validación

Ejecutar las validaciones

• SG2 El producto o los componentes de producto son validados para asegurar que sean adecuados para usar en su entorno operacional previsto.
• SP2.1 Realizar la validación sobre productos y componentes de producto seleccionados.
• SP2.2 Analizar resultados de las actividades de validación.

Conclusión: Me parece que si bien se entiende mucho del alcance que se pretende de la posición, hay algunos aspectos que el postulante lo debería tener en cuenta a la hora de la entrevista con el área técnica ya que los estándares que nos gobiernan no son precisamente los de la CMMi sino los de la TMMi, pero bue, es una cuestión cultural y mucho para recorrer.

Búsqueda 4: Analista de QA y Procesos

Conocimientos / Experiencia Requerida.

• Sólida experiencia en la implementación de las diferentes Process Areas del Modelo
• Sólidos conocimientos en diseño e implantación de Sistemas de Gestión de Calidad / Mejora de procesos de software (Experiencia mínima requerida: 4 años en implantación de Sistemas de Calidad)
• Experiencia en conducción y coordinación de Auditorías de Calidad.
• Dominio de las metodologías de desarrollo de proyectos
• Conocimiento de las herramientas necesarias para la gestión de calidad.
• Conocimientos Mediciones y Métricas

Conclusiones: no hace falta analizar la búsqueda y entender que el alcance que le fijan al puesto corresponde con el término original de QA (Aseguramiento de la calidad), y hago esta mención porque en muchas búsquedas (como las anteriores que hemos visto) proponen una posición de Analista de QA ó QA Manual, cuando en realidad están buscando un profesional del Testing, es decir, que controle la calidad del software. Es muy sutil la diferencia pero que sin embargo aún hoy, muchas áreas de reclutamiento no la conocen y lo peor del caso, las áreas técnicas no le explican las diferencias.

En fin, seguiremos en tema y gracias por leerme hasta aquí.
Gustavo
gustavo@testingbaires.com