Lenguaje de IT entre los testers

En IT, la gente a menudo habla una mezcla de idiomas. Cuando comencé a trabajar en una empresa de IT, raramente comprendía los diálogos de mis colegas. Para ese entonces, ya era buena en pruebas, pero no estaba acostumbrada a comunicarme en la mezcla de inglés, ruso y IT. Fue muy difícil y frustrante. Entendiendo este “dolor”, quiero compartir un conjunto de palabras y expresiones que te ayudarán a estar en la misma sintonía que tus colegas experimentados.

Cómo se comunica un tester

Una palabra que todo tester conoce es bug

Un bug es una inconsistencia entre el comportamiento de una aplicación y los requerimientos del cliente. También podemos decir que es un comportamiento inesperado e indeseable de una aplicación o un programa.

Además de bugs, los testers a menudo llaman la atención del equipo sobre los implements, sugerencias para mejorar un sitio o un programa.

Encontrar bugs es una de las principales tareas de un tester. La tarea principal y responsabilidad del QA, sin embargo, es asegurar la calidad de la aplicación en su totalidad. Para hacer esto, los testers no solo buscan bugs, sino también los previenen, inventan escenarios de prueba, crean datos de prueba, escriben documentación de prueba y automatizan el proceso de verificar regularmente las funciones principales de la aplicación. Si el tester es un profesional, el usuario no se encontrará con un crash, no se encontrará con botones impredecibles y seguramente regresará al sitio.

Todos los días se espera que tengas meetings, calls, syncs y dailies

• Una meeting es una reunión de trabajo. Normalmente se programan con anticipación y se agendan en el calendario. Puedes recibir una invitación a una meeting o puedes compartir un enlace a una meeting con un colega.

• Una call (“llamada”) se refiere a la comunicación telefónica o de video con uno o más colegas. A menudo, puedes escuchar: “disculpa, tengo una call urgente, tengo que atender esto”.

• Sync es la abreviatura de synchronization (“sincronización”). Es lo mismo que una reunión o llamada. Es común decir: “Vamos a sincronizar sobre esto por separado”. Lo que significa “vamos a sincronizar nuestros conocimientos y entendimiento sobre este asunto”.

• Daily (abreviatura de daily meeting “reunión diaria”) se refiere a una reunión de equipo diaria. Usualmente se lleva a cabo por la mañana, pero esto puede variar.

En las reuniones debatirás sobre el board, los tickets y los updates

• Un board es un tablero de trabajo o un espacio de trabajo para cada miembro del equipo individualmente y para el equipo en su conjunto. La mayoría de las veces, se usa la aplicación Jira para hacer un seguimiento del trabajo diario. Dependiendo del proyecto, se puede usar un tablero Scrum o un tablero Kanban. En cualquier caso, el board parece un conjunto de tareas, responsabilidades y estatus.

• Un ticket es simplemente una tarea, expresada en forma escrita. Los tickets parecen pegatinas en el board. Pueden contener una tarea muy grande (epic) o una tarea más pequeña (story), o incluso una tarea aún más pequeña. También pueden contener una descripción de un bug. Los tickets más importantes para ti son aquellos que tienen el estatus RFQA (Ready for QA).

• Un update es una actualización; desarrollos recientes. Compartir updates significa “compartir las noticias o el estatus de una tarea”.

“Verificar un ticket” significa verificarlo y asegurarse de que todo funcione como se espera

Si, por ejemplo, has verificado el ticket de un bug y todo funciona como debería, entonces el bug está resuelto. Si, después de la verificación, ves que el bug sigue ahí, puedes reabrir el ticket y devolverlo al desarrollador para que siga trabajando.

A veces, es imposible verificar el ticket de un bug porque, por ejemplo, no tienes derechos de acceso al entorno de prueba o no tienes el dispositivo adecuado para las pruebas. Si algo te impide verificar el ticket, puedes bloquearlo (cambiar el estatus del ticket a Bloqueado) hasta que se resuelva el problema.

A veces, evaluamos una story interesante. Inventamos un escenario exótico en el que la aplicación se comporta mal (hay bugs o aparecen algunas advertencias inapropiadas). El tester puede pensar que esto es terrible y que es urgente arreglar el problema, pero el analista de negocios (BA) o el product manager (PM) puede decir: “No es gran cosa, este es un caso normal; ponlo en el backlog por ahora”. ¿Qué-qué?! ¿Ponerlo dónde?! En realidad, el colega puede estar diciendo: “Este escenario es raro. El usuario probablemente no se encontrará con este bug. Puedes dejarlo de lado por ahora y ponerlo en el archivo de bugs y tareas pendientes para ver más tarde”.

¿Bug o feature?

A menudo hay un debate entre el desarrollador y el tester sobre si algo es un bug o una feature. Si te encuentras, por ejemplo, con un comportamiento inesperado de una aplicación, puedes considerarlo un bug. Pero el desarrollador puede argumentar que todo está funcionando como se esperaba. Si este es el caso, los criterios de aceptación de la respectiva story deberían usarse para resolver la discusión. Los acceptance criteria (“Criterios de aceptación”) es un conjunto de requisitos desarrollados por un BA. Una feature de una aplicación es una opción que se implementa específicamente (no es un bug).

Cuando se termina una nueva feature (se escribe el código, se prueba), se dice que la feature está implementada.

¿Cómo saberlo todo?

En el curso de su trabajo, los testers utilizan diferentes tipos, métodos, niveles y técnicas de prueba. Dependiendo del proyecto y las tareas actuales, puedes probar la localización, la compatibilidad, la accesibilidad, etc. Puede que tengas que hacer manualmente una regresión o unn smoke test después del lanzamiento. Todas estas palabras deberían ser definitivamente parte de tu léxico profesional. Sugiero estudiar materiales y cursos especializados y dominar estos conceptos por tu cuenta. Te serán útiles en una entrevista de trabajo.