Introduccion
Buenas tardes, residentes de Khabrovsk. Aquí estaba resolviendo una tarea de prueba para la vacante de QA Lead para una empresa fintech. La primera tarea, elaborar un plan de prueba con una lista de verificación completa y ejemplos de casos de prueba para verificar una tetera eléctrica, se resuelve trivialmente:
Pero la segunda parte resultó ser una pregunta: "¿Hay algún problema común a todos los evaluadores que interfieran con el trabajo con mayor eficiencia?".
Lo primero que me vino a la mente: para enumerar todos los problemas más o menos notables que encontré durante las pruebas, eliminar las cosas pequeñas, generalizar el resto. Pero rápidamente se dio cuenta de que el método inductivo respondería una pregunta relacionada no con "todos", sino, en el mejor de los casos, solo con la "mayoría" de los evaluadores. Por lo tanto, decidí acercarme desde el otro lado, deductivo, y eso fue lo que sucedió.
Definiciones
Lo primero que suelo hacer cuando soluciono una nueva tarea es tratar de entender de qué se trata, y para ello debes comprender el significado de las palabras que se plantean. Las palabras clave para entender son las siguientes:
- el problema
- probador
- trabajo probador
- rendimiento del probador
Vaya a Wikipedia y al sentido común:
El problema (dr. Griego πρόβλημα) en sentido amplio es una pregunta teórica o práctica compleja que requiere estudio, resolución; en ciencia: una situación contradictoria, que actúa en forma de posiciones opuestas en la explicación de cualquier fenómeno, objeto, proceso y que requiere una teoría adecuada para resolverlo; En la vida, el problema se formula de una manera que la gente entiende: "Sé qué, no sé cómo", es decir, sabemos lo que hay que recibir, pero no se sabe cómo hacerlo. Viene de tarde lat problēma, del griego πρόβλημα "lanzado hacia adelante, colocado al frente"; desde προβάλλω "lanzar hacia adelante, poner delante de ti; culpa ".
No tiene mucho sentido, de hecho, "problema" = "cualquier cosa con la que lidiar".
Tester es un especialista (no lo dividiremos en tipos, ya que estamos interesados en todos los probadores), que participa en la prueba de un componente o sistema, cuyo resultado es:
El trabajo del probador es un conjunto de actividades relacionadas con las pruebas.
Eficiencia (lat. Effectivus ): la relación entre el resultado logrado y los recursos utilizados ( ISO 9000 : 2015).
Un resultado es una consecuencia de una cadena (secuencia) de acciones (total) o eventos expresados cualitativa o cuantitativamente. Los posibles resultados incluyen ventaja, inconveniencia, ganancia, pérdida, valor y victoria.
Al igual que con el "problema", tiene poco sentido: algo que surgió como resultado del trabajo.
Recurso : una capacidad medida cuantitativamente para realizar cualquier actividad de una persona o personas; condiciones que permiten usar ciertas transformaciones para obtener el resultado deseado. Un probador es una persona y, de acuerdo con la teoría de los recursos vitales, cada persona es propietaria de cuatro activos económicos:
efectivo (ingresos): un recurso renovable;
energía (vitalidad): un recurso parcialmente renovable;
tiempo: un recurso fijo y fundamentalmente no renovable;
conocimiento (información): un recurso renovable, es parte del capital humano, que puede crecer y colapsar [1] .
Quiero señalar que la definición de efectividad en nuestro caso no es del todo correcta, ya que cuanto más conocimiento usamos, menor es la eficiencia. Por lo tanto, redefiniría la eficiencia como "la relación entre el resultado logrado y los recursos gastados". Entonces todo es correcto: el conocimiento en el trabajo no se desperdicia, pero reduce el costo del único recurso fundamentalmente no renovable del probador: su tiempo.
Solución
Por lo tanto, estamos buscando problemas globales de evaluadores que empeoren la efectividad de su trabajo.
El recurso más importante que se gasta en el trabajo del probador es su tiempo (el resto se le puede brindar de una forma u otra), y para que podamos hablar sobre el cálculo correcto de la eficiencia, necesitamos llevar el resultado a tiempo.
Para hacer esto, considere un sistema cuya viabilidad el probador proporciona con su trabajo. Tal sistema es un proyecto cuyo equipo incluye un probador. El ciclo de vida del proyecto puede representarse aproximadamente con el siguiente algoritmo:
- Trabaja con requisitos
- Formación de especificaciones técnicas.
- Desarrollo
- Prueba
- Lanzamiento en producción
- Soporte (goto p.1)
Además, todo el proyecto se puede dividir recursivamente en subproyectos (características), con el mismo ciclo de vida.
Desde el punto de vista del proyecto, la efectividad de su implementación es mayor cuanto menos tiempo se dedica a él.
Por lo tanto, llegamos a la determinación de la máxima efectividad posible del probador desde el punto de vista del proyecto: este es el estado del proyecto cuando el tiempo de prueba es cero. Un problema común para todos los evaluadores es la incapacidad de lograr este tiempo.
¿Cómo lidiar con esto?
Las conclusiones son bastante obvias y han sido utilizadas durante mucho tiempo por muchos:
- El desarrollo y las pruebas deben comenzar y finalizar casi simultáneamente (esto generalmente lo hace el departamento de control de calidad ). La opción ideal es cuando toda la funcionalidad desarrollada para cuando esté lista ya esté cubierta por las pruebas automáticas organizadas en pruebas de regresión (y, si es posible, precompromiso) utilizando algún elemento de configuración .
- Cuantas más funciones tenga el proyecto (cuanto más complicado sea), más tiempo tendrá que dedicar a verificar que la nueva funcionalidad no haya roto la anterior. Por lo tanto, cuanto más complejo es el proyecto, más automatización se requiere de las pruebas de regresión .
- Cada vez que omitimos un error en la producción y el usuario lo encuentra, tenemos que dedicar más tiempo al ciclo de vida del proyecto a partir del paso 1 (Trabajar con los requisitos, en este caso, los usuarios). Debido a que las razones para omitir un error son generalmente desconocidas, solo tenemos una forma de optimizar: cada error encontrado por los usuarios debe incluirse en las pruebas de regresión para asegurarse de que no vuelva a aparecer.