Probadores en desarrollo de software [cerradas]

https://stackoverflow.com/questions/525514

22-08-2019
|

Pregunta

En mi empresa se desarrolla un producto de software. Hasta ahora no hemos tenido ningún probadores, por lo que, básicamente, los desarrolladores fueron los probadores, y por supuesto el cliente y los usuarios (no es bueno).

Nuestro equipo se compone actualmente de 4 desarrolladores y trabajamos principalmente con climatizador, Flex, ASP.NET, IIS, MSSQLServer y WebORB. Insto a los gerentes para contratar a un probador, pero me pregunto si los probadores son normales en el desarrollo de software. Por lo tanto:

¿Son necesarios los probadores de producto (o proyecto de desarrollo a gran escala)?
En caso de que los probadores sólo lo prueba? O se puede esperar de un desarrollador o diseñador gráfico para probar la mitad de la semana?
¿Dónde se puede encontrar buenos probadores (supongo que no es un grado en las pruebas de desarrollo de software)?
¿Es la tarea del director del proyecto de teamlead técnica para probar todo?

THX, Lieven Cardoen

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

Solución

1) ¿Son necesarios los probadores de producto (o proyecto de desarrollo a gran escala)?

Sí. Alguien tiene que asumir la responsabilidad de evaluar cuando algo se prueba suficiente y la elaboración de los insectos, que necesitan ser arregladas o puede enviar porque hay soluciones.

2) En caso de que los probadores sólo lo prueba? De se puede esperar de un desarrollador o diseñador gráfico para probar la mitad de la semana?

Los probadores suelen hacer el trabajo de atención al cliente o trabajar con el cliente para desarrollar requisitos. Los probadores pueden actuar como voces internas de los clientes ... y si interactúan con el cliente lo suficientemente deben tener un sentido de responsabilidad de conseguir un producto de calidad adecuada de desarrollo saben que el cliente va a querer.

3) ¿Dónde se puede encontrar buenos probadores (supongo que no es un grado en las pruebas de desarrollo de software)?

apuesto a que hay un grado en alguna parte. Una gran cantidad de los probadores que tenemos son los estudiantes universitarios la ciencia informática 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 director del proyecto de teamlead técnica para probar todo?

No necesariamente. Depende de lo grande es el equipo, si es pequeña, entonces sí, alguien puede doblar y hacer los dos papeles. Para proyectos más grandes sin embargo, éstas son personas diferentes.

Recuerde. Tener un probador no es una excusa para que los desarrolladores / programadores no para probar código como lo escriben o crean unidad de prueba. Los desarrolladores todavía tienen la responsabilidad de desarrollar un buen producto. Ellos nunca deben intentar realizar una excusa para un error que crearon al culpar a un probador de no encontrarlo.

Otros consejos

Es la pregunta # 10 en la prueba de Joel:

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

En caso de contar todo lo que necesita saber. :)

Es mejor tener probadores en el equipo. Nosotros, los desarrolladores no podemos obtener tanto de defectos cuando se prueba, pero si se prueba con un probador entonces atrapa tantos defectos antes de liberar los defectos.

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

Los probadores son necesarios en ambos casos. Incluso si su desarrollo es impulsado prueba, creo que el papel del probador a menudo se centra en los requisitos externos del proyecto - no entregar el proyecto al producto esperado que cumpla con los requisitos?

Me parece que en grandes entornos corporativos que a menudo tienen una mina de oro de buenos probadores en los centros de llamadas o los que hacen el servicio al cliente. A menudo tienen un conocimiento muy sólido de los procesos de negocio, problemas y necesidades.

En este contexto hemos menudo permiten a los probadores trabajan con la construcción de casos de prueba de la vida real en los sistemas de back-end también, a veces se aplican incluso utilizado por las pruebas de integración que los desarrolladores escriben. Hemos tenido un gran éxito con dejar que los desarrolladores piden los probadores de datos / escenarios de prueba para la prueba automatizada basada en CI.

puede esperar que otros papeles para participar en las pruebas. Realmente creo que todo el mundo debe centrarse en la calidad y pruebas, pero desafortunadamente todos no puede ser responsable.

A partir de cierto tamaño en, absolutamente (yo diría que unos 10 desarrolladores).
Los probadores también podían hacer construir y trabajo de integración. En grupos más pequeños desarrolladores tienen que probar, porque no hay nadie más para hacerlo.
Buena pregunta. Tal vez algunos de sus desarrolladores como prueba.
No, sobre todo cuando el proyecto se hace más grande.

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

a gran escala, sí. Sin embargo, hay muchos métodos y tipos de pruebas diferentes. Estos incluyen usuario, la regresión, la unidad, y las pruebas de integración. Tratar de automatizar tanto como sea posible. Echa un vistazo a selenio (IDE), Molydbenum, Escenarios de uso y desarrollo ágil.
Un desarrollador o diseñador debe decidir si han cumplido con los criterios de aceptación, pero si se ponen a prueba su propia obra, entonces es algo así como la escritura de su propio examen antes de sentarse para ello. Los desarrolladores de prueba el trabajo de otro desarrollador no es mucho mejor en mi opinión.
No sé
Creo que un jefe de proyecto no tendrá tiempo para pruebas rigurosas. Es realmente el trabajo de un probador dedicado que sabe que es diligente y puede interactuar con el director del proyecto.

¿Son necesarios los probadores de producto (o proyecto de desarrollo a gran escala)?

En caso de que los probadores sólo lo prueba? De se puede esperar de una   desarrollador o diseñador gráfico de   prueba de la mitad de la semana?

¿Dónde se puede encontrar buenos probadores (supongo que no es un título de   las pruebas de desarrollo de software)?

¿Es la tarea del director del proyecto de teamlead técnica para poner a prueba   todo?

1 - en el desarrollo de productos cuando se tiene> 10 clientes: claro que sí. ESENCIAL. Misma en un proyecto a gran escala. Usted puede escatimar cuando eres pequeño, pero una vez que llegue a un cierto tamaño, el dolor de la actualización (por ejemplo) 100 clientes en todo el mundo es mayor que el salario de incluso un probador.

2 - sí, aunque existe un cierto solapamiento en el trabajo de apoyo también. Desarrollador debe hacer la prueba básica - Cómo funciona? - pero le toca a los probadores para hacer el,, raro-caso de uso de pruebas de tipo exhaustiva de extremo a extremo. Es un desperdicio de un tiempo a los desarrolladores a hacer eso, creo. Los diseñadores gráficos no deben probar -. bien, prueba de usuario, espero, pero eso es incluso antes de que llegue a los desarrolladores

3 - algunos desarrolladores hacen buenos probadores. algunas personas de apoyo hacen buenos probadores. aparte de eso - acaba de encontrar al azar. anunciar. etc no hay grados, pero alguien que es pedante, pueden pegarse por sí mismos, y sabe más acerca de cómo el medio ambiente extremo que mantiene juntos como cada línea de código funciona sería bueno.

4 - no. el PM tiene el proyecto juntos, y coordina la probadores, desarrolladores etc., el plomo tecnología debería ser, ya sabes, lo que lleva el equipo técnico. No prueba.

Obviamente, hay fugas entre los roles. A veces, todo el mundo debería hacer algunas pruebas, pero esto es más para obtener la máxima cobertura justo antes de RTM, no en el día a día o semana a la semana.

Las pruebas unitarias son un gran comienzo, ya que capturan los errores de lógica, pero no se puede esperar que coger las interacciones del usuario locos, o problemas que sólo aparece después de su aplicación ha estado funcionando durante 72 horas + - pruebas de unidad se NUNCA NUNCA atrapar estos. Su cliente, pero entonces no tendrá clientes por mucho tiempo:)

Por cierto, me he "estado allí, hecho eso". He probado en los clientes y tenía probadores adecuados en las diferentes etapas de puesta en marcha (VRS comprados por una compañía grande) del mismo producto. El producto era mucho más sólida una vez tuvimos probadores, y los clientes eran más felices también (además, es difícil poner en marcha un pequeño parche crítico para 400 sitios en todo el mundo - atraparlo antes de que los barcos)

Nunca subestime el valor de especialistas.

La mayoría de las personas que no son probadores, en particular los desarrolladores, no gozan de la prueba y no lo hará así. Si le preguntas a un diseñador gráfico o un desarrollador que pasar la mitad de su tiempo de prueba, en el mejor de usted perderá el 50% de la producción de un buen diseñador / desarrollador y obtener 50% de un pobre, probador caro. En el peor, los perderá por completo, porque van a encontrar un lugar mejor para trabajar.

En el caso de los desarrolladores, que son por lo general demasiado cerca del código para poder probar de forma objetiva. Van a hacer suposiciones sobre la base de su conocimiento de los componentes internos. Un desarrollador de poner a prueba su propio código es especialmente mala.

El director del proyecto debe ser responsable de asegurar que todo lo que se pone a prueba pero no debería estar haciendo ellos mismos. Ellos no tendrán suficiente tiempo o la experiencia necesaria.

Anteriormente trabajé para una empresa de consultoría. No teníamos probadores especializadas y en su lugar utilizar cualquier consultores eran actualmente sin un proyecto. Ninguno de ellos tenía experiencia en pruebas y como resultado la mayoría de ellos no eran muy buenos probadores. Nos gustaría recibir informes de errores como "el sistema ya no funciona" o mi favorito personal: una captura de pantalla de una aplicación que muestra cómo era lenta (una captura de pantalla de la aplicación que se ejecuta rápidamente, no se habría visto nada diferente). Ellos abusar del sistema de seguimiento de errores también (o de derivación completamente a favor de sus propios spreadshhets Excel hecha en casa). Fue una pesadilla.

Creo que lo que los probadores (CAN) traer a la mesa es un nuevo juego de los ojos de un producto. He descubierto que tengo tendencia a seguir el camino feliz cuando se ejecuta el software, ya sea a través de la interacción interfaz de usuario o la utilización de clases que he escrito. Cuando se sabe cómo se supone que algo funcione, es poco natural de hacer las cosas de manera equivocada, a ejercer el producto de una manera que no se pretendía o para probar cosas en un orden que nadie que conozca cómo funciona haría hacer.

Mis respuestas a sus preguntas son las siguientes:

Sí. La prueba es una necesidad y por lo tanto se necesita algún tipo de probador. Por lo general, las pruebas unitarias se captura una gran cantidad de los problemas de bajo nivel, pero las pruebas de usabilidad y las pruebas 'requisitos' determinar si cumple con las demandas en el folleto en papel satinado. Si usted afirma que su software hace 'X', entonces parte del trabajo del probador es para asegurarse de que lo que realmente hace 'X'. Hemos tenido probador de descubrir algunos problemas en plataformas que no uso normalmente. Es bueno para encontrar a los problemas a tiempo.
Tal vez. Nos cruzada probar nuestros productos de la casa, pero tienen un grupo de ensayo por separado también. Tenemos la tendencia a (in-house) encuentran la mayor parte de los problemas, pero los probadores de tiempo completo encontrar a veces las cosas que nos gustaría probablemente nunca hemos encontrado. Si se divide el tiempo entre el desarrollo y las pruebas, tiene que quedar claro que la prueba no es una idea de último momento. Si estoy trabajando en mi sobrecargado en desarrollo y tienen dificultades para pasar el tiempo necesario probar sus productos, entonces yo no voy a ser tan eficaces como probador. La gestión del tiempo es esencial si se va a tener desarrolladores doblando como probadores.
No está seguro. Algunos grupos (IV y V grupos, por ejemplo) en una organización no solamente la prueba. Sospecho que hay un número de personas por ahí que no tienen ningún negocio o deseen software de escritura, pero puede poner a prueba a los diablos de un producto. Algunos de nuestros mejores probadores en mi último trabajo no escribir ningún código en absoluto.
dependerá de su proyecto, pero yo diría que no, por lo general. La responsabilidad es algo que se extendió a cabo en mi tienda. El plomo no es responsable de todas las pruebas. Todos somos responsables.

En cualquier caso, es mi granito de arena.

Todo el mundo va a decir se requieren probadores, y esa es la respuesta políticamente correcta. Pero probadores son sólo una de las muchas herramientas disponibles en la caja de herramientas de control de calidad. Puede enviar el software perfectamente bien sin probadores. Por ejemplo, me pregunto si Stackoverflow tiene un departamento de prueba?

Un probador medida la calidad del código de sus desarrolladores producen. Sin embargo, la disponibilidad de medidas de calidad no hace nada para mejorar la calidad.

Los probadores no vienen gratis. Vas a tener que cambiar el desarrollo para entregar al equipo de pruebas en lugar del cliente. Esto puede conducir a una falta de conexión entre los clientes y los desarrolladores: los probadores pueden encontrar errores que los clientes no podían importan y pasar por alto los errores que son muy importantes para el cliente. Además, usted tiene que crear y mantener un entorno de pruebas por separado.

Los buenos probadores le ayudarán a desarrollar mejor, y sobre todo liberar más suavemente. Sin embargo, su kilometraje puede variar.

P.S. En una gran empresa probadores son esenciales: permiten pasar la culpa. Decir provoca un error por el daño al cliente -> ejecutivo es molesto. En este punto, el Ejecutivo está dispuesto a hacer cosas desagradables a su equipo. Con un equipo de prueba, puede echar la culpa al equipo de pruebas, que echarle la culpa a usted. Un compromiso lanza:. Introduces nuevos procesos, el equipo de pruebas contrata más probadores, y el ejecutivo dice que está personalmente mejorado cosas

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow