testing - software - tester que es

Probadores en desarrollo de software (10)

¿Los comprobadores son necesarios en el desarrollo de productos (o proyectos a gran escala)?
¿Los probadores solo deben hacer el trabajo de prueba? ¿Se puede esperar de un desarrollador o diseñador gráfico que pruebe la mitad de la semana?
¿Dónde puede encontrar buenos probadores (supongo que no hay un título en pruebas de desarrollo de software)?
¿Es la tarea del gerente de proyecto del equipo técnico de probar todo?

1 - en el desarrollo de productos cuando tienes> 10 clientes: diablos, sí. ESENCIAL. Lo mismo en un proyecto a gran escala. Puede escatimar cuando es pequeño, pero una vez que sobrepasa cierto tamaño, el dolor de actualizar (por ejemplo) a 100 clientes en todo el mundo supera el salario de incluso UN tester.

2 - sí, aunque también hay cierta superposición en el trabajo de soporte. El desarrollador debe hacer pruebas básicas, ¿funciona? - pero depende de los evaluadores hacer las pruebas de tipo de casos de uso extraños, exhaustivos y de extremo a extremo. Es un desperdicio de tiempo para los desarrolladores hacer eso, creo. Los diseñadores gráficos no deberían probar, bueno, la prueba del usuario, espero, pero eso es incluso antes de que llegue a los desarrolladores.

3 - algunos desarrolladores hacen buenos probadores. algunas personas de apoyo son buenos evaluadores. aparte de eso, solo hay que encontrarlos al azar. anunciar. etc. no hay grados, pero alguien que es pedante, puede defenderse por sí mismo, y sabe más sobre cómo se mantiene el entorno final que sobre cómo funcionaría cada línea de código.

4 - no. el PM mantiene el proyecto en conjunto y coordina a los evaluadores, desarrolladores, etc., el líder tecnológico debería ser, ya sabe, el líder del equipo técnico. no probando

Obviamente, hay una fuga entre los roles. A veces, TODOS deberían hacer algunas pruebas, pero esto es más para obtener la máxima cobertura justo antes de RTM, no de día a día o de semana a semana.

Las pruebas unitarias son un gran comienzo, ya que detectan los errores lógicos, pero no se puede esperar que atrapen interacciones locas del usuario, o problemas que solo aparecen después de que su aplicación ha estado funcionando durante 72 horas + - las pruebas unitarias NUNCA PODRÁN atrapar estos . Su cliente lo hará, pero luego no tendrá clientes por mucho tiempo :)

Por cierto, he "estado allí, hecho eso". Probé con clientes y tuve probadores adecuados en diferentes etapas (vrs de inicio comprados por una gran empresa) del mismo producto. El producto fue MUCHO más sólido una vez que tuvimos probadores, y los clientes también fueron más felices (además, es difícil implementar un pequeño parche crítico en 400 sitios de todo el mundo, ¡tómelo antes de enviarlo!)

En mi empresa desarrollamos un producto de software. Hasta ahora no hemos tenido probadores, por lo que básicamente los desarrolladores fueron los probadores, y por supuesto los clientes y usuarios (no buenos).

Nuestro equipo ahora consta de 4 desarrolladores y trabajamos principalmente con Cruisecontrol, Flex, ASP.NET, IIS, MSSQLServer y WebORB. Estoy instando a los gerentes a contratar un probador, pero me pregunto si los probadores son normales en el desarrollo de software. Asi que:

¿Los comprobadores son necesarios en el desarrollo de productos (o proyectos a gran escala)?
¿Los probadores solo deben hacer el trabajo de prueba? ¿O puede esperar de un desarrollador o diseñador gráfico probar la mitad de la semana?
¿Dónde puede encontrar buenos probadores (supongo que no hay un título en pruebas de desarrollo de software)?
¿Es la tarea del gerente de proyecto del equipo técnico de probar todo?

thx, Lieven Cardoen

ps: Thx, Vinay, tenemos pruebas unitarias pero, de hecho, las pruebas unitarias no pueden cubrir lo que los probadores pueden hacer.

Desde cierto tamaño, absolutamente (diría que unos 10 desarrolladores).
Los probadores también podrían hacer trabajos de construcción e integración. En grupos más pequeños, los desarrolladores tienen que probar, porque no hay nadie más para hacerlo.
Buena pregunta. Tal vez a algunos de tus desarrolladores les gusten las pruebas.
No, especialmente cuando el proyecto se agranda.

He trabajado en un gran proyecto (cientos de desarrolladores), en nuestro grupo unos cincuenta. Nuestro grupo tenía un grupo de integración y evaluación de dos o tres personas a tiempo completo y un grupo de estudiantes.

EN gran escala, sí. Sin embargo, hay muchos métodos y tipos de pruebas diferentes. Estos incluyen usuario, regresión, unidad y prueba de integración. Intenta automatizar todo lo que puedas. Consulte Selenium (IDE), Molydbenum, Escenarios de uso y Desarrollo ágil.
Un desarrollador o diseñador debe decidir si han cumplido los criterios de aceptación, pero si ponen a prueba su propio trabajo, es como escribir su propio examen antes de sentarse. Los desarrolladores que prueban el trabajo de otros desarrolladores no son mucho mejores en mi opinión.
No sé
Creo que un gerente de proyecto no tendrá tiempo para realizar pruebas rigurosas. Es realmente el trabajo de un probador dedicado que sabe ser diligente y puede interactuar con el gerente de proyecto.

1) ¿Los probadores son necesarios en el desarrollo de productos (o proyectos a gran escala)?

Sí. Alguien tiene que asumir la responsabilidad de evaluar cuándo algo se ha probado lo suficiente y averiguar qué errores deben corregirse o pueden enviarse porque hay soluciones provisionales.

2) ¿Los probadores solo deben hacer el trabajo de prueba? ¿Se puede esperar de un desarrollador o diseñador gráfico que pruebe la mitad de la semana?

Los probadores a menudo hacen trabajos de soporte al cliente o trabajan con el cliente para desarrollar requisitos. Los probadores pueden actuar como voces internas para los clientes ... y si interactúan con el cliente lo suficiente deben sentir un sentido de responsabilidad por obtener un producto de calidad adecuada del desarrollo que saben que el cliente querrá.

3) ¿Dónde puede encontrar buenos probadores (supongo que no hay un título en pruebas de desarrollo de software)?

Apuesto a que hay un grado en algún lado. Muchos de los evaluadores que tenemos son estudiantes universitarios de ciencias de la computación que están haciendo un año en la industria antes de regresar para su último año en la universidad.

4) ¿Es la tarea del gerente de proyecto del equipo técnico de probar todo?

No necesariamente. Depende de qué tan grande sea el equipo, si es pequeño, entonces sí, alguien puede duplicar y hacer ambos papeles. Sin embargo, para proyectos más grandes, estas son personas diferentes.

Recuerda. Tener un probador no es una excusa para que los programadores / desarrolladores no prueben el código a medida que lo escriben o crean pruebas unitarias. Los desarrolladores todavía tienen la responsabilidad de desarrollar un buen producto. Nunca deberían intentar inventar una excusa para un error que crearon culpando a un probador por no encontrarlo.

Creo que lo que los probadores (pueden) traer a la mesa es una nueva mirada sobre un producto. Descubrí que es probable que siga el camino feliz cuando ejecuto software, ya sea a través de la interacción de IU o utilizando las clases que he escrito. Cuando sabes cómo se supone que algo funciona, es un poco antinatural hacer las cosas mal, ejercitar el producto de una manera que no fue intencionada o probar cosas en un orden que nadie sabe cómo funciona. hacer.

Mis respuestas a sus preguntas son las siguientes:

Sí. Las pruebas son una necesidad y, por lo tanto, se necesita algún tipo de comprobador. Normalmente, las pruebas unitarias captarán muchos de los problemas de bajo nivel, pero las pruebas de usabilidad y las pruebas de "requisitos" determinan si cumplen con los requisitos del folleto brillante. Si afirma que su software tiene ''X'', entonces parte del trabajo del verificador es asegurarse de que realmente ''X''. Hemos hecho que Tester descubra algunos problemas en plataformas que normalmente no uso. Es bueno encontrar esos problemas temprano.
Tal vez. Realizamos pruebas cruzadas de nuestros productos en la empresa, pero también tenemos un grupo de prueba por separado. Tendemos a (en casa) a encontrar la mayor parte de los problemas, pero los evaluadores de tiempo completo encuentran cosas que a veces nunca hubiéramos encontrado. Si divide el tiempo entre el desarrollo y las pruebas, debe quedar claro que las pruebas no son una idea de último momento. Si estoy sobrecargado trabajando en mi desarrollo y me cuesta pasar el tiempo requerido para probar su producto, entonces no voy a ser tan efectivo como probador. La gestión del tiempo es esencial si va a tener que los desarrolladores se dupliquen como probadores.
No es seguro. Algunos grupos (grupos IV y V, por ejemplo) en una organización solo hacen pruebas. Sospecho que hay una gran cantidad de personas que no tienen ningún negocio o desean escribir software, pero que pueden poner a prueba el producto. Algunos de nuestros mejores probadores en mi último trabajo no escribieron ningún código.
Depende de tu proyecto, pero yo diría que no, en general. La responsabilidad es algo que se extiende en mi tienda. El líder no es responsable de todas las pruebas. Todos somos responsables.

De todos modos, esos son mis dos centavos.

Es la pregunta # 10 en la prueba de Joel:

http://www.joelonsoftware.com/articles/fog0000000043.html

Debería decirle todo lo que necesita saber. :)

Es mejor tener probadores en el equipo. Nosotros, los desarrolladores no podemos obtener tantos defectos cuando realizamos la prueba, pero si un probador lo prueba, detecta tantos defectos antes de liberar los defectos.

Es mejor tener casos de prueba unitaria también. Cuando desarrollamos una nueva característica, solo tenemos que actualizar el caso de prueba y ejecutarlo.

Los probadores son necesarios en ambos casos. Incluso si su desarrollo se basa en pruebas, creo que el papel del evaluador a menudo se centra en los requisitos externos del proyecto: ¿el proyecto entrega el producto esperado que cumplirá con los requisitos?

Encuentro que en entornos corporativos grandes, a menudo tienes una mina de oro de buenos testers en call-centers o aquellos que hacen servicio al cliente. A menudo tienen una comprensión muy sólida de los procesos, problemas y requisitos del negocio.

En ese contexto, a menudo permitimos que los probadores trabajen con la construcción de casos de prueba de la vida real en sistemas de back-end, algunas veces incluso son utilizados por pruebas de integración que los desarrolladores escriben. Hemos tenido un gran éxito al permitir que los desarrolladores soliciten a los evaluadores datos / escenarios para probar las pruebas automatizadas basadas en CI.

Puede esperar que otros roles participen en las pruebas. Realmente creo que todos deberían centrarse en la calidad y las pruebas, pero desafortunadamente no todos pueden ser responsables.

Nunca subestimes el valor de los especialistas.

La mayoría de las personas que no son probadores, en particular los desarrolladores, no disfrutan las pruebas y no lo harán bien. Si le pides a un diseñador gráfico o a un desarrollador que dedique la mitad de su tiempo a las pruebas, en el mejor de los casos perderás el 50% de la producción de un buen diseñador / desarrollador y obtendrás el 50% de un probador pobre y costoso. En el peor de los casos, los perderá por completo porque encontrarán un lugar mejor para trabajar.

En el caso de los desarrolladores, generalmente están demasiado cerca del código para poder probarlo objetivamente. Harán suposiciones basadas en su conocimiento de las partes internas. Un desarrollador que prueba su propio código es particularmente malo.

El gerente del proyecto debe ser responsable de garantizar que todo se pruebe, pero no deberían hacerlo ellos mismos. No tendrán suficiente tiempo o la experiencia necesaria.

Previamente trabajé para una empresa de consultoría. No contamos con probadores especializados y, en su lugar, utilizaremos los consultores que actualmente no tengan un proyecto. Ninguno de ellos tenía experiencia en pruebas y, como resultado, la mayoría de ellos no eran muy buenos evaluadores. Obtendríamos informes de errores como "el sistema ya no funciona" o mi favorito personal: una captura de pantalla de una aplicación que muestra lo lento que fue (una captura de pantalla de la aplicación que se ejecuta rápidamente no se habría visto diferente). También abusarían del sistema de seguimiento de fallas (o lo ignorarían completamente a favor de sus propios difusores Excel de fabricación casera). Fue una pesadilla.

Todos dirán que se requieren testers, y esa es la respuesta políticamente correcta. Pero los probadores son solo una de las muchas herramientas disponibles en la caja de herramientas de garantía de calidad. Puede enviar software perfectamente fino sin probadores. Por ejemplo, me pregunto si tiene un departamento de pruebas.

Un probador medirá la calidad del código que producen sus desarrolladores. Pero la disponibilidad de mediciones de calidad no mejora la calidad.

Los probadores no vienen gratis. Tendrá que cambiar el desarrollo para entregarlo al equipo de prueba en lugar del cliente. Esto puede conducir a una desconexión entre los clientes y los desarrolladores: los evaluadores pueden encontrar errores que a los clientes no les interesan e ignorar los errores que son muy importantes para el cliente. Además, deberá crear y mantener un entorno de prueba separado.

Los buenos probadores lo ayudarán a desarrollarse mejor y, especialmente, a liberarlo más suavemente. Pero su millaje variará.

PD En una empresa grande, los comprobadores son esenciales: permiten el cambio de comportamiento. Digamos que un error causa daño al cliente -> ejecutivo está molesto. En este punto, el ejecutivo está listo para hacer cosas desagradables para su equipo. Con un equipo de prueba, puede echar la culpa al equipo de prueba, quien le devuelve la culpa a usted. Se produce un compromiso: se introducen nuevos procesos, el equipo de prueba contrata más probadores y el ejecutivo dice que ha mejorado personalmente.