Este post está motivado por el curso de introducción al testing que preparamos con Gabriela para Abstracta Academy.

Uno de los momentos más estresantes, y al mismo tiempo jugados, que deberás enfrentar para poder entrar en el mundo del testing, es la entrevista de trabajo. Allí te juegas todo o nada. Lo mejor es que estés preparado para cuando te llegue el momento, y así tendrás más oportunidades de comenzar tu carrera como software tester.

Existen algunas preguntas típicas, que son clave y que deberías poder responder sin mayores problemas. A continuación seleccioné las 7 preguntas que consideré que deberías saber responder sí o sí y sin titubear cuando te presentas a un puesto para Software Tester (junior).

1 – ¿Cómo harías para probar una aplicación completamente nueva en un tiempo muy corto?

Aplicación que no conozco y poco tiempo, son las dos características claves donde mejor se aplica el testing exploratorio. Puedes comenzar realizando testing exploratorio para familiarizarte con la aplicación a medida que vas realizando el inventario de pruebas (ya sea en un mind-map o en una simple tabla o lista). Una vez que tienes el inventario de pruebas, debes priorizarlo. Para hacerlo, puedes considerar la criticidad y complejidad y luego en función de ambos establecer la prioridad.

Algo clave en este proceso es que por más que haya poco tiempo es vital dar buena información, ya que es lo más importante del testing: brindar información sobre la calidad del producto a quien la necesita. Entonces, el uso de un mind-map es una muy buena estrategia para luego poder dar un indicativo de la cobertura alcanzada con las pruebas.

2 – ¿Cuándo dejarías de probar?

Es importante no sólo saber priorizar adecuadamente las pruebas, para comenzar siempre por lo más importante, sino también tener claro cuándo deberíamos dejar de probar. Es posible que al comenzar nos hayamos puesto la meta de alcanzar cierta cobertura y una vez logrado este tenemos un criterio para deternos. Ten cuidado de tener bien claro el concepto de cobertura.

Lo que siempre tienes que tener claro es: “si el costo de probar supera el beneficio de encontrar defectos, nos urge dejar de probar”.

3 – ¿Cómo probarías de manera exhaustiva una aplicación?

Esta es una pregunta capciosa, ya que una de las limitantes más conocidas del testing es “no es posible que pruebes una aplicación de manera exhaustiva”. Probar exhaustivamente resulta sumamente costoso cuando no es además una tarea imposible de realizar. Si te pones a pensar la cantidad de pruebas que deberías realizar para probar exhaustivamente algo tan simple como la suma de dos números, llegarías a la conclusión que ¡necesitarías varias vidas para poder realizar las pruebas!

La respuesta entonces debería dejar claro que el tester inteligente no es aquel que quiere probar todo, sino aquel que quiere probar lo que realmente le aporte valor al producto que se está desarrollando.

4 – ¿Qué elementos son indispensables para describir un bug?

Un bug (o incidente, error, falla, o como quieras referirte a ellos) deben ser gestionados para poder resolverlos. Esto es, el software tester debe reportarlos en un sistema fiable, como para mantener el estado de cada uno y poder mantener un flujo de trabajo junto al desarrollador, de forma tal que éstos puedan ser resueltos antes de entregar el software a los usuarios.

Para que el trabajo del software tester sea efectivo, hay ciertos elementos que son indispensables a la hora de reportar y describir un bug.

Algunos elementos que deberías incluir en tu respuesta:

• Un identificador, ya sea numérico o no, pero que sea único. Por lo general las herramientas de gestión de incidentes se encargan de proporcionar estos identificadores, pero es importante que lo menciones también.
• El título es fundamental, debe ser lo suficientemente descriptivo. Piensa que algunas personas, como gerentes por ejemplo, sea quizás lo único que lean. También es fundamental para evitar reportes duplicados.
• Una buena descripción incluyendo los pasos a seguir para reproducirlo es básico. Recuerda, antes de salvar,  seguir los pasos que escribiste y así validar que no te has olvidado de nada.
• Debes incluir además, resultados esperados y resultados obtenidos, reproducibilidad (si sucede a veces, siempre, etc.) y la versión del software en la cual lo detectaste.

5 – ¿Qué elementos tiene un caso de prueba?

La forma en la que siempre explico la utilidad de escribir un caso de prueba y cómo saber si está completo y bien detallado es pensar en la situación (quizá absurda) de que le pedimos a alguien que va pasando por el pasillo que se detenga un segundo, se siente en nuestra computadora y ejecute el caso de prueba que tenemos documentado. Si es capaz de ejecutarlo y determinar si la aplicación funciona adecuadamente o no, entonces el caso de prueba está completo. Si no, algo nos está faltando.

En base a ese razonamiento podrías llegar a que lo mínimo que debes especificar es:

• El título, que debe ser descriptivo, y diferenciarlo de cualquier otro caso de prueba.
• Debes incluir precondiciones y poscondiciones de ejecución (por ejemplo, si es necesario que exista determinado dato o archivo, o que cierto servicio esté disponible).
• Es fundamental contar con la lista de pasos a seguir para poder ejecutar el caso de prueba, y para cada uno detallar los datos de prueba y los resultados esperados.
• Luego podrías agregar otra información como ser prioridad, información del ambiente sobre el que se debe ejecutar, etc.

Un caso de prueba completo podría contener más elementos, pero esta lista contiene los básicos y más importantes.

6 – ¿Cuál es la diferencia entre validación y verificación?

Si bien la diferencia para algunos es algo sutil, yo creo que no es menor. Al fin de cuentas un software tester debe realizar ambas acciones, pero es importante saber cuál es cuál.

Verificar: Consiste en comprobar la implementación de los requerimientos. Esto implica aportar evidencia objetiva de que un elemento satisface los requisitos especificados Tendrías que preguntarte lo siguiente: “¿Estamos construyendo el producto correctamente?”.

Validar: Implica comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construyó el producto. O sea, verificar que los requisitos especificados son adecuados para un uso previsto. La pregunta que te tendrías que hacer en este caso sería: “¿Estamos construyendo el producto correcto?”.

7 – ¿Cómo probarías X?

Esta quizá es una de las preguntas que encuentro más divertidas y desestructuradas, pero al mismo tiempo de las más típicas, ya que revelan mucha información sobre nuestro potencial como software testers; es la de plantear la prueba de otro tipo de objetos, no necesariamente software ni tecnología. Aquí las más comunes:

• ¿Cómo probarías una máquina de café? (ésta por excelencia es la más popular)
• ¿Cómo probarías una botella de agua?
• ¿Cómo probarías un microondas?
• ¿Cómo probarías un bolígrafo?
• ¿Cómo probarías una pelota de fútbol?

Si bien está en inglés, te recomiendo le des una leída a la metodología planteada en el sitio Software Testing Tricks (www.softwaretestingtricks.com). Ahí proponen algunos ejemplos de ideas de prueba para distintos productos como los planteados en las preguntas, donde lo más importante es la metodología descrita, ya que te servirá para cualquier tipo de objeto.

Los pasos para elaborar las ideas de prueba son los siguientes:

1. Primero debes hacerte preguntas sobre el producto que quieres probar, lo que te va a permitir familiarizarte con el mismo.
2. Luego debes enumerar todas las ideas de prueba que se te ocurran. La idea es hacer una tormenta de ideas y anotar todo lo que surja en un lapso aproximado de 15 minutos.

Para bajar a tierra esto un poco más, te planteo un ejemplo: piensa la situación de que eres un carpintero, y alguien te contrata para que le hagas un escritorio, ¿cómo probarías ese escritorio antes de dárselo al cliente? Siguiendo los pasos descritos, llegarías a plantearte las siguientes preguntas:

• ¿Quién va a utilizar el escritorio? ¿Un adulto? ¿Un niño? Dependiendo de quién lo use podría estar variando las dimensiones del mismo, el color o los colores, quizás para un niño sea mucho más atractivo si lo pinta de colores.
• ¿Para qué lo va a utilizar? Si solo lo utiliza una vez al día o si va a estar todos los días durante muchas horas podría variar la elección de distintos atributos que afecten la ergonomía del usuario.
• ¿Lo va a utilizar una sola persona o varias? Si solo lo va a utilizar un usuario podría hacerse a su medida, si lo van a utilizar distintas personas, lo más apropiado sería recurrir a dimensiones estándares.

Más preguntas:

• ¿De qué espacio dispone para ubicar al mismo?
• ¿Necesita cajones? ¿Cuántos? ¿De qué medidas? ¿Deben tener rieles para que puedan abrirse con mayor facilidad?

Seguro que a tí se te ocurren más preguntas.

Entonces, a partir de estas preguntas y de este esquema mental, podrías llegar a las siguientes pruebas:

• Verificar que soporta el peso al que va a estar sometido.
• Verificar si es posible abrir los cajones con facilidad.
• Verificar si las dimensiones del escritorio resultan adecuadas para los distintos usos posibles: colocar una computadora, escribir leyendo de un libro, etc.
• Si lo va a utilizar más de una persona, verificar que ambas personas puedan sentarse y usar el mismo cómodamente.
• Verificar si la altura del mismo resulta cómoda luego de una jornada de 8hs.

En el caso de la máquina de café automática (la que uno le ingresa monedas o fichas, selecciona el café, y lo sirve automáticamente), creo que ahí es donde pueden entrar en juego otros tipos de cosas, especialmente algo conocido como “testing negativo”. Esta técnica básicamente lo que plantea es de atacar al software con entradas inválidas. ¿Qué sucede si inserto una ficha cuando está sirviendo café? ¿qué sucede si se queda sin vasos, o sin azúcar? En el caso del escritorio, podríamos considerar como testing negativo algunas situaciones extremas, como ¿qué sucede si acercan el escritorio al fuego? o ¿qué sucede si apoyan una caja de 100 kg sobre el escritorio?

Creo que podríamos seguir ideando situaciones interesantes a probar, y eso es lo que debes demostrar. O sea, debes demostrar que tienes la suficiente flexibilidad mental como para adaptar tus técnicas de prueba a contextos inesperados. Además, mientras más ideas plantees, más estarás demostrando tu creatividad y tu curiosidad. Si todo lo haces con foco en el posible usuario o cliente del objeto, entonces estarás demostrando empatía. Todas estas características son las que buscan ser evaluadas con este tipo de preguntas.

Conclusiones para todo el que quiera convertirse en un software tester

Si bien son muchas las preguntas que podrían llegar a realizarte en una entrevista, existen algunos conceptos claves que deberías demostrar que conoces y dominas perfectamente. Repasa los conceptos principales y también recuerda que hay muchas aptitudes que a veces son más valoradas incluso que los conocimientos técnicos, como la curiosidad, la proactividad y el poder de observación.

¿Qué otras preguntas interesantes te han hecho en este tipo de entrevistas?

Photo credit: Chop_Suey_Stuey via VisualHunt.com / CC BY-NC-ND