Introducción
Buen día, habitantes de Habr. Estuve resolviendo una tarea de prueba para una vacante de QA Lead en una empresa fintech. La primera tarea, elaborar un plan de pruebas con una lista de verificación completa y ejemplos de casos de prueba para verificar una tetera eléctrica, se resuelve de manera trivial:
Es difícil pensar en un mejor plan de pruebas con una lista de verificación completa.
Pero la segunda parte resultó ser una cuestión: "¿Existen problemas comunes para todos los probadores que dificultan trabajar con mayor eficacia?".
Lo primero que se me ocurrió fue enumerar todos los problemas más o menos notables que había encontrado durante las pruebas, filtrar lo trivial y generalizar el resto. Pero rápidamente comprendí que el método inductivo respondería a una pregunta que se refiere no a "todos", sino, en el mejor de los casos, solo a "la mayoría" de los probadores. Así que decidí abordar la cuestión desde otro ángulo, el deductivo, y esto es lo que obtuve.
Definiciones
Lo primero que suelo hacer al enfrentar una nueva tarea es intentar entender de qué se trata en general, y para ello es necesario comprender el significado de las palabras con las que se formula. Las palabras clave en las que hay que profundizar son las siguientes:
- el problema
- probador
- trabajo del probador
- eficacia del trabajo del probador
Consultemos a Wikipedia y al sentido común:
(del griego antiguo πρόβλημα) en un sentido amplio — cuestión teórica o práctica compleja que requiere estudio y resolución; en ciencia — situación contradictoria que se presenta en forma de posiciones opuestas en la explicación de ciertos fenómenos, objetos, procesos y que requiere una teoría adecuada para su resolución; en la vida, el problema se formula de una manera comprensible para las personas como "sé qué, no sé cómo", es decir, se sabe qué se necesita obtener, pero no se sabe cómo hacerlo. Proviene del latín tardío problēma, del griego πρόβλημα "algo lanzado hacia adelante, puesto adelante"; de προβάλλω "lanzar hacia adelante, presentar ante sí; acusar".
No hay mucho sentido, en esencia, “problema” = “cualquier cosa con la que hay que lidiar”.
— especialista (no vamos a dividir por tipos, ya que nos interesan todos los testers), que participa en la prueba de un componente o sistema, cuyo resultado de actividad es:
— un conjunto de actividades relacionadas con la prueba.
(del lat. effectivus) — la relación entre el resultado alcanzado y los recursos utilizados (:2015).
— consecuencia de una cadena (serie) de acciones (resultado) o eventos, expresados cualitativa o cuantitativamente. Los resultados posibles incluyen ventaja, inconveniente, beneficio, pérdida, valor y victoria.
Como con el 'problema', el significado es escaso: algo que se logró al final del trabajo.
— capacidad cuantitativamente medible para realizar alguna actividad por parte de un individuo o personas; condiciones que permiten, mediante determinadas transformaciones, obtener el resultado deseado. Un tester es una persona, y de acuerdo con la teoría de los recursos vitales, cada persona posee cuatro activos económicos:
fondos (ingreso) — recurso renovable;
energía (vitalidad) — recurso parcialmente renovable;
tiempo — recurso fijo y fundamentalmente no renovable;
conocimientos (información) — recurso renovable, es parte del capital humano, que puede aumentar y disminuir..
Quiero señalar que la definición de efectividad en nuestro caso no es del todo correcta, ya que cuanto más conocimientos utilizamos, menor es la efectividad. Por lo tanto, redefiniría la efectividad como 'la relación entre el resultado alcanzado y los recursos gastados'. Así, todo queda correcto: los conocimientos en el trabajo no se gastan, sino que reducen el gasto del único recurso fundamentalmente no renovable del tester — su tiempo.
Solución
Así que busquemos los problemas globales de los testers que afectan la efectividad de su trabajo.
El recurso más significativo que se gasta en el trabajo de un tester es su tiempo (los demás pueden de alguna manera vincularse a él), y para que podamos hablar de un cálculo correcto de la efectividad, es necesario también llevar el resultado al tiempo.
Para ello, consideremos un sistema cuya viabilidad es garantizada por el trabajo del tester. Tal sistema es un proyecto que incluye a un tester en su equipo. El ciclo de vida del proyecto se puede representar de manera general con el siguiente algoritmo:
- Trabajo con los requisitos
- Formulación del pliego de condiciones
- Desarrollo
- Pruebas
- Lanzamiento en producción
- Soporte (volver al p.1)
A su vez, todo el proyecto se puede descomponer recursivamente en subproyectos (características) que tienen el mismo ciclo de vida.
Desde el punto de vista del proyecto, la eficacia de su implementación es mayor cuanto menos tiempo se dedique a ella.
Así, llegamos a la definición de la máxima eficacia posible del tester desde la perspectiva del proyecto: es el estado del proyecto en el que el tiempo dedicado a las pruebas es cero. Y el problema común para todos los testers es la imposibilidad de alcanzar ese tiempo.
¿Qué hacer al respecto?
Las conclusiones son bastante evidentes y por muchos utilizadas desde hace tiempo:
- El desarrollo y las pruebas deben comenzar y terminar prácticamente al mismo tiempo (esto suele ser responsabilidad del departamento de ). La opción ideal es que toda la funcionalidad que se está desarrollando esté cubierta por pruebas automatizadas al momento de estar lista, organizadas en pruebas de regresión (y, si es posible, también de pre-commit) utilizando alguna .
- Cuantas más características tenga el proyecto (cuanto más complejo sea), más tiempo se necesitará para verificar que la nueva funcionalidad no rompa la anterior. De aquí que cuanto más complicado sea el proyecto, más automatización se requiere para .
- Cada vez que dejamos pasar un error en producción y un usuario lo encuentra, debemos gastar tiempo adicional siguiendo el ciclo de vida del proyecto comenzando desde el p.1 (Trabajo con los requisitos, en este caso, de los usuarios). Dado que las razones de pasar un error son generalmente desconocidas, solo nos queda un camino para la optimización: cada error encontrado por los usuarios debe ser incluido en las pruebas de regresión para asegurar que no vuelva a aparecer.
Fuente: habr.com
