Para comenzar, entre la gente, todos los ingenieros de garantía de calidad ("a nuestra manera", ingenieros del departamento de calidad) se llaman probadores. Esto no es del todo correcto, en realidad las pruebas son solo una parte de las tareas de control de calidad, pero a quién le importaría. Por lo tanto, vamos a la tendencia general y usaremos la unidad habitual para todos.
Entonces, ¿qué determina un buen probador? No nos rebajaremos a los lugares comunes y diremos: atención, perseverancia, paciencia, curiosidad, talento, todo descanso y otras tonterías. Esto es todo, por supuesto, importante, pero no es lo principal. En primer lugar, una persona debe tener un sentido de sentido común y responsabilidad.
Por ejemplo, dicen, lo principal es tener el talento para romperlo todo. A menudo se puede escuchar, dicen que él no contestará, lo romperá todo. Esto, por supuesto, es encomiable, pero el trabajo del probador no es lo principal para romper algo. Aquí, una definición vendrá en nuestra ayuda, que no es difícil de encontrar en Wikipedia.
La prueba de software es el proceso de investigar, probar un producto de software, con el objetivo de verificar la correspondencia entre el comportamiento real del programa y su comportamiento esperado en un conjunto finito de pruebas seleccionadas de cierta manera.
Muestra que hay requisitos específicos para el software y es necesario que se cumplan. Si el probador rompió el programa en lugar de verificar si realiza las funciones que se le asignaron, como resultado, puede obtener basura estable, pero no necesaria, para el cliente.
Entiendo que a todos les encantan las historias, cómo alguien la jodió, las tengo. Por mi trabajo trabajé en diferentes lugares y en diferentes proyectos, así que fui testigo o escuché muchas historias de mis colegas. Algunos de ellos están listos para contar. Bueno y sí, el mantra necesario: todas las coincidencias son aleatorias y se inventan nombres.
Pruebas y más
Comencemos en orden. Como dije al principio, el probador no solo está probando. ¿Cómo te gusta ese juego de palabras? En compañías grandes y de buena reputación, intentan conectar al equipo de prueba al proyecto en una etapa temprana, es decir. en la etapa de recopilación de requisitos, pero esto no se hace en todas partes y no siempre.
Una vez durante las pruebas de aceptación, el usuario inició un error crítico, porque uno de los requisitos no se cumplió. La esencia de la afirmación era que el usuario en la pantalla no encontraba el atributo que necesitaba (para aquellos en el tanque, un campo con un valor). El probador, por supuesto, subió a la especificación, verificó que este atributo estaba presente en la aplicación y corrió alegre para decirle al usuario que todo estaba bien.
Ya entiendes que la historia no termina ahí.
El probador intentó explicarle al usuario en qué se equivocaba, ya que se encontró con una parte de negatividad e indignación. El usuario lo sentó y descubrió los requisitos sobre la base de los cuales se escribieron las especificaciones. Uno de estos requisitos casi literalmente dice lo siguiente: "El atributo debe mostrarse en cada pantalla". Una oración, pero ¡cuánto sentido! Luego abrió la aplicación y comenzó a navegar aleatoriamente a diferentes pantallas, diciendo: "¿Y dónde está este atributo?" Está claro que el usuario se burló abiertamente, pero formalmente tenía derecho a hacerlo. El problema es que la escalada continuó y cada vez más personas participaron en la discusión del problema. Al final del usuario, además del propio probador, varios PM y una multitud de analistas lo convencieron, y él se mantuvo firme y exigió lo imposible.
Como resultado, se encontró un compromiso, y en la solicitud apareció una lista de las pantallas necesarias en las que se debe ubicar el atributo, pero esto requirió grandes cambios en el código del programa, por lo tanto, todo el ciclo de desarrollo tuvo que volver a ejecutarse, pero a un ritmo acelerado. La compañía gastó dinero extra, sin mencionar los costos de reputación, para el estrés y el procesamiento de los empleados. Todo esto podría haberse evitado si el probador estuviera conectado al comienzo del proyecto y pudiera ver los requisitos de ambigüedad, al menos, o más tarde, para verificar que las especificaciones cumplan con los requisitos. Y sí, los evaluadores a menudo trabajan directamente con usuarios reales, lo que les obliga a lidiar con la reducción del estrés, el psicoanálisis y la percepción extrasensorial.
Sin fanatismo
Vamos más allá, muy irónicamente, el proceso de prueba en sí se caracteriza por una anécdota barbuda:
Una vez que el probador ingresa a la barra.
Corre hacia el bar.
Se arrastra hacia el bar.
Bailando, penetra la barra.
Furtivamente en un bar.
Entra en el bar.
Salta al bar.
Órdenes:
una jarra de cerveza
2 vasos de cerveza
0 vasos de cerveza
999999999 jarras de cerveza,
lagarto en un vaso
-1 taza de cerveza
jarras de cerveza qwerty.
El primer cliente real entra al bar y pregunta dónde está el baño. El bar estalla en llamas, todos mueren.
No todos entienden que puedes probar sin parar. El ideal es inalcanzable y los proyectos tienen plazos muy específicos para ajustarse. Entonces, hubo un probador que, al pasar el caso de prueba, constantemente le falla. Pasó el tiempo, el proyecto ya había comenzado a terminar y el desarrollador superó todos los problemas encontrados. Y aquí el probador declara que la funcionalidad básica necesaria no funciona. Todos lo entienden: no funcionará arreglarlo a tiempo.
En el curso del proceso, resulta que: durante las pruebas, el guión nunca se completó por completo hasta el momento desafortunado. El probador encontró una falla al comienzo del proceso, que probó, comenzó un boleto y tiró a la mitad. Al mismo tiempo, fue posible continuar con las pruebas, porque Todos los errores encontrados no lo bloquearon. Posteriormente, todo el equipo tiene estrés y procesamiento tradicional.
Por cierto, algunos usuarios confirman esto en las pruebas de aceptación, declaran que el error es crítico y dejan de funcionar. Esto complica mucho el trabajo, porque En la corriente general de problemas, que en general puede no ser un problema, se pierden errores realmente críticos.
La moraleja es esta: un buen probador nunca dejará de encontrar el primer error que se encuentre. Recorrerá todo el script de principio a fin, registrará simultáneamente todos los errores encontrados y, si se encuentra con un error que bloquea el paso, buscará una solución, es decir. solución alternativa Y cuando esté convencido de que no hay soluciones, se detendrá.
Hay una advertencia. La mayoría de las veces, los proyectos se realizan dentro de plazos ajustados, o no muy ajustados, pero bastante específicos. Sucede que una persona se rocía en pruebas interminables de un campo, introduciendo en él todas las variantes de valores posibles e imposibles. Al mismo tiempo, de acuerdo con los requisitos del cliente, es necesario verificar la función realizada por la aplicación, aunque utilizando el valor de este campo. Como resultado, corre el riesgo de perder el tiempo y no verificar lo principal. El probador debe poder evaluar correctamente sus fortalezas y lugares críticos de la aplicación. No es necesario probar esos lugares que no requieren pruebas. Lo principal es que la aplicación debe cumplir la función asignada. Primero necesita lograr la ejecución de un escenario directo, y luego mejorar la calidad de ejecución al nivel deseado.
Mi lengua es mi enemigo
Además ... Los problemas con la documentación pueden ser no solo para analistas, sino también para probadores. Se observó repetidamente que no solo los desarrolladores no pueden describir claramente el contenido del ticket en su campo correspondiente, sino que los probadores mismos no pueden escribir correctamente el orden de las acciones que causan el error. Este es un gran problema. Alguien simplemente no entiende por qué ocurre el error y no se molesta en descifrar los pasos. Alguien tiene problemas de alfabetización en absoluto.
¿Qué implica todo esto? Aquí la respuesta y el erizo es comprensible, pero con los ejemplos, por supuesto, más interesantes.
Hay una cohorte de probadores que, al ver un error frente a ellos, simplemente registran ese millón de pasos, incluida la basura que condujo al error. No reproducen el error y no descubren qué causa exactamente lo que está hecho. Al mismo tiempo, pueden escribir un conjunto de pasos que no están asociados con este error en absoluto. El desarrollador intentará reproducirse, en algún momento su cabeza hervirá, y él tratará personalmente con el probador. Entenderán juntos y ambos pasarán mucho tiempo en comunicaciones innecesarias. Afortunadamente, todo esto se trata rápidamente con tiempo y experiencia, aunque existen casos clínicos.
La alfabetización se está volviendo más difícil. En mi práctica, hubo un caso en el que el líder de control de calidad necesitaba corregir la descripción de varias docenas de tickets, porque deberían haber sido enviados al cliente en un informe de progreso. Esto sucedió porque la mayoría del equipo no pudo formular correctamente sus pensamientos en inglés.
Pero también hay problemas con los rusos, gracias a Dios, con menos frecuencia. Aquí todo es igual, una descripción mal escrita lleva al hecho de que el boleto, como un balón de fútbol, comienza a galopar entre las personas sin llegar a la meta. Es bueno si el equipo está en la misma sala y puede hablar sin levantarse del monitor. Más difícil, si el equipo está distribuido. Muy mal, si es multilingüe. Lo peor que puede suceder al final es que el boleto se realizará incorrectamente debido a un malentendido y se volverá a abrir mil veces. E incluso para el cliente volará en una de las versiones con lógica invertida.
Espacio personal
Otro problema son los bancos de prueba y los datos de prueba. En diferentes compañías, esto sucede de diferentes maneras, pero a menudo sucede que a un empleado se le otorgan derechos sobre el servidor de trabajo de un cliente o se le da su base de datos para realizar pruebas. Parece que lo que podría salir mal?
Pero dofiga de qué ... Si alguien tiene acceso al servidor del cliente, por un lado es conveniente, puede ver los problemas desde los primeros rangos y no cometer un error sobre la foto. Pero existe el riesgo de estropear los datos del cliente, lo que puede tener graves consecuencias. Ya estoy en silencio sobre los casos en que dicho acceso está generalmente prohibido por la ley.
Hubo un caso cuando un cliente se cayó de un servidor durante 3 días. El desarrollador durante todo este tiempo no pudo entender por qué sucedió esto, y frenéticamente buscó un error, y el negocio sufrió pérdidas. Como resultado, resultó: la compañía contrató a indios para externalizar, donde la gente, sin más preámbulos, otorgó todos los derechos administrativos. Para todos, esto significa incluso esa chica que ha estado trabajando durante 3 días en la empresa, y no había computadora en su pueblo, por lo que tienen un período de citas más corto. Pero la chica resultó ser terriblemente talentosa, logró encontrar la esencia básica en el panel de administración y cambió su tipo, después de lo cual todo naturalmente se cayó y dejó de funcionar. Es fácil adivinar cómo se quitó la escalera de la carrera después de eso.
Lo mismo sin sentido y con datos del cliente. Nuevamente, no estoy hablando de casos en los que esté prohibido por ley. Si es posible trabajar con datos reales, está bien, pero hay que tener cuidado con esto. Probablemente todos escucharon historias sobre el envío aleatorio de cartas o mensajes desde un servidor de prueba a usuarios reales. Entonces, estos no son chistes. Esto realmente sucede, y con bastante frecuencia. De acuerdo, si estos mensajes tienen derecho como mensajes de prueba y tienen un contenido sensato, pero sucede que la gente finge escribir algo que lamenta todo el equipo de desarrollo de aplicaciones.
Momentos organizacionales
Ya comencé a aburrirme con una gran cantidad de texto, así que el último. El probador debe proporcionar constantemente a su jefe información actualizada sobre su trabajo. Según dichos informes, si se realizan correctamente, el jefe llega a una conclusión sobre el estado del proyecto en su conjunto. No solo se trata del trabajo de un probador o de todo el equipo de pruebas, sino también del trabajo del equipo de desarrollo y la etapa en la que se encuentra el proyecto. Además, dichos informes permiten planificar el análisis para futuras versiones, etc., etc.
Existen muchos ejemplos en los que este trabajo no se realizó o se realizó de manera inapropiada, de lo cual las autoridades tuvieron un sentimiento de incertidumbre con todas las consecuencias que se derivaron. Te diré lo más brillante.
Una vez que el probador se puso en un nuevo proyecto. Como no lo conocía bien, se le asignó la tarea de clasificar y registrar observaciones. Como era algo informal, acordamos que escribiríamos en Googledock. El hombre comenzó a llevar a cabo la tarea, una semana más tarde se verificó esta tarea, el probador recibió una palmada en el hombro y continuó trabajando. Pasaron los meses, las autoridades comenzaron a preocuparse por qué no hay entradas en el rastreador de errores y no se está haciendo nada en el proyecto. Comenzamos a resolverlo, resultó que una persona continúa escribiendo en ese mismo Googledock. Nadie dijo "ir al baño, no cocines" y no detuvo al probador, y regularmente continuó entendiendo y registrando observaciones, sin darse a conocer. Hay errores, y los encontró, pero no se lo dijo a nadie, solo los anotó en un archivo, que todos olvidaron una semana después.
De hecho, la expectativa era que una persona continuaría trabajando ya formalmente, es decir. en el rastreador de errores, dando a los desarrolladores entradas con sus entradas, pero esto no sucedió. Parecía que el hombre no hizo nada, aunque trabajó. Está claro que el problema no era solo del probador, sino que si hacía un informe regular sobre sus actividades, entonces podrían evitarse malentendidos.
A menudo, la falta de información crea la sensación de una prueba deficiente del producto, que esta o aquella parte de la funcionalidad no ha sido probada. Para evitar que esto suceda, debe realizar informes detallados, esto es especialmente importante para proyectos grandes.
Conclusión
Debe comprender que QA es, de hecho, el abogado del usuario. En cualquier situación incomprensible relacionada con la aplicación, el probador debe ponerse en su lugar. Si, a través de esta simple manipulación de la conciencia, resulta que la aplicación no está contenta con algo, entonces necesita iniciar un ticket. Y esto puede ser un botón en el lugar equivocado u otra bagatela desde el punto de vista del desarrollador, pero a menudo sucede que para un usuario esta bagatela puede convertirse en un infierno y un punto de irritación. Como ejemplo, puede tomar una gran cantidad de ventanas emergentes en la aplicación. Sí, el programa realiza su función, pero es difícil de usar, porque La ejecución de esta función requiere mucho tiempo y esfuerzo de un usuario que se ve obligado a presionar un montón de ventanas adicionales con descargas y más, en lugar de hacer todo el trabajo en una pantalla.
Y si una persona responsable y con sentido común se acerca a su trabajo, podrá evitar la mayoría de los problemas en su camino, no solo en la profesión de control de calidad.