introducción
Buenas tardes, residentes de Khabrovsk. Justo ahora estaba resolviendo una tarea de prueba para una vacante de líder de control de calidad para una empresa fintech. La primera tarea, crear un plan de prueba con una lista de verificación completa y ejemplos de casos de prueba para probar un hervidor eléctrico, se puede resolver de manera trivial:
Es difícil pensar en un mejor plan de prueba con una lista de verificación completa.
Pero la segunda parte resultó ser una pregunta: "¿Hay algún problema común a todos los evaluadores que les impida trabajar de manera más eficiente?"
Lo primero que me vino a la mente fue enumerar todos los problemas más o menos notables que encontré durante las pruebas, eliminar las pequeñas cosas y resumir el resto. Pero rápidamente me di cuenta de que el método inductivo respondería a una pregunta que no se aplicaba a “todos”, sino, en el mejor de los casos, sólo a “la mayoría” de los evaluadores. Por eso decidí abordarlo desde el otro lado, deductivamente, y esto es lo que sucedió.
definir
Lo primero que suelo hacer cuando resuelvo un nuevo problema es intentar entender de qué se trata, y para ello necesito entender el significado de las palabras que lo plantean. Las palabras claves a entender son las siguientes:
- problema
- ensayador
- trabajo de probador
- eficiencia del probador
Vayamos a Wikipedia y al sentido común:
(griego antiguo πρόβλημα) en un sentido amplio: una cuestión teórica o práctica compleja que requiere estudio y resolución; en ciencia: una situación contradictoria que aparece en forma de posiciones opuestas en la explicación de cualquier fenómeno, objeto, proceso y requiere una teoría adecuada para resolverlo; en la vida, el problema se formula de una forma comprensible para las personas: “Sé qué, no sé cómo”, es decir, se sabe lo que hay que obtener, pero no se sabe cómo hacerlo. . Viene de tarde. lat. problema, del griego. πρόβλημα “arrojado hacia adelante, colocado al frente”; de προβάλλω “tirar hacia adelante, poner delante de ti; culpa".
De hecho, no tiene mucho sentido “problema” = “cualquier cosa que deba solucionarse”.
- un especialista (no lo dividiremos en tipos, ya que nos interesan todos los probadores) que participa en las pruebas de un componente o sistema, cuyo resultado es:
— un conjunto de actividades relacionadas con las pruebas.
(lat. effectivus) - la relación entre el resultado obtenido y los recursos utilizados (: 2015).
- una consecuencia de una cadena (serie) de acciones (resultado) o eventos, expresada cualitativa o cuantitativamente. Los posibles resultados incluyen ventaja, desventaja, ganancia, pérdida, valor y victoria.
Al igual que con el “problema”, tiene poco significado: algo que surgió como resultado del trabajo.
- la posibilidad cuantitativamente mensurable de realizar cualquier actividad de una persona o personas; condiciones que permiten utilizar determinadas transformaciones para obtener el resultado deseado. El probador es una persona, y de acuerdo con la teoría de los recursos vitales, cada persona es propietaria de 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 (información) es un recurso renovable, es parte del capital humano que puede crecer y destruirse..
Me gustaría señalar que la definición de eficiencia en nuestro caso no es del todo correcta, ya que cuanto más conocimiento utilizamos, menor es la eficiencia. Por lo tanto, redefiniría la eficiencia como “la relación entre los resultados obtenidos y los recursos gastados”. Entonces todo es correcto: el conocimiento no se desperdicia durante el trabajo, pero reduce los costos del único recurso fundamentalmente no renovable del evaluador: su tiempo.
Solución
Por lo tanto, buscamos problemas globales de los evaluadores que afecten la efectividad de su trabajo.
El recurso más importante que se gasta en el trabajo de un tester es su tiempo (el resto se le puede reducir de una forma u otra), y para que podamos hablar del cálculo correcto de la eficiencia, el resultado también debe reducirse a tiempo. .
Para ello, consideremos un sistema cuya viabilidad el evaluador garantice mediante su trabajo. Un sistema de este tipo es un proyecto cuyo equipo incluye un probador. El ciclo de vida del proyecto se puede representar aproximadamente mediante el siguiente algoritmo:
- Trabajar con requisitos
- Formación de especificaciones técnicas.
- Desarrollo
- pruebas
- Lanzamiento a producción
- Soporte (ir al elemento 1)
En este caso, todo el proyecto se puede dividir de forma recursiva en subproyectos (características), con el mismo ciclo de vida.
Desde el punto de vista del proyecto, cuanto menos tiempo se dedique a él, más efectiva será su implementación.
Por lo tanto, llegamos a la definición de la máxima eficiencia posible de un probador desde el punto de vista del proyecto: este es el estado del proyecto cuando el tiempo para las pruebas es cero. Un problema común para todos los evaluadores es la imposibilidad de alcanzar este tiempo.
¿Cómo lidiar con esto?
Las conclusiones son bastante obvias y muchos las han utilizado durante mucho tiempo:
- El desarrollo y las pruebas deben comenzar y finalizar casi simultáneamente (esto generalmente lo hace el departamento ). La opción ideal es cuando toda la funcionalidad que se está desarrollando ya esté cubierta por pruebas automáticas cuando esté lista, organizada en pruebas de regresión (y, si es posible, de confirmación previa) utilizando algún tipo de .
- Cuantas más características tenga un proyecto (cuanto más complejo sea), más tiempo habrá que dedicar a comprobar que la nueva funcionalidad no interrumpe la anterior. Por lo tanto, cuanto más complejo sea el proyecto, más automatización se requerirá. .
- Cada vez que pasamos por alto un error en producción y un usuario lo encuentra, tenemos que dedicar tiempo adicional a recorrer el ciclo de vida del proyecto comenzando desde el punto 1 (Trabajar con los requisitos, en este caso, los usuarios). Dado que las razones por las que se pasa por alto un error generalmente se desconocen, solo nos queda una ruta de optimización: cada error encontrado por los usuarios debe incluirse en las pruebas de regresión para estar seguros de que no volverá a aparecer.
Fuente: habr.com