¿Qué hacen los probadores?

Question

Trabajo en una empresa en la que los desarrolladores controlan el trabajo de los otros desarrolladores que verifican las cosas, como la adhesión a los estándares de codificación, ya sea que funcione o no.

Ahora, esto parece funcionar muy bien para nosotros, pero no puedo evitar sentir que estamos perdiendo tiempo de desarrollo en algo que un comprobador o probadores dedicados podrían hacer.

El problema es que siempre he trabajado para esta empresa, así que nunca he trabajado con probadores, así que no sé qué función tienen dentro de un equipo de desarrollo que no sea la vista de una milla de "lo prueban".

También tendemos a contratar personas de nivel de postgrado para que alguien tenga que guiarlas en todas sus tareas durante un tiempo.

En resumen, ¿qué hacen los verificadores dentro de su empresa y cómo encajan en sus procesos de desarrollo y lanzamiento?

Answer 1

Un departamento de control de calidad buena va a hacer varias cosas:

1. Escribir un plan de pruebas según la especificación funcional del producto.Esto ayuda a eliminar las especificaciones funcionales y a encontrar áreas en las que es necesario mejorarlas o modificarlas.
2. Encuentra errores en el producto Este es obvio.
3. Pruebe la usabilidad del producto desde un punto de vista que no sea del desarrollador. Este va mucho más allá de encontrar errores: no sirve de nada tener un producto libre de errores si nadie puede descubrir cómo usarlo.

cuanto a cómo encajan en el proceso:

1. Tan pronto como el equipo de desarrollo siente que la especificación funcional es completa, se le da al equipo de control de calidad para que puedan escribir los planes de prueba
2. Cuando el equipo de desarrollo tiene una compilación relativamente estable con una cantidad razonable de funcionalidad, se le puede dar a QA para que pueda comenzar a analizarlo. En este punto, el objetivo de QA es familiarizarse con la nueva versión y señalar cualquier defecto evidente de usabilidad en lugar de apuntar a errores.
3. Una vez que los desarrolladores dicen "está bien, creo que estamos listos", la garantía de calidad inicia la misión de búsqueda de errores.
4. Los desarrolladores y el control de calidad trabajan para resolver todos los problemas. Los errores se arreglan, eliminan o posponen para futuras versiones.
5. control de calidad tiene la última palabra sobre si la liberación se deja salir la puerta

Tenga en cuenta que por encima de 3 y 4 puede variar mucho dependiendo de si se está hablando de un nuevo producto o una liberación de una producto existente. Si tiene un producto existente, se pueden realizar muchísimas pruebas en paralelo con el desarrollo.

Answer 2

Debe contratar personas para realizar las pruebas.

Los comprobadores usan la aplicación e informan de los errores que encuentran. Si tiene una especificación, puede probar la aplicación en su contra para informar cualquier incoherencia.

Ninguna versión del producto puede tener calidad si no se prueba.

Answer 3

Su trabajo es simple. Rompe la aplicación. Siempre sabe cuándo tiene un buen probador, porque siempre está un poco molesto cuando esa persona se acerca a su escritorio/cubo. La razón de esto es que sabes que si el probador está en tu vecindad general, han encontrado algo mal con lo que has escrito. Todas las excusas comienzan a acumularse en tu mente de '¡Bueno, no lo estás usando bien!', Etc., pero al final, sabes que el probador está en lo cierto, y que has cometido un error en tu programación .

buenos probadores pueden encontrar errores. Pueden pensar como un usuario, verificar las reglas comerciales, etc., pero también actúan como un usuario cuando hacen clic en patrones inusuales para forzar la ruptura de su aplicación. Puede parecer que están abusando de la aplicación y usándola de una manera que no está destinada a ser utilizada, pero ese es su trabajo, y es por eso que se les paga como probadores.

Usted sabe que su probador necesita ser reemplazado cuando no pueden encontrar nada malo. Créanme, en cualquier sistema complejo, siempre hay algo mal, y es tarea del probador encontrarlo.

Dicho esto, es de suma importancia utilizar personas de prueba dedicadas, especialmente cuando se trata de cualquier aplicación que tenga un componente de IU considerable.

Answer 4

Código de prueba de programadores, aplicaciones de prueba de probadores. Los probadores leen la especificación, piensan en escenarios que podrían causar problemas (¿qué pasaría si dos personas hacen esto al mismo tiempo?) Etc.

Luego documentan una serie de pruebas, las prueban, informan el resultado, etc. .

Answer 5

Consulte Joel's Top Five (Wrong) Reasons You Don't Have Testers para obtener una descripción de lo que hacen los verificadores y por qué son buenos para las compañías de software.

Answer 6

En realidad recientemente me he dado cuenta de cómo distinguir un probador malo de uno bueno. Cuando las tareas se cierran porque no se encuentran errores y una hora más tarde tú bloqueas la aplicación porque sientes que "es estúpido, pero ¿qué pasará si realizas ese tipo de entrada?" y lo hizo, es una buena señal de que alguien (probador) no hizo su trabajo.

Normalmente informo de errores en algún lugar de nuestro software y todo el tiempo caí como "Ese no soy yo quien debería estar haciendo esto".

Answer 7

Siguiendo de David's answer, un buen probador vale su peso en oro, y los buenos comprobadores de contrato pueden ser muy caros.

Trabajé con un excelente comprobador hace algunos años. Yo era el líder tecnológico en ese momento, y él era la ruina de mi vida, pero su valor era incalculable.

Era muy organizado y extremadamente inteligente. Escribió sus propios planes de prueba, basados ​​en documentación limitada de requisitos y funciones. En su mayoría, ejecutó la aplicación y, a partir de su comprensión del negocio, averiguó qué debería hacer y dónde se quedó corto.

Su atención al detalle fue nada menos que impresionante. Todo lo que informó fue completamente reproducible, documentado, y no solo vino con informes de errores, sino con sugerencias para un comportamiento alternativo. Esto fue muy útil, por supuesto, ya que no todos los errores dan como resultado la ruptura de la aplicación.

También fue lo suficientemente flexible como para reconocer que las cosas eran de alta prioridad, y (¡temporalmente!) Dejar de molestarnos por las cosas que no tuvimos tiempo de hacer.

Así que obtuvimos comentarios de la UI, informes de errores, incluso sugerencias sobre dónde se habían malentendido los requisitos.

Me trabajó mucho con lo que encontró, pero teníamos un fuerte reconocimiento de nuestro objetivo común, a saber, un sistema de alta calidad. Si estás ahí fuera, Nicholas, te deseo lo mejor.

Para el OP, le sugiero que busque a alguien con estas habilidades.

Answer 8

Lo ideal es que los evaluadores participen desde el principio en el proyecto, para que puedan formular los planes de prueba. Esto implicará, entre otras cosas, la creación de scripts de prueba. Los scripts de prueba escritos reales son importantes para las pruebas repetibles (por ejemplo, para pruebas de regresión de versiones nuevas). Además de probar la funcionalidad, los planes cubrirán las pruebas de diferentes plataformas, probando la usabilidad y el rendimiento de las pruebas.

Los comprobadores ejecutan los planes de prueba y buscan e informan errores con suficiente detalle para minimizar el trabajo del desarrollador en la reparación de errores. Esto significa tomarse el tiempo para descubrir exactamente cómo reproducir problemas. Por lo general, los comprobadores cuestan menos que los desarrolladores, por lo que es mejor para la empresa si los evaluadores lo hacen que si se lo dejan a los desarrolladores. Los evaluadores también tienden a ser mejores ya que no hacen las suposiciones que hacen los desarrolladores.

Los comprobadores en realidad no deberían estar metiéndose en el campo de verificar el cumplimiento de las normas de codificación; esto es mejor para las herramientas automatizadas. Los probadores nunca necesitan ver el código fuente.

Cuando tiene buenos probadores que trabajan a tiempo completo en un proyecto, rápidamente se convierten en expertos en los requisitos (más que los desarrolladores que solo trabajan en una parte del sistema).

Answer 9

Para obtener un mejor manejo de este, recomiendo encarecidamente el libro "Perfect Software: And Other Illusions about Testing" de Gerry Weinberg (sanitised Amazon link).

Está lleno de ideas excelentes que le harán pensar en las pruebas de maneras completamente nuevas.

HTH

aplausos,

Rob

Answer 10

En contraste con su escenario, que han estado trabajando estrechamente con los probadores. Los encuentro muy útiles por el hecho de que entienden bien dónde encaja mi software en el esquema general de las cosas. Conocen mejor la aplicación con la que interactúa la mina. Las aportaciones al respecto son muy valiosas.

Answer 11

tareas Desarrollador:

• Desde el interior hacia el exterior - se centran en código
• afirmaciones - Verifique el flujo de datos y estructuras
• Depurador - verificar el flujo de código y datos
prueba
• Unidad - verificar cada función
• Prueba de integración: verificar los subsistemas
• Prueba del sistema: verificar la funcionalidad

tareas Tester:

• De afuera hacia adentro - se centran en las características
• Escenarios - verificar las situaciones del mundo real
• pruebas globales - verificar las entradas factibles
• pruebas de regresión - verificar defectos permanecen fijo
• Cobertura de código - prueba de código no modificado
• Compatibilidad - con anterior libera
• Buscando peculiaridades y los bordes ásperos

Answer 12

Tradicionalmente, en una gran empresa de servicios de TI, el papel de un probador tiende a variar ligeramente con la naturaleza del proceso de desarrollo adoptado. Cascada tradicional o proyectos iterativos tienden a involucrar probadores diseñar planes de prueba, escribir casos de prueba y aclarar los requisitos durante ese proceso, ejecutarlos (tanto manuales como automatizados) y borrar la aplicación para movimientos de producción. También realizan pruebas de regresión de otras aplicaciones que podrían verse potencialmente afectadas. En su mayor parte, nunca miran el código, pero en algunos casos especiales, validan las entradas de la base de datos, especialmente en escenarios en los que están involucrados trabajos por lotes u otros sistemas heredados.

Los proyectos ágiles, por otro lado, están causando cada vez más confusión entre las responsabilidades de un probador y un desarrollador. Con frameworks como Rails o Django, el desarrollador tiene una visión mucho mejor del "panorama general" que nunca, por lo que generalmente no tiene sentido tener un equipo grande, dedicado y puramente de prueba. Y con una filosofía beta perpetua, una buena parte de las pruebas las realizan los usuarios finales reales. Así que un equipo de pruebas mucho más ágil y más experto en desarrollo suele ayudar a los proyectos de Agile (al menos dentro de las empresas). Entre otras cosas, ayuda cuando los evaluadores pueden armar scripts para automatizar casos de prueba regulares en lugar de tener que depender de herramientas costosas (como Win/Loadrunner)

En promedio, los niveles de motivación de un evaluador tienden a ser más bajos que los de los desarrolladores. Al menos en mi organización, muchos testers quieren "crecer" para ser desarrolladores, aunque algunos de ellos entienden que convertirse en un asesor de QA/Assurance es una carrera en sí misma.