introducción
Hola, usuarios de Habr. Recientemente completé una prueba para un puesto de líder de control de calidad en una empresa fintech. La primera tarea, crear un plan de pruebas con una lista de verificación completa y ejemplos de casos de prueba para probar un hervidor eléctrico, fue muy fácil de resolver:
Es difícil elaborar un plan de pruebas mejor con una lista de verificación completa.
La segunda parte, sin embargo, resultó ser una pregunta: "¿Existen problemas comunes a todos los evaluadores que les impidan trabajar de manera más eficaz?"
Lo primero que pensé fue hacer una lista de todos los problemas, más o menos evidentes, que encontré durante las pruebas, descartar los triviales y generalizar el resto. Pero enseguida me di cuenta de que el método inductivo respondería a una pregunta que no se aplica a «todos», sino, en el mejor de los casos, solo a «la mayoría» de los evaluadores. Así que decidí abordarla desde una perspectiva diferente, deductiva, y esto es lo que se me ocurrió.
definir
Lo primero que suelo hacer al resolver un problema nuevo es intentar comprender de qué se trata, y para ello, necesito entender el significado de las palabras utilizadas. Las palabras clave para comprender son:
- problema
- ensayador
- trabajo de probador
- rendimiento del probador
Recurramos a Wikipedia y al sentido común:
(Griego antiguo: πρόβλημα) En un sentido amplio, se refiere a una cuestión compleja, teórica o práctica, que requiere estudio y solución. En ciencia, es una situación contradictoria que se presenta como posturas opuestas en la explicación de ciertos fenómenos, objetos o procesos, y que exige una teoría adecuada para su resolución. En la vida cotidiana, un problema se formula de manera comprensible: «Sé qué, pero no sé cómo», es decir, se sabe qué se necesita lograr, pero no se sabe cómo hacerlo. Proviene del latín tardío problēma, del griego πρόβλημα, que significa «arrojado hacia adelante, colocado delante»; de προβάλλω, que significa «arrojar hacia adelante, poner delante de uno mismo; acusar».
No tiene mucho sentido, esencialmente “problema” = “cualquier cosa que necesite ser atendida”.
— un especialista (no haremos distinción entre tipos, ya que nos interesan todos los evaluadores) que participa en las pruebas de un componente o sistema, cuyo resultado de trabajo es:
— un conjunto de actividades relacionadas con las pruebas.
(Latín: effectivus) - la relación entre el resultado obtenido y los recursos utilizados (: 2015).
— La consecuencia (resultado) de una cadena (secuencia) de acciones o eventos, expresada cualitativa o cuantitativamente. Los posibles resultados incluyen ventaja, desventaja, ganancia, pérdida, valor y victoria.
Al igual que con el “problema”, hay poco significado: algo que resultó del trabajo.
— una capacidad cuantitativamente medida para realizar cualquier actividad por parte de una o varias personas; condiciones que permiten alcanzar el resultado deseado mediante ciertas transformaciones. Un evaluador es un ser humano y, según la teoría de los recursos vitales, cada persona posee cuatro activos económicos:
El efectivo (ingresos) es un recurso renovable;
La energía (fuerza vital) es un recurso parcialmente renovable;
El tiempo es un recurso fijo y fundamentalmente no renovable;
El conocimiento (la información) es un recurso renovable; forma parte del capital humano y puede tanto crecer como destruirse..
Me gustaría señalar que la definición de eficiencia en nuestro caso no es del todo precisa, ya que cuanto más conocimiento utilizamos, menor es la eficiencia. Por lo tanto, redefiniría la eficiencia como «la relación entre el resultado obtenido y los recursos empleados». De esta forma, todo sería correcto: el conocimiento no se desperdicia durante el trabajo, sino que reduce el gasto del único recurso fundamentalmente no renovable del evaluador: su tiempo.
Solución
Así pues, buscamos problemas globales de los evaluadores que reduzcan la eficiencia de su trabajo.
El recurso más significativo que se invierte en el trabajo de un tester es su tiempo (otros recursos pueden atribuirse a él de una u otra forma), y para hablar de un cálculo correcto de la eficiencia, el resultado también debe estar relacionado con el tiempo.
Para ello, consideremos un sistema cuya viabilidad está garantizada por el trabajo del tester. Dicho sistema es un proyecto cuyo equipo incluye un tester. El ciclo de vida del proyecto puede representarse, a grandes rasgos, mediante el siguiente algoritmo:
- Trabajar con requisitos
- Elaboración de especificaciones técnicas
- Desarrollo
- pruebas
- Lanzamiento a producción
- Soporte (ir a la pág. 1)
En este caso, todo el proyecto se puede dividir recursivamente en subproyectos (funcionalidades), con el mismo ciclo de vida.
Desde la perspectiva del proyecto, cuanto menos tiempo se dedique a él, mayor será su eficacia.
Así, llegamos a una definición de la máxima eficiencia posible del tester desde la perspectiva del proyecto: este 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 este tiempo.
¿Cómo lidiar con esto?
Las conclusiones son bastante obvias y han sido utilizadas por muchos durante mucho tiempo:
- El desarrollo y las pruebas deben comenzar y terminar casi simultáneamente (esto lo suele hacer el departamento). La opción ideal es cuando toda la funcionalidad que se está desarrollando ya está cubierta por pruebas automatizadas cuando está lista, organizadas en pruebas de regresión (y, si es posible, pruebas previas a la confirmación) utilizando algún tipo de .
- Cuantas más funcionalidades tenga un proyecto (y, por lo tanto, cuanto más complejo sea), más tiempo habrá que dedicar a comprobar que las nuevas funcionalidades no interfieran con las existentes. Por consiguiente, cuanto más complejo sea el proyecto, mayor será la automatización necesaria. .
- Cada vez que un error llega a producción y un usuario lo encuentra, debemos invertir tiempo adicional revisando el ciclo de vida del proyecto desde el paso 1 (trabajando con los requisitos, en este caso, los requisitos del usuario). Dado que generalmente se desconocen las razones por las que un error pasa desapercibido, solo tenemos una opción de optimización: incluir cada error encontrado por los usuarios en las pruebas de regresión para garantizar que no vuelva a aparecer.
Fuente: habr.com
